Patch for powered units (issue 617)

[~A Mystery Guest~]

This patch implements issue #617. It adds the tag PoweredBy=<BuildingType> to all TechnoTypes, so one building can power multiple unit types, and a player can have more than one of those buildings. Powered units are only deactivated when all <BuildingType>s of the same owner are offline or destroyed. I took care that deactivated units are only reactivated when they are both powered and not affected by EMP. The logic is completely separate from the Robot Control Center's, but they are compatible (not on the same unit). It would be better to just replace the RCC logic, but I don't know how to hook that up.

If you also set EMP.Threshold=inair and the unit is in the air, it will crash when it goes offline. Meant for helicopters like the BlackHawk.

I tested it on vehicles, aircraft and balloonhover vehicles (the BlackHawk).

Minor issue: EVA doesn't play robot tanks online/offline messages.

I know this feature isn't targetted for 0.2 or 0.3, but it's something I and other people would like to have, so here it is.

Example:

Code:

[MGTK]
PoweredBy=GATECH ; mirage tank needs battle lab online to function
; these are optional:
VoiceSelectDeactivated=RobotTankSelectDeactivated
ActivateSound= RobotTankOnline
DeactivateSound= RobotTankOffline

[GATECH]
Powered=yes ;already there but you need this if you want powered units to deactivate when low power.

If you want to disable Westwood's powered unit control (so you can build multiple RCCs):

Code:

[ROBO]
PoweredBy=GAROBO

[GAROBO]
;PowersUnit=ROBO ; remove this tag.

Download the patch file here and save it as poweredunits.patch. Then apply the patch to ares/trunk/src with SVN. Then rebuild Ares.

[DCoder]

Thanks! We'll look over this.

[Graion Dilach]

Nice work.

Question: Is your PoweredBy accepts only one value per unit or is it accepts a list? If it accepts only one value, can it be a GenericPrerequisite?

[Renegade]

I could wade through the code/apply it to figure it out, but I guess asking is easier: When crafting this, did you take the Operator= logic into account?

[¥R M0dd€r]

Thanks for this.
If bugs are reported, are you willing to fix them?

[~A Mysterious Guest~]

Oops no I forgot about Operator=, I'll add it later. Yes I can fix bugs for this if needed.

At the moment PoweredBy= only takes a specific BuildingType. I looked a bit into how to let it accept GenericPrerequisites, but I thought I should keep it simple for now.

---

Also, although I added it to TechnoTypes (because it was easier to code that way) I didn't take buildings with PoweredBy= into account, since I couldn't find a good use case for it, and it didn't make a lot of sense to me the way powered buildings already work. The way I coded it is meant to be used on units only.

[Renegade]

Heh, that's our standard bug whenever anyone touches anything activation-related: Different systems touching the activation-status in ignorance/disregard of eachother.
I haven't had the time to look closely at the code yet, so I don't know if you're aware of this, but there are a block or two in TechnoClass::Update where we tried to converge EMP, Operator=, etc.
If you do want to patch this, that'd probably be the best place.

If you didn't see yet, I applied the patch to a branch last night, Alex said it compiled fine.

[DCoder]

I'm just hoping somebody fixed the formatting to match existing code...

[Renegade]

Nah, not yet...it was late and I just wanted to get it out there so people can test it.
It's not all of it, either, as far as I can see...just a few blocks. We'll fix it before merging into trunk.

Edit: Mysterion, according to eva on the bugtracker, Operator= works as expected (at least on VehicleTypes), but there are a number of other detail-issues.

[~A Mysterious Guest~]

I patched my patch. Apply it to the /src folder again.

- Now takes Operator= into account, and vice versa.
- PoweredBy= now takes a list of specific BuildingTypes. Example: PoweredBy=GAPILE,GAWEAP. If the owner of the powered unit has any of those buildings online, the powered unit is also online.

There seem to be a lot of issues with buildings, but they're caused by something other than my code. My patch mostly just calls the new EMP logic that was already in Ares to disable/enable units. So that means those issues also occur with EMP weapons, and most likely operators too (they all call the same Deactivate() and Reactivate() functions which is where I think the problem lies). Base defenses do work for some reason, except that when they are deactivated while being placed on the map their animations aren't drawn correctly. But if a defense deactivates after being placed on the map everything works fine.

[Black Shadow 750]

If I read that correct, if you have a unit which restores EMP, can it restore offline stuff?

[~A Mysterious Guest~]

No, I put checks in so that a unit only goes back online if it's powered, not EMP'd and operated.

[Renegade]

I will apply this patch later, but I have to say that checking IsOperated() inside EMPulse.cpp looks bad to me. It violates encapsulation, imo.
EMP should be dependent on EMP only, not Operator= as well. It should be checked whether EMP should be disabled before calling DisableEMPEffect(), or DisableEMPEffect() should query a generic state indicator.

Building webs of dependencies like that isn't a good idea.
(I'm not pretending at all that shit like that couldn't be in the current trunk as well, but the fact that bad things have already happened doesn't mean we have to pile more on top of them.)

I think I have an idea on how to best handle this business, I'll test it out in a branch sometime, and then we'll have to see how to integrate your code into it.

[Marshall]

If the way in which objects are disabled is the same for all these different things, then can you just add a counter of "how many things are disabling me"? Each disable-action calls a common function which increases the counter. Then, as each one dissipates, call a common function which decreases the counter and, if it has reached zero, re-enable the object.

The uncommon effects of the disable (sparking/colouring/anims/etc) should still be handled by the thing doing the disabling.

[Renegade]

That is exactly what I had in mind.