Server Updated Shots - Revision history

JeffM2501: Remove TODO group, that is what the version planing pages are for

2013-02-10T08:21:38Z

Remove TODO group, that is what the version planing pages are for

← Older revision		Revision as of 08:21, 10 February 2013
Line 36:		Line 36:
	===Changes from 2.0.x===		===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.		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.



	~~[[Category:TODO]]~~

JeffM2501: /* Generic Shot Updates */ I suck

2011-05-10T02:29:40Z

Generic Shot Updates: I suck

← Older revision		Revision as of 02:29, 10 May 2011
Line 11:		Line 11:

	==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 [[~~BFSZ_API~~]].		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]]

	==Guided Missile Update Changes==		==Guided Missile Update Changes==

JeffM2501: /* Generic Shot Updates */ ' ' != '_'

2011-05-10T02:28:48Z

Generic Shot Updates: ' ' != '_'

← Older revision		Revision as of 02:28, 10 May 2011
Line 11:		Line 11:

	==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 [[~~BFSZ API~~]].		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 [[BFSZ_API]].

	==Guided Missile Update Changes==		==Guided Missile Update Changes==

JeffM2501: /* Generic Shot Updates */ BZ_API == BZFS_API

2011-05-10T02:27:59Z

Generic Shot Updates: BZ_API == BZFS_API

← Older revision		Revision as of 02:27, 10 May 2011
Line 11:		Line 11:

	==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 [[~~BZ_API~~]].		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 [[BFSZ API]].

	==Guided Missile Update Changes==		==Guided Missile Update Changes==

JeffM2501: /* GM Behavior */

2008-04-07T17:22:53Z

GM Behavior

← Older revision		Revision as of 17:22, 7 April 2008
Line 34:		Line 34:
	*When the flag is dropped ( ether manually, or by death) The tank looses the ability to set a lock target.		*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.		*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.



	[[Category:TODO]]		[[Category:TODO]]

JeffM2501: /* Shot ID */

2008-04-07T17:14:58Z

Shot ID

← Older revision		Revision as of 17:14, 7 April 2008
Line 21:		Line 21:
	==Shot ID==		==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.		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==		==GM Behavior==

JeffM2501: /* Questions */

2008-04-07T16:59:48Z

Questions

← Older revision		Revision as of 16:59, 7 April 2008
Line 33:		Line 33:
	*When a tank dies the current lock on target is cleared for all live GMS, and shots will be unguided.		*When a tank dies the current lock on target is cleared for all live GMS, and shots will be unguided.

	~~===Questions===~~
	This behavior will cause the last shot of a GM to be unguided. Should we only clear the GM lock on a death? or after the last shot hits? Should GMs be fire and forget where they always just go on the last target? Is that too mean?

	[[Category:TODO]]		[[Category:TODO]]

JeffM2501: /* GM Behavior */

2008-04-07T16:59:09Z

GM Behavior

← Older revision		Revision as of 16:59, 7 April 2008
Line 30:		Line 30:
	*A tank can only lock onto a single target at a time. When a new lock is set, it overrides all previous locks.		*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 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 current lock on target is cleared, and GM shots will be unguided.		*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.

	===Questions===		===Questions===

JeffM2501: /* Generic Shot Updates */

2008-04-07T06:33:09Z

Generic Shot Updates

← Older revision		Revision as of 06:33, 7 April 2008
Line 11:		Line 11:

	==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 ~~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~~ [~~clarify, which API~~].		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 [[BZ_API]].

	==Guided Missile Update Changes==		==Guided Missile Update Changes==

JeffM2501: /* GM Bhavor */

2008-04-07T06:31:56Z

GM Bhavor

← Older revision		Revision as of 06:31, 7 April 2008
Line 22:		Line 22:
	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.		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.

	==GM ~~Bhavor~~==		==GM Behavior==
	A clarification of the GM ~~behavor~~ is as follows:		A clarification of the GM behavior is as follows:
	*Having The GM flag confers 2 linked abilities to a tank		*Having The GM flag confers 2 linked abilities to a tank
	**The ability to generate GM type shots		**The ability to generate GM type shots
	**The ability to set a ~~lockon~~ target.		**The ability to set a lock on target.
	*All live GM shots in the world will always track to the current ~~lockon~~ target for the player they belong to. This ~~behavor~~ is regardless of the target set when ~~the~~ GM is fired.		*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.
	*When a tank has no ~~lockon~~ target GMs are unguided.		*A tank can only lock onto a single target at a time. When a new lock is set, it overrides all previous locks.
	*When the flag is dropped ( ether manually, or by death) the current ~~lockon~~ target is cleared.		*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 current lock on target is cleared, and GM shots will be unguided.

			===Questions===
			This behavior will cause the last shot of a GM to be unguided. Should we only clear the GM lock on a death? or after the last shot hits? Should GMs be fire and forget where they always just go on the last target? Is that too mean?

	[[Category:TODO]]		[[Category:TODO]]