Spring RTS Engine

Hello all,
Just a short post to show some strange stuff happening in BA since years now and it makes the game way less enjoyable.





Here we can see air transport thats has some trouble to load a commander.
Also another strange thing :



Here we can see a Maverick Kbot that has 2 different orders : Set target on ground, that means that he has to shoot here, and 2 waypoints with repeat, so he will always go from first waypoint to second one and restart again.
What is really sad is Maverick constantly rotate his torso stupidly and he lose focus on the target every time he's changing direction for a short duration.

When u micro manually u have same problem, and this behavior happens with units I think.

Anyone has ideas to fix this?

First is non-trivial combination of both, second is game (maverick unit script) but something of a chore to fix.

As I mentioned on discord, I believe that the first is an issue of unit radius. I.E. unit radius collides with terrain (when flying), won't go down further. That might not be it, but when I was lua scripting the dragonfly (it's old script is a bit of a mess decompiled and recompiled from the original ta script) in an attempt to make it more reliable, I ran into this same issue. In fact I posted on these forums about it and was informed that it was an issue with unit radius.

Which is why I draw this conclusion. I haven't looked in the wiki, but I think lua gives us a way to easily alter radii of units. Assuming that is the case, and assuming that I have the right problem in mind, then it should be semi-trivial to simple reduce unit radii of all air transports.

We have already disabled air collision iirc.
Will reducing the radius really help even knowning that?

It seemed recompiling the script and adding a few tags to the transport defs improved the situation alot.
There are still a certain number of issues slowing the unload process (the load process seems fine now).
It's mostly due to the lack of space and the transports having troubles finding another spot to unload.
But that is at least closer to older BA situation.

--> Script recompilled from the existing BOS with linear constant = 81902.000000 vs 163840.000000 (default scriptor setting) which means distances/2
--> unitdeftags:
airStrafe = false,
airhoverfactor = 0,
bankingAllowed = false,
loadingradius = 300, (vs 220 default)
verticalSpeed = 5.0, (vs 3.0 default)

I tested disabling some airtransport related gadgets, and they didnt seem to alter the behaviour so i ruled gadgets out.

I don't know which one of those helped the most, i haven't tried em one by one, only all of them at once...

Edit:
Here are some GIFs.

Well for now transport looks "fixed", but without engine dev's helps I dont see how we can fix 2nd problem

Units shouldnt stop to aim when changing direction, also units should rotate their turrets and rdy their weapons towards the ennemies BEFORE they enter in weapon's range. But it's another problem :)



Here is an example of peewees starting to shoot Aks while they are on melee range already.

Transport area unload needs to send transports directly to unload points

Currently they all converge on 1 central point then fan out. This is pointlessly slow and all of them can be killed by 1 flak

without engine dev's helps I dont see how we can fix 2nd problem

Afaik this is within the games control - as said above, the maverick unitscript is responsible. But its not a fun thing to try and change, plus its not fully obvious (to me) what the right behaviour would be.

Transport area unload ... converge on 1 central point then fan out.

The engine controls this part, but its a separate issue to cases of failed load/unload.

Silentwings wrote:

without engine dev's helps I dont see how we can fix 2nd problem

Afaik this is within the games control - as said above, the maverick unitscript is responsible. But its not a fun thing to try and change, plus its not fully obvious (to me) what the right behaviour would be.

Transport area unload ... converge on 1 central point then fan out.

The engine controls this part, but its a separate issue to cases of failed load/unload.

The issue lies with the low AimWeaponX() call rate, which can be artificially increased with lower fireTolerance and/or by calling it manually via gadget.
I had gotten smoother aiming for flashes/pws whose weapons's aiming would be updated at a 10x - 20x higher rate with both a gadget or by decreasing firetolerance, but then the abusive calls of AimWeaponX() ended up forbidding the unit to shoot while moving. That is the complete opposite of the way we want it to behave.

Maybe a separate AdjustAim() script and AimWeaponX() script in the COB file, with AdjustAim() being called via gadgets only, while AimWeaponX() is still called every 0.5s by engine and would still return 1 whatever the AdjustAim() state is, would allow to keep the ability of units to fire while moving while the AdjustAim() script will allow cannons to follow target on turns/moves.

I honestly have troubles thinking about anything else. Having the torso not following the pelvis turns when aiming would be another possibility but it seems like more troubles to do for a probably non effective result.

I fixed the transport failing to load: https://github.com/spring/spring/pull/328

The problem is that the transport starts to hover when it is near its target.
Hovering is random, so it might never reach it for pickup.

In addition, hovering was broken. Hovering units drift to the bottom right, which makes the problem worse.

1k armatlas hovering


After 2 hours of ingame time


The screenshots are from Phoenix Annihilation. No air collision there, so it is more obvious what happens.

Thanks Spice, pro dev!!

Nah. My pull request was too ugly. But I think I was able to show why it was broken.
Rtri wrote up a real fix.

There will be no base safe without aa in spring-104.

Still, good job, I always wondered what was causing that.

CommanderSpice wrote:Nah. My pull request was too ugly. But I think I was able to show why it was broken.

Yup, which is a significant chunk of the work, so thx :)