-- [ Picked text/plain from multipart/alternative ] This is the reason I made my vehicles purely out of SOLID_BBOX. I was able to reduce cpu load from physics by ALOT and was able to have great prediction. On top of that, I controled my movements with 100% precision. Only downside was I had to fake my Angles to orient to the ground correctly, and fake the z Origin to have the vehicle lay flat on the ground instead of floating, this was done all clientside though, so no extra load on the servers.
Overall, I'm satisfied to say people will be happy with the vehicles in our mod. It only works out great for my mod because realism rules don't apply to the gameplay design. For realistic vehicles it would not work at all due to the bounding box not being able to rotate, so you'll have square cars! I surely hope we get either better precision control over physics or bring in SOLID_OBB for all us hardcore coders to have fun with. On 1/12/07, John Sheu <[EMAIL PROTECTED]> wrote: > > I've come to the conclusion, finally, that the Source engine in its > present > form does not do multiplayer vehicles well. > > The issue is this: for a smooth experience, we need prediction. To do > prediction, we need to be able to simulate a vehicle forward multiple > timesteps relative to the environment as a whole. For example, when the > client copies an authoritative position for some time in the past, the > client > must be able to simulate the object forward from that position into the > present time, while not affecting the world at large. Similarly, when the > server receives a collection of user commands, the server must be able to > simulate the object forward as many timesteps as there are commands. > > The player code is able to do this, as the extent of the simulation in the > player code consists of some velocity integration combined with BBOX > traces > nand a whole set of heuristics for game-world permissibility; as the > engine > exposes facilities to do BBOX traces quite well, simulating multiple > commands > in a client/server frame is no problem. The shadow controller tied to the > player, which interacts with the VPhysics world, does not completely march > in > lockstep with the player, but lags (at most) close behind. > > For vehicles, there is no analogous procedure. To simulate vehicles in > game > code, one would be required to use traces of collision hulls at arbitrary > angles (as collision models for vehicles generally cannot be simplified to > the BBOX that serves the player rather well). Unfortunately, no such > facility exists. If one were to attempt to do this in VPhysics, one could > use a motion controller, but the motion controller can only integrate a > single command per world timestep; this does not fit the requirements for > client prediction, or multi-command server simulation. > > So the solution that I see is that a facility be opened in the VPhysics > interface that allows the simulation of any one arbitrary IPhysicsObject > (and > any associated shadow controllers/motion controllers) by one timestep, > leaving the rest of the world that does not interact with this object > alone. > In essence, putting all objects except one to sleep, then simulating the > world by one timestep, but done more efficiently. As fundamentally, a > physics engine must simulate its objects serially, I believe that this is > possible. I don't know Havok, though, so I won't know if that's actually > true. I would, however, respectfully ask that VALVe look into the > possibility. > > As far as I know, in the land of predicted multiplayer Source vehicles, > Krenzo > went with client-side authoritative vehicle physics for Empiresmod (with > some > server-side checking). HLRally gave up. I'll see what Eternal-Silence > can > come up with. > > -John Sheu > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
