2020-09-28 06:59 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0003896Spring engineGeneralpublic2013-08-09 01:52
ReporterGoogle_Frog 
Assigned ToKloot 
PrioritynormalSeverityfeatureReproducibilityalways
StatusresolvedResolutionfixed 
Product Version94.1.1+git 
Target VersionFixed in Version94.1.1+git 
Summary0003896: 94.1.1-730 gunship movement behaviour has changed since 91.0
DescriptionTitle says it all. I want to be able to configure gunships such that they behave as they do in 91.0. The largest problem is that they must turn around before they can move in a different direction, this looks a lot worse than the old behavior and introduces an undesiredlag time to changing directed. To implement the old behaviour I would have to increase turn speed to the point that they look stupid.
Additional InformationExample: http://zero-k.info/Battles/Detail/184850

The gunships drift for a large amount of time before turning around.
TagsNo tags attached.
Checked infolog.txt for Errors
Attached Files

-Relationships
+Relationships

-Notes

~0011202

Google_Frog (reporter)

Caused by this commit https://github.com/spring/spring/commit/f0bc1affccb6246ecca3ea1e01a0f8dacc319807

~0011212

Kloot (developer)

the change in behavior is an intentional consequence, so you are referred to dealwithit.jpg

~0011214

Google_Frog (reporter)

Intentional consequence? So you get to decide to break everyone's games and make gunships look worse?

Gunships work fine in 91.0 so whatever the change is since then is unneeded. Maybe gunships are really broken in 94.1, I wouldn't know having never got that far. If that's the case then it should be simply enough to revert their behaviour to when it worked.

The simplest compromise is to add a tag to toggle this behaviour. cleanrock added such support for turnRate=0 gunships, surely it would be very easy to add a dedicated tag for this. The ticket which caused this commit was only about a bug involving construction aircraft so this workaround should only be required for construction aircraft.

~0011215

Kloot (developer)

Last edited: 2013-08-06 13:12

View 2 revisions

"break everyone's games"

Stop being such a drama queen making mountains out of molehills. Your game is not broken, your gunships still work. You may not _like_ the new behavior but that doesn't give you any reason to expect your report will be treated as a MAJOR BUG, especially without knowing the underlying reasons which I do.

"gunships work fine in 91.0 so whatever the change is since then is unneeded"

There is no single "the change" and you should understand by now "reverting their behaviour to when it worked" is not a valid argument re development.

"The simplest compromise is to add a tag to toggle this behaviour. surely it would be very easy to add a dedicated tag for this."

A toggle while possible would open the door back to 3785 which I do not care for and there will be no more static tags to control highly specific minor per-unitdef crap if I can help it.

"the ticket which caused this commit was only about a bug involving construction aircraft"

And yet again you are drawing the wrong conclusion from incomplete knowledge, because ALL gunship types were affected by it in various ways.

"cleanrock added such support for turnRate=0 gunships"

Since we are on the subject maybe you should think about how moronic this actually is first.

The engine should not "support" parameter abuse to achieve whatever the desired gimmicky behavior of the week is in any form.

~0011216

Google_Frog (reporter)

Gunships are broken in the sense that the gliding on low turnrate gunships looks really bad and the low response time makes them awful to control. I could give them all really high turnrate but that would also look bad. My gunship balance depends on their movement behaviour and turnrate so this change will require a rebalance, it's really hard to make a game when the unit behaviour (which has worked fine in the past) keeps changing.

No I do not understand why "reverting their behaviour to when it worked" is not a valid argument for development. How has their behaviour improved since 91.0? It certainly hasn't improved enough to make up for this change.

This change (and the ones leading up to it which made it required to fix a bug) has limited what the engine can do. A rotation free firing platform is not gimmicky, the old smooth acceleration gunships looked good. A tag to make them only able to fly forwards would have been nice but not at the cost of the old behaviour.

~0011217

Forboding Angel (reporter)

Kloot, this is pretty serious. It means that you can no longer effectively micro gunships and have a much better chance of flying headlong into AA because you tell them to turn around and they take 3 or 4 seconds to obey your command.

Not a good thing at all.

So yes, even if it's intended, this is a "MAJOR BUG".

~0011218

Kloot (developer)

Last edited: 2013-08-06 13:48

View 3 revisions

"Gunships are broken in the sense that the gliding on low turnrate gunships looks really bad"

This is your opinion. Another one (and you even acknowledge this) is that at the other extreme would be StarcraftII-esque movement which looks even worse. A little bit of inertia modelling (which is a common theme in Spring) is therefore the best middle road.

"the old smooth acceleration gunships looked good"

They _still_ _accelerate_ smoothly... are you even aware what you are really complaining about?

"and the low response time makes them awful to control"

1) what low response time? the time it takes them to complete a turn has not changed, just the way the turn is performed (if >= 90 degrees)
2) that's why turnrate and acceleration tags exist in the first place (and how the engine interprets those is not a guaranteed constant either)

"My gunship balance depends on their movement behaviour and turnrate"

Again, their _turnrate_ is exactly the same as it was before. This doesn't help your balance case. Your "problem" specifically is with the sliding behavior and there the turnInPlaceAngleLimit tag could be re-used to govern at what angle it kicks in, but that's the only compromise I'll make.

"A rotation free firing platform is not gimmicky"

The engine expects and requires mobile units to be able to execute any movement order at will and setting turnRate=0 pulls out that pillar from underneath it, so yes, it is.

~0011219

Kloot (developer)

Last edited: 2013-08-06 13:58

View 2 revisions

"It means that you can no longer effectively micro gunships and have a much better chance of flying headlong into AA because you tell them to turn around and they take 3 or 4 seconds to obey your command."

This doesn't become a problem (note I have already proposed a compromise) unless your game is fundamentally built around such micro mechanics, so... yeah. And even then, why is this so important but not losing a couple of sluggish tanks to turrets you didn't see in time?

~0011220

Google_Frog (reporter)

Gunships already have inertia modelling, it is called acceleration. This has been present for a long time.

My problem is exactly with the sliding behaviour. Currently if you give a move order which requires them to turn more than 90 degrees the path they trace will look jagged.

"1) what low response time? the time it takes them to complete a turn has not changed, just the way the turn is performed (if >= 90 degrees)"

The response time is longer in the sense that if you give them a move order they will continue to move in their old direction for a (possible large) amount of time before turning (in the sense of the path they trace through the world, not their heading). In effect they take more time to turn.

"2) that's why turnrate and acceleration tags exist in the first place (and how the engine interprets those is not a guaranteed constant either)"

To make gunships not awful I would have to increase their turnrate. This fast rotation would look silly for most gunships, especially the slow flying fortresses. So how did I make the gunship heading change slowly while allowing them to change directly rapidly? High acceleration. The strength of the gunship moveclass was the ability to face and move in different directions.

"The engine expects and requires mobile units to be able to execute any movement order at will and setting turnRate=0 pulls out that pillar from underneath it, so yes, it is."

This has always worked for gunships and I see no reason for it to not continue working.

"the turnInPlaceAngleLimit tag could be re-used to govern at what angle it kicks in, but that's the only compromise I'll make"

Sure, that sounds good. As long as I can set the value to 180 degrees in order to recreate the old behaviour.

~0011221

Kloot (developer)

Last edited: 2013-08-06 15:04

View 2 revisions

"Gunships already have inertia modelling, it is called acceleration."

Acceleration models _linear_ inertia, not _rotational_ inertia. The combination of acceleration and turnrate is also not a full movement description.

"they will continue to move in their old direction ... In effect they take more time to turn."

brakeRate.

"To make gunships not awful I would have to increase their turnrate."

That would be far from the only way to rebalance (one I mentioned above). I also reject the notion that gunships have suddenly become "awful", hyperbole without strong empirical evidence backing it simply causes reports to receive a decrease in priority.

"This has always worked..."

"Something has always worked" by itself is not a good enough reason to assume / demand that it will continue to always work.

Finally, on a general note, engine behaviors are not and will never be fixed for all time and by relying on them to stay the same you lock yourself to one version even more than you already do. The majority of changes are not going to get a backward-compatible toggle because it leads to an unmaintainable mess of code paths and the sooner you accept this the better.

~0011222

cleanrock (reporter)

>>"cleanrock added such support for turnRate=0 gunships"
>Since we are on the subject maybe you should think about how moronic this actually is first.

What i did was skip waiting for turn when turnRate is zero.
If you allow a turnRate of zero (which spring do atm) you shall support it.

~0011223

Kloot (developer)

I know what you did and you make the mistake of assuming that "no explicit check for bad value" means "value allowed and has no bad consequences".

~0011224

Google_Frog (reporter)

By awful I mean they are annoying to control. They can take a long time to respond to orders. So, the way around this is to increase turnrate? Then they look bad because it does not make sense for a large gunship to turn rapidly.

"Finally, on a general note, engine behaviors are not and will never be fixed for all time and by relying on them to stay the same you lock yourself to one version even more than you already do. The majority of changes are not going to get a backward-compatible toggle because it leads to an unmaintainable mess of code paths and the sooner you accept this the better. "

That should NOT be the state of affairs for engine behaviours as high level as gunship movement. I find it extremely hard to believe that there is a technical reason which makes it impossible to support the old gunship behaviour.

~0011225

Forboding Angel (reporter)

I am loathe to stoke the fires here, but I have to agree with googlefrog. This will significantly negatively impact evo, and when engine changes affect game balance I tend to get cranky.

Evo air balance is somewhat delicate, especially when it comes to gunships. THis change effectively makes them un-micro-able and imo that is quite bad.

Perhaps some sort of compromise between the current and previous behavior can be reached?

Basically that would allow kloot to fix the problem that existed initially, and allow us to have our (admittedly, probably semi broken) original gunship behavior.

~0011229

KingRaptor (reporter)

Last edited: 2013-08-07 12:39

View 3 revisions

Look, gunships in develop (I last tested with 94.1.1-826-g7f6f61d) do not make _any_ attempt to change velocity until their current heading is <= 90° from the direction of their next move goal*. Even if acceleration and/or brakeRate are 10. Even if they are moving at 10 km/s and their next waypoint is directly behind them.

*but once it is, they can have maximum acceleration in the direction they want to go regardless of their current heading

There is simply no way you can represent this as realistic or desirable behavior.

Try it yourself - it's present on any gunship, but most noticeable on ZK's Athena (armcsa).

~0011231

silentwings (reporter)

I've played with this a bit and it looks to me as though 'brakerate' is not controlling braking, but just gives a temporary speed boost in the new direction?

It's easy seen with BA t1 trans if you set brakerate=10000 or something similarly ridiculous (tested on a sudden 90 degree turn order given to a full speed trans).

~0011237

Kloot (developer)

I may look at brakerate behavior some other time.

The turnInPlaceAngleLimit tag is now functional for gunship-type aircraft.
+Notes

-Issue History
Date Modified Username Field Change
2013-07-25 16:33 Google_Frog New Issue
2013-08-06 07:47 Google_Frog Note Added: 0011202
2013-08-06 10:56 Kloot Severity major => feature
2013-08-06 11:52 Kloot Note Added: 0011212
2013-08-06 11:52 Kloot Status new => resolved
2013-08-06 11:52 Kloot Resolution open => won't fix
2013-08-06 11:52 Kloot Assigned To => Kloot
2013-08-06 12:17 Google_Frog Note Added: 0011214
2013-08-06 12:17 Google_Frog Status resolved => feedback
2013-08-06 12:17 Google_Frog Resolution won't fix => reopened
2013-08-06 12:50 Kloot Note Added: 0011215
2013-08-06 13:07 Google_Frog Note Added: 0011216
2013-08-06 13:07 Google_Frog Status feedback => assigned
2013-08-06 13:12 Kloot Note Edited: 0011215 View Revisions
2013-08-06 13:20 Forboding Angel Note Added: 0011217
2013-08-06 13:43 Kloot Note Added: 0011218
2013-08-06 13:44 Kloot Note Edited: 0011218 View Revisions
2013-08-06 13:48 Kloot Note Edited: 0011218 View Revisions
2013-08-06 13:57 Kloot Note Added: 0011219
2013-08-06 13:58 Kloot Note Edited: 0011219 View Revisions
2013-08-06 14:02 Google_Frog Note Added: 0011220
2013-08-06 14:43 Kloot Note Added: 0011221
2013-08-06 15:00 cleanrock Note Added: 0011222
2013-08-06 15:04 Kloot Note Edited: 0011221 View Revisions
2013-08-06 15:06 Kloot Note Added: 0011223
2013-08-06 15:10 Google_Frog Note Added: 0011224
2013-08-07 03:07 Forboding Angel Note Added: 0011225
2013-08-07 12:32 KingRaptor Note Added: 0011229
2013-08-07 12:33 KingRaptor Note Edited: 0011229 View Revisions
2013-08-07 12:39 KingRaptor Note Edited: 0011229 View Revisions
2013-08-07 16:32 silentwings Note Added: 0011231
2013-08-09 01:52 Kloot Note Added: 0011237
2013-08-09 01:52 Kloot Status assigned => resolved
2013-08-09 01:52 Kloot Fixed in Version => 94.1.1+git
2013-08-09 01:52 Kloot Resolution reopened => fixed
+Issue History