So I have looked around for a long time about networking.

Something that is said that when a prediction error happens let the server set the state and replay all the commands to get back to the current prediction. Though were this gets confusing as that bullet for instance has to have the entire step forward at the same time. Which means you would have to rewind the entire world and go through everything again. Which seems very annoying, but wouldn't it also be expensive performance wise?

Any information of ideas on this would be greatly appreciated.

extra notes

when a player becomes dead there is no need to synchronize the body yet once again rewinding to playback a player physics will muck up the ragdoll.

Only way I can see around this is having to physics worlds running and only rewinding one that has the local player and player owned stuff(guided missile or something). though both worlds would need to be filled with map objects and other player objects.

Yes, there is extra cost to re-playing physics.

Sometimes, you can store the state of each player at each step in the past for some amount of replay log, and only replay the entities that got invalidated. If entities interact (collide, weapon hit, etc,) then those sets of entities need to be rolled forward from the time when they interacted.

Often, physics simulation isn't particularly expensive, so the cost to doing this is acceptable, especially for fast-paced shooters with less than a hundred players per level.

Once the player count goes up, it starts becoming more important to hide latency in other ways, either by simulating commands when-received, or forcing players to lead shots, or something else.

My message was not that clear as it was really late at the time.

The only way I can see how to rewind one entity and replay was to have a separate world for each entity and copy a static copy of each worlds dynamic one to each other. or when a prediction conflict occurs create a new world copy everything from the other world as static then recalculate the entities physics stuff.

There is one thing I just noticed for bullet physics engine is http://bulletphysics.org/mediawiki-1.5.8/index.php/Activation_States it has one that is DISABLE_SIMULATION. I'm hoping I can just set all other objects as DISABLE_SIMULATION and then apply an old state to an the object and just step forward 200ms of calculations for that one player and then reactivate all the objects and they keep their velocities. I assume there is a feature like this for ODE?

Is this what people do? Any help or ideas is much appreciated

When resimulating using Bullet, I suspend the dynamics of any object which isn't involved in the simulation. At the moment, that is technically all but the player, but I should address that

I see; you're asking about limitations in a particular physics engine (Bullet.)

In general, if you want to support partial re-play with cascading correction in case of interaction, you have to put that into the physics engine; most physics engines don't have that built-in.

hplus0603, Well I have bullet physics engine in my mind I'm really talking of any open source physics engines like ode or what ever.
Which is what seems to be confusing me since most articles about replaying movement on prediction error can just rewind that one object and step it through time. A lot of the time these people have articles about basic theory about creating a physics engine. Like gafferongames.com

I thought I would avoid making my own physics engine.

I'm not really sure what you mean by cascading correction. In my mind I had a picture of everything else except for the replayed object being frozen and these frozen object interacts like they are solid and static with the object being replayed. Yet after completing the error correction all frozen objects still retain and velocity or spin that they had before the prediction error.

Though cascading corrections sounds like something much more advanced than what I was thinking.

Maybe the answer is so obvious that no one ever talks about it and I'm just so dumb.

most articles about replaying movement on prediction error can just rewind that one object and step it through time

With ODE, you can do that too. Note that collision and simulation are entirely separate concepts. You can create a separate body for an actor, and a separate dWorld to keep that body in, and just simulate that body. You can collide that body's colliders against your static world collision space and generate contact joints only in that "single-body" world.
The main question is: what parameters do you use to create that body? You need a log of the last X ticks for each entity that may rewind.
And, if you have that log, you could just as well use the regular world, forcing all entities except the rewound one to take on their state as of the given time step being re-simulated.

I'm not really sure what you mean by cascading correction.

If I rewind the world, and change whether your character hit a wall or not, then that wall may collapse where it previously didn't, and the player standing on top of that wall will fall down versus not, and the sniper shot she was taking will hit or miss, which affects another character ...
You can think of causality as a graph, and each time two different actors that are non-computer-controlled interact, that's nodes in the graph. Some simulations don't actually change the connectivity between the nodes (or the existence of nodes), whereas others do.

If all you do is re-simulate the one player with the rest of the world locked, then you don't have that problem. You will instead have problems of time travel: If the portcullis was open when I first passed through it, but I then get re-simulated when the portcullis has closed, I will suddenly not have moved through it and instead gotten blocked. As a player, I may disagree with this chain of events. But then, hopefully corrections are rare, and statistically speaking happens during less important sequences (because those are the most frequent -- just running across open ground or standing still.)

Maybe the answer is so obvious that no one ever talks about it and I'm just so dumb.

The reason nobody talks about it is that there's maybe a few hundred people total in the world, out of seven billion, who have done it successfully over a network. It's a small clique, and most of us have real jobs and don't particularly need to go to a forum to talk about it :-)

hplus0603, that makes a lot of sense. It was just in my mind all those methods seemed excessive for moving one object. Though like you said physics is not the most expensive part of a game engine and corrections should be infrequent.

I had a suspicion that was what cascading correction was. I suppose it might be worth rewinding other objects as well if you are stepping through for everything to miss those edge cases like a closed door.

That makes sense why no forums really talk about it. Also it was pretty obvious and I am pretty dumb ;)

Also it was pretty obvious and I am pretty dumb ;)

If it's dumb to try things you haven't done before, then every inventor in history has been dumb. I prefer the term "foolhardy" :-)
If you end up building a game where multiple players can have a great time over a network, that's pretty clear proof you're not dumb in the end.