Somewhat less basic airbase gadget

[Silentwings]

http://imolarpg.dyndns.org/trac/balates ... irbase.lua

Once its had more testing I'll attach a file, for now treat BARs repo as the current version. But it should be fully functional now, report errors (there are likely to be some edges cases) to this thread. Use the latest dev engine.

It will automagically fly injured planes to repair pads, after which they continue with their previous commands.

Things to note:
(1) Airbases should have one special piece per repair pad, with piece name containing "pad" as a substring, for the incoming plane to attach too. The piece must be positioned accordingly.
(2) There is no nano spray.
(3) It adds & uses two custom commands, "land at any airbase" and "land at specific airbase".

(developed from viewtopic.php?f=23&t=34417#p575780)

[hokomoko]

you may want to fix the healing as resourceFrames are now every 30 frames and not 32

[Silentwings]

@hokomoko: http://imolarpg.dyndns.org/trac/balatest/changeset/4925 fixes my memory, and http://imolarpg.dyndns.org/trac/balatest/changeset/4927, I think does everything you asked for in #sy.


For gritty details, there are several minor engine issues that writing this gadget exposed, besides the ones that were already fixed:

(1) When a unit is detached it does not always continue with its command queue, sometimes it just hangs in midair. Afaics this is a bug. This is currently hackily worked around by a double CMD.WAIT sent after unit detachment. You can reproduce it (fairly easily, but not on 100% of detachments) using the gadget by commenting out the double wait. Let me know if you want a mantis

(2) Using the engine to draw the custom command means that the command line ends at the airbase, rather than in the center of the pad at which the unit is trying to land. It's a bit ugly, but there is no CMD_TYPE that can support parameters {airbaseID, padPieceNum}.

(3) Since units can only repair one target at a time, and an airbase can have multiple pads, "repairing" is done with SetUnitHealth and CMD.REPAIR is not active whilst it happens. This means its quite difficult for the repairing to use resources cleanly, because the rest of lua doesn't see it happening and can't control buildspeed, etc. It's not a regression - the same issue was present with hardcoded repair pads in Spring 100. Consequently there is no nano spray (and this part is a regression).

[hokomoko]

Thanks!

[Silentwings]

Updated version of gadget (see repo)

fixed visual side of snapping, planes now move smoothly into place
fixed issues where planes tried to land on dead airpads
fixed issues where some large planes weren't able to land (*all* planes will now land, even if they really don't fit)

Needs 101.0.1-111 or later.

[hokomoko]

In the latest version in BAR there are still some issues with ClearUnitGoal.
to solve them add:

Code: Select all

function gadget:UnitCmdDone(unitID, unitDefID, teamID, cmdID, cmdParams, cmdOptions)
	if cmdID ~= CMD_LAND_AT_SPECIFIC_AIRBASE then return end

	Spring.ClearUnitGoal(unitID)
end

and remove Spring.ClearUnitGoal from all other places in code.

In general, cleaning after a command is best done in this callin

EDIT: can you please verify that gunships work correctly after https://github.com/spring/spring/commit ... 0b2148f4fc ?

[Silentwings]

can you please verify that gunships work correctly

They don't - now the result of ClearUnitGoal on a landing gunship is that it accelerates (beyond its own max speed) over the top of the landing position and stops shortly past it (still in the air), and then hangs there without continuing its order queue.

To test, give corcarry, give corcrw, 'luarules halfhealth', set the corcrw to land at 80, and then self d the corcarry before it manages to land.

there are still some issues with ClearUnitGoal.

Can you give me details of an example? I can't see a case where its not called and should be.

[hokomoko]

Everything lua-related works for me with the following gadget:
http://paste.springfiles.com/view/e40dbdaf