Spring RTS Engine

Could you not just repeatedly search for the nearest repairable unit within the radius? Better than relying on the existing loop which cant be modified, make your own instead!

Also why should you intercept these patrol etc commands? You could just hide them from the Ui so the user cannot directly issue them.

I thought it was because guard and patrol will call them automatically?

Meh, just test it, by writing an AllowCommand() loop that shows whether those are Commands or whether the engine doesn't even let Lua know they're happening.

bobthedinosaur wrote:I thought it was because guard and patrol will call them automatically?

And guard and patrol really aren't all that complex, most of the complexity arises from the combinations of their sub commands, meaning re-implementing them isn't as hard as you'd imagine.

Argh wrote:You sure that something like this won't work, substituting CMD_CAPTURE with CMD_REPAIR and dropping the command if conditions aren't met? It works great with Capture, effectively forbidding the command if not CanBeHacked...

That is something completely different. You aren't intercepting area capture there and blocking it. (does area capture even exist? I don't remember.)

You are just providing a custom default command for certain units. AFAIK that doesn't prevent the user from still giving capture commands on the particular units, nor does it have anything to do with the subject being discussed. (Which is blocking engine-issued XXX commands as part of a area-XXX command or another `highlevel' command such as patrol or fight.)

AF wrote:Could you not just repeatedly search for the nearest repairable unit within the radius? Better than relying on the existing loop which cant be modified, make your own instead!

Of course. Then you are doing exactly what I said:

Tobi wrote:To do this properly you need to reimplement ALL the `highlevel' commands that can possibly issue the individual command you want to block in Lua, or (preferably) fix the engine.

AF wrote:Also why should you intercept these patrol etc commands? You could just hide them from the Ui so the user cannot directly issue them.

Of course.

It's a completely different subject though. Personally I don't think it's nice for users to only be able to repair stuff using a patrol command that's not even visible in the UI. (so no chance for new players to find out about it.)

Or, if your users are happy with that, you could obviously also completely block area, fight, and patrol commands.


EDIT: if you're going to reimplement such commands anyway and are considering to do it in a generic way, here are some things you may want to consider:

• don't help allies build unless set on roam
• don't help factories produce units when set on hold pos
• don't repair stuff that can't be repaired
• don't assist or repair if can't assist or repair
• don't repair if target has a soloBuilder already assigned
• don't repair self unless canRepairSelf
• don't repair units that are being reclaimed
• for immobile builders: don't try to repair things (just) outside range
• don't repair enemies
• for fight/patrol: adapt max distance based on move state

Another sidenote: the repairable UnitDef tag isn't sufficient, right?

(In other words: you aren't just considering always blocking repair for unit type X, but you are considering blocking repair for unit type X unless e.g. spell Z has recently been activated, or it's recently been blue moon, or blocking repair of X only for builder A but not for builder B, etc.)

Tobi wrote:(does area capture even exist? I don't remember.)

yes, it's beautiful for a commander underwater near a bunch of enemy units :D

"repairable" sounds to me like it's a good start towards what Bob was looking for. That means only one category of repair, but that is something, at least.

SeanHeron wrote:"repairable" sounds to me like it's a good start towards what Bob was looking for. That means only one category of repair, but that is something, at least.

No, it's not enough at all.

no what we want is categories, not disallowing any repair to units.