Unit Movement Pt. II

[Forboding Angel]

Even if it is not about any presumed delicate balance... Don't Forbs suggestions simply change the game into something else? That is not a fix.

You obviously didn't look to see what I did. The vast majority of you won't even notice a difference.

If the balance was that fragile to begin with, then it wasn't balanced at all.

@google =D

[very_bad_soldier]

armflash = {
acceleration = 0.05,
brakerate = 0.06,
maxvelocity = 3.5,
turnrate = 592,
}

And you have the gall to bitch about pathing sucking???

Why don't you do some math and figure out how long it takes 0 to turn into 3.5 by adding 0.05 a bunch of times.

Suck it.

Well, I am not so much into that unit tweaking stuff. You seem to be an absolute expert regarding that stuff because you are into that since so many years. So please excuse my following naive approach to that:

So, the Wiki says acceleration is this:

Code: Select all

The acceleration of the unit, in elmos per frame2

and maxVelocity is this:

Code: Select all

The maximum speed attainable by the unit in elmos per frame

So, a unit's speed is measured in e/f (elmos per frame). The flash accelerates at 0.05 e/f^2 to a maximum speed of 3.5. So it needs 70 frames to reach full speed, yes? AFAIK spring's simulation runs at 30fps (or 25?). So a flash needs 2,33 seconds to accelerate to full speed. Where am I wrong?

[Forboding Angel]

You aren't wrong vbs, it's gross exaggeration aimed at making a point. Those 2 seconds are enough to cause the pathfinder to lose it's mind, especially when you consider that if a unit is doing anything besides going perfectly straight it is braking and accelerating constantly, which also makes the pathfinder go nuts.

Moreover then you have to take into account the 2 seconds it takes to come to a stop. That's 4 seconds worth of fail and suck.

[Kloot]

The flash accelerates at 0.05 e/f^2 to a maximum speed of 3.5. So it needs 70 frames [2.333 seconds] to reach full speed, yes?

Yes.

Time to divulge a little secret though: in older Spring versions (those where the "pathing" was considered "good") the acceleration and brakerate tags were actually interpreted incorrectly, with the effect that units could change their speed much more easily than what was supposed to be allowed by the raw tag values. More recent Spring releases however do implement the physics the right way (effectively giving units more inertia, combined with proper turninplace=false behavior) so players whine about there being "less control over units" and "declines in pathing", yet at the same time they think setting values that better reproduce old engine behavior (which is what FA's proposal comes down to, not that he had a clue) will "change the game into something else" and "is not a solution". This is why their opinions are worthless to those in the know.

[Forboding Angel]

Unbelievable... Why do I bother to stick up for you if all you can ever do is be a jerk, kloot?

[smoth]

The flash accelerates at 0.05 e/f^2 to a maximum speed of 3.5. So it needs 70 frames [2.333 seconds] to reach full speed, yes?

Yes.

Time to divulge a little secret though: in older Spring versions (those where the "pathing" was considered "good") the acceleration and brakerate tags were actually interpreted incorrectly, with the effect that units could change their speed much more easily than what was supposed to be allowed by the raw tag values. More recent Spring releases however do implement the physics the right way (effectively giving units more inertia, combined with proper turninplace=false behavior

so kloot, given this information, the pathing "sucks(their words not mine)" for ba because the values need to be updated to reflect how they used to be interpreted? can you give an equation to alter the BA values to reflect something similar to the old values? that way I can do some code to output updated untidefs with values making the ba players happy?

[FLOZi]

The flash accelerates at 0.05 e/f^2 to a maximum speed of 3.5. So it needs 70 frames [2.333 seconds] to reach full speed, yes?

Yes.

Time to divulge a little secret though: in older Spring versions (those where the "pathing" was considered "good") the acceleration and brakerate tags were actually interpreted incorrectly, with the effect that units could change their speed much more easily than what was supposed to be allowed by the raw tag values. More recent Spring releases however do implement the physics the right way (effectively giving units more inertia, combined with proper turninplace=false behavior

so kloot, given this information, the pathing "sucks(their words not mine)" for ba because the values need to be updated to reflect how they used to be interpreted? can you give an equation to alter the BA values to reflect something similar to the old values? that way I can do some code to output updated untidefs with values making the ba players happy?

https://github.com/spring/spring/commit ... 3621f74c53

[Johannes]

20120504_141502_Comet Catcher Redux_88.sdf

Pathing woes with forbs "fix"

(204.62 KiB) Downloaded 15 times

Oh snap, forb just fixed BA *GASPED*, now we have to find somethign else meaningless and even more full of bullshit to BAWWW about. SHIIIIIIIT!!!!!!

http://springfiles.com/spring/games/bal ... ilation-32

Still doesn't seem to affect most things. Units still clump, get stuck, and go through or bounce off buildings.
I'd say the biggest issue with current pathing is that units don't respect each others footprints, neither those of other units nor buildings.


Interesting info about the accel/brake tags from Kloot though. Those ratings probably should be adjusted now that we finally know of this... You got any other critical bits of info that would help us find judge which issues are fixable modside and which are engine faults?
And interesting that you say we now have proper turninplace = false behavior, wasn't turninplace = true changed much more to match how it's supposed to work if judging by the name? Even if the old turninplace = true had its pros over both of the current values.

[smoth]

https://github.com/spring/spring/commit ... 3621f74c53

add CClassicGroundMoveType

a snapshot of "the last good version" of CGroundMoveType before my
"change nonsense" started the "pathing decline" and "gave Spring a
bad name" by "messing things up for everyone" (right BA trolls?)

to use it: "movement = { useClassicGroundMoveType = true, }" in modrules.lua

should you find that pathing wasn't as good as you imagined after all and
feel the need to make even the slightest offhand comment about it anywhere
this will get ripped out again, so better learn how to love unconditionally

this in the current release?

[FLOZi]

Current release is near meaningless if devs keep up with "release early release often" paradigm.

And at any rate, any tweaking of stats is a bandaid compared to direct comparisons with the old code.

[smoth]

Current release is near meaningless if devs keep up with "release early release often" paradigm.

Huh? how would that make it meaningless?

And at any rate, any tweaking of stats is a bandaid compared to direct comparisons with the old code.

I was asking if someone could find out the number difference/equation difference in the OLD CoDE so I could correct the values.

[Cheesecan]

Johannes is not really wrong..unless you didn't get enough praise as a child, there is no reason to assume someone is programming for your praise rather than their own interest. Of course devs are good guys but there's lots of stuff you don't see happen that never gets praised too. What i'm saying really is that it's an ungrateful job. People that stay committed are used to getting more crap than praise.

[smoth]

I don't follow the first part but yeah.

A programmer's best praise is that they don't have to revisit something. It is all we get, at least professionally that is.