?, thru, what? wtf? etc.

[Mucho Maas]

An optional GU client. If you don't want to use it, you don't have to. The client will
have both bug fixes, and allow one or two extra settings to be accessed from the
GUI (not the whole lot - just a few). And we can allow a size 40 radar so that people
get the advantage of an up to date client, with security fixes applied, and don't have
to rely on 2.0.2

If you compile a list of issues and patches for them, I offer to build a windows version for it. Included with the list however it would also help to know if it changes any tank behavior.
In the meanwhile, we would also have to find a way about the rule for the GU league, that we don't allow mods. As this probably won't go into any 2.0 branch, it would be classified as a mod? That is something us GU league admins would have to think about.

[snick]

First off, it's 4am, so mistakes are inevitable. Anyway, herein follows the hitzone
correction as applied last February.

A sphuboid (silly name) is defined as the intersection of a sphere and cuboid,
as pictured here:



These are the code changes.

In src/bzflag/SegmentedShotStrategy.cxx replace

Code: Select all

t = rayAtDistanceFromOrigin(relativeRay, 0.99f * radius);

with

Code: Select all

t = timeRayHitsSphuboid(relativeRay, radius, tankHeight);

( Note: SegmentedShotStrategy.cxx is now in src/clientbase )

A new prototype goes in include/Intersect.h:

Code: Select all

float timeRayHitsSphuboid(const Ray& r, float radius, float height);

A new function goes in src/game/Intersect.cxx:

Code: Select all

float timeRayHitsSphuboid(const Ray& r, float radius, float height)
{
  float t = -1.0f;
  const float h = 0.5f * height;

  const float* d = r.getDirection();
  if (d[0] == 0.0 && d[1] == 0.0 && d[2] == 0.0) return 0.0f;

  const float* p = r.getOrigin();

  /* cylinder wall */
  const float a = d[0] * d[0] + d[1] * d[1] + d[2] * d[2];
  const float b = -(p[0] * d[0] + p[1] * d[1] + p[2] * d[2]);
  const float c = p[0] * p[0] + p[1] * p[1] + p[2] * p[2] - radius * radius;
  const float disc = b * b - a * c;
  if (disc < 0.0f) return -1.0f;                // misses
  const float d1_2 = sqrtf(disc);
  const float t0 = b + d1_2;
  const float t1 = b - d1_2;

  /* earliest wall hit */
  if (t0 < t1)
    if (t0 < 0.0f)
      t = t1 / a;
    else
      t = t0 / a;
  else
    if (t1 < 0.0)
      t =  t0 / a;
    else
      t =  t1 / a;

  if (t >= 0.0f) {
    /* wall impact not too high or low */
    if (p[2] + d[2]*t < -h || p[2] + d[2]*t > h) {
      t = -1.0f;
    }
  }

  const float rs = radius * radius - h * h;

  /* downward ray */
  if (d[2] < 0) {
    /* outside or touching, impacts top cap */
    if (p[2] >= h) {
      const float t1 = (h - p[2])/d[2];
      if ( (p[0] + t1 * d[0]) * (p[0] + t1 * d[0]) + (p[1] + t1 * d[1]) * (p[1] + t1 * d[1]) < rs ) {
          return t1;
      }
    }
    /* inside, impacts bottom cap */
    if (-h < p[2] && p[2] < h && t < 0.0f) {
      const float t1 = (-h - p[2])/d[2];
      if ( (p[0] + t1 * d[0]) * (p[0] + t1 * d[0]) + (p[1] + t1 * d[1]) * (p[1] + t1 * d[1]) < rs ) {
          return t1;
      }
    }
  }
  /* upward ray */
  if (d[2] > 0) {
    /* outside or touching, impacts bottom cap */
    if (p[2] <= -h) {
      const float t1 = (-h - p[2])/d[2];
      if ( (p[0] + t1 * d[0]) * (p[0] + t1 * d[0]) + (p[1] + t1 * d[1]) * (p[1] + t1 * d[1]) < rs ) {
          return t1;
      }
    }
    /* inside, impacts top cap */
    if (-h < p[2] && p[2] < h && t < 0.0f) {
      const float t1 = (h - p[2])/d[2];
      if ( (p[0] + t1 * d[0]) * (p[0] + t1 * d[0]) + (p[1] + t1 * d[1]) * (p[1] + t1 * d[1]) < rs ) {
          return t1;
      }
    }
  }

  return t;
}

[snick]

If you compile a list of issues and patches for them, I offer to build a windows version for it.

I'm able to compile for Windows (x86 and x64), too. But if you would rather do it instead,
that's cool. I have a slight problem with the PPC version of SDL under OS X because an SDK
is missing from Leopard that was there in Tiger ( SDK version 10.2.8 ).

Included with the list however it would also help to know if it changes any tank behavior.

Most certainly!

In the meanwhile, we would also have to find a way about the rule for the GU league, that we don't allow mods. As this probably won't go into any 2.0 branch, it would be classified as a mod? That is something us GU league admins would have to think about.

Yes.

Cheers,

Snick.

[smoooth]

It appears we are making some progress. Foo made good point that we know there are no big dollars involved here and that is duelly noted. I can only imagine the difficulty of hearing every complaint here or there about this or that. I do think the GU league as well as the Ducati leagues are probably some of the most loyal players of this game period. It looks like the problem is this:

1. The GU league players may want a "better" bzflag client for GU play
2. Getting changes first takes a GU Admin/League consensus and then buy in from Developers
3. How is it possible to get these changes implemented; are they appropriate for ALL bzflag?
4. If they don't make sense for ALL cases of bzflag; is it possible to implement a seperate versioning for GU league (this is something the GU admins / League would have to determine first, and then have support from the Devs)

I think what we are doing now is brain storming to the GU admins about what things we would like to see fixed. Snick has mentioned a few minor bugs and a major one with the hit calculation whic maybe or maynot be applicable to ALL bzflag. I don't see any objections from developers or admins or league players on those. I have mentioned making config settings available through the GUI or fixing config file input to limit those options available in the GUI. FS has mentioned the possibility of using a module to "verify" a legitimate client. Finally we have all asked about the possibility of this in a GU specific binary release.

smoooth

[slime]

First off, I am all for a separate GU Client that contains snick's bug fixes, maybe an optional full screen radar, or whatever else. Am I not mistaken that this has been tried like 50 times before, and has never gone through due to issues with the devs or licensing or something? Maybe it will work this time since it is not closed source (but I doubt it )

And, this solution would absolutely not fix the issue this thread was started for. The only issue it would possibly fix would be smoooth's idea of an 'even playing field'. Although it was said this client would be optional for members of the GU League, lol, that would most certainly not be the case. I think we all know how certain members of the community would identify each and every player without the client and single them out, refuse to match them, and use their client as an excuse for anything near suspicious. Heck, tell me how this would be different from the current 2.0.2 case now, unless it would be worse.

Now I am sure I will get fired back with some response, "But there will be no reason for each and ever player not to use this client, unless they have something to hide, etc." First of all, there goes that optional bit again. Second, there will always be some instance where a player's setting gets left off the new build. Overlooked, deemed faulty, whatever the case, that player will want to stay where he is comfortable. I am telling you now, the current GU League community would not let that player live it down.

[blast]

There is nothing that stops you from making a build of the game with changes as long as you post the full source along with any binaries. That's what open-source is all about.

However, if you put in fixes for stuff like collision detection in a client based on 2.0.x, you would break compatibility with the official 2.0.x version. So it would need be a fork of the game with a different protocol version that all league players would have to use.

If you don't like that idea, then it's completely possible that some or all of that patches could be put into the trunk version, and would then be available for 3.0.0. Then you would just have to wait for 3.0.0 to come out. You just need to get them posted on the patch tracker on SF.net and then work with the developers to get them integrated and tested.

[snick]

There is nothing that stops you from making a build of the game with changes as long as you post the full source along with any binaries. That's what open-source is all about.

However, if you put in fixes for stuff like collision detection in a client based on 2.0.x, you would break compatibility with the official 2.0.x version. So it would need be a fork of the game with a different protocol version that all league players would have to use.

I don't think you understand what this bug fix is. Because, if you did, I doubt
you'd say it needs a different protocol version.

Reason I say this: the fix produces collision detection that some 2.0.x players
already have (or almost exactly so). What the fix does is give everyone who
uses it that same correct detection.

And they get this without (the other method) cranking up their framerate really
high, which produces other less desirable effects. Is it better to have players
manipulating their framerate to overcome a bug, or is it better to fix the bug?

If the protocol version has to be changed, the bug will likely go unfixed in 2.0.x.
People don't want two clients, one for GU and one for elsewhere. They want one
correct client they use anywhere. You know, the sort of client that doesn't allow
a shot to go through the middle of a tank without blowing it up!

[joevano]

Officially 2.0.x is dead and will not be "fixed" as you call it. So in that sense you are correct, it will never get fixed in 2.0.x "officially". Releasing another version of the 2.0.x line won't happen unless something more serious than a collision detection bug, that has been around forever comes up, and that is very unlikely to happen.

[blast]

snick
I do understand what the fix does. But technically any change that would alter behaviour should be considered incompatible, since that is part of what our protocol version is tied to. Therefore, it should not be put into a client that can connect to 2.0.x servers. Two different clients that can both connect to the same server should die the same.

You'd also really have no benefit if people could opt to use a lesser quality collision detection system.

[snick]

Just a quick graphical illustration of how framerate can affect the hit zones[1] of
jumping tanks:



The above assumes a jumping tank and a shot moving along a horizontal path.

A decent graphics card is, effectively, a thin flag for tanks (assuming the rest
of your system is up to the task). To be more accurate, one could use the term
"short flag", short being thin in a vertical direction. Note also that there are
two large holes in the hit zone surface for a high framerate tank. Where there
are holes, no hit can occur.

[1] Terminology: a hit zone is a shape used internally by BZFlag to calculate
when a shot hits. It's a simple surface that allows for efficient calculation.
If a shot hits this surface, your tank blows up. That's the theory, anyway

PS

That picture is utter rubbish. Sadly, I can't be bothered to do a better one right
now. I seem to be suffering from an apathetic syndrome.

[snick]

And now, Hit Zone Bug, the movie -->

http://www.vimeo.com/5353924

Notes: this is a different situation from the one described in my previous
post. Here the tank is not jumping and the shot is not always horizontal.
The shot's initial path is horizontal, but then it hits the needle object, a
deflector that sends it on a vertical trajectory. The shot passes through
the very centre of the tank without blowing it up. Of course, this is a
very contrived situation, and one would likely not encounter it in a match.
Nevertheless, it's a clear demonstration, I think, that the bug exists. Try it
for yourself

[smoooth]

Great demonstration snick. This is a major problem. This is likely a reason for many of the "Thru" comments, etc. Also I'd like to note that using low fps to make "long" jumps should be corrected as well. If the low fps cannot be fixed easily then one way to prevent people from using fpsLimit during a match to make long jumps is to disallow all FPS changes that don't occur during application startup. Don't allow fpsLimit to be changed "on the fly". No way fps or energy saver should ever change the physics of the game. Also correct fps limit control will prevent fps jitter and other problems as well. I would like this feature to be corrected or included in the GU binary that we are conceputalizing.

I have been calling these people out for sometime who use this pathetic hack to manipulate the physics of the game. They are not "cheaters" by the GU definitiion but it is dishonest and cheap. If the admins who make the rules knew what these dishonest players were doing, they would make it illegal and thus these players would become "cheaters".

smoooth

[quantum dot]

I have been calling these people out for sometime who use this pathetic hack to manipulate the physics of the game. They are not "cheaters" by the GU definitiion but it is dishonest and cheap. If the admins who make the rules knew what these dishonest players were doing, they would make it illegal and thus these players would become "cheaters".

smoooth

That is incorrect smooth, you have been calling cheaters to people who select 3 fire buttons, define quick key strokes for zoom radars, or sets a a larger radar with high contrast. In summary, anyone editing the config file.

Snick is describing a bug of the game in which he has been looking into for quite some time. How could any gu admin make a rule against using a game bug or call it illegal? that makes no sense. 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?

I often wonder how would you do, what decisions would you make in administrative matters should you were given the responsibility. It would be a really interesting experiment.

with my best regards

qdot

[JeffM]

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, and those that wanted to exploit it would just not upgrade. You'd have to require people to use 2.0.14, and if you are going to do that then why not just require them to use your own version? Then you can include other checks.

[smoooth]

QD,

That is not the case at all. I am not calling someone who uses multiple fire buttons cheaters. Nor someone who uses radar zooms. There are config options that are not available in the GUI and that are available thru text editting that exploit the gaming system to give advantages. That is what I am getting at; i.e. using a fpsLimit change to make super jumps and fps jitter. You can't do that in the GUI config. This puts players who don't know about these text edit config only changes at a disadvantage. The whole fps should be fixed (but if it can't) atleast make a GUI available option for the less technically competent.

Another question I pose: What was the intent of the designers of the game for shot length?

1. Shot length max 14 (limited in GUI config)
2. Text file config (no limit, 90, 120, 200, 1000)

If there was no intended limit for shot length, why not just have an editable field in the GUI that allows for 120 shot length? Why the difference from what the GUI allows to what the text file edit allows? Was it intentional or does the game accidentally not check input from the text file for limitations. People who use shot length 90 or 120 cheapen the game. Much less hand eye coordination is needed for that. If that is available why not just put in a radar path too and a auto dodge; before you know it the game will play itself and no input from the user will be needed at all. I liked the idea of having to use hand-eye coordination for where the bullets are going, not having them "lasered" out on the radar any non-coordinated dope could avoid.

smoooth

[joevano]

That is just the way it was coded. I doubt there was any intent, just no checking of the value. The assumption by the person coding it was probably that a person would use the gui to set shot length, and the file was for storage. Therefore, there was no reason to check that the value was outside the range of what could be set in the gui, I'm just guessing, but based on old programming styles you see that quite a bit in older code.

As for cheapening the game, I really think you are blowing it out of proportion. Just a personal observation, you seem to sit on all sides of the fence depending on what you are arguing for/against. I think you like it like that...

[smoooth]

Some truth in in that Joe. I do like to discuss/argue plenty. There are many sides and not many get represented .

My thoughts are the same as you on this issue -- I believe the text file was supposed to be for storage and thus was not checked for input. So by that logic shot length was probably not intended to exceed 14. We should correct it, if this was the intent. Maybe a developer could step in an help give us some insight on the intent here?

Although I do argue on many points, I really just want to help clean up the game, because I like the game. Why not fix these loopholes if its not too much work, ya know? I am not getting anything out of this. I really just encouraging making the game as fair as possible. There seems to many out there who support doing nothing or thinking that everything is great the way it is. These arent huge changes, just small ones.

smoooth

[smoooth]

I often wonder how would you do, what decisions would you make in administrative matters should you were given the responsibility. It would be a really interesting experiment.

I thought no one would ever ask.

0. Establish a voting system for league issues; where by the players decide the league decisions
1. Establish more detailed clearly written rules
2. Establish clearly defined punishment and lengths for specific behavior with increasing time penalities for repeat offenders
2. Create a rotating admin board or have adminship voted on by majority of players
2. Make client version 2.0.2 illegal
3. Coordinate with developers on fixing issues related to "bugs" or "undesirables" that effect GU play
a. Limit input values in the config file
b. Fix fps problems
c. others
4. Reduce maximum team size to 8 players
5. Illiminate obvious cheaters -- admins have been doing a great job of this in the last 6 months. So no need to change what they are doing.
6. Provide a user rating system where by players rate other players after a match; Sample
a. Good experience *****
b. Average experience ****
c. Horrible experience ***
d. Bad connection **
e. Complete cheater! *

I think that would be it.

smoooth

[Mopar Madness]

my take on the this issue is that the dev's put a limit on radar size, and if they wanted to limit the rest of the gui options, they probably would have by now, so until they do, it should be legal.

[quantum dot]

QD,

That is not the case at all. I am not calling someone who uses multiple fire buttons cheaters. ... There are config options that are not available in the GUI and that are available thru text editting that exploit the gaming system to give advantages. ... This puts players who don't know about these text edit config only changes at a disadvantage.

Three fire buttons are NOT available via gui config. You got to edit the file. Same applies to more than 3 radar zooms. So make your mind, the problem is with editing the config file? or is not?

[macsforme]

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. Most of the "thru" comments, in my experience, are due to lag or other network issues or simply very close shots that are in fact legitimate misses. This is not to say that the bug should not be fixed, but it is one of several glitches and not a game-stopping issue as far as I'm concerned.

There are config options that are not available in the GUI and that are available thru text editting that exploit the gaming system to give advantages. That is what I am getting at; i.e. using a fpsLimit change to make super jumps and fps jitter. You can't do that in the GUI config. This puts players who don't know about these text edit config only changes at a disadvantage.

I'm not even sure what you're getting at... the "low fps jump" is not a config option at all, although there are obviously settings that affect it. And once again, until a tactic is declared out-of-bounds by the GU admins, it is a legitimate tactic that no one can call cheating (although some tactics are obviously considered more or less lame by the player population... i.e., passcamping).

[Saturos]

People who use shot length 90 or 120 cheapen the game. Much less hand eye coordination is needed for that.

Sometimes I get the impression you never read what other people type. I already adressed this some dozens posts before this one, but I'll do it again. You're proposing that combat strength is increased proportionally with the shot length. This is wrong. Longer shots mean you can dodge shots more easily when they're approaching your tank in open field, but they also mean that your radar gets cluttered with information you dont need. With too long shots every shot gets a giant line, which has nothing to do with when the shot ends or ricochets. A shot can be fired halfway across the map with three blocks between the shooter and you and you still get the line across your whole radar although the shot could never reach you. So in conclusion too short lines make dodging harder and too long lines make dodging harder. Everybody has to find the setting that suites him. I dont use extremely long lines because otherwise I get distracted by the mess on my radar. SAMY uses longer lines than me because he can handle it most of the time. It happens that he survives when I die because his setting is better for some individual situtions. And it happens that I survive when he dies because my setting is better for some individual situations. Every setting has its upsides and its downsides and thats why everybody has to experiment with the config to find out what suites best. I cant see whats wrong with that. You're lumping it all together, saying "longer shotlines are better, anywhere, anytime". Thats nonsense.
Now you'll say that not everybody has the technical knowledge to edit the config and set the values he likes. Yes, thats true. But we're going in circles. What we need is a "beginner's guide to the configuration of BZ". I already started it. No idea when it will be completed, but this is definitely the way to go.

[dexter]

Completely agree with Satu's post above. I've also started a Wiki documentation of the config file and we've both agreed on combining them in the not to distant future. Until then, I would advise you not to go ranting on about how terrible the config file can be for those who don't know how to edit it (!). Give us a couple weeks, and we should have a very detailed guide to the config and hits individual settings. Deal?

[smoooth]

Saturos,

I understand the differences and nuances with shot length. You are correct however my point here is that I don't believe a shot length 120 was ever intended for the game. I think, like Joevano has suggested, that config file was intended for storage only and the input is not checked for out of range values. The intent appears to be max shot length 14 but through an unchecked config file edit any value can be obtained. How ever I have thrown this question out for other developers or maintainers to comment on. Was this the intent? Then should this be fixed. The problem is we get players on here who are so hooked to using these unchecked values and flaws they get defensive about fixing them. Then they convince their gu admin buddies to allow things. I.e. 2.0.2 that shouldn't be allowed. My 2 cents.

smoooth

[Mucho Maas]

...I don't believe a shot length 120 was ever intended for the game. I think, like Joevano has suggested, that config file was intended for storage only and the input is not checked for out of range values. The intent appears to be max shot length 14 but through an unchecked config file edit any value can be obtained.

This is all assumption and opinion. Its a valid opinion. There is nothing wrong with that opinion. But opinions will differ. Both views have been excessively expressed in this topic, as well as on many other occasions. The conclusion is: there is a disagreement.
So far I cannot detect from comments that your view about the config-file is favored by the majority of the league players.
But still someone like dexter is putting effort in addressing some of your points, in removing the "mystical" aspect of configs and provide an opportunity for new players to know about them. Other's like snick examine the physics implementation and exposes for anybody to read the impact of the current implementation on the physic engine. These are very time intensive steps to address issues.
A current consensus seems to be that we try to create a client version that addresses some issues regarding the physics engine and test that version. This comes down to who ever has the time to help with it, implement it, and if the motivation is there to invest that amount of time. What happens then is still unclear and undecided. The preference expressed by JeffM is to classify it as a mod, which would be realized through a protocol break to enforce that mod for GU league playing. Maybe there are other solutions, but that would depend on how much of the behavior of the tank is changed. According to snick, there will be no behavior change, except that the physics engine will be more FPS independent.
If such a client would come with a protocol break, one could discuss changing the internal limits of configuration values. But a decision for this would not be based on preferences of a single player.

But all of this comes with a cost:
Many of the changes possible can change the very nature of the game and the league. It is a free league based on a free game based on a spirit of free will. The league and the game does not have any obligations for catering towards anybodies personal needs. What our responsibility is, is to ensure that the league remains operational. The rules for the league basically reflect what we consider to be common-sense. Sadly there seem to be some fields where the idea of common-sense diverges. We address those issues where we think it's necessary. But we don't think that special needs of individuals should be our most concern. There is not a single competitive mind-set envisioned for the game. The league should be open for people that simply want to have some fun, as well as for people that like to shine. There are different levels of skill, as well as different levels of how much one wants to invest on improving skill. Changing the game to suite a single mind-set and motivation mode is not what this league is about.
Second thing is time. Everybody in the league including admins are here to play a game. Every day spend on non-playing related issues are days taken away from a potentially fun gameing time. We are all not here to maximize your fun and react on every opinion you have. We are here for our own fun, which we get from playing the game. So every second invested in the game not related to playing is an offering of the person doing it.
Basically this means, if you want to get something done, do it and then offer it. If it is accepted, its great, if it's not accepted, then there wasn't any need for it. BZflag, the game servers, the leagues, the league site, the server trackers, this forum, all the wiki's, all our time spend.....all of this happened not because someone asked for it, but because someone did it and offered it.

The key word for a "free league based on a free game based on a spirit of free will" is do it, don't demand it.

How ever I have thrown this question out for other developers or maintainers to comment on. Was this the intent? Then should this be fixed.

The developers are available on IRC. Have you talked to them there?
To some of the proposed changes, JeffM and other devs/moderators have excessively expressed their view on changing implementation in 2.0.x. When you ask questions, you have to atleast acknowledge the answers.

The problem is we get players on here who are so hooked to using these unchecked values and flaws they get defensive about fixing them.

Just because people disagree and they don't accept your personal opinion, it doesn't make them villains. They simply disagree.

Then they convince their gu admin buddies to allow things. I.e. 2.0.2 that shouldn't be allowed.

This is an assumption which is factually wrong. Nobody convinced us to allow 2.0.2. More to the truth, 2.0.2 was never disallowed, so there was no convincing necessary to allow what was already allowed.