New Configuration Items
-
Tank Program
- Forum & Project Admin, PhD
- Posts: 6712
- Joined: Thu Dec 18, 2003 7:03 pm
New Configuration Items
Z-man (or others who know), would it be too much trouble to request a complete list of the new configuration entries since 0.2.7.0 to cvs? I'm looking at upgrading Tigers Network you see, and I have no idea what half the new stuff does, for example, cycle_rubber_mauls_*, as the help is missing too...
Sorry, I thought the documentation in settings.cfg would be enough.
As you know, your speed gets decreased a bit on every turn by 5%. This factor can now be tuned in CYCLE_TURN_SPEED_FACTOR. It's the numerical value the speed gets multiplied with. Make it bigger than one if you like weird settings.
The rubber code:
There's a new property called rubber effectiveness. It's usually a value between 0 and 1. If a certain action consumes x rubber, at effectivity e it will consume x/e rubber. At effectivity 0, rubber gets disabled completely. At default settings, rubber effectivity is constant and always 1.
Two things possibly influence the effectivity of rubber:
Shortly after you make a turn, a certain portion of the time ( given by CYCLE_RUBBER_DELAY ) until you are legally allowed to make your next turn determined by CYCLE_DELAY, the effectivity gets multiplied by CYCLE_RUBBER_DELAY_BONUS ( Hmmm. We should rename that to _FACTOR, _BONUS sounds too positive ). The logical use of this mechanism is to punish 180s and adjusts by higher rubber usage or death.
Then there is another state variable, the rubber malus. Initially it is set to 0. On every turn, CYCLE_RUBBER_MALUS_TURN gets added. It decays over the time of CYCLE_RUBBER_MALUS_TIME seconds. The rubber effectiveness gets divided by ( 1 + rubber malus ). This setting is to punish to hectic turning and repeated 180s. ( or to provoke floating point chaos if you make CYCLE_RUBBER_MALUS_TURN negative ). The new experimental red rubber gauge displays 100/(1+malus), it should display the full effectivity in the end. ( Umm, would that rather be efficiency? Definition lawyers, please to the rescue! )
The time rubber decays on ( formerly hardcoded 10 seconds ) can now be controlled by CYCLE_RUBBER_TIME. Setting it to 0 will disable the decay.
New clients will sync the rubber state and brake reservoir from the server, old clients will display horribly wrong values if you play with the settings too much.
Those were the new experimental settings, that's why they are not yet documented.
Then there is the way rubber prevents you from hitting walls. Formerly, if you got close to a wall, the rubber code would allow you to cut the distance to it in half. The new code ( from 0.2.7.1 ) will not let you closer to a wall than determined by the _MINDISTANCE settings. Exception: right after a turn, you are always allowed to go a bit forward. How much is determined by CYCLE_RUBBER_MINADJUST, useful values are between 0 and 1. Values bigger than 1 will also kill all 180ers. Setting _MIDISTANCE to a small negative value is another way of punishing all kinds of rubber whores, because then rubber will stop you only a bit after the wall, while making you slower before the hit and therefore still faciliating grinding to an extent. ( Not recommended right now because the old clients will ignore it. )
The speed at which you approach a wall is determined by CYCLE_RUBBER_SPEED. Mathematically, if you are at distance d from a wall, rubber makes sure you don't approach it faster than CYCLE_RUBBER_SPEED * d.
Since this speed of approaching may be slower or faster than with the old code depending on the framerate, people complain about it. Therefore the new client reverts back to almost the old code ( a tiny minimal distance to walls is still kept ) when any pre-0.2.7.1 server or client is involved. The server admin can disable this admittedly dangerous behavior with CYCLE_RUBBER_LEGACY 0.
Now the server to client synchronization settings:
Old servers would send all cycle syncs once per second. Since 0.2.7.1, the interval is configurable separately for the client that owns a cycle and all other clients in the CYCLE_SYNC_INTERVAL_ settings.
New clients since 0.2.7.1 send the time of turn commands to the server. This makes it possible to avoid grinding lag sliding ( you move towards a wall, grind it shortly and turn away again, and you'll slide ) by letting the cycle on the server turn not before the time sent by the client. At the low speeds before the grind, the positional command interpretion is inaccurate and will usually turn the cycle too early.
Now, old clients don't send the command time, so this code can't work. The lag sliding is a clear disadvantage, but the earlier turn is an advantage in some situations because it makes you cover more ground, so both the new and the old players have plenty of reason to complain if they are not treated equally. Therefore, when CYCLE_FAIR_ANTILAG is set to 1 and old clients are present, this code is deactivated.
When a cycle turns in free space, the server will try to follow the client's request by matching the turn position as closely as possible. Sometimes however there are large desyncs and clients sent silly turns halfway across the grid from their current position. So, for clients that send the command time, the server will execute turns only in a time window around that command time. The width of that window is determined by CYCLE_TIME_TOLERANCE.
I observed that old clients ( 0.2.7.0 and earlier ) would be more likely to pass through walls when they received a sync from the server shortly before. So, if you set CYCLE_AVOID_OLDCLIENT_BAD_SYNC to 1, the server will not send those syncs. Whether this helps or makes matters worse by not sending enough syncs is unknown, that's why it is a setting.
The other new settings are purely local and don't have gameplay relevance on the server.
As you know, your speed gets decreased a bit on every turn by 5%. This factor can now be tuned in CYCLE_TURN_SPEED_FACTOR. It's the numerical value the speed gets multiplied with. Make it bigger than one if you like weird settings.
The rubber code:
There's a new property called rubber effectiveness. It's usually a value between 0 and 1. If a certain action consumes x rubber, at effectivity e it will consume x/e rubber. At effectivity 0, rubber gets disabled completely. At default settings, rubber effectivity is constant and always 1.
Two things possibly influence the effectivity of rubber:
Shortly after you make a turn, a certain portion of the time ( given by CYCLE_RUBBER_DELAY ) until you are legally allowed to make your next turn determined by CYCLE_DELAY, the effectivity gets multiplied by CYCLE_RUBBER_DELAY_BONUS ( Hmmm. We should rename that to _FACTOR, _BONUS sounds too positive ). The logical use of this mechanism is to punish 180s and adjusts by higher rubber usage or death.
Then there is another state variable, the rubber malus. Initially it is set to 0. On every turn, CYCLE_RUBBER_MALUS_TURN gets added. It decays over the time of CYCLE_RUBBER_MALUS_TIME seconds. The rubber effectiveness gets divided by ( 1 + rubber malus ). This setting is to punish to hectic turning and repeated 180s. ( or to provoke floating point chaos if you make CYCLE_RUBBER_MALUS_TURN negative ). The new experimental red rubber gauge displays 100/(1+malus), it should display the full effectivity in the end. ( Umm, would that rather be efficiency? Definition lawyers, please to the rescue! )
The time rubber decays on ( formerly hardcoded 10 seconds ) can now be controlled by CYCLE_RUBBER_TIME. Setting it to 0 will disable the decay.
New clients will sync the rubber state and brake reservoir from the server, old clients will display horribly wrong values if you play with the settings too much.
Those were the new experimental settings, that's why they are not yet documented.
Then there is the way rubber prevents you from hitting walls. Formerly, if you got close to a wall, the rubber code would allow you to cut the distance to it in half. The new code ( from 0.2.7.1 ) will not let you closer to a wall than determined by the _MINDISTANCE settings. Exception: right after a turn, you are always allowed to go a bit forward. How much is determined by CYCLE_RUBBER_MINADJUST, useful values are between 0 and 1. Values bigger than 1 will also kill all 180ers. Setting _MIDISTANCE to a small negative value is another way of punishing all kinds of rubber whores, because then rubber will stop you only a bit after the wall, while making you slower before the hit and therefore still faciliating grinding to an extent. ( Not recommended right now because the old clients will ignore it. )
The speed at which you approach a wall is determined by CYCLE_RUBBER_SPEED. Mathematically, if you are at distance d from a wall, rubber makes sure you don't approach it faster than CYCLE_RUBBER_SPEED * d.
Since this speed of approaching may be slower or faster than with the old code depending on the framerate, people complain about it. Therefore the new client reverts back to almost the old code ( a tiny minimal distance to walls is still kept ) when any pre-0.2.7.1 server or client is involved. The server admin can disable this admittedly dangerous behavior with CYCLE_RUBBER_LEGACY 0.
Now the server to client synchronization settings:
Old servers would send all cycle syncs once per second. Since 0.2.7.1, the interval is configurable separately for the client that owns a cycle and all other clients in the CYCLE_SYNC_INTERVAL_ settings.
New clients since 0.2.7.1 send the time of turn commands to the server. This makes it possible to avoid grinding lag sliding ( you move towards a wall, grind it shortly and turn away again, and you'll slide ) by letting the cycle on the server turn not before the time sent by the client. At the low speeds before the grind, the positional command interpretion is inaccurate and will usually turn the cycle too early.
Now, old clients don't send the command time, so this code can't work. The lag sliding is a clear disadvantage, but the earlier turn is an advantage in some situations because it makes you cover more ground, so both the new and the old players have plenty of reason to complain if they are not treated equally. Therefore, when CYCLE_FAIR_ANTILAG is set to 1 and old clients are present, this code is deactivated.
When a cycle turns in free space, the server will try to follow the client's request by matching the turn position as closely as possible. Sometimes however there are large desyncs and clients sent silly turns halfway across the grid from their current position. So, for clients that send the command time, the server will execute turns only in a time window around that command time. The width of that window is determined by CYCLE_TIME_TOLERANCE.
I observed that old clients ( 0.2.7.0 and earlier ) would be more likely to pass through walls when they received a sync from the server shortly before. So, if you set CYCLE_AVOID_OLDCLIENT_BAD_SYNC to 1, the server will not send those syncs. Whether this helps or makes matters worse by not sending enough syncs is unknown, that's why it is a setting.
The other new settings are purely local and don't have gameplay relevance on the server.
-
Self_Destructo
- Round Winner
- Posts: 317
- Joined: Tue Jun 07, 2005 1:24 am
- Location: HillBilly Country
- Contact:
-
Self_Destructo
- Round Winner
- Posts: 317
- Joined: Tue Jun 07, 2005 1:24 am
- Location: HillBilly Country
- Contact:
