Physics Simulation Forum

I am new to working with Bullet and am trying to verify whether or not it is possible to do the following:
1) Capture the complete state of a train-like sequence of rigid body objects in memory.
2) After allowing the physics to step forward for some duration, return the simulation to the stored state.

I read through the forums and learned that complete determinism in Bullet is planned for version 3.0.

I am wondering if the non-deterministic behavior I am observing is due to absence of the work-in-progress features,
or whether I am simply doing something wrong, like not storing all of the correct attributes to capture the state.

The objects whose state I want to store are a series wheeled vehicle rigid-body objects connected by btHingeConstraints, like a train.

The following pseudo code the attributes I currently save as the state of the train:

Save:
State* state = new State()
// breaking, engine, steering apply only to first train engine, storing them outside of loop
state->SetBreakingForce(m_breakingForce);
state->SetEngineForce(m_engineForce);
state->SetVehicleSteering(m_vehicleSteering);
foreach body in train:
save body->getWorldTransform();
save body->getLinearVelocity();
save body->getAngularVelocity();

I tried 2 approaches for restoring that state:
First Case: I remove the train, and add a new train with the stored state value.
Second Case: I apply the stored state values directly to the existing train.

In both cases, it appears I neglected to store or reset some important force.
It is more apparent in the second case, but still easy to spot in the first case too.

Any suggestions on what I may be missing?
Or whether this might be related to something else?

Thank you for any ideas!

-Brian

After seeing suggestions in a related post, I looked closer and found I was leaving out several things.
After using code like what is below for each segment of the train, I believe I have the state saved/restored as completely as possible for the current Bullet version with the post-restore variations being due to this issue http://code.google.com/p/bullet/issues/detail?id=519.