keeping server and client in sync when weapons use energy
by kcpdad · in Torque Game Engine · 07/31/2010 (2:30 pm) · 5 replies
In stock TGE 1.5.2 mEnergy is a property of shapebase and considered part of the control object's state, it is calculated as part of the checksum in writePacketData(). It is updated every tick based on a recharge rate. My prototype's primary weapon uses energy as its ammo.
This causes a server control object correction to be sent every time the weapon is fired because mEnergy in ShapeBase is only reduced on the server side. The client is updated by an entire control object update. This is not efficient and causes noticeable lag.
Should I move the client/server sync code from the readPacketData/writePacketData functions to packUpdate/unPackUpdate()? Or something else?
Suggestions appreciated, thanks
This causes a server control object correction to be sent every time the weapon is fired because mEnergy in ShapeBase is only reduced on the server side. The client is updated by an entire control object update. This is not efficient and causes noticeable lag.
Should I move the client/server sync code from the readPacketData/writePacketData functions to packUpdate/unPackUpdate()? Or something else?
Suggestions appreciated, thanks
About the author
Hobbyist working on a tank game when time allows. Play the prototype at => http://www.sytrept.com/60tons/
#2
I'm still getting more calls to readPacketData then I should be getting so it is a matter of tracking down why that is but for now mEnergy does not seem to be the culprit.
08/04/2010 (10:51 am)
Thanks for the suggestion but I switched mEnergy and mRechargeRate from being updated as part of the readPacketData/writePacketData to packUpdate/unpackUpdate and it seems to be working better. I got rid of MountedMask and replaced it with a EnergyMask. Also changed setEnergyLevel() to set EnergyMask only if mEnergy was actually changed on a call to it.I'm still getting more calls to readPacketData then I should be getting so it is a matter of tracking down why that is but for now mEnergy does not seem to be the culprit.
#3
Alternatively, add a "useEnergy" value to the state system itself, so that any state transition can consume energy if configured correctly in the datablock.
08/05/2010 (7:11 pm)
Optimally you could have the ShapeImage state system handle this internally. Introduce a flag to the Image like "consumesEnergy" and a value such as "energyPerShot," then draw from mEnergy anytime the fire state triggers. Since this happens on the client and server, there should be no need to rely on net updates to stay in sync.Alternatively, add a "useEnergy" value to the state system itself, so that any state transition can consume energy if configured correctly in the datablock.
#4
08/05/2010 (7:31 pm)
The stock energy usage behavior is actually an energy used over time method and not per shot -- just like how the Elf & Repair gun from Tribes functioned. Henry's suggestion is a great idea and could be accomplished through script as part of the Image state system and it's script callbacks.
#5
I'll try your suggestion, if it works do you think it is worthy of a resource? thanks again
08/06/2010 (11:04 am)
Thanks Henry and Michael. I did notice that the energy was drained over time resulting in multiple packet updates(packUpdate). My change was a definite improvement over resetting the control object state but if I can avoid any network updates then great! I'll try your suggestion, if it works do you think it is worthy of a resource? thanks again
Torque 3D Owner Thomas
mercatronics