Spring RTS Engine

I approve.

Tobi wrote:TBH the weights assigned to particular types of targets should be made mod configurable.

Then any mod who wants this can just set the weight for the last target epically high (it's now 25x the weight the unit would have otherwise), so the unit will always keep shooting the last user target if it is able to hit it.

+10000

I've been asking for this for ages now.

EDIT: Actually, we're not asking for the same thing. I would like this to be exposed to lua and configurable on the fly, but if this is made pre-definable, then changing it on the fly could change balance as well.

What hunterw says about balance is true, however...

lurker wrote:Is it really worth respecing parts of balance that depend on units being difficult to control?

I'm inclined to agree with lurker here. My thought is to enable the change and then patch over the units that get substantially different.

So, when is this thing cleared? I made a 10x10 field of solars, assigned some arty to fire at a specific solar, and then gave them a move order and they started picking targets at random. What am I doing wrong?

last time i tested, the units recall their target for like, 2-5 shots after you issue a move order after a direct attack order, then after those shots, it will lock to another target by its weigth.

Example in xta:

Put 3 targets at dominators range, under radar (and only radar, not identified icons/ghosts) coverage.

Ive tested with HLT commander and Popup

The dominator, only having radar coverage (without los nor previously scouted targets), will always know which is the best target to shot at (commander).

Issue a direct attack order, then a direct move order, it will still prefer the more expensive target after some shots (commander).

In my testing, actually, the dominator switched inmediatly to the best target dot, after the move order, it didnt shot one more shot to its previously given target but prefered the commander inmediatly (without knowing it was the commander).


This is because of tartgets weigths, and happened in old versions too, even when the "remember target" feature was just introduced.


Update:

actually found some sort of bug.

just a remark of what i wrote:Once dots are identified (by los), they are assigned the unit stats rite? so the commander is given a commander icon and the defense turrets are given a ghost of their own (when you leave los contact). Then its evident which unit shall be destroyed first (commander in this case).

Well.... if you turn off your radar, that information "should" be forgotten.
it is, in part, specific icons are gone(like commander icon), and so are ghost-icons (dots reapear)...

but the unit stat information is not forgotten, thats why the dominator kept firing the commander.

Only way to "erase" the information about dots and their stats is to destroy the units and place new ones in their place, that way the dominator is "confused" again.




What would be desired is,
The "direct attack" order should last till the target is dead or no longer in range, not taking into account the weigth of the units in range, but the previously given target.

yet, this behaviour can be bad at times....


Edit: also it seems radar on/off state toggle is broken, pressing x or clicking the button does the same = it turns off, then inmediatly on, or viceversa. other times it works fine.

lurker wrote:Is it really worth respecing parts of balance that depend on units being difficult to control?

I've found that this statement is the core of the widgets=cheating debate. If you play TA for the thrill/skill of managing attack formations then any opponent widget or gameplay change that automates or simplifies this reduces your advantage against players who focus on their econ.

On the other hand players who enjoy the tech rush / eco rush game don't want to manage their units so intimately.

Both players see the skill in the game differently. To one it's an action game (in which case unit control is a matter of reflexes) to the other it's a management game (unit control is incidental to production volume).

The players who play TA as an action game are not going to be happy if a widget or game change automates the action. To them automatic unit control is basically an aim bot (in fact "Auto Comm DGun" IS an aimbot).

ANY game change that makes combat easier pushes the advantage to the econ player, regardless of whether the change is really a bug fix. Any change that makes manual combat more effective gives advantage to the action player. In short you'll get complaints no matter how you do this because players do not all play spring for the same reasons.

As a side note, I watched a game last night that revealed just how inefficient you can be with a pure econ approach. A DSD player rushed 4 adv fusions and 8 adv converters by the time most players were building their first normal fusion. The player then spammed Zeuses to a waypoint near the enemy. The trouble was the enemy advanced past the waypoint and the zeuses simply walked single-file into the teeth of 3 enemy battlemechs. The battlemechs could have been defeated by even 20 Zeuses moved as a squad but instead the mechs killed HUNDREDS of them without taking any significant damage. I couldn't believe the player didn't see what was happening but obviously they assumed having the superior production was enough to win (they lost).