[chriscalef]

Paul, you're probably all over this aspect of it but if not, make sure you take a good hard look at whether you really need to network all the physics objects you're trying to network, ie are they all gameplay critical and interactive between different players? Because if there's anything that can be assumed to be only providing eye candy for one client at a time, you can simulate it and render it on that client and remove it from the network bandwidth. You probably already knew that though.

[PaulWeston]

Thanks, yes I had read that before and it makes sense... In some cases I do in fact want the physics effects to be networked, so that one player could crash into a wall which would break into blocks, and those would get in the way of the following player. I tried this in my PhysX game with mixed results, it would work on a low level, but too many moving objects and one client would crap out.

I never actually did figure out how to exclude certain things, is that something that can be done in script when a physics object is loaded? During gameplay I have code that creates new physics shapes in real time, so that you have a tower or wall of TSStatic blocks that convert on-the-fly to physics objects when they are hit with a projectile. Works great, you can build a tsstatic prefab house of blocks and then explode it with a grenade

But I would love to know how to control which objects get networked, is that easy enough to do?

[chriscalef]

By default you're running a physics sim on the server as well as on each client, so if you want objects to run on the client and not get networked you would theoretically just say "simType=0" in the physicsShape datablock. I say "theoretically" because this actually hasn't worked for me, it seems they don't perform at all unless they are simType=2, which is client & server.

For my current ragdoll build, I ended up running my shapes as client+server, but put all my bodyparts on the client, and only put a placeholder physics object on the server - I haven't decided yet what to do with the server side, will probably change that to a player controller or a capsule and use it for collision detection.

Re: your crashing into a wall scenario, though, would it not work just as well to pass the event (driver crashed into wall at location xyz) and then spawn the actual physics blocks separately on each client? The game experience would be the same, the only thing different is each block wouldn't be exactly where it is on everybody else's machine. The lead driver probably won't even see the blocks because he's already speeding away though, so it shouldn't result in any noticeable artifacts.

If the players were actively throwing blocks at each other or something like that, then you would definitely have to network them, but for the case you describe it doesn't sound necessary.

[PaulWeston]

That's a great thought... we actually do have the ability to launch physics blocks at each other with a block firing gun, and that already works networked without much issue, so I would keep the status quo foe that.

However, I see great potential in doing client side only physics for when the vehicles and block walls are involved, as well as other times when I have physics blocks raining from the sky...

Is it really that simple? If the physics blocks are client side, how does the server handle collision and damage detection when a client hits a physics block in those cases?

[chriscalef]

Ah, yeah, it's never that easy. . You'd probably have to write your own clientside damage logic based on physx collisions, which would be less hack proof, but...

[Azaezel]

before I completely and totally forget (yet again):

https://github.com/Azaezel/Torque3D/tre ... shapeReorg cleaner version for the pending physics refactor.