Spring RTS Engine

Id like to request a callin, Repaired(unitID, unitDefID, unitTeam, repairAmount, repairerID).
As the name implies it should be called everytime a unit is being repaired by a builder with the repair mechanism or reclaimed, basically the counterpart to UnitDamaged.
Since its not listed on the wiki, i assume its not there.
The repairerID is the unit that does the repairs to unitID and repairAmount the hp added to the unit.
This callin should also be called when a unit is being reclaimed, in which case the repairAmount would be negative.

Small sidenote: someone should check if UnitDamaged gives back a negative damage value when negative damage is done.

gadget:AllowUnitBuildStep probably does everything you want. Well, it is what you want if you are making a gadget. If you want to make a widget then request to your game that they use gadget:AllowUnitBuildStep to send events to widgets.

When I looked at AllowUnitBuildStep for something similar, I discovered it gets called so often that simply including it as a blank callin is a noticable performance hit. So I think this is a sensible request.

This is true, and this is the reason that the production rate gadget is so costly.

But wouln't a similar callin for repairing also be as costly? Would it instead be feasible to request a UnitRepairedComplete callin?

Silentwings how does the performance of AllowUnitBuildStep make this a reasonable request? code_mans Repaired callin would call just as frequently as AllowUnitBuildStep, every frame for every repairer. Is the request more reasonable because the requested callin would only occur for repaired units?

I also doubt that the impact of a blank AllowUnitBuildStep would be noticeable.

The vast majority of build steps are not repairs.

That said, I'd prefer a callin which was only triggered when a constructor started/stopped repairing (with that, GameFrame suffices for the rest and is more flexible).

I also doubt that the impact of a blank AllowUnitBuildStep would be noticeable.

I measured it in BA games with 2-3k units - although two years ago now.

Silentwings wrote:That said, I'd prefer a callin which was only triggered when a constructor started/stopped repairing (with that, GameFrame suffices for the rest and is more flexible).

Can be reasonably approximated via LUS

This is true, but not all games use LUS, or can reasonably expect to switch to it. And there is something to be said for the modularization gained by keeping unitscripts and widgets/gadgets well separated too.

While as you said games using bos/cob still exist and we can't expect them to switch, I'd argue that they can't expect the same level of support as LUS.

Whilst that may be important when the difficulty of writing/keeping clean code within the engine applies, I don't see it as important here. The suggested changes are uncomplicated and have no effect on backwards compatibility.

I personally would avoid writing general game mechanics or gui features that work ~equally for all units by relying on calls from each individual LUS, on grounds of messy code.

So I don't even rate what LUS provides here as "support" for what's being asked, in any more than I'd rate AllowUnitBuildStep or GameFrame as support for it. The same principle applies to any "UnitStartedXXX/UnitStoppedXXX" pair of callins for common events, most of which already have callins in LuaUI/LuaRules as well as LUS.

I should have elaborated a bit more.
IMO AllowUnitBuildStep is a terrible callin.
UnitRepaired sounds equally horrible to me.

That's why, considering there's a pretty decent way of implementing something similar using LUS, I'm not rushing to implement it.


P.S. If anything they should probably be merged, and also add resurrect to the mix.

AllowUnitBuildStep is a terrible callin.

<3, although for some purposes I can't see another way. But

silentwings wrote:I'd prefer a callin which was only triggered when a constructor started/stopped repairing (with that, GameFrame suffices for the rest and is more flexible)

is the way to go here. What's horrible about that? I don't mean to accuse anyone of not rushing to implement it, just to establish if the design is viable.

is the way to go here. What's horrible about that?

Someone has to implement it...

hokomoko wrote:

is the way to go here. What's horrible about that?

Someone has to implement it...

However it is implemented, the fact of the matter is that someone has to implement it. That's like saying that the sky is blue. I certainly agree to both statements.

Jools wrote:

hokomoko wrote:

is the way to go here. What's horrible about that?

Someone has to implement it...

However it is implemented, the fact of the matter is that someone has to implement it. That's like saying that the sky is blue. I certainly agree to both statements.

You implicitly assume someone will implement it.

Wow i sure stirred up the hive, i really hadnt seen that one coming.

Anyway to clarify, this callin is not that important to me, i can live without it just fine actually, if somewhat inconvenient.

I would use this call if it were implemented in a widget and at it would had to be called at every repair step.

One thing that occurred to me tough, does UnitDamaged get called when a unit is being reclaimed?
If this is not the case then there is a decent lack of case coverage from what i see.

Out of curiosity - why every repair step? If you know when stopped/started, you can keep a table of what's currently reclaiming and use GameFrame for the rest - which is more flexible and avoids the major objections above.

I gave it some thought btw, a sane design could be where the allowbuildstep etc. is behind a "watch list" (like projectiles) so you get a start event where only if you return true you get the step callin every frame.

Silentwings wrote:Out of curiosity - why every repair step? If you know when stopped/started, you can keep a table of what's currently reclaiming and use GameFrame for the rest - which is more flexible and avoids the major objections above.

Too be honest i just havent thought this trough and assumed the direct way was the best, i assumed it was better to have a callin rather than having to abuse gameframe, or anything else.
I want a widget to display health of a unit, its that simple really.

And e.g. http://imolarpg.dyndns.org/trac/balates ... thbars.lua isn't suitable?

That's not abusing GameFrame - in this case you actually want something new on every game frame. Iirc that's precisely how the "normal" healthbars widget does it, using widget:Update (which is called at least once per gameframe).

If there was going to be a projectile/movectrl-esque mask, it might be better to stick with the format of having on-off callouts, for consistency? I certainly think AllowUnitBuildStep would benefit from it.