0.2.8 CFG-Comments

[Lyx]

# sets the file path for the map

# relative file path to the default map

# when a client's connection is blocked because he's banned, make him banned for at least this many seconds

# when a banned client tries to connect, update the remaining ban-time to be at least this many seconds

# autoban-settings

i still dont get it.(tm). Ban-time and max-cap on bans combined in a single formula?!?

# if set to 1, this allows two players that apparently come from the same machine to fight for points

Not sure about this one:
# if set to 1, allow players from the same ???IP??? to be ???enemies???

# if set to 1, this allows two players that play on the same client to fight for points with each other

Not sure about this one:
# if set to 1, allow players from the same client(splitscreen) to be ???enemies???

# acceleration offset. Must be positive, it serves as a cutoff to avoid dividing by zero.

From "cutoff" it may not be obvious to others if this relates to the top or bottom of the scale.

# when is a wall near?

# the distance from a wall at which wall-acceleration kicks in (???scale???)

# allow braking

# brake-strength (set to 0 to disable brakes)

# min time between turns in seconds. Never enable the topology police if this is set lower than 0.001. Only values bigger than zero are supported.

# minimum time in secs between cycle-turns. (must be above zero. Never enable the topology police if this is set to less than 0.001)

# turn delays will be based on the time since the last turn if this is 1 (default) and the distance if this is 0. Intermediate values and values out of these bounds are supported as well.

# cycle-turn delays are based on the time since the last turn if set to 1 (default) and the distance if set to 0. Intermediate and other values are supported as well.

# factor multiplied to speed on every turn

# at every cycle-turn it's speed is multiplied by this value

# rubber usage is based on distance travelled if this is 0 (default) and the time passed if this is 1. Intermediate values and values out of these bounds are supported as well.

# rubber usage is based on distance travelled(0 - default) or time passed(1). Intermediate and other values are supported as well.

# The minimal distance rubber code keeps you from the wall in front of you

# Minimum distance the rubber keeps cycles from walls
No need to mention the "in front of you", since that should be obvious

# Addidional distance if you have an empty rubber meter (gets faded out gradually as you use up all your rubber)

"emtpy" may be ambigious to users who dont know the code

# Timescale rubber is restored on

# How long does it take the rubber to regenerate?


The other comments seem fine to me.

[Jonathan]

# acceleration offset. Must be positive, it serves as a cutoff to avoid dividing by zero.

From "cutoff" it may not be obvious to others if this relates to the top or bottom of the scale.

# when is a wall near?

# the distance from a wall at which wall-acceleration kicks in (???scale???)

Two rays are cast diagonally backwards, with CYCLE_WALL_NEAR range. Acceleration from each sensor is calculated by

Code: Select all

         CYCLE_ACCEL                         CYCLE_ACCEL
----------------------------- - ------------------------------------
distance + CYCLE_ACCEL_OFFSET   CYCLE_WALL_NEAR + CYCLE_ACCEL_OFFSET

and both are added. Distances are sideways.

# allow braking

# brake-strength (set to 0 to disable brakes)

Deceleration by braking.

# min time between turns in seconds. Never enable the topology police if this is set lower than 0.001. Only values bigger than zero are supported.

# minimum time in secs between cycle-turns. (must be above zero. Never enable the topology police if this is set to less than 0.001)

…

# Addidional distance if you have an empty rubber meter (gets faded out gradually as you use up all your rubber)

"emtpy" may be ambigious to users who dont know the code

IMO these are worse.

The rubber meter clearly shows what's empty. I'm more concerned about addidional.

# Timescale rubber is restored on

# How long does it take the rubber to regenerate?

I don't think misinformation is allowed.

[Lyx]

# autoban-settings

i still dont get it.(tm). Ban-time and max-cap on bans combined in a single formula?!?

Got it. z-man was right - one can indeed only understand it after reading the coresponding section in the docs.

[Z-Man]

Thanks a lot! I took what I liked (sometimes it was a blend of the two versions). I'm commenting on those I did not use. I used jonathan's version for the brake strenght.

# sets the file path for the map

# relative file path to the default map

The comment generally describes the variable, not the value; of course the corresponding map is the default map, but you want to know what happens when you change it.

# if set to 1, this allows two players that apparently come from the same machine to fight for points

Not sure about this one:
# if set to 1, allow players from the same ???IP??? to be ???enemies???

Clarification: the setting does not prevent the two players from the same machine (players may appear to come from the same machine if they connect to the internet via the same router) to play in opposing teams; what it does is that if player A kills player B, he and his team don't get points for it.

# acceleration offset. Must be positive, it serves as a cutoff to avoid dividing by zero.

From "cutoff" it may not be obvious to others if this relates to the top or bottom of the scale.

I avoid the cutoff now; it says
# acceleration offset. Must be positive or smaller than -CYCLE_WALL_NEAR, otherwise there is a risk of a division by zero.
And I added the hint at the section that for the acceleration settings, the full docs are useful. They give the formula Jonathan quoted.

# min time between turns in seconds. Never enable the topology police if this is set lower than 0.001. Only values bigger than zero are supported.

# minimum time in secs between cycle-turns. (must be above zero. Never enable the topology police if this is set to less than 0.001)

I don't know why you repliaced "min" my "minimum", but then "seconds" by "secs" I just did the "min"->"minimum" replacement. Clarification: zero is a legal value that works basically, but it makes turning around on the spot possible with all related gameplay and engine problems. That's why it's marked as not supported.

# rubber usage is based on distance travelled if this is 0 (default) and the time passed if this is 1. Intermediate values and values out of these bounds are supported as well.

# rubber usage is based on distance travelled(0 - default) or time passed(1). Intermediate and other values are supported as well.

I'm not sure whether "other" is better here than "out of bounds". Clarification of what I mean: actually, all floating point values are supported; the two effects are blended together if it's a value between zero and one and are in overdrive mode when the value is out of bounds (like the value of 2 giving "realistic" turn radius). Perhaps it should say
# ... All values are allowed, see below for examples.
?

# Addidional distance if you have an empty rubber meter (gets faded out gradually as you use up all your rubber)

"emtpy" may be ambigious to users who dont know the code

This is a bit of a conceptual dilemma. If I ever had planned a rubber meter in the HUD, I would have made it work the other way round: starting in full state and emptying as you hit a wall. Documentation for this is much easier to formulate, but in the code, it is easier to do it the way it is done (start empty and die when it's full). Well, the HUD is here now and we have to live with it that it works strangely.

# Timescale rubber is restored on

# How long does it take the rubber to regenerate?

As Jonathan points out in his usual charming way, this is inaccurate. The rubber never fully regenerates once it has been used; but if it is used to its max, it will empty again to 40% filling after the timescale given here; after another timescale, it'll be at 16%, after another one, ad 6.4%. Generally, it will be reduced by 60% during each period of RUBBER_TIME seconds (all values are rough, the 40% are actually 100%*exp(-1)). I happen to like exponential decays and as I said, rubber was not meant to be exposed so much to the user that an explanation would even be necessary. Otherwise, I would have chosen a good old linear regeneration.