Spring RTS Engine

By popular request two years ago, I made a widget to do an area guard of multiple units. Guards that can assist and/or repair will do so as needed to any units within their guarded blob. Combat unit guards that are fast enough surround the guarded blob in a circle to protect it.

download

GitHub project

Any selected units within the area guard circle will be ignored as guard targets (so that units aren't guarding themselves). Any blobs with overlapping units will be merged. This includes single units, so that if you guard a unit already within a blob, you'll guard the whole blob.

When shift is pressed, a faint blue circle will show under guard blobs.

The encircling behaviour of combat units also applies to the normal one-unit guard command.

To use it, you need to assign a key in uikeys.txt to areaguard.

Made a widget for similar behaviour on numbered groups

I like this very much. Ill have to try it (or watch someone using it) ingame :)

Made some updates (visual indicators, blob merging). Adding a custom command is wonky. Is it possible to modify the guard command to accept either ICON_MODE (1) or ICON_AREA (4) parameters, like reclaim or attack?

and now i learn that Jools already made something similar for XTA (but without the protective aspect, i think).

Jools wrote:-- (Why are you even reading this, go out in the sun and play with the kids.)

Yes, but nobody uses it. It's too complicated.

I don't even use it myself, because it should filter out non-military units such as windmills to be efficient.

This is really nice, but I don't know what about it, but it does NOT play nice when trying to add a hotkey and menu button in integral menu.

Are you see the command is set up correctly? Cause it appears in the orders menu even when nothing is selected.

Edit: Yeah the command is not declared properly and I don't know enough about it to fix it.

This widget is fantastic though. Guard behavior that doesn't suck. Can you fix the command? I'll lurve you forever!

i think so? we'll see, i may have started a few too many spring projects recently

It can be queued and won't mess with other queued commands now. I remain confused by menus and custom commands. It doesn't show up at all in the BA Red menu. In fact, with the Red menu turned on, the command isn't registered at all and cannot be accessed via hotkey. It does show in the engine menu, in a dumb place (between the previousmenu and nextmenu buttons). Apparently it shows up in Evo's menus, even when it shouldn't.

How does one properly define a custom command? Here is the definition currently:

resolved command queue issues, and now it should only show up for units that can guard.

forb, does this play nicely now?

I'll check it out. God I hope so, because this guard behavior is frigging awesome.

I have a feeling because of the way units in evo move it is probably more effective in evo than stuff like BA, etc. Probably the same for ZK to some extent as well.

I have no idea when I'll have some free time. I'll try to get to it today after work, but no promises. However, that said, friday is my evo crunch day because of the get-togethers, so if not tonight, definitely by tomorrow night.

Looks useful - I am tempted to test this out with a view to including it in BA.

I guess you have got it now - but in case not - to properly add a custom command you can do as in this gadget (see definition near top, call to gadgetHandler:RegisterCMDID within Initialize, then InsertUnitCmdDesc in UnitCreated): http://imolarpg.dyndns.org/trac/balates ... e_move.lua. I've never tried to do it from with a widget, I would guess it works much the same, but I would have this as a gadget anyways

Are you planning to work on this in future or is it basically 'finished' now?

Thanks for the tip. As I understand it now, the proper way would be to define the command in a gadget. I just wanted it to be widget only because who knows what games want to do. But if you want to add it to BA, and forb wants to add it to Evo, I think the best way would be to write a small gadget that just redefines the Guard command to be ICON_UNIT_OR_AREA, so that players don't have to deal with two different menu buttons / shortcut keys. That would also allow (I think?) right clicking on a unit and dragging to turn it into an area, like area attack. I would need to modify the widget slightly to use the modified guard command. I think that would be less work than converting all my unsynced command queue hocus-pocus to a gadget? I don't mind working on it a bit more, but I'd like to avoid a total rewrite.

Yes - good idea. I think it would be left click and drag on the ground to draw circles rather than right click and drag on units.

It is done here: https://code.google.com/p/zero-k/source ... aguard.lua

Block at line 158 is commented due to fellow dev complaining that he dislikes the rightclick-drag on a unit issuing an area-guard, preferring it continues to be a customformation-move. As it's commented, the areaguard can only be issued with the button press or hotkey.

I changed CMD.GUARD to type = ICON_UNIT_OR_AREA and got it working with the widget fine. I can't get right click and drag on a friendly unit to do an area guard though (after using the block that's commented out in CarRepairer's gadget). Investigating this has lead me to some confusion:
BA has a gadget, cmd_areaattack.lua, that inserts its own custom area attack command. However, according to http://springrts.com/wiki/Lua_CMDs Spring has its own native area attack command, which leads me to believe this gadget is old and does nothing? How does one setup a command to work like area attack--switching automatically to the area version of the command when right-click dragging?

PS the one that uses a gadget to edit the guard command i'm keeping here: https://github.com/zoggop/SpringBlobGuardIntegrated

Oh. It's just because custom formations is getting in the way.

So what's worse, seperating area guard command from guard command, or modifying the guard command to accept areas? The latter seems better in every way except: if some poor widget decides to assume that the first parameter of guard is a unit ID.

if some poor widget decides to assume that the first parameter of guard is a unit ID.

More info about the problem here?

zoggop wrote:So what's worse, seperating area guard command from guard command, or modifying the guard command to accept areas? The latter seems better in every way except: if some poor widget decides to assume that the first parameter of guard is a unit ID.

You could do what we did in the xta one:

http://code.google.com/p/xta-springrts/ ... ta.lua#102

In CommandNotify: if #parameters == 1, then normal guard, else area guard.

It's better not to make any default action on right click, that interferes with a number of other things that are usually reserved for that functionality in other widgets.

And yeah, I prefer to have it as a widget and not gadget. Gadgets cannot be turned off as easily in case someone wants to do that.

Edit/addendum: In xta, this is separated into a widget and gadget: the widget does everything basically, except adding the new command to build menu. That's insted done by a gadget:

http://code.google.com/p/xta-springrts/ ... ommand.lua

The only thing I couldn't figure out is how to change the map draw colour of the command (I'd like the colour to be blue for guard instead of default white), if you figure that out then please tell me how to do it.

Jools wrote:if #parameters == 1, then normal guard, else area guard.

right. i should have clarified. i'm not worried about my own widget not knowing what to do with area vs unitID. i'm worried about some other widget not bothering to check how many parameters a guard command has (this seems reasonable), and assuming that cmdParam[1] of a guard command is a unitID (when in fact it would be an x coordinate).

Ah, I also see that in the xta one, you've added a new command, AREA_GUARD, whereas I'm considering (in a gadget)

My issue with using a new command is that while I can replace the normal guard command in the build menu, the hotkeys remain linked to the normal guard command. And if I make the new command only ICON_AREA and not for guarding individual units, then players have to define two hotkeys and use two build menu buttons.

Jools wrote:The only thing I couldn't figure out is how to change the map draw colour of the command

I couldn't figure this out either. I tried , but maybe this only works for custom commands, not default commands?