This wiki is archived and useful information is being migrated to the main bzflag.org website

Editing Server Updated Shots

Jump to: navigation, search

Warning: The database has been locked for maintenance, so you will not be able to save your edits right now. You may wish to copy and paste your text into a text file and save it for later.

The administrator who locked it offered this explanation: Archived wiki

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 6: Line 6:
  
 
==Server Shot State==
 
==Server Shot State==
To do this, we need the server to have an accurate/authoritative representation of the shots in the game. We need to move the shot strategies over from the client into libGame so they can be tracked by both the players and the server. Shots are '''time stamped''' with a server clock so syncing the states should not be too hard.
+
To do any of this we need the server to have an accurate picture of the shots in the game. We need to move the shot strategies over into libGame so they can be tracked by both the players and the server. Shots are Time Stamped with a server clock so syncing the states should not be too hard.
  
It would also be up to the server to send out endshots to all clients. The game client should never send an actual endshot.
+
==GM Update Changes==
 +
The MsgGMUpdate should be changed to only send out the newly targeted player. This should happen after a PlayerUpdateMessage, so the server has the most accurate state for the player. If the lock-on change is valid ( verified via the server DR state that should now match the client DR state ) the server will send out Shot Updates for the GM shot to all players, including the shooter.
  
 
==Generic Shot Updates==
 
==Generic Shot Updates==
A new [[MsgShotUpdate]] will be created that can send a new time stamp, position, vector, and lifetime for any shot. Any client that receives this message needs to find the shot, delete the old shot path, create a new shot path/strat with the starting position, vectors, and times, then plot the shot position forward to the current server time. This may make shots "pop" as they update if there is a discrepancy, but all states will be valid. This prevents clients from having to provide GM shot updates, and lets the server do non standard shot dynamics such as gravity well, and enforcing shot ends in a predictive manner. Shot updates should be exposed to the [[BZFS_API]]
+
A new MsgShotUpdate should be created that can send a new time stamp, position, vector, and lifetime for any shot. Any client that receives this message needs to find the shot, delete the old shot path, create a new shot path/strat with the starting position, vectors, and times, then plot the shot position forward to the current server time. This may make shots "pop" as they update if there is a discrepancy, but all states will be valid. This prevents clients from providing invalid GM shot updates, and lets the server do non standard shot dynamics such as gravity well, and enforcing shot ends in a predictive manner. Shot updates should be exposed to the API.
  
==Guided Missile Update Changes==
+
===Shot ID===
The [[MsgGMUpdate]] will be removed. A new message 'MsgLockon' will be added. This message will simply tell the server who the player wishes to lock on to, and notify locked players that they are locked on to. The shot updates will come from the server with a generic [[MsgShotUpdate]].
+
Shot IDs should be separate from the slot. The client should take all newly fired shots and assign them a temporary shot ID until it gets the shot back from the server. At this time it would replace the shot ID with a valid server ID to be used with shot updates at a later date. The local client should send it's temporary shot ID when sending a new MsgShotBegin and be passed that local ID back in the verification message. When the server sends the shot back to the local player, it should recompute the shot path from the new data as if it was a remote path, as the server may have modified it. All local shots can go into one big list on the client, as they will have unique IDs.
  
==Reload Slot From the server==
+
[[Category:TODO]]
The reload shot slots will be made to be set by the server on a per player basis using a new [[MsgShotAmmo]] message. This message will tell each player how many shot slots they have and what there reload times are. This will be sent out on each flag update and spawn. It will be exposed to the API.
+
 
+
==Shot ID==
+
Shot IDs should be separate from the slot.  The client should take all newly fired shots and assign them a temporary shot ID until it gets the shot back from the server. At this time it would replace the shot ID with a valid server ID to be used with shot updates at a later date. The local client should send it's temporary shot ID when sending a new MsgShotBegin and be passed that local ID back in the verification message. When the server sends the shot back to the local player, it should recompute the shot path from the new data as if it was a remote path, as the server may have modified it. All local shots can go into one big list on the client, as they will have unique IDs.
+
===Parted Players===
+
Players that part will have there shots asigned to the server player, and the shots will become world weapons.
+
 
+
==GM Behavior==
+
A clarification of the GM behavior is as follows:
+
*Having The GM flag confers 2 linked abilities to a tank
+
**The ability to generate GM type shots
+
**The ability to set a lock on target.
+
*All live GM shots in the world will always track to the current lock on target for the player they belong to. This behavior is regardless of the target set when a GM is fired.
+
*A tank can only lock onto a single target at a time. When a new lock is set, it overrides all previous locks.
+
*When a tank has no lock on target GMs are unguided and will fly along there last vector.
+
*When the flag is dropped ( ether manually, or by death) The tank looses the ability to set a lock target.
+
*When a tank dies the current lock on target is cleared for all live GMS, and shots will be unguided.
+
===Changes from 2.0.x===
+
The only real change this makes is that the last shot fired from a shot limited GM unable to acquire a target after launch. If the shot is launched locked, it will track.
+

Please note that all contributions to BZFlagWiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see BZFlagWiki:Copyrights for details). Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel | Editing help (opens in new window)

Template used on this page: