How do I create a unit that reclaims but gets zero from it?

[MadRat]

I want units that can reclaim wreckages and whatnot only the player does not get any benefit from the act. The only way I can think of now is to not let them use the resource at all and to give them zero storage of that resource which means the reclaimed materials are lost after the reclaim. I want that kind of result only I still want to use the metal resource.

[Argh]

Well... the metal / energy value of a corpse can be 0.

[Warlord Zsinj]

Argh's solution works so long as you don't want players to ever get resources from wrecks.

Alternatively, what about giving it a weapon that does no damage to any unit in the game, but has an extremely high 'default' damage so that it blasts away wrecks, but can't be used to harm anything else?

Not as good as actually getting the reclaim thing to work, because you can't really que up multiple wreckage removals, etc.

[lurker]

I believe you can hook some lua into allow reclaim step and then take away the resources gained the same nanosecond they are given.

[Argh]

I thought about that, Lurker, but meh, that's awfully expensive, I'd think- it needs to check every frame, just for reclaiming happening, let alone run the resource transfer logic (and how's it supposed to know how much of current income is from reclaiming, anyhow? That's a pretty puzzle, heh). It'd run like a dog with the flu, imo.

Better to just remove the resources entirely, if the game design allows. Or, if one side must be able to get metal and the other can never get metal, then check for Features that are being removed, and if A, then check for active reclaimers nearby, if on the "right side", then they now get resources, and so on and so forth. Slower when it ran, but it'd run a lot faster overall.

[KDR_11k]

I thought about that, Lurker, but meh, that's awfully expensive

Do you have any idea how long the Spring code for nano stuff is?

Me, I'd use a custom command and just show the unit doing wreckage removal while using Lua to remove it.

[lurker]

Argh, the callin's name is AllowFeatureBuildStep. Take a look at it.

[MadRat]

Here's the problem, Argh, I want one side to not gain from reclaims while the other sides do gain from it. It would be nice if there was a hook where I could define the efficiency of the reclaim, i.e. 50% reclaim efficiency means the unit only reclaims half of the metal and the rest is lost to the ether.

[Argh]

Um, I'm not home, so I can't test right now... does AllowFeatureBuildStep return the UnitID of the Unit doing a Reclaim order, or the FeatureID of the Feature being reclaimed / repaired / built as the first parameter?

If it's the FeatureID, it'd be much faster to run a check from COB to determine whether the builder is Reclaiming or not, when it declares it's ready to build, then get the Target of that action, then use the Target's ID to obtain the necessary information about resource exchange. If it's the UnitID, you still need to get the target, etc., so why not just do that from the COB event in the first place... much faster, imo, when it's not happening it's just an empty IF/THEN that you need anyhow, for normal operation of the COB.

[lurker]

Argh: No, because you then spend half the time guessing about what the unit's doing. And cob is far slower than lua. I don't think you even have access to resource levels in cob, so how is that supposed to work?

AllowFeatureBuildStep(unit, team, feature, featureID, part)
Look up the unitdef, and if it only gets part, you give them the resources, use SetFeatureReclaim, and return false.
MadRat: I'll have this coded in a day or so.

[Argh]

Argh: No, because you then spend half the time guessing about what the unit's doing. And cob is far slower than lua. I don't think you even have access to resource levels in cob, so how is that supposed to work?

You'd run the Lua only when InBuildStance == TRUE, in this case, since you've gotta do that anyway in COB, unless you do the all-Lua solution KDR proposed.

At any rate, glad to hear you're going to do this, I'm sure people will find this useful

[KDR_11k]

Why do you think it matters in which order the parameters are given?

[lurker]

I think argh thought it only passed one parameter or something.

[Argh]

Yeah, nobody ever bothered telling me that all of that's in API.txt, which I'm reading through now

[zwzsg]

Yeah, nobody ever bothered telling me that all of that's in API.txt, which I'm reading through now

Be fast, the only response I got from trepan when asking for more doc was him deleting the only one.

[jK]

Yeah, nobody ever bothered telling me that all of that's in API.txt, which I'm reading through now

Be fast, the only response I got from trepan when asking for more doc was him deleting the only one.

cos there is a wiki!

[Argh]

Yeah, but it's not in the Wiki, is it? That's been my primary reference source, I hadn't thought to read that particular text file.

Meh, I'll just add it, when I get the chance, maybe tomorrow, I'm too tired to edit it all to look nice tonight. It'd be better to have out-of-date or incomplete documentation of the various events where Lua can get data, and the parameters returned, than not have it.

[Lolsquad_Steven]

[jK]

all callins are listed in the widgetHandler/gadgetHandler (widgets.lua/gadgets.lua)

[KDR_11k]

Really unwieldy to use though.