[hlcoders] Multiplayer Vehicles
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
Re: [hlcoders] Multiplayer Vehicles
-- [ 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
RE: [hlcoders] Linux DS Build problem
And found the bug. FYI in the Makefile you shouldn't be referencing tier0_i486.so and vstdlib_i486.so by $(GAME_DIR)/bin. As these symbolic links are made in the Makefile when you do a 'make mod' it will suffice to have it set to just 'tier0_i486.so' and 'vstdlib_i486.so'. If you do a 'ldd' on the server_i486.so file and you had $(GAME_DIR)/bin and you have $(GAME_DIR) set to ~/srcds_l (which is how most people have the Linux Dedicated Server setup) there won't be any issues as it will lookup the .so's fine. However, if you have it set to something else (as I did) that differed from the next machines setup it will cause weird crashes and stack traces. Mirroring the install directories and .so's to the way the build machine had it will solve this issue. But as stated, your best bet is to have tier0_i486.so and vstdlib_i486.so set with no path as then LD_LIBRARY_PATH will be able to look them up as it should. If that doesn't make any sense, lemme know and I'll do my best to explain. It's been a long night _ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Everett Sent: Wednesday, January 10, 2007 9:35 PM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] Linux DS Build problem Woops, wrong call stack (and some additional info I neglected to add in). I've compiled the mod on linux and it runs great; however, running it on FreeBSD causes the segfault. Querying gdb for a stack trace results in no symbols loading. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Everett Sent: Wednesday, January 10, 2007 8:09 PM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] Linux DS Build problem Just tacking onto this thread... compiling my mod on linux and attempting to run it causes a seg fault. When attaching GDB and doing a stack trace I get the following: #0 0x in ?? () #1 0x02bf94b3 in CModAppSystemGroup::Create () from bin/engine_i686.so #2 0x02cfaeaf in CAppSystemGroup::Run () from bin/engine_i686.so #3 0x02bf9e1f in CDedicatedServerAPI::ModInit () from bin/engine_i686.so #4 0x0028328a in CDedicatedAppSystemGroup::Main () from bin/dedicated_i686.so #5 0x002b0dc3 in CAppSystemGroup::Run () from bin/dedicated_i686.so #6 0x002b0dc3 in CAppSystemGroup::Run () from bin/dedicated_i686.so #7 0x00283668 in main () from bin/dedicated_i686.so #8 0x0804909e in main () Any clues? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of LDuke Sent: Sunday, January 07, 2007 8:35 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Linux DS Build problem -- [ Picked text/plain from multipart/alternative ] I downloaded one of the fedora images from http://www.thoughtpolice.co.uk/vmware/ and used yum to install a couple other items I needed. Was really quick and painless. On 1/7/07, Sylvain Rochette [EMAIL PROTECTED] wrote: This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] The idea is good, the only problem is my image is 20GB, so its a little to much. But i can show some link about tutorial how to setup it if poeples are interested. First you need Linux Slackware 11! Download the dvd image (3 GB) http://www.slackware.com/getslack/torrents.php http://www.slackware.com/torrents/slackware-11.0-install-dvd.torrent I used bittorrent, the 3 GB taked 3-4 hours to get Installing Slackware 11 over VMWare (you need VMWare) http://howtoforge.org/slackware11_vmware_windows_xp Then you need to install VMWare Tools to speedup the graphic and mouse driver http://www.vmware.com/support/ws4/doc/new_guest_tools_ws.html but read this first http://www.linuxforums.org/forum/slackware-linux-help/21451-vmware-install-r c0-d-rc6-d-problem.html Installing srcds_l http://forums.srcds.com/viewtopic/1139 The only remaining thing is to install Xerces http://xml.apache.org/xerces-c/download.cgi Before executing the makefile you need to mount a drive over source sdk where the real source is using samba and add env var mount -t smbfs -o username=xxx,password=xxx //xp_computer_name/shared_network_drive_on_src /mnt export LD_LIBRARY_PATH=.:/bin:./bin ldconfig So what i have done is i have added another section in the makefile that do the job for you. At the makefile end after the check: ... add config: and add the 3 lines (mount, export, ldconfig) Before you compile the mod, just call make config then make You also need to configurate your linux makefile using the correct path With this linux version (Slackware11) GCC are already fine, so you dont need to worry about the version to use. And over windows XP its very fast. Regards - Original Message - From: Benjamin Davison [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Sunday, January 07, 2007 9:28 AM Subject: Re: [hlcoders] Linux DS Build problem -- [ Picked text/plain from multipart/alternative ]
Re: [hlcoders] Multiplayer Vehicles
I remember Valve said Havok doesn't want their code opened in the SDK at all, so I doubt Valve wants to start opening anything up in the VPhysics interface to get the functionality you want. I chose client-side vehicles because it's the fastest solution. You just move the vehicle code client-side, add some checks on the server, and you're done. If you really want client-side prediction of vehicles, you could code your own physics. That's what I did for aircraft. It's not as hard as you would think, but that's time that could be spent elsewhere. The bigger disadvantage is that the load still exists on the server. Once you start running out of cpu cycles with higher player counts, you'll start thinking about moving stuff to the client and appreciate client-side vehicles. What caused you to bring this topic up? Are you redoing your spacecraft movement? I thought you had prediction, albeit not a very elegant solution programmatically, but if it's not broken, why fix it? John Sheu wrote: I've come to the conclusion, finally, that the Source engine in its present form does not do multiplayer vehicles well. ... 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
Re: [hlcoders] Multiplayer Vehicles
-- [ Picked text/plain from multipart/alternative ] We are attempting to rewrite our prediction code in order to make collisions less crazy. We might just drop the idea at this point. As for custom physics, this is the implementation we currently have, however there is no way to trace a collideable at arbitrary angles, so its not possible to get accurate collisions without using VPhysics. So while we can write our own fully custom physics, we can't write any sort of predictable collision algorithm without making the space ships bounding boxes. On 1/12/07, Justin Krenz [EMAIL PROTECTED] wrote: I remember Valve said Havok doesn't want their code opened in the SDK at all, so I doubt Valve wants to start opening anything up in the VPhysics interface to get the functionality you want. I chose client-side vehicles because it's the fastest solution. You just move the vehicle code client-side, add some checks on the server, and you're done. If you really want client-side prediction of vehicles, you could code your own physics. That's what I did for aircraft. It's not as hard as you would think, but that's time that could be spent elsewhere. The bigger disadvantage is that the load still exists on the server. Once you start running out of cpu cycles with higher player counts, you'll start thinking about moving stuff to the client and appreciate client-side vehicles. What caused you to bring this topic up? Are you redoing your spacecraft movement? I thought you had prediction, albeit not a very elegant solution programmatically, but if it's not broken, why fix it? John Sheu wrote: I've come to the conclusion, finally, that the Source engine in its present form does not do multiplayer vehicles well. ... 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 -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Multiplayer Vehicles
Does SweepCollideable(...) not support OBB? I know const.h says SOLID_OBB is not implemented, but from what little I played with it, SweepCollideable seemed to correctly orient the entity's bounding box before doing the trace. As far as VPhysics, what about using PhysShouldCollide( IPhysicsObject *pObj0, IPhysicsObject *pObj1 ) to catch physics collisions in the space ship entity to alert you that a collision is taking place and then override the response (return false, halt its velocity, and create opposing reaction force) to make things less crazy? Daniel Menard wrote: -- [ Picked text/plain from multipart/alternative ] We are attempting to rewrite our prediction code in order to make collisions less crazy. We might just drop the idea at this point. As for custom physics, this is the implementation we currently have, however there is no way to trace a collideable at arbitrary angles, so its not possible to get accurate collisions without using VPhysics. So while we can write our own fully custom physics, we can't write any sort of predictable collision algorithm without making the space ships bounding boxes. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Multiplayer Vehicles
I believe someone from Valve mentioned earlier that SweepCollideable() and TraceRay() are currently stub implementations in IPhysicsEnvironment, so they don't do anything meaningful. - Original Message - From: Justin Krenz [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Friday, January 12, 2007 1:34 PM Subject: Re: [hlcoders] Multiplayer Vehicles Does SweepCollideable(...) not support OBB? I know const.h says SOLID_OBB is not implemented, but from what little I played with it, SweepCollideable seemed to correctly orient the entity's bounding box before doing the trace. As far as VPhysics, what about using PhysShouldCollide( IPhysicsObject *pObj0, IPhysicsObject *pObj1 ) to catch physics collisions in the space ship entity to alert you that a collision is taking place and then override the response (return false, halt its velocity, and create opposing reaction force) to make things less crazy? Daniel Menard wrote: -- [ Picked text/plain from multipart/alternative ] We are attempting to rewrite our prediction code in order to make collisions less crazy. We might just drop the idea at this point. As for custom physics, this is the implementation we currently have, however there is no way to trace a collideable at arbitrary angles, so its not possible to get accurate collisions without using VPhysics. So while we can write our own fully custom physics, we can't write any sort of predictable collision algorithm without making the space ships bounding boxes. ___ 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
Re: [hlcoders] Recording demos broken in EP1?
I have the same problem, but my anims (mostly guns) are all courpted the first time i built the mod code - with default settings. Adam --- Nate Nichols [EMAIL PROTECTED] wrote: Hi, On the two machines I've tried it on (one of which is full of my modding stuff and the other which is a clean HL2/HL2:EP1 install), the record command works correctly in Half-Life 2, and munges animations and other things in Episode 1 and my mod. The animations jump all around, NPCs looking at targets are spasmodic, etc. Changing my mod's AppID from 215 to 220 doesn't fix anything. I can record a demo video if it would help. Has anyone else experienced this or have any idea why record/demos in general would break between HL2 and EP1? Thanks and have a nice weekend, Nate ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Nigredo Studios http://www.nigredostudios.com TV dinner still cooling? Check out Tonight's Picks on Yahoo! TV. http://tv.yahoo.com/ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Multiplayer Vehicles
-- [ Picked text/plain from multipart/alternative ] That's interesting Krenzo. I will have to check out how PhysShouldCollide works. If it works alright, it could really help with the prediction. At the very least we could implement something like sv_turbophysics. What may be difficult is getting the point of contact. What do you think of that John? On 1/12/07, Justin Krenz [EMAIL PROTECTED] wrote: Does SweepCollideable(...) not support OBB? I know const.h says SOLID_OBB is not implemented, but from what little I played with it, SweepCollideable seemed to correctly orient the entity's bounding box before doing the trace. As far as VPhysics, what about using PhysShouldCollide( IPhysicsObject *pObj0, IPhysicsObject *pObj1 ) to catch physics collisions in the space ship entity to alert you that a collision is taking place and then override the response (return false, halt its velocity, and create opposing reaction force) to make things less crazy? Daniel Menard wrote: -- [ Picked text/plain from multipart/alternative ] We are attempting to rewrite our prediction code in order to make collisions less crazy. We might just drop the idea at this point. As for custom physics, this is the implementation we currently have, however there is no way to trace a collideable at arbitrary angles, so its not possible to get accurate collisions without using VPhysics. So while we can write our own fully custom physics, we can't write any sort of predictable collision algorithm without making the space ships bounding boxes. ___ 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
Re: [hlcoders] Multiplayer Vehicles
On Friday 12 January 2007 3:34 pm, Justin Krenz wrote: Does SweepCollideable(...) not support OBB? I know const.h says SOLID_OBB is not implemented, but from what little I played with it, SweepCollideable seemed to correctly orient the entity's bounding box before doing the trace. Not sure, but I'm not a fan of BBox collisions. We have this fancy VPhysics doohickey, and so I'd rather get some more accurate collisions out of it. As far as VPhysics, what about using PhysShouldCollide( IPhysicsObject *pObj0, IPhysicsObject *pObj1 ) to catch physics collisions in the space ship entity to alert you that a collision is taking place and then override the response (return false, halt its velocity, and create opposing reaction force) to make things less crazy? I have something similar going on in the codebase as it stands, with an added VPhysicsPreCollision call in the physics code that does some velocity fixups before collisions. Trying to fix it there I think is trying to fix the wrong problem though. Essentially, when you collide, the player is expecting to be banged around a bit. Going crazy on collision is not very distracting. The problem is that since we cannot predict collisions, I have to switch prediction off on the client whenever we come into physics contact, and only switch it on when we come out. There's a jolt as prediction switches off, another as it switches on, and what's in between is rather laggy. If you want a true smooth experience, you're going to have to predict all the time, and that requires more than we currently have in VPhysics. IIRC turbophysics does well for player interactions against VPhysics. It does little for player interactions against CWorld. Unfortunately, the latter is where most of our interactions lie. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
