I'd like to see wings be a server settable option for all tanks. Note that I'm not talking about allowing or not allowing the wings flag, but adding a server option to give all tanks wings capability all the time, much like you can do with jumping.
Having this option opens up some pretty cool map ideas for capture the flag (and FFA) that are only possible if you can both fly and carry another flag.
I suppose some would criticize this change as too drastically changing the game play (and I would be truly disappointed if "all" the popular servers enabled it), but it's really no different than servers with the jumping option turned on.
Don't know if this would be a protocol change per se, but would almost certainly require client changes. I suppose you would want the addition of a "no wings" bad flag along with this, but that would definitely be a protocol change.
Thoughts?
Wings - Always-On Server Setting
OK - I've posted a patch on sourceforge at https://sourceforge.net/tracker/index.p ... tid=303248
The new client allows all tanks on a server to fly (as though they always have a Wings flag) when the server has the feature enabled. Otherwise they act like normal tanks. When enabled, the flying tanks can carry any of the other flags on the field (team, super or bad).
I've not come across any bugs yet in my testing. Plus, the new client works fine (but doesn't fly) on current 2.0 servers and the current 2.0 client works fine with the new server code (but obviously doesn't fly). This means (I think) that if accepted by the devs, the code could be used immediately instead of having to wait for version 2.2 (since it doesn't really break protocol).
The patch works fine as it is, but I will be posting a new version that makes the "No Jumping" and "Bouncy" flags behave more like expected. At the recommendation of one of the devs I will also change the enabling switch from -wings to -flyingTanks (more descriptive that way).
How interested are people in having this option available? I know much (if not all) of the dev team is against letting tanks carry two flags at once. But this I view this feature as more like the "allow jumping" game style that most servers tend to use.
If you want this feature you might need to speak up and say so, since I'm not sure yet how it will be received by the developers. I'll go hang out on IRC tonight and see. If the idea is rejected, that's fine too - at least I learned a bit about the inner workings of BZFlag.
The new client allows all tanks on a server to fly (as though they always have a Wings flag) when the server has the feature enabled. Otherwise they act like normal tanks. When enabled, the flying tanks can carry any of the other flags on the field (team, super or bad).
I've not come across any bugs yet in my testing. Plus, the new client works fine (but doesn't fly) on current 2.0 servers and the current 2.0 client works fine with the new server code (but obviously doesn't fly). This means (I think) that if accepted by the devs, the code could be used immediately instead of having to wait for version 2.2 (since it doesn't really break protocol).
The patch works fine as it is, but I will be posting a new version that makes the "No Jumping" and "Bouncy" flags behave more like expected. At the recommendation of one of the devs I will also change the enabling switch from -wings to -flyingTanks (more descriptive that way).
How interested are people in having this option available? I know much (if not all) of the dev team is against letting tanks carry two flags at once. But this I view this feature as more like the "allow jumping" game style that most servers tend to use.
If you want this feature you might need to speak up and say so, since I'm not sure yet how it will be received by the developers. I'll go hang out on IRC tonight and see. If the idea is rejected, that's fine too - at least I learned a bit about the inner workings of BZFlag.
How does it comunicate to the client to do this? if it's a new state or game option, we can't put it in 2.0.x since it would be incompatable with 2.0.0. Unless it's a server only change.
Actualy I don't see how this could go in any 2.0.x version. If a 2.0.0 client conencted he could not fly, where all others could. This would efectvly make the patch a cheat to the player with the older version. We'd have to put this in the next major version 2.2.0. The patch realy should change the protocol version unless it has some way of detecting if there is any client loged in that dosnt' support the feature, and turning it of for everyone when there is an "old" user on.
Actualy I don't see how this could go in any 2.0.x version. If a 2.0.0 client conencted he could not fly, where all others could. This would efectvly make the patch a cheat to the player with the older version. We'd have to put this in the next major version 2.2.0. The patch realy should change the protocol version unless it has some way of detecting if there is any client loged in that dosnt' support the feature, and turning it of for everyone when there is an "old" user on.
JeffMIt sets a new game style that I called FlyingGameStyle (patterned off of JumpingGameStyle). The client sees this and sets the World::getWorld()->allowFlying() property. All "flying" behavior is based on either this property being set or having the Wings flag.JeffM2501 wrote:How does it comunicate to the client to do this? if it's a new state or game option, we can't put it in 2.0.x since it would be incompatable with 2.0.0. Unless it's a server only change.
So, the short answer is that a 2.0.0 client connecting to this new "flying-enabled" server would not be able to fly, while a new "flying-enabled" client would.
I can understand the devs' responsibilities to avoid new "gameplay affecting" features in minor revisions. But, wouldn't that be a great incentive to upgrade.JeffM2501 wrote:Actualy I don't see how this could go in any 2.0.x version. If a 2.0.0 client conencted he could not fly, where all others could. This would efectvly make the patch a cheat to the player with the older version. We'd have to put this in the next major version 2.2.0.
I'll also add that besides the old clients not being able to partake in the unbridled flying, nothing else is "broken".
Boy, THAT'd be a way to make a whole server full of people mad at you - show up with an old client and watch the tanks start falling from the sky - hehe.JeffM2501 wrote:The patch realy should change the protocol version unless it has some way of detecting if there is any client loged in that dosnt' support the feature, and turning it of for everyone when there is an "old" user on.
But, if there were enough demand for it I could probably do it. Heck, it might be a fun challenge just to do it anyway.
The client sends its version in the join message. You can read this and reject the client (like he was banned) if he has an old version and this option is enabled, sending him a message like "This server is using an option that your client does not support (too old). Upgrade at http://bzflag.org/"
That would be a fairly clean way of dealing with this without "really" breaking protocol.
That would be a fairly clean way of dealing with this without "really" breaking protocol.
we do the "force you to upgrade" by changing the protocoll version. this way we don't punish players for joining a server they can see, yet dosnt' support some magic feature they don't know they don't have.
The kick on old version is kinda also a punishment. It would work, but it's kind of a hack.
We had a similar issue when we made some changes to pyramid physics. Old cliets had become "cheats". So the feature had to be pushed to the next proocoll breaking release.
While I too think it would be cool to have, our procedure is to put game breaking changes into a new protocoll version, as it is the cleanest for all players.
The kick on old version is kinda also a punishment. It would work, but it's kind of a hack.
We had a similar issue when we made some changes to pyramid physics. Old cliets had become "cheats". So the feature had to be pushed to the next proocoll breaking release.
While I too think it would be cool to have, our procedure is to put game breaking changes into a new protocoll version, as it is the cleanest for all players.
JeffM-
I_Died_Once
- Special Forces
- Posts: 635
- Joined: Sun Nov 28, 2004 5:27 pm
- Location: The Dark Side
- Contact:
How about make this option so you can turn ANY flag to an "always on" status... Or any "status" flag, perhaps?
For example, you could set your server to "All Stealth" - and payers will always behave as if they are carrying the ST flag. They could then pick up superbullets, and still be stealthed.
Sweet idea, even if they only go with the wings, although I shudder to think of people flying that high, carry GM with 'em.
For example, you could set your server to "All Stealth" - and payers will always behave as if they are carrying the ST flag. They could then pick up superbullets, and still be stealthed.
Sweet idea, even if they only go with the wings, although I shudder to think of people flying that high, carry GM with 'em.
...This has been a recording.
The _wingsJumpCount setting is still in effect with this option turned on. So the server operator can still limit how high you go and how long you can stay airborne by limiting the number of flaps.I_Died_Once wrote:Sweet idea, even if they only go with the wings, although I shudder to think of people flying that high, carry GM with 'em.
Plus, you'll have people flying up behind the "flying GM" with a "flying ST"
I_Died_Once
one of the ideas I've been trying to push is to turn flag actions into an atribute system where you can then apply any set of atributes to a starting condition. Then flags are just a transport medium for those atributes, and they could be set via the server. You could then have other ways to get attributes, like a zone where you get high speed. or even have attributes that are tied to weapon shots ( a shot that makes you only turn left when you get hit by it for example ). Sadly this would require a fairly large rewrite of the flag handaling system so nobody has taken to implementing it.
one of the ideas I've been trying to push is to turn flag actions into an atribute system where you can then apply any set of atributes to a starting condition. Then flags are just a transport medium for those atributes, and they could be set via the server. You could then have other ways to get attributes, like a zone where you get high speed. or even have attributes that are tied to weapon shots ( a shot that makes you only turn left when you get hit by it for example ). Sadly this would require a fairly large rewrite of the flag handaling system so nobody has taken to implementing it.
JeffM