-- [ Picked text/plain from multipart/alternative ] Not having a method of tracing a VCollide to the world really limits what we can do with prediction, especially when talking about vehicles. Since VPhysics is essentially unpredictable in the networking sense, we can't run the collision code client-side (unless we limit ourselves to an AABB, which really won't work for proned players, cars, trucks, planes etc..). The ability to sweep a collidable and implement our own physics in game code would fix this... There is a SweepCollideable function in the physics interface, but it is stubbed.
We've found a happy medium, which is to have predictable simulation code much like the players and having a Physics Shadow follow the object server side. This works for flying vehicles (since most of the time they don't hit stuff). Any mod working with ground vehicles has a huge problem though, since they're always colliding. Not predicting vehicles is an option, but expect your player base to complain about laggy controls... On 9/29/07, John Sheu <[EMAIL PROTECTED]> wrote: > > Jay Stelly wrote: > > But it's not a framework that lets you sweep a > > vcollide against the entire scene - which is probably what you want (and > > what John wanted as I recall). In fact it's pretty straightforward to > > extend vphysics to do this, but the current implementation would be > > incredibly slow if you used any displacements at all because it would > > have to consider each triangle separately. > > > > That would be really nice. Or actually, would have been really nice. > And kinda overdue, since the SDK-side framework is there > > d) "physics tests only happen once per frame in static positions" - not > > exactly sure what you are trying to say here but it sounds incorrect to > > me. The movement in vphysics though not described as sweeps/traces is > > still computed as continuous motion. It's not like all of the objects > > move and then do a static test to see if they are inside another object > > or have passed through another object. The collisions are computed > > continuously along the path of translation/rotation. It may still be a > > pain for your player movement strategy, but it certainly isn't evaluated > > in "static positions" if that helps to understand it better. > > > > I realize that VPhysics fundamentally does continuous collisions. I've > played around some with the Bullet physics library some, and an idea of > how things work. (Whether this is a correct "idea" or not is another > question.) What I mean was that from game code, you cannot evaluate > collisions on a collideable from more than one position in a given > frame, or move/sweep them during the frame for movement tests. > > -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
