?, thru, what? wtf? etc.

[snick]

Great demonstration snick. This is a major problem. This is likely a reason for many of the "Thru" comments, etc.

Unless I am myself mistaken, the bug demonstrated by snick (while interesting) is not a "major" problem in any sense of the word, as it can only be exploited when a shot can be made almost directly upward or downward into a tank, which would only occur with an extremely freak pyramid ricochet.

The vertical shot example is a freaky case, and it's true that that is not something
to worry about. But my earlier postings deal with a very common case: a jumping
tank with a horizontal shot at that tank. Some players will be approximately twice
as easy to hit as some other players because of this bug. To my mind, that makes
this an important issue.

The value of the freaky case demonstration is that it is a very clear demonstration
of the bug's existence. Not everyone in the past has been convinced there even is
a bug.

[snick]

We would be more than happy if this bug is fixed in 2.x, which is not going to happen apparently. But if it is not, what would you do as gu admin? ban everyone because they use the official buggy client?

The problem with us fixing it in a 2.0.14 version would be that it would have to be compatible with the older versions

Compatibility is already ensured. The behaviour of the fixed version is exactly the
same behaviour many players already get with 2.0.10/12. The fix is removing a bug
that affects a subset of players using 2.0.10/12. It's not about adding in new stuff.

and those that wanted to exploit it would just not upgrade.

People who, as you say "exploit it", are easier to it. That's what the bug does:
it effectively makes your tank bigger. Isn't that a very strong incentive to upgrade?

Note: this does rest upon the assumption that the trimmed sphere was how the
hit zone was meant to be. There are some arguments in favour of this assumption,
and, I shouldn't doubt, some against. We can go into all that if you like and have a
good discussion about it.

[JeffM]

But would you guys require players to use .14? that's my main question.

The "intent" of the hit area is to have an area that works and is fun. The original author is long gone, so we can define whatever "intent" we want.

[smoooth]

I think the maintainers should provide some insight as to what the hit zone was meant to be. In any case a hit zone should not change at all -- in my opinion. Especially as a function of fps.

If the change is made I think the league should require people to upgrade. Sure there is always the possibility that people won't or will hide it but they will be easier to identify. There will always be the ones who cheat but atleast we should strive to make a proper scenario by which players who want to play properly can, and in a bug free environment.

[snick]

I think the maintainers should provide some insight as to what the hit zone was meant to be. In any case a hit zone should not change at all -- in my opinion. Especially as a function of fps.

It changes when you change fps. It changes when your tank moves this
way or that. It changes according to the angle of the shot. In fact, there
isn't any well-defined notion of a stable hit zone at all. One begins to
suspect that the code is complete rubbish

[JeffM]

You must remember that bzflag was never meant to be used like it is these days.

It is a LAN game that was made for old hardware. It makes a lot of assumptions. If you want to figure out what the best "intent" was, figure on 30fps, with 10ms or less lag. That's how the game was first played.

I'm not sure the capped sphere is the best hit volume, personally I think a simple cylinder is better ( simpler to predict, and compute ), but the math is very similar (XY dist check rather then XYZ dist check).

The overriding goal is, "is it fun", and the only thing that can be done for stuff like this is to make some changes and TRY it. No amount of talk is going to tell you if the method is still fun.

Make a branch, build some clients and see how it plays, simple as that.

Smooth, you are asking for answers that don't exist, and don't really matter. All we have to do is pick something and move on.

Snick, it's not rubbish, it's just not what you expect it to be, or assumed it to be, and insults are not going to endear your ideas to anyone. Sure it's not great for internet play, that's true of the ENTIRE game.

[smoooth]

Smooth, you are asking for answers that don't exist, and don't really matter. All we have to do is pick something and move on.

Agreed. Foo's point is well taken that everyone doesn't agree with me about limiting the shot length. My opinion is that the game appears to have placed emphasis via the GUI on keeping shot length 14 and other maximum values. There is no debate there. However if everyone believes that the shot length was intended to be changed in the config file (kind of the unnatural way to set things) then perhaps unlimited shot length is seen by most as the intent of the game.

It's hard to get a general consensus here on these boards from what the majority think because I'd guess about maybe 10% of the whole league reads this and has that level of interest. The persons who are neglected often are the new and unexperienced player. These are the players I'm trying to speak for. I can accept if the "majority"want to maintain the unlimited shot length. I think the majority is often spoken for by the top 10% of the league players, most of who use the config changes.

Definitely one opinion should not be held for all, including mine. I am hoping to use this forum as an avenue to get feedback, but unfortunately the seasoned players will read this, the new players who get owned and perhaps quit, will go unheard.

If unlimited shot length is found by the majority as the intent of the game then shouldn't we consider making "unlimited" shot length available thru the GUI? I think this would be a fair compromise and give new players the ability to have the same abilities the rest of us use. In other words. It is my belief that most players look to the GUI config to make settings changes first -- it is not intuitively obvious to newbies and non-technical minded people, that there are additional settings in .cfg files. Why not put all these in the GUI -- if possible. This wouldn't change the game but provide all the options to all competency levels.

smoooth

[Mucho Maas]

If unlimited shot length is found by the majority as the intent of the game then shouldn't we consider making "unlimited" shot length available thru the GUI?

Its a bit tricky to program an unlimited slider. As i said before, i am not in general against defining limits. I still believe for example that the default FPS limit of 30 is a relict from the passed, and that there is no use for it today. Especially as it has an effect on the current physics implementation (for the bad or good). Limits for minor tweaks is something that can be decided for if there is a positive consensus about it, which i feel there isn't.

And who are these unexperienced players? The once that joined a week ago? The once that joined 2 years ago? If after a certain time they don't develop an interest in sharing thoughts and ideas with the community, or take an interest in these forums, maybe they all don't care enough about it. Those that do, will take up customizing their settings in the configuration file as greedy as the rest.

There wasn't a single configuration change that I found out about, that made a great impact on my play. I think getting a better mouse made a lot more difference. Do we also want to start to standardizing hardware then? Think screensizes, processor power, high fps, gaming mice, smoothness of table, nagging of wife during game play. They all add a lot more than shotline lenght.

[smoooth]

You can make an input value not a slider. Perhaps the effect of the config changes are different for everyone. I recently told an average player about some config changes. He had never made before and he is someone who has played for years here. He didn't know how. I showed him. Let's just say he's looking much better these days. Dexter himself stated that he sucked really bad until he got a new config. I think most will agree editting the config is helpful, otherwise no one would do it.

If I had not told this player about the config changes he would have been stuck within the limits of the GUI, and most likely at disadvantage to those that have the informtation or capability.

Let's make these changes abundantly known to all and easily accessible so that there is'nt an information advantage for verteran players.

Perhaps we can put it in the MOTD, or when you log in "Please edit config.cfg for advanced options and configuration not available thru the GUI" Maybe even list a few samples; Increased shot length, increased mouse box size.

I would support standardizing input devices, but I think that it is too difficult and would have zero support. So i'm not fighting that battle. Nagging wifes have got to go! Just kidding. Gotta run mine is calling for me.

smoooth

[snick]

You must remember that bzflag was never meant to be used like it is these days.

It is a LAN game that was made for old hardware. It makes a lot of assumptions. If you want to figure out what the best "intent" was, figure on 30fps, with 10ms or less lag. That's how the game was first played.

[...]

Snick, it's not rubbish, it's just not what you expect it to be, or assumed it to be, and insults are not going to endear your ideas to anyone. Sure it's not great for internet play, that's true of the ENTIRE game.

There are no insults here. To say the code might be rubbish is not to insult anyone. I don't
think the code itself will be offended

Some of the code quality is dreadfully poor. That it was a LAN game is no excuse for that.
You could reasonably use the argument where lag is involved, but that's not relevant here.

For example, when a tank is hit, checkHit is supposed to determine the hit position. But it
doesn't. The position is always wrong by half a tank's height. And that's because the wrong
reference point is used in the code (centre of tank base rather than centre of tank). A lot
of the errors are simple stuff like that (remember how the mousebox was the wrong size?),
and it has little to do with LAN vs internet.

Cheers!

ps The half-tank error is still unfixed 5 months after I mentioned it. The fix is completely
trivial, by the way (just a few bytes and would take about 30 seconds to do). Here is the
conversation I had last Feb, from the IRC log:

11:06.55 randomparticle this is possibly wrong:
11:06.57 randomparticle position[0] = tankPos[0] + closestPos[0];
[...]
11:07.16 brlcad and it's possibly right, conjecture doesn't help
11:07.38 randomparticle it doesn't take account of the fact that the ray is relative to the centre of the tank, and the tank's position is relative to its base
11:07.58 randomparticle a bit more than conjecture, i think you'll find
11:08.26 brlcad then you should be able to find a specific example that is more than "possibly wrong"
[...]
11:13.25 randomparticle just bunging a console->addMessage in to prove my hypothesis
11:13.29 randomparticle one sec
[...]
11:22.22 randomparticle does look like the position returned by checkHit is always wrong
11:22.36 randomparticle it's off by half a tank's height
11:23.57 CIA-66 ow
11:24.09 randomparticle e.g., i shot myself on the ground. the position of the hit assigned had a Z value of 0.545
11:24.51 randomparticle but the muzzle height was 1.57
11:25.34 brlcad what's the tank height?
11:25.38 randomparticle 2.05
11:26.06 brlcad so gravity does kill
11:26.12 randomparticle :)
11:26.32 randomparticle 0.545 = (1.57 - 2.05/2)

I've removed a few smilies from that passage, because this forum won't accept more than 3.

[joevano]

But again.. you don't listen to what has been said. Fixing 2.0.x is not something that will happen. You will have 2 different behaviors depending on the client, and that will not fly. It isn't fair to anyone. The client is the way it is and the only way to fix it fairly is to break the protocol. That isn't going to happen. If GU wants it, they can fix it and use some of their other ideas as well, but it won't be fixed in the official 2.0.x branch.

[snick]

But again.. you don't listen to what has been said. Fixing 2.0.x is not something that will happen. You will have 2 different behaviors depending on the client, and that will not fly. It isn't fair to anyone.

I have listened, and I disagree. Repeating yourself endlessly will not make
your argument correct.

How simply do I have to put this before you grasp this blindingly obvious
concept: the client is already completely un-blinking-fair. Fixing the bug
I mentioned before doesn't make it any more unfair, it makes it less so.

And, by the way, you do know that substantial changes were made to client
behaviour in the 2.0.x branch creating different behaviour for different
minor versions of 2.0.x? And yet, somehow, there was no need to break
protocol then. How do you explain that? Even the positions of tanks on the
screen were changed.

Finally, the half-tank height thing. I never said that should be fixed
in 2.0.x, so don't go assuming that (and I'm not assuming that you are
assuming that). Why isn't that easy-peasy 30 second fix already in 3.0?

[FiringSquad]

Regarding the config file modification program:
I haven't forgotten about it. Just no time at the moment and I'm about to go on vacation.
I originally thought of making a stand-alone app that reads details from an XML file and presents these details in an editor, so that you could see the option that could be edited and the range of values allowed, along with notes about how it effects performance etc.
I might still go this route, but I would also like to maximise the use of existing BZFlag Src code.
The main reasons for this is that it will be easier to maintain and will definitely interpret the config file in exactly the same way as the client.
Also I have to worry about the config editor getting out of step with the BZFlag client, so that it allows values that are no longer supported etc.
The more I look into code re-usage though, it seems to make sense to provide this as an option in the BZFlag GUI. Something like Options->ExpertMode that allowed you to edit the config file directly, or just set the option locally and try it out first before saving. That way it could be part of the main distribution and would be more useful, though the UI would be more restricted.
Another alternative is if more extensive comments were added to the default config file that's shipped with the client. This would certainly be easier to produce and again would benefit everyone.
Anyway, if I can provide it within the BZFlag client within a reasonable amount of time, then I will take this option, otherwise it will be a standalone app written for the Mac with the user interface separated from the config stuff so that versions for other OSes could easily be written just by adding the editing window.