With Quality=Experimental you get a GM lock box on screen that follows the player you locked on. If that player subsequently picks up a ST flag, the box remains on screen and tracks him. The lock appears to cancel, but the box still follows the player. If you fire, the box disappears when your shot dies. If the locked player dies, and respawns, the box continues to follow him, regardless of which flags he grabs.
The GM lock should cancel, and the box disappear when ST flag is grabbed.
wp
2.4 GM lock problem
2.4 GM lock problem
<life> <!-- insert something interesting here --> </life>
Re: 2.4 GM lock problem
It's interesting how the markers are showing the bugs in the other code since they are just displaying client data in a new way. I'll take a look into this, it seems we don't clear out the "lock target" from GM when we should.
JeffM
Re: 2.4 GM lock problem
I have a fix that should help committed to 2.4.1 in svn, it needs testing but it should clear out the lockon target and make it match the GM update code. It should be noted that this bug seems to have been in bzflag for a very long time we just didn't see it until something showed us graphically what the tank thought it was locked onto.
JeffM
Re: 2.4 GM lock problem
Since this is, in effect, a 'see ST when you shouldn't' bug, how will we keep players from using 2.4.0 client to cheat? I assume make bzfs require >= 2.4.1? I realize this is of minimal use since it is only good until you shoot once.
<life> <!-- insert something interesting here --> </life>
Re: 2.4 GM lock problem
The server can't tell what version of the client you have, so there is no way to make what you say happen. People WILL and are cheating with the 2.4 client and there really isn't anything to be done about it until the game is moved server side with the client getting limited updates. It is on the roadmap.... but not for quite some time.War Pig wrote:Since this is, in effect, a 'see ST when you shouldn't' bug, how will we keep players from using 2.4.0 client to cheat? I assume make bzfs require >= 2.4.1? I realize this is of minimal use since it is only good until you shoot once.
There is nothing worse than aggressive stupidity. -- Johann Wolfgang von Goethe
"How many legs does a dog have if you call his tail a leg? Four. Calling a tail a leg doesn't make it a leg." -- Abraham Lincoln
"How many legs does a dog have if you call his tail a leg? Four. Calling a tail a leg doesn't make it a leg." -- Abraham Lincoln
Re: 2.4 GM lock problem
yep it's in there for the life of the version. It sucks, but then there are TON of other bugs in there too. As I said, the data has been set this way for a long time there was just no display for it.
If it becomes a big issue then servers can force markers to be off with _forbidMarkers
Also 2.4.1 will never be released, the next update will be 2.4.2 since we always release even revisions, odd numbers are just used during development.
If it becomes a big issue then servers can force markers to be off with _forbidMarkers
Also 2.4.1 will never be released, the next update will be 2.4.2 since we always release even revisions, odd numbers are just used during development.
JeffM
- Mopar Madness
- Private First Class
- Posts: 169
- Joined: Mon Jul 03, 2006 3:31 am
Re: 2.4 GM lock problem
2.0.2 still gets a few people ticked off, but we lived through that bug for 6 years, we can live through this bug too, hopefully it won't be a 6 year wait for next break in protocol though