21 spring game&engine quirks that can make you win(or lose)

[Godde]

More suited names/categorisations suggestions are welcome.
Clarifications and suitable examples are welcome.
Please point out errors if any are found.
While most of these quirks are only found in some spring games I still consider them engine based because knowledge of these behaviours/quirks increases your chances of winning in several mods.
This post is a bit lenghty.


Targeting
1. Kiting with speed
Units lead their target in order to hit but if their leading is further away than the weapon range they can't fire. This means that a target near the edge of the weapon range going away from the unit cannot be fired at because the leading is ahead of the target out of range. This creates a gamemechanic where the chasing units are put at a disadvantage either being outranged or having less units firing even though they have similar ranges as the units being chased.
This engine quirk becomes notable with units that have comparably high speed to low weapon velocity. It affects ballistic weapons aswell as lasers. I don't know to what degree it affects tracking missiles.
Notable units are Raiders and Stumpies in most spring games.

2. Hi five enemy
Some units, that have to raise their arms, open up or such to fire, can simply walk by each other without even trading a single shoot because their relative fast speed and slow aiming and/or animation makes them unable to fire in time. This can make killing raiders so much more difficult as units can just drive by your Peewees if you don't micro them in the same direction as the enemy is going in order to give them more time to fire. It can also make it harder to chase down enemies as their weapon animation/aiming has to be redone several times in the chase. Coupled with Kiting with speed this can put the chaser at a great disadvantage.
It also affects units when they are going around corners or operate in big groups. When the Line of Fire is obscured by friendly units(AvoidFriendly=1(true) ), terrain or features(AvoidFeature=1(true) ) as units won't start to aim until they got clear Line of Fire. Keeping the units in a line and not too close to the enemy will usually produce greater firepower.
This is especially notable with BA/XTA peewees and in GundamRTS.

3. Cannon 45 degree limit upwards
Ballistic weapons cannot fire at ground targets that are about 45 degrees above them. This means that units standing on a steep cliff can fire with impunity on units with ballistic weapons below them. In order to counter this the ballistic units can move away from the cliff and fire at a lower angle if the they have enough range or they have to higher ground. Note that units with good slope tolerance might be unable to return fire when they go up a steep hill even if they are in range of the enemy. This can prove crucial with Thuds and Hammers, espacially in the spring game NOTA.
I think that high trajectory ballistic weapons are unnaffected.

4. Out of LoS innaccurucy
An option that spring games can implement is to make radar dots float about and not be exactly where the unit center is. This also makes weapons be innaccurate. This can greatly affect gameplay as units with accurate weapons, such as Punisher, Snipers in BA, XTA, ZeroK, will miss a lot and unless LoS is provided their relative usefulness will diminish.

5. Attacking targets out of LoS and radar coverage.
Units will keep their lock on targets even when they are out of LoS and radar coverage. If the player specifically ordered the unit to attack or if the MoveState is set to Roam(rather than Hold position or Manouver as Manouver will make the unit return after a while if the chase is unsuccesful) the unit will follow its target until its dead.
Units will also return fire on units that are out of LoS and radar covarage although the inaccurucy will propably be even greater as most Spring games have severe accurucy reductions then. They prefer targets that are in LoS and radar covarage though.
If I recall correctly the only things that can brake a lock is Cloak and the target being loaded into a transport.

6. Weapons only being able to target the center of enemy units
Units get a center that can be targeted by weapons. That units weapon can be higher or lower than the center of that units. If the weapon is higher than then the center it means that the unit might be able to fire at enemy units while the enemies are unable to hit that unit. If the weapon is lower than the center it means that enemy units might be able to fire at that unit while the unit canÔÇÖt fire back.
Pressing alẗ́+b is the default key for debug. Then you can see unit hitboxes and unit centers(are displayed as white dots. If the unit center is inside the model you might have to go inside the unit to see it or watch the unit be built.
TargetBorderhttp://spring.clan-sy.com/phpbb/viewtop ... 59#p219659
It pose some trouble for game makers as setting the unit center can inflict that units performance. If the weapon is high and the unit center is high aswell innaccurate stuff like artillery might have trouble hitting that unit.

7. Continue to fire when holdfire
A unit will continue to fire at its target even if you set it to holdfire. You have to give a ÔÇ£StopÔÇØ command to make it stop fire.

8. Turning the left cheek
When the weapon Line of Fire is blocked units are likely to turn their left side towards the enemy. It has been this way ever since units with firearcs automatically turned towards their enemy to get the enemy in their firearc. It can cause trouble when you are trying to DGun the enemy as the commander might start turning while aiming the DGun delaying the shoot and mess up your timing. Set the commander to hold fire to avoid this.
In S44 where tanks and vehicles have directional armor this were a problem but it were solved by giving them a firearc facing forward. The firearc can still have 360 degrees covarage.

9. Units with firing arc will always assume that they are on flat ground.
Units that follows the same slope, which have upright=0, will only turn to shoot at enemies which the firing arc of the unit being on flat ground could fire at. This means that the player have to make sure that the unit is turned it the direction of the enemy if it is in steep terrain and the enemy is above or below that unit. If the unit is distracted by some other enemy it is almost impossible to make it fire on an enemy which is below or above it since it will prefer to target the enemy that or on the same level as the unit while the unit will drive towards the enemy below or above if it is targeted.
It is mostly a problem in S44 where there are quite alot of units that are turretless with very small firing arcs.

10. Weapons inside other units hitspheres will fire.
If a weapon is inside of 1 unit is inside another friendly unit that weapon will fire and hit the friendly unit. It can cause trouble when units have small footprints and big hitboxes or when they are inside a factory. Press alt+b to see hitboxes.

11. Popups and infantry
Popups, weapons that are closed and under the ground will usually check their Line of Fire according from where their weapon is when it is closed. This means that the popup might not open up to fire on the enemy because there are some small bump blocking the Line of Fire when its closed even though it would be able to fire at the enemy when its open. A way to make a popup open up is to force fire at a place where they have free Line of Fire from closed position.
Infantry in S44 suffers from a similar problem when they go prone. Since their unit center is higher than their point of fire they might be unable to fire at an enemy that can fire at them and they'll be forced to crawl slowly against the enemy. Machine gunners and other units that needs to go prone in order to fire might be unable to fire from prone position although their point of fire had free line of fire when they stood up. Those units also doesn't tend to crawl against the enemy and are harder to retreat because they will crawl as long as they have enemies in range and in Line of Fire making their retreat slow unless you set their firestate to "Hold fire". A way to make machine gunners fire more reliable is to avoid hilly areas and place them on hills and not so close to edges of cliffs, hills and small bumps.



Pathing
12. Slowing down when turning
Units with low turn rate relative to max velocity slow down when they turn even with turnInPlace set to 1(true). This makes microing flash, weasels and fast tanks more cumbersome as giving several commands to them can cause them to turn and lose speed when you need to raid, get away or just travel around the map with them. It also means that they take extra time to manouver around obstacles.
How much the unit slows down to, calculated within the engine, depends mostly on the turnRate to maxvelocity ratio if I remember correctly. Setting a specific turnInPlaceSpeedLimit can also control how much it slows down but some low turnRates with high speed can cause pathing issues. The default value for turnInPlaceSpeedLimit is set quite conservatively as many units can path well even with much higher values. BrakeRate also affects how fast units lose speed when they turn. Note that brakeRate can be set really low relative to acceleration as it seems that units rarely use all their acceleration when they speed up, atleasts that's my guess why brakeRate cause the unit to slow down very fast compared acceleration at the same values,.

13. Slowing down in turns above 45 degrees.
Even when turnInPlaceSpeedLimit is set to the same value as maxVelocity units will slow down in turns above 45 degrees as it seems. This will make them thier turns be smaller but also means that they will keep less speed if you are trying to dodge bullets.
Noticable units flash, stumpy in BA, XTA and NOTA and tanks and vehicles in S44.
Not slowing down when going backwards.
Units that are able to go in reverse will disregard turnInPlaceSpeedLimit when they drive backwards. This makes driving tanks in reverse particulary smooth in S44. S44's custom formation widget allows you to do line draw commands for single units which makes driving them in reverse easier.

14. Pathing though slopes
The pathing favor level paths rather than hilly ones even to the extent that they will go down from a ridge/hill when they are ordered to go to the other side for example. If you wan't to be sure that your units stay along the ridge or on the hill giving additional orders about 500-1000 elmos away is neccessary(Kbots on the ridges of Tundra for example). Even if units are completly all terrain(can climb 90 degrees), spiders in BA, XTA, ZK for example, will prefer going on level terrain rather than follow the cliffside. Alot of orders have to be given in proximity of each other in order for the spiders to go on the cliffsides.
It's especially hard to make spiders go on the steep sides on bridge on FolsomDam_Final.

15. Cardinal pathing over long distances.
Pathing in Spring is done in 45 degrees cardinal directions for land units. This means that units might not go in a straight line towards their ordered position even if the map is completly flat. This needs to be taken into consideration when you wan't go through holes in the enemy defence lines or go around enemy units as units might not go in a straight line towards where they are ordered to go. A few extra orders in the hole, where you wan't your units to go should asure that they go where you wan't them to.

16. Bunching up on long distances
Long distance pathing makes several mainpaths. Even if the map is completly flat and you draw a Line draw command on the other side of the map units are likely to bunch up and walk in several lines across the map. This is bad if you want to attack on a line to maximize firepower and keep your units spread out. The solution is to draw several line draw commands in succession so that the longer pathing doesn't make your units bunch up or to regroup next to the enemy before you attack. Longer pathing seems to kick in after about 500-1500 elmos.

17. Big units disregards their own hitboxes when over 4x4.
Units will path around other units and buildings. However units can't accomodate for the size of their own hitbox if it is over 4 times 4. Units with bigger footprints will try to go paths between other units, buildings and features that 4 even though their footprint is larger. This means that the player have to keep an eye on such units and order them so they don't get stuck.
Big ships in NOTA and S44 suffers from this.



Air
18. Air maxPitch preventing planes from turning in slopes.
MaxPitch makes planes unable pitch their nose more than this value when they are patrolling, moving or whatever other order that is not attacking or dogfighting. This makes it troublesome for the planes to turn when they raise their nose to avoid a mountain or such as all their pitching is used to climb and only leaves the rudders for turning. This can be overridden by giving an attack order in the direction that you wan't them to go.
When they are attacking, have a target or dogfighting they disregard maxPitch and pitch their nose at will. Notice however that if you give an attack command within their turnRadius and behind them, the planes will try to go away from that spot/target as they are trying to get further away than the turnRadius and make an attack run at that spot/target.

19. Air continous orders after refueling. NOTA
Units can be set to refuel at repair pads after running out of fuel. When they do this they will ignore orders given to them and continue whatever order they had when they ran out of fuel. This can cause frustration as they might go over enemy territory and die if you don't give them a new order after they have refueled. NOTA airplanes suffers from this. Zero-K bombers don't seem to suffer from this.

20. Air units don't do terrain check
Weapons on on air units don't do terrain check this means that the might just fire their missiles blindly into a cliff when the target is behind the cliff. Most units fly high so it is rarely a problem although it can cause trouble for toadfoots and vashps in NOTA.



Radar
21. Radar following ground
Radar covarage covers the ground. Even if something are flying way above a ridge, radar has to cover the ground in order to spot that flying thing. If an airborne radar plane flies above the sea their radar covarage will follow the bottom of the sea and mountains under the sea might even block them from seeing ships on the surface.


Feel free to discuss wheather you consider something to be a bug rather than a feature.

[knorke]

Good idea, there are quite alot of those.

The question is, who is to read this text?
And is it a guide for new players, modders or a bug report to engine devs? It seems a bit mixed right now.

Also too long winded and detailed writing makes for a hard read.
ie for 2) it could simply be:

2. Hi five enemy
Some units action may appear delayed because they have to aim their weapons beforing firing.

Unit names like "toadfoots and vashps in NOTA" "flash, stumpy in BA" is too detailed imo and few readers will know what you mean.

If it is a guide to players, make it more compact and put it on wiki, not forum. Also if note if you publish such things you imo gain a certain responsibility to keep it somewhat updated.
ie I think the 4x4 footprint thing is already fixed in the next release, with footprings as large as 7x7 or so.

If an article is about multiple games in general, it tends to become outdated junk quicker. ie the notes about S44 infantry: Should S44 eventually fix that then you really do not want to have that text part still floating around etc.

tl;dr
good idea, not sure how to make it work

[Godde]

And is it a guide for new players, modders or a bug report to engine devs? It seems a bit mixed right now.

I guess its mixed.

Also too long winded and detailed writing makes for a hard read.
ie for 2) it could simply be:

2. Hi five enemy
Some units action may appear delayed because they have to aim their weapons beforing firing.

Definetly. I thought it would be short at first but then the list started lining up and I couldn't decide if I should have excluded tags and whatnot.
Also I don't know if these sort of things should be brought as general advice or if they are demoralizing.

tl;dr
good idea, not sure how to make it work

What do you mean?

[knorke]

Also I don't know if these sort of things should be brought as general advice or if they are demoralizing.

Not sure. They kind of make good feature like a nice aiming animation look like a bug.
Should be left to game manuals to explain that things ie:
With the large cannon and heavy armor this tank dominates the battlefield. Downside are the low speed and slow turret rotation
(from http://springrts.com/wiki/Spring_Tanks# ... Heavy_Tank)

I guess its mixed.

bad I think. Players should not have to worry about pressing alt+b to look at hitboxes. Ideally they would not even need to understand such concepts as hitboxes, sadly it is somewhat needed to play spring.

If it is for modders, the info should be used to build the wiki.
ie hitbox should could be added here http://springrts.com/wiki/Unit_collision_volumes and on pathfinding there is nothing yet at all I think, only http://springrts.com/wiki/Units:MoveTypes
So a pathfinding article with basically the text from 12-17 would be good. Because anything is better then nothing

[Saktoth]

It's interesting how much effort ZK has gone to to fix most of these problems. Though some of them, like having the high aiming point on turrets meaning artillery misses, are kind of tradeoffs.

ZK uses lua to manage its bomber refuelling which is why we dont have a lot of the problems with the engine system.

Oh and this doesnt even get into the whole bonusshield thing and a bunch of other stuff.

I didnt know about the 360 degree angle forward-facing turret thing as a fix for the turn-to-the-left-if-you-cant-fire bug. Does it lead to any other complications?

[Godde]

I didnt know about the 360 degree angle forward-facing turret thing as a fix for the turn-to-the-left-if-you-cant-fire bug. Does it lead to any other complications?

Units will turn their front towards the enemy in the same fashion which is pretty nice on S44 tanks. I guess you can even make units turn their back towards their enemy in the same manner although I haven't tested.
Other than that I don't know any complications.

[Godde]

2. Hi five enemy
Some units, that have to raise their arms, open up or such to fire, can simply walk by each other without even trading a single shoot

In supcom turrets would start to aim at the enemy before they entered the turrets range.

[Google_Frog]

It looks like a mix of bugs an features.

1. Kiting with speed

If you ignore relativity this makes sense given projectile speed is comparable to unit speed. If relativity was added units would be able to fire further forwards by moving towards their target, this could lead to some very strange range harassment behaviour so I think the current system is the best choice.

2. Hi five enemy

I agree that it would be nice if units aimed even when they have no line of fire and the target is slightly beyond their range. Aiming animations can be arbitrarily slow so if something like this was added it would be nice if the game creator could set the fudge factor for pre-aiming.

3. Cannon 45 degree limit upwards

I agree this is a bit of a bug. Especially because ballistic units can hit aircraft directly above them.

4. Out of LoS innaccurucy

Purely a feature. I think the wobble makes this clear.

5. Attacking targets out of LoS and radar coverage.

I am annoyed by this bug as it prohibits games from using intel as a core mechanic. You can target an enemy commander with an LLT and whenever the commander is within radar range the LLT will have an attack arrow pointing to exactly which radar dot the commander is.

6. Weapons only being able to target the center of enemy units

This is a bit annoying but it is a decent tradeoff for an RTS engine to make. ZK has the firepoints and aimpoints of turrets set to the top of the turret so you cannot make invulnerable terraformed turrets. This creates other problems such as stupid artillery targetting, the best location to target is the foot of the turret because AOE will hit the turret if the shot misses. This also causes some strange behaviour with AOE.

10. Weapons inside other units hitspheres will fire.

Bug report: http://springrts.com/mantis/view.php?id=2407

11. Popups and infantry

Could this be fixed by moving the aimpoint around to predict the behaviour of your unit? I think aiming from the aimpoint is a decent feature that is possible to ignore by moving the aimpoint to a smart location with the script. Dominatior used to have this problem as the weapon would open and the aimpoint would move backwards which caused it to be out of range. This was simply fixed by moving the aimpoint to the middle of the unit. Dominator is simple as it has a vlaunch missile but similar things should be possible for other units.

12. Slowing down when turning

I think you made a mistake, turnInPlace = 0 should cause them to not slow down.

13. Slowing down in turns above 45 degrees.

12 and 13 used to not be issues, the behaviour worked well. There are other threads for this and hopefully it will be fixed.

15. Cardinal pathing over long distances.

I think this a a reasonable limitation for a pathfinder. Sure it would be nice to move in straight lines over distances but this is the least broken thing about the current pathfinder.

19. Air continous orders after refueling.

The air fuel system is hardcoded but technically works. ZK has a lua implementation of the entire system because customisation of the inbuilt one is so limited.

20. Air units don't do terrain check

Bug, especially annoying with ZK Licho.

21. Radar following ground

Bug.

[Godde]

1. Kiting with speed

If you ignore relativity this makes sense given projectile speed is comparable to unit speed. If relativity was added units would be able to fire further forwards by moving towards their target

Currently units can actually fire at enemies before they enter their range because of leading. It works both ways.
I think relativity would be better since it puts more emphasis on physics and because it removes the hidden defensive bonus that in no way is intuitional. Look at Scorchers in Zero-K. They both do less damage and have less range when they are chasing a target. Offcourse these changes completly changes the balance between units, raiding and defending in many if not all mods.

... this could lead to some very strange range harassment behaviour so I think the current system is the best choice.

Units would only be able to get their first shoot off and then be forced stop otherwise they would drive into range of the enemy anyway. I guess it could be used with relatively fast units with low muzzle velocities and high turn rate like recluse, crudgel and thud but is it anymore strange than dogding bullets which is also a result of similar unit stats?
Why couldn't it a be a modoption set for different weapons or such if someone feels like implementing it? You are not against the concept, right?

12. Slowing down when turning

I think you made a mistake, turnInPlace = 0 should cause them to not slow down.

Remember that fast units with low turnRate and turnInPlace=0 used to path badly? They still path bad if you set the turnInPlaceSpeedLimit to the same as their maxVelocity. I think all units get a turnInPlaceSpeedLimit calculated by the engine by default.

[Forboding Angel]

[quote="Godde"] I think all units get a turnInPlaceSpeedLimit calculated by the engine by default./quote]

Of course they do. It's half of their max velocity.

And basically google_frog addressed all your other points quite well (I'm glad he did, cause I really didn't want to have to quote all that).

[Johannes]

2. Hi five enemy

I agree that it would be nice if units aimed even when they have no line of fire and the target is slightly beyond their range. Aiming animations can be arbitrarily slow so if something like this was added it would be nice if the game creator could set the fudge factor for pre-aiming.

How can you agree with him about that when he took no formal stance? :)

I think it's fine as it is, it gives fast units a bit more survivability against unmicroed units, gives a bit more for the player to do and consider (something very interactive too) in early game when unit counts are low. And increases survivability of scouting units later which is good. Sure option for alternate behavior wouldn't hurt, but a bit pointless effort possibly.

[Forboding Angel]

How can you agree with him about that when he took no formal stance? :)

I didn't say I agreed. I said that google frog did a good job of addressing his points.

[knorke]

This will go nowhere this way.
ie I could say how imo "Cardinal pathing over long distances." is one of the reasons why units do not keep formation and like to travel in lines instead - but ultimately it is just contributing to another thread that will never be read again.

Take every bit and put it in its place on wiki, it is the only way to go. Takes more effort, but nobody will read a such long wall of text of unconnected bits of information.

[Godde]

[/quote]

I think all units get a turnInPlaceSpeedLimit calculated by the engine by default.

Of course they do. It's half of their max velocity.

I have changed the default turnInPlaceSpeedLimit so that it now depends on both maxVelocity and turnRate. This is the only way for the engine to reasonably handle all value combinations. Units that move much faster than they can turn (like S44 tanks) simply *need* to slow down a lot for sharp turns; the pathfinder is not advanced enough to create smooth wide curves for such units in the presence of obstacles/terrain.

Its something else than half their value. Different dependant on turnRate and maxVelocity ratios plus something else I think. If I only knew how to search to through the engine code...

And basically google_frog addressed all your other points quite well (I'm glad he did, cause I really didn't want to have to quote all that).

I think so too.

Take every bit and put it in its place on wiki, it is the only way to go.

I'll try to do that but I have a history of not finishing projects(not that I started any)... I mean stuff.

[knorke]

useless speculations are useless.
https://github.com/spring/spring/blob/m ... nitDef.cpp

Code: Select all

speed = udTable.GetFloat("maxVelocity", 0.0f) * GAME_SPEED;
...
turnRate = udTable.GetFloat("turnRate", 0.0f);
turnInPlace = udTable.GetBool("turnInPlace", true);
turnInPlaceSpeedLimit = ((turnRate / SPRING_CIRCLE_DIVS) * ((PI + PI) * SQUARE_SIZE)) * (speed / GAME_SPEED);
turnInPlaceSpeedLimit = udTable.GetFloat("turnInPlaceSpeedLimit", std::min(speed, turnInPlaceSpeedLimit));

No idea if that results in "half of their max velocity" but I would think no.

From what I see, turnInPlaceSpeedLimit is calculated from turnRate & maxVelocity.

[Johannes]

How can you agree with him about that when he took no formal stance? :)

I didn't say I agreed. I said that google frog did a good job of addressing his points.

I was commenting the text I quoted. Not your post.

[BaNa]

Thanks for the write-up, very nice list.

[Godde]

2. Hi five enemy

In supcom turrets would start to aim at the enemy before they entered the turrets range.

I agree that it would be nice if units aimed even when they have no line of fire and the target is slightly beyond their range. Aiming animations can be arbitrarily slow so if something like this was added it would be nice if the game creator could set the fudge factor for pre-aiming.

How can you agree with him about that when he took no formal stance? :)

Google_Frog were correct in his assessment that I would like units being able to pre-aim even though I didn't state that.

How can you agree with him about that when he took no formal stance? :)

I didn't say I agreed. I said that google frog did a good job of addressing his points.

I was commenting the text I quoted. Not your post.

Is this enough fuel for a flamewar? Peace, love and understanding, yo!