Breakfast in Shrunkland
Moderator: Lucifer
- Phytotron
- Formerly Oscilloscope
- Posts: 5041
- Joined: Thu Jun 09, 2005 10:06 pm
- Location: A site or situation, especially considered in regard to its surroundings.
- Contact:
So we tried changing the basic cycle_accel from 15 to 10. I thought that worked pretty well. But...
Then just a little while ago I was looking through my settings.cfg (was altering settings for local game for when I check out new graphics I's makin'), and I was reminded of a couple nice little things, which I experimented with locally:
First, CYCLE_ACCEL_SLINGSHOT, which is the "multiplicator to CYCLE_ACCEL if you're between your wall and another wall." It appears that the default is 1. I propose experimenting with lowering this. Setting it to a big fat zero is very tempting but then I discovered that even in instances where I would go through tunnels and wasn't grinding, zero about had the effect of slowing me down, basically negating cycle_accel, and I don't think we want that for gameplay. Setting it to 0.2 felt okay perhaps. But then, like I said, that was local. It may act differently in Shrunkland, hence the experimentation.
Second, there's CYCLE_SPEED_DECAY_ABOVE. This is basically the deceleration rate back to cycle_speed, from what I could tell. Default appears to be 0.1. I dunno what Shrunkland has it set to because it's currently down. But I propose upping that a little bit (i.e., increasing deceleration). In my messing with it, slight changes seemed to have a fairly dramatic effect. Setting it to a low single digit (I forget which exactly) negated acceleration entirely, and that's no good. So, yeah, experimentation in the 0.1-1 range, probably.
If these things are changed, we might determine that keeping cycle_accel at 15 is still good afterall. I dunno. So what say you, Swampy?
Then just a little while ago I was looking through my settings.cfg (was altering settings for local game for when I check out new graphics I's makin'), and I was reminded of a couple nice little things, which I experimented with locally:
First, CYCLE_ACCEL_SLINGSHOT, which is the "multiplicator to CYCLE_ACCEL if you're between your wall and another wall." It appears that the default is 1. I propose experimenting with lowering this. Setting it to a big fat zero is very tempting but then I discovered that even in instances where I would go through tunnels and wasn't grinding, zero about had the effect of slowing me down, basically negating cycle_accel, and I don't think we want that for gameplay. Setting it to 0.2 felt okay perhaps. But then, like I said, that was local. It may act differently in Shrunkland, hence the experimentation.
Second, there's CYCLE_SPEED_DECAY_ABOVE. This is basically the deceleration rate back to cycle_speed, from what I could tell. Default appears to be 0.1. I dunno what Shrunkland has it set to because it's currently down. But I propose upping that a little bit (i.e., increasing deceleration). In my messing with it, slight changes seemed to have a fairly dramatic effect. Setting it to a low single digit (I forget which exactly) negated acceleration entirely, and that's no good. So, yeah, experimentation in the 0.1-1 range, probably.
If these things are changed, we might determine that keeping cycle_accel at 15 is still good afterall. I dunno. So what say you, Swampy?
- Jonathan
- A Brave Victim
- Posts: 3391
- Joined: Thu Feb 03, 2005 12:50 am
- Location: Not really lurking anymore
CYCLE_SPEED_DECAY_BELOW and CYCLE_SPEED_DECAY_ABOVE were previously hardcoded. They're there to keep a cycle's speed near CYCLE_SPEED, roughly like this:
CYCLE_ACCEL_SLINGSHOT multiplies wall acceleration if you're grinding two walls and at least one of them is yours. Note that you're grinding when you're closer than CYCLE_WALL_NEAR, which is 6 by default.
Code: Select all
baseSpeed = CYCLE_SPEED * 2 ^ (.5 * CYCLE_SPEED_FACTOR);
if(speed < baseSpeed) {
acceleration += (baseSpeed - speed) * CYCLE_SPEED_DECAY_BELOW;
} else {
acceleration += (baseSpeed - speed) * CYCLE_SPEED_DECAY_ABOVE;
}
I'm ok with tweaking the server, I'd like us to get the settings as nice as possible.If these things are changed, we might determine that keeping cycle_accel at 15 is still good afterall. I dunno. So what say you, Swampy?
As for the server being down, we had a snow storm last night and we lost power for over 4 hours. Just about any sort of inclement weather means I'm without power for a couple of hours - guaranteed. I live in a town with a population of 500, so we're the last to get our service back when there's a storm - too
- Phytotron
- Formerly Oscilloscope
- Posts: 5041
- Joined: Thu Jun 09, 2005 10:06 pm
- Location: A site or situation, especially considered in regard to its surroundings.
- Contact:
Yeah, that's why I reckoned values may act differently in Shrunkland. I dunno what cycle_wall_near is there, and that's probably not something that should be changed. So, experimentation.Jonathan wrote:Note that you're grinding when you're closer than CYCLE_WALL_NEAR, which is 6 by default.
Glad you're receptive to it, Swampy.
- CoffeeTeeCat
- On Lightcycle Grid
- Posts: 49
- Joined: Sun Jan 01, 2006 12:51 am
- Location: 02152930435061
- Contact:
i feel better with cycle_accel is 10 and games are more exciting than before.
more controlable and more close combat-needed.
less extra high speed when i go through between the walls.
and how about cycle_ping_rubber, it is set to 7 now.
i think it is still high value with this speed.
like me with a little high ping player, _ping_rubber is a good reason.
but i can survive a little longer than i play in local games.
if i have any chance to play with you swampy, try to set it 4 (or 3).
and eh we can still do PUSH walls.
it works to defeat wall grinders, but too much.
i think it's not a technique or anything.
it is just a rubber usage. >how much did you use rubbber when hitting wall.
*i sniffed around the settings of shrunkland.
cycle_wall_near 8
cycle_accel_offset 2
cycle_accel_offset is also an important part of accerelation settings.
and new feature of cycle_accel like _slingshot, _decay_above, _decay_below,
if you change one of it to defferent value from default,
clients older than 0.2.8_beta3 will not be allowed in.
*thank you swampy for decreased _ping_rubber.
i think it's going fine.
more controlable and more close combat-needed.
less extra high speed when i go through between the walls.
and how about cycle_ping_rubber, it is set to 7 now.
i think it is still high value with this speed.
like me with a little high ping player, _ping_rubber is a good reason.
but i can survive a little longer than i play in local games.
if i have any chance to play with you swampy, try to set it 4 (or 3).
and eh we can still do PUSH walls.
it works to defeat wall grinders, but too much.
i think it's not a technique or anything.
it is just a rubber usage. >how much did you use rubbber when hitting wall.
*i sniffed around the settings of shrunkland.
cycle_wall_near 8
cycle_accel_offset 2
cycle_accel_offset is also an important part of accerelation settings.
and new feature of cycle_accel like _slingshot, _decay_above, _decay_below,
if you change one of it to defferent value from default,
clients older than 0.2.8_beta3 will not be allowed in.
*thank you swampy for decreased _ping_rubber.
i think it's going fine.
Last edited by CoffeeTeeCat on Sat Feb 18, 2006 2:35 pm, edited 2 times in total.
- Phytotron
- Formerly Oscilloscope
- Posts: 5041
- Joined: Thu Jun 09, 2005 10:06 pm
- Location: A site or situation, especially considered in regard to its surroundings.
- Contact:
Yes. And that latter part can be decreased even more if we decide to lower slingshot.CoffeeTeeCat wrote:i feel better with cycle_accel is 10 and games are more exciting than before.
more controlable and more close combat-needed.
less extra high speed when i go through between the walls.
I personally think all of this should probably remain unchanged, otherwise it might alter the dynamics too much so it's no longer fundamentally Shrunkland.CoffeeTeeCat wrote:and eh we can still do PUSH walls.
it works to defeat wall grinders, but too much.
i think it's not a technique or anything.
it is just a rubber usage. >how much did you use rubbber when hitting wall.
*i sniffed around the settings of shrunkland.
cycle_wall_near 8
cycle_accel_offset 2
cycle_accel_offset is also an important part of accerelation settings.
If that's so, I wouldn't consider it a bad thing. Those players would just need to download the latest version. I mean, there's no downside to that, is there?CoffeeTeeCat wrote:and new feature of cycle_accel like _slingshot, _decay_above, _decay_below,
if you change one of it to defferent value from default,
clients older than 0.2.8_beta3 will not be allowed in.
- CoffeeTeeCat
- On Lightcycle Grid
- Posts: 49
- Joined: Sun Jan 01, 2006 12:51 am
- Location: 02152930435061
- Contact:
ah i was just concerned by the problem that people with previous version cannot get into Shrunkland caused by changing the settings..
if lowed slingshot make the games exciting, that would be nice.
sure if swampy said yes, totally yes.
i set _slingshot to 0.4 or 0.5, i felt tunneling was like acceleration on one wall.
less accerelation of slingshot, the games requires more shrunken battle,
but also all the players will be ease to get out from the box?
then we shall be going to make more shrunken box or get into the box.
(just in my thought.)
i also think it should keep the value of _offset or something related settings stay.
cuz why Shrunkland behaves Shrunkland.
and it's bit complex to make settings totally balanced.
i just posted about it cuz i saw Jonathan and Oscilloscope's previous post about _wall_near.
if lowed slingshot make the games exciting, that would be nice.
sure if swampy said yes, totally yes.
i set _slingshot to 0.4 or 0.5, i felt tunneling was like acceleration on one wall.
less accerelation of slingshot, the games requires more shrunken battle,
but also all the players will be ease to get out from the box?
then we shall be going to make more shrunken box or get into the box.
(just in my thought.)
i also think it should keep the value of _offset or something related settings stay.
cuz why Shrunkland behaves Shrunkland.
and it's bit complex to make settings totally balanced.
i just posted about it cuz i saw Jonathan and Oscilloscope's previous post about _wall_near.
- Phytotron
- Formerly Oscilloscope
- Posts: 5041
- Joined: Thu Jun 09, 2005 10:06 pm
- Location: A site or situation, especially considered in regard to its surroundings.
- Contact:
Yeah, we definitely still want there to be acceleration when in a tunnel, otherwise that and mazing and whatnot would indeed be too easy. I drew up this little diagram-type thing to illustrate what I think might be ideal, also considering CYCLE_WALL_NEAR. The idea is this:
The acceleration produced in situation A should equal that of situation B. Additionally, if acceleration in A = B, then likewise, C should equal D. (One of the settings experts, let me know: Would that be automatic? Does CYCLE_ACCEL_SLINGSHOT apply equally, regardless of distance from the wall, so long as it's within CYCLE_WALL_NEAR?)
See footnote.
Now, to go further, and again appealing to the settings experts who are also math geeks. I'm thinking about reducing or eliminating the need for trial-and-error tweaking.
Given that all these physics are math-based, would the following be possible: Come up with a formula which contains variables representing CYCLE_SPEED, CYCLE_ACCEL, CYCLE_WALL_NEAR, and any other relevant settings. Then plug in values for those settings, producing the value needed for CYCLE_ACCEL_SLINGSHOT to accomplish the above described effect.
(If that is indeed possible, then conceivably folks could come up with other formulas used to accomplish different effects, which could be very handy for server admins.)
* I just realised, CYCLE_ACCEL_SLINGSHOT won't apply if a cycle is between two walls, neither of which is its own, will it? Damn. Not only does that make my diagram inaccurate, but it could make things really strange in gameplay. Imagine you're between two walls, one your own, and one another's. CYCLE_ACCEL_SLINGSHOT will restrain your acceleration. But then, you move from that tunnel into another where you're now between two walls, neither of which are your own. You'd get a sudden burst in acceleration, wouldn't you. Hmm. I think it would be better if CYCLE_ACCEL_SLINGSHOT applied when between any two walls, no matter to whom they belong. Nevertheless, I still think it's worth experimenting with—whenever we get around to it, heh.
Um, as for my illustration, just imagine the blue tail is a yellow one instead, heh. Not gonna redo it.
The acceleration produced in situation A should equal that of situation B. Additionally, if acceleration in A = B, then likewise, C should equal D. (One of the settings experts, let me know: Would that be automatic? Does CYCLE_ACCEL_SLINGSHOT apply equally, regardless of distance from the wall, so long as it's within CYCLE_WALL_NEAR?)
See footnote.
Now, to go further, and again appealing to the settings experts who are also math geeks. I'm thinking about reducing or eliminating the need for trial-and-error tweaking.
Given that all these physics are math-based, would the following be possible: Come up with a formula which contains variables representing CYCLE_SPEED, CYCLE_ACCEL, CYCLE_WALL_NEAR, and any other relevant settings. Then plug in values for those settings, producing the value needed for CYCLE_ACCEL_SLINGSHOT to accomplish the above described effect.
(If that is indeed possible, then conceivably folks could come up with other formulas used to accomplish different effects, which could be very handy for server admins.)
* I just realised, CYCLE_ACCEL_SLINGSHOT won't apply if a cycle is between two walls, neither of which is its own, will it? Damn. Not only does that make my diagram inaccurate, but it could make things really strange in gameplay. Imagine you're between two walls, one your own, and one another's. CYCLE_ACCEL_SLINGSHOT will restrain your acceleration. But then, you move from that tunnel into another where you're now between two walls, neither of which are your own. You'd get a sudden burst in acceleration, wouldn't you. Hmm. I think it would be better if CYCLE_ACCEL_SLINGSHOT applied when between any two walls, no matter to whom they belong. Nevertheless, I still think it's worth experimenting with—whenever we get around to it, heh.
Um, as for my illustration, just imagine the blue tail is a yellow one instead, heh. Not gonna redo it.
Last edited by Phytotron on Fri Sep 04, 2015 3:35 am, edited 1 time in total.
The math guy says: SLINGSHOT = .5 does that within the limitations you noticed.
SLINGSHOT is really only there to reduce the efficiency of humping walls for speed, and it probably is not a very good idea: since it gets activated, as you observe correctly, whenever an own wall is nearer than CYCLE_WALL_NEAR, it can have some odd and unexpected side effects.
Maybe, as a real gameplay regulation, two values should be collected form walls: the sum of the individual accelerations, and the maximum of the individual accelerations. A setting can then blend between these two values. You can then have it that whenever you're grinding one wall closely, a second wall does not give you any additional boost.
SLINGSHOT is really only there to reduce the efficiency of humping walls for speed, and it probably is not a very good idea: since it gets activated, as you observe correctly, whenever an own wall is nearer than CYCLE_WALL_NEAR, it can have some odd and unexpected side effects.
Maybe, as a real gameplay regulation, two values should be collected form walls: the sum of the individual accelerations, and the maximum of the individual accelerations. A setting can then blend between these two values. You can then have it that whenever you're grinding one wall closely, a second wall does not give you any additional boost.
- Phytotron
- Formerly Oscilloscope
- Posts: 5041
- Joined: Thu Jun 09, 2005 10:06 pm
- Location: A site or situation, especially considered in regard to its surroundings.
- Contact:
Shouldn't [Swampy] update Shrunkland to 0.2.8.0 final (or 0.2.8.1, which is supposedly imminent) ASAP because of this security risk thing, and probably take down the beta_4 version in the meantime?
***
On another note, in case anyone is curious, awhiles back we changed cycle_speed_decay_above from the default 0.1 to 0.3. A subtle difference that some players might not notice, but I think it has made a significant change in gameplay, for the better. With that I'd say the cycle_accel_slingshot thing can just be left alone, especially given the above reasons and descriptions and yadda yadda.
***
On another note, in case anyone is curious, awhiles back we changed cycle_speed_decay_above from the default 0.1 to 0.3. A subtle difference that some players might not notice, but I think it has made a significant change in gameplay, for the better. With that I'd say the cycle_accel_slingshot thing can just be left alone, especially given the above reasons and descriptions and yadda yadda.