Spring RTS Engine

SA todo list:
*make AA stop shooting at planes being built in an air lab.
*make Intrusion Countermeasure System decloak cloaked units.
*make a new UI(new icons,a new look and structure for menus,themed decorations).
*fix Bladewing behavior when sent to patrol.
*make a widget to change the way the camera zooms in and out so when your fully zoomed you see the entire battlefield from the top.
*make a widget to force icons on units from a certain distance.
*make high quality icons with symbols and the ability to flash and blink.
*make a widget to help align metal extractors on metal spots when the camera is zooming out.
*make new section rules so that cons do not get selected when are mixed with units able to attack and air is easier to select out of a unit mix.
*make a widget similar to team platter or Xray but only for construction units.
*integrate central ai in a more effective way into the gameplay.
*make new visual effects.
*make a widget to allow to drag commands without breaking a queued commands tree.
*optimize the ui and keyshortcuts to be as intuitive and simple as possible.
*make new intro shots for SA.
*integrate BA team com ends into SA modoptions.
*make sa ip free when it becomes possible.

New SA is out.
V1.71.
Fully compatible with the new spring.
SA is mod which attempts to create a competitive friendly unit balance where all units have their place and can all be effectively used in combat as opposed to only being effective and usable in theory.

In SA a set of equations is used to function as the spine of the balance on which human subjective balancing has been applied.

Some of the more tangible differences between BA and SA are:
*The player's units and turrets can shoot one through the other.
*t1 missile trucks are anti-air only.
*flash and gator are less dominant and balanced to give all T1 units a chance while still remaining very effective at raiding in wide open spaces.
*Defensive structures are more effective.
*air units are more viable.
*T1 artillery is more useful and requires lees micromanagement.
*T2 units are balanced correctly and the second Tier is meant to function as the main tier around which the 1st and 3rd revolve.
*air defenses,both T1 and T2 static turrets act as an appropriate defense to air units.
*units speed is generally a bit slower.
*corvettes are lighter.
*all torpedo launchers(T1 and T2) now act a bit more as defences versus underwater entities and less as ship counters,that role is better filled by the floating Hlt.

While units are those used in BA their qualities have changed and each and every unit had its statistics modified.

SA download page with screenshots :
http://spring.jobjol.nl/show_file.php?id=1334

When did SA turn into Xta?

well this is actually pretty outdated but still some of it is correct.
SA's goals now are reintegrate some features from OTA into it.
The first main thing is to allow air units to move like they do in OTA,which enabled much more control and rewarded good micromanagement of Your air force,unlike the uncontrollable and chaotic behavior spring is limited to.
The second is to stop units and turrets to automatically shoot at radar blips.
These 2 coupled with turrets and units shooting through one another(as long as they are yours) like in OTA and like it already is now in SA,IMO,and along with a better and more balanced unit stats will result in an excellent gameplay.

Why would you want to stop units shooting at blips? It would just mean a lot of pointless frantic micro. There is never a situation when you would not want units shooting at blips.

It doesnt mean a lot of frantic micro.
It means you are dependant on scouting los and to get your defenses maximum effeciency you need units.
It worked well in OTA no reason why it shouldnt in Spring.

re not shooting at radar blips: don't bother. one widget and you've got it back, and quite likely it'll be smarter than default behavior.

Nope. Render it in unsynced luarules, don't expose the locations to anything. LuaUI doesn't even know how many blips are in range, much less where they are.

lurker wrote:Nope. Render it in unsynced luarules, don't expose the locations to anything. LuaUI doesn't even know how many blips are in range, much less where they are.

Yeah, that was my idea too - when I'm done with my current projects I might do that for HA - radar is lua-only, and just renders blips to the user's screen.

But still, couldn't you make a Lua UI widget that could talk to to the gadget that handles the radar-visible unit locations and feeds those locations to units?

The mod maker would have to change the gadget to make it talk back. And why would they do that?

lurker: won't enterradar/exitradar unsynced call-ins still be called? or do you want to reimplement radar LOS in synced lua? anyway, those unsynced callins could use a modinfo setting if they don't have it now.

imbaczek wrote:lurker: won't enterradar/exitradar unsynced call-ins still be called? or do you want to reimplement radar LOS in synced lua? anyway, those unsynced callins could use a modinfo setting if they don't have it now.

So you can use GetAllUnits() instead?

Yeah, recoding radar in lua is probably the best way. It's not that heavy on math.

lurker wrote:Yeah, recoding radar in lua is probably the best way. It's not that heavy on math.

Particularly since, if you're going for OTA-style radar you'd leave out LOS and do fixed radius instead.

jK wrote:So you can use GetAllUnits() instead?

point taken. a tag that disables access to any radar LOS information in unsynced Lua. dunno how hard that'd be.

re radar in Lua: needs a smart algo, trivial O(units*radars) won't do IMHO. there's GetUnitsIn* family, not sure if it's any better though.

Just copy what spring does with circular.

imbaczek wrote:

jK wrote:So you can use GetAllUnits() instead?

point taken. a tag that disables access to any radar LOS information in unsynced Lua. dunno how hard that'd be.

re radar in Lua: needs a smart algo, trivial O(units*radars) won't do IMHO.

So you'd need a synced module that exposes the radar-synced units to an unsynced widget right? I'm just trying to understand - I've only just started dabbling in Spring's lua code.

Isn't there a Lua call for "get all units in range X of unit Y?" You could use that for each radar, and then do a passthrough to cull out redundant units, right? That would just get you circular radar which is enough for OTA clones.

I wouldn't mind units not being able to shoot at the radar dots if there isn't a LOS.

As long as the Targeting Facility works as it did in OTA, as it was the only unit that allowed units to fire at radar blips without active scouting.

Tbh, removing radar dot targeting might slow the game down, and would need alot of solid testing to ensure the balance of the game is maintained.

It will require some thinking but shouldn't mess things too much since los was calculated in the equation so there is no reason why it shouldn't work well now.
But if u draw radar blips using lua will it be possible to force fire the units?and i don't mean the land near them I mean the lua dots themselves.
If you cant force fire them it will take away of the power of long range weapons.
In small battles involving only small amounts of units force firing radar dots might come in handy as a tactical choice of micro spending.
It has to allow force fire as well..

That's where it gets hard.

Alternate approach I already mentioned in a PM: is there a way to make a unit that units will not auto-fire on, but will only attack when ordered to do so? In that case, a hacky approach would be to graft an invisible ghost to every unit. This "ghost" is radar-visible and only manually targettable, and all other units are radar-invisible.