View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
---|---|---|---|---|---|---|---|---|---|
0003896 | Spring engine | General | public | 2013-07-25 16:33 | 2013-08-09 01:52 | ||||
Reporter | Google_Frog | ||||||||
Assigned To | Kloot | ||||||||
Priority | normal | Severity | feature | Reproducibility | always | ||||
Status | resolved | Resolution | fixed | ||||||
Product Version | 94.1.1+git | ||||||||
Target Version | Fixed in Version | 94.1.1+git | |||||||
Summary | 0003896: 94.1.1-730 gunship movement behaviour has changed since 91.0 | ||||||||
Description | Title 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 Information | Example: http://zero-k.info/Battles/Detail/184850 The gunships drift for a large amount of time before turning around. | ||||||||
Tags | No tags attached. | ||||||||
Checked infolog.txt for Errors | |||||||||
Attached Files |
|
Notes | |
Google_Frog (reporter) 2013-08-06 07:47 |
Caused by this commit https://github.com/spring/spring/commit/f0bc1affccb6246ecca3ea1e01a0f8dacc319807 |
Kloot (developer) 2013-08-06 11:52 |
the change in behavior is an intentional consequence, so you are referred to dealwithit.jpg |
Google_Frog (reporter) 2013-08-06 12:17 |
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. |
Kloot (developer) 2013-08-06 12:50 Last edited: 2013-08-06 13:12 |
"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. |
Google_Frog (reporter) 2013-08-06 13:07 |
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. |
Forboding Angel (reporter) 2013-08-06 13:20 |
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". |
Kloot (developer) 2013-08-06 13:43 Last edited: 2013-08-06 13:48 |
"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. |
Kloot (developer) 2013-08-06 13:57 Last edited: 2013-08-06 13:58 |
"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? |
Google_Frog (reporter) 2013-08-06 14:02 |
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. |
Kloot (developer) 2013-08-06 14:43 Last edited: 2013-08-06 15:04 |
"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. |
cleanrock (reporter) 2013-08-06 15:00 |
>>"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. |
Kloot (developer) 2013-08-06 15:06 |
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". |
Google_Frog (reporter) 2013-08-06 15:10 |
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. |
Forboding Angel (reporter) 2013-08-07 03:07 |
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. |
KingRaptor (reporter) 2013-08-07 12:32 Last edited: 2013-08-07 12:39 |
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). |
silentwings (reporter) 2013-08-07 16:32 |
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). |
Kloot (developer) 2013-08-09 01:52 |
I may look at brakerate behavior some other time. The turnInPlaceAngleLimit tag is now functional for gunship-type aircraft. |
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 |