New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Independent loadout zone access in teamed games #461
Comments
From buckyballreaction on October 31, 2014 20:28:34 I know this is crazy, but fixing this will break network compatibility since we sent a flag to the client saying a loadout zone was found. This will have to wait until 020. I'm not sure of a proper fix - maybe send a TNL Vector with team ID as the array index, and the value if that team has a zone... Status: Accepted |
From watusim...@bitfighter.org on November 03, 2014 10:08:58 The fix for this seems simple -- currently we have a flag that specifies which loadout mechanism to use on a level. Instead of sending it with the level info, we send it with the team info (name, color, etc.). But yes, this will have to be a 020 fix. |
From watusim...@bitfighter.org on November 03, 2014 11:01:31 Actually... aren't all loadout zones known by the client? If so, the client itself could determine what mechanism each team uses. If this is correct, we could fix this in 019d. |
From Jomskylark on January 11, 2015 19:04:09 If this cannot be fixed in the 020 release, how about a warning prompt when testing or exiting an applicable level that states, "One team is missing a level, please address" or something like that? Similar to the warning prompts provided for missing spawns, soccer balls in a non-soccer level, etc. |
From watusim...@bitfighter.org on January 12, 2015 12:03:53 Labels: 019x |
From watusim...@bitfighter.org on July 29, 2015 02:23:21 Actually, we should continue sending the loadout presence because of the unpredictable nature of when objects are sent -- there could be a loadout zone in a level, but it hasn't yet been sent to the client for whatever reason. |
From watusim...@bitfighter.org on July 29, 2015 02:23:43 Labels: -019x |
From watusim...@bitfighter.org on July 29, 2015 02:27:28 Or... perhaps the client could make the determination about loadout zone presence in ClientGame::doneLoadingLevel() method? Then again if a new loadout zone is sent (or removed) by the server? Labels: 019x |
From watusim...@bitfighter.org on August 04, 2015 00:55:16 Fixed in 020, could be backported to 019x if we do another release in that cycle. Status: Fixed |
From Jomskylark on September 19, 2014 21:41:34
Currently in a level with two (or more) teams the following occurs:
I presume
#3
is not intentional as if there is a level design error and only one team has loadouts it will effectively prevent the other team from changing their loadout.Ability to change loadout should occur independent of the other team. If one team has at least one loadout zone, they must use it to change their loadout. However if the other team has no loadout zones, they should be able to respawn to activate loadout changes.
Original issue: http://code.google.com/p/bitfighter/issues/detail?id=461
The text was updated successfully, but these errors were encountered: