PowersUnit= logic for more than one vehicle a side.

[modder666]

If there would be a way to add more than one PowersUnit entry for a building, breaking the current limitation of only one a side. Maybe even rewrite the logic a bit?

[Building]
PowersUnit=ROBO,GTNK

[ROBO]
PoweredUnit=yes ;enables the logic and needs additional tagwork to have it function properly
PoweredUnit.Building=Building ;just to attach units to buildings
PoweredUnit.NegativeStructure=Building2 ;disables the vehicle if it's built
PoweredUnit.ExtraPower=200 ;can be set to require extra power to keep units online, defaults to zero?

[GTNK]
PoweredUnit=yes ;enables logic
PoweredUnit.Building=Building2 ;same as before
PoweredUnit.PowerCost=-5 ;each unit costs this many power points

And anything else you could think of that might make the logic a bit more flexible. Notes adding onto this could be helpful.

[Bug Importer (bug-importer)]

the robotank sparks when it becomes "unpowerd", perhaps that should be costimazable?

[octagon (octagon)]

just a thought, if you have PoweredUnit.Building=, then surely you don;t need to do anything to the PowersUnit= tag, since if you want multiple untis powered by the same building, you could just use the PoweredUnit.Building= tag on all of those units.

[modder666 (modder666)]

PowersUnit would tell the building what to power. Which is needed.

[DCoder DCoder (dcoder1337)]

-_^ Octagon's point is valid. If you set
[UnitA]
PoweredUnit.Building=GAROBO
, that's enough to figure out the reverse relationship.

[Tempest (xero-2)]

So, basically, introducing these tags to techotypes could be a great enhancement...

Powered.By = {technotype}
Disabled.By = {technotype}

In addition, expanding "Power = {integer}" to all technotypes would make things simpler...

Xero

[EagleEye (eagleeye)]

I happen to STRONGLY agree with Tempest. Giving those 3 to all TechnoTypes, along with the one that controls whether the thing can work w/o power, would open up so many new possibilities. Also, could you implement Powered.Range (defaults to infinite), Disabled.Range (defaults to 5, I guess) and Powered/Disabled.AffectEnemies/Allies so it's possible to make a powerer provide power for any enemy units to be powered by you and your own hijacked/mind-controlled units to be unpowered by you, or for you to completely stop any such thing from happening.

[Firefly (firefly)]

or to stop powered units from entering your base.

enemy robotank approaches
enemy robotank comes into the range of your unpower-building
enemy robotank shuts off
enemy robotank ready for being destroyed

[EagleEye (eagleeye)]

Exactly. Some more ideas would be:
1. Make a game mode where you have a couple of units and a MHQ that powers all of your other units. If it gets destroyed, you can't move any of your units.
2. Radio-wave jammer that you can send into an enemy base to disable their robo tanks.

[Bug Importer (bug-importer)]

to disable robotank you could simply make them vulnerable to an EMP weapon

[EagleEye (eagleeye)]

That's another way of doing it, but there's 2 ways to do lots of things.

[RandomNutjob (randomnutjob)]

Linked to issue 352?

[Renegade (renegade)]

Retargeting this to 0.2 under the assumption that the Mystery Patch is going to work.
Should the Mystery Patch fail, this'll likely go back to "undefined future"

See also: http://forums.renegadeprojects.com/showthread.php?tid=1784&pid=17960#pid17960

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: Renegade
Location: trunk, r987
Commit contains DLL: No
Revision comment:
Creating feature branch for issue #617 Powered Units using the Mystery Patch provided at http://forums.renegadeprojects.com/showthread.php?tid=1784&pid=17960#pid17960.
SVN: http://svn.renegadeprojects.com/Ares/987

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: Renegade
Location: issue-617-powered-units-mystery-patch, r988
Commit contains DLL: No
Revision comment:
Applied Mystery Patch implementing issue #617.
SVN: http://svn.renegadeprojects.com/Ares/988

[YR M0ddEr (yr-m0dder)]

Very intresting! I hope this work

[EVA-251 (eva-251)]

GATECH is the required building

Case 1: VehicleType
-Works as expected. Unit is non-functional without GATECH present

Case 2: VehicleType, Helicopter
-If built when structure is missing: Unit destroyed immediately above the WF, spinning endlessly until building is sold. The unit is repeatedly "destroyed" when GATECH is disabled/enabled (with EVA announcement).
-If built when structure is present, but is then sold: Unit explodes immediately at location

Case 3: VehicleType, PoweredBy=GATECH,GAOREP
-Has no effect. Unit works with neither building present

Case 4: VehicleType, Naval=yes
-Works as expected. Ship is disabled (doesn't sink) until building is present.

Case 5: BuildingType, combination oil derrick, spy-sat, powerplant, Powered=yes
-Has no effect. Building still provides power, spy-satellite, and oil-derrick income.

Case 6: BuildingType, Base defense, Powered=yes
-Works as expected.

Case 7: InfantryType
-Is disabled when building is not present.

Case 8: AircraftType
-Cannot be box-selected; but can be click-selected like any other disabled unit
-When disabled, it WILL accept force-fire orders at TERRAIN WITHIN its weapon range, and take off from the airpad, but will just wildly fly around the target area without attacking
-If is powered in flight, and then loses the power source, it immediately crashes to the ground.

Case 9: VehicleType, Operator=SSIONTROOP
-When SSIONTROOP enters vehicle without GATECH present, it's non-functional.
-If GATECH is present, but SSIONTROOP isn't inside the vehicle, it's non-functional
-If both are present, it works.

EDIT- More indepth
Case 10: BuildingType, Superweapon LightningStorm (with modded recharge time)
-Building doesn't animate, but the SW still counts down and can be activated

Case 11: BuildingType, Any
-If built when unpowered, the build-up's first frame appears, but it then freezes. Even if power is restored, the build-up will not finish. Building still fulfills prerequisites. It can be sold in this state.

Case 12/13: BuildingType, Factory (Navy Yard), Refinery
-Doesn't animate, but still functions

Case 14: BuildingType, Base Defense, Powered=no
-Still animates, doesn't function

Case 15: VehicleType, Naval=yes, hovers
-Sinks immediately when produced. Sinks on water when structure is sold/power is lost.

Case 16: BuildingType, Repair Bay
-If the Repair Bay is PoweredBy=, the vehicles repairs will cease
-If the vehicle is PoweredBy= and the Rep bay isn't, vehicle will continue to repair, but won't move from the bay when it finishes
Running out of ideas, but in all it seems to work. Most importantly, all of these TechnoTypes were powered by the same building.

[YR M0ddEr (yr-m0dder)]

EVA-251 what happens if someone EMP the powered building(example GAROBO)?
Do the robot tanks get disabled?
Then, there is Chronosphere buildings you could try.
There is temporal.... cant think of more.

[EVA-251 (eva-251)]

Case 17: GATECH hit by EMP weapon
-Basically it's like the base losing power or the building being destroyed, as long as the building is EMPed.

Case 18: GATECH hit by temporal weapon
-PoweredBy= units are disabled until the temporal effect is removed.

I also tried combinations of EMP, Operator, and disabling the powering building simultaneously without major issue.

[Renegade (renegade)]

Thanks a lot, EVA, that was awesomely thorough! :D

[Untrue (untrue)]

Another way of disabling powered units is going through spy logic.

SpyEffect.Custom=yes
SpyEffect.DisablePoweredUnit=yes
Maybe SpyEffect.PowerOutageDuration but only the Robot Center. Then a time interval starts then after it ends the powered units will go back online.

[Graion Dilach (graiondilach)]

No offense, but have you realized that this feature is written by an external, unknown coder?

I don't think a SpyEffect is attached. And honestly, I don't even get the reason why should one be attached.

[Untrue (untrue)]

If that unknown coder isn't intelligent enough to attach SpyEffect then no problem to me. It was just only a suggestion anyway. Unknown coder? I'd bet a cent for LH_Mouse on that. :\

[Blade (nadia-xy)]

I doubt it would be anything to do with intelligence, but really such a thing should be a different feature request anyhow. As for it being LH_Mouse... I wouldn't think so since he said he doesn't really know C++ all that well and is making his own assembly patch with features unrelated to this.

[YR M0ddEr (yr-m0dder)]

This works great. I found some bugs, but they are not related A Mysterious Guests code, so I post a seperate isssue for that.

[secondwtq (secondwtq)]

LH_Mouse? The arrogant guy? It seems that he knows some of C++, but can't understand the code of Ares. though as if we can inject ASM code in C++.

[WoRmINaToR (worminator)]

Does anyone else find it a bit ironic that this guy is calling LH_Mouse arrogant?

[Krozalid (krozalid)]

You are damn right, Worm.

[YR M0ddEr (yr-m0dder)]

hey Ren, is r898 the update by "A Mystery Guest" that support multiple buildings?

[Renegade (renegade)]

Given that that revision is 99 before the previous one, I'm rather sure it's not.

[WoRmINaToR (worminator)]

The mystery patch was applied ten days ago... the team could implement nine patches each day for all of those ten days and still not push out enough revisions to get to the number it is now...

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: Renegade
Location: issue-617-powered-units-mystery-patch, r991
Commit contains DLL: No
Revision comment:
Added the second mystery patch for issue #617, though I'll likely open an alternative branch for an overhauled powering logic in general soon.
SVN: http://svn.renegadeprojects.com/Ares/991

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: Renegade
Location: trunk, r992
Commit contains DLL: No
Revision comment:
Creating branch for an overhaul of the activated/deactivated state checking, including implementation of issue #617.
SVN: http://svn.renegadeprojects.com/Ares/992

[YR M0ddEr (yr-m0dder)]

Tested in r994.
Update works like it suppose to do. The comma character that seperate two buildings in PoweredBy= tag mean OR and not AND.
I noticed in my test that some original logics are now broken. I will test in other in trunk and in vanillia before I write them.

EDIT: Never mind that, this feature works fine! :D

[g.a (g.a)]

I would rather have a poweredby= tag where the commas mean AND, along with another tag called poweredby.alternate= tag, so we can do cool stuff, like having a tech structure that powers units, along with the original buildings. It would also be useful with complex tech hierarchies.

Also, can buildings power (or disable) other buildings?

[YR M0ddEr (yr-m0dder)]

"Also, can buildings power (or disable) other buildings?"
Yes, you can aslo disable infantry with this logic.

Is there anything else here that need to be tested or can this can be closed?
I tested this with many vanillia and ares tags. It works fine.

[cranium (cranium)]

I second YR Modders confirmation.

[Renegade (renegade)]

Closure is not dependent on the amount of tests. As I have said before, your obsession with closing issues is alarming.

[Renegade (renegade)]

Can I get a second confirmation from a less close-happy tester?

[Graion Dilach (graiondilach)]

Your altbranch haven't finished yet, AFAIK. I don't see why this should be closed. Until it isn't in trunk, it cannot be closed, IMO.

Mystery Patch rev 2.: PoweredBy and Operated units: Needs both to function. I guess it's the good behaviour.
Listing: Listed buildings are in OR condition, as YR Modder pointed out. It takes Powered on the listed buildings into account as well. I think this is good, too.

[Renegade (renegade)]

So does the Mystery Patch itself work?

[Graion Dilach (graiondilach)]

Sure. The first version considered only one building and didn't take Operator into account, it worked as well.

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: Renegade
Location: issue-617-powered-units-mystery-patch, r1006
Commit contains DLL: No
Revision comment:
Merging latest trunk into issue #617 feature branch.
SVN: http://svn.renegadeprojects.com/Ares/1006

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: Renegade
Location: trunk, r1007
Commit contains DLL: No
Revision comment:
Merging Mystery Patch into trunk. This conflicted with or required merging of a few recent fixes, so make sure to test thoroughly if the fixes to issues #bug:1494, #bug:1492 and #bug:1452 still work as expected. (As well as if #617 still works, obviously.)

Related to issue #617, issue #1494. issue #1492, issue #1452.
SVN: http://svn.renegadeprojects.com/Ares/1007

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: Renegade
Location: trunk, r1008
Commit contains DLL: No
Revision comment:
Deleting feature branch for issue #617.
SVN: http://svn.renegadeprojects.com/Ares/1008

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: AlexB
Location: trunk, r1010
Commit contains DLL: Yes
Revision comment:
New trunk binary.

Related to issue #617, issue #1452, issue #1492. issue #1494.
SVN: http://svn.renegadeprojects.com/Ares/1010

[Graion Dilach (graiondilach)]

After trunk merge, the logic still works.

[Renegade (renegade)]

Hooray!

I would like to take this moment to express the developers' gratitude towards the Mystery Guest for coding this up - without him (or her), this wouldn't be in 0.2.

Thanks a lot, mysterious guest!

[mevitar (mevitar)]

I don't know if it was fixed already in previous revisions, but I can order units to attack when they are unpowered, and they play their attack voices when I do so (they don't attack, however). Also, if a jumpjet aircraft won't crash due to no power (I made mine that way intentionally) and it has a turret, then it spins when I order it to attack, and returns back to its starting position after it fails (because it is still forbidden to use its weapons).

Tested in revision 1015.

[Rogan (pdrogan)]

I can't seem to get multiple powered units in one building to work... Unpowered units will stay unpowered until destroyed even when there's sufficient power and/or the building powering them remains intact.

I just cloned the entry for the Robot Tank and have the Control Center to power both the original and cloned Robot Tanks.

Tested in trunk, r1051.

[Graion Dilach (graiondilach)]

Drogan, the mystery patch uses it's own tag, PoweredBy=(BuildingType) on the TechnoType.

PowersUnit wasn't changed.

[Rogan (pdrogan)]

Ok, used PoweredBy= and it mostly works now.
However, using this flag in issue 1401 causes units that get unpowered while being carried by a magnetron to "sink" past the ground

Also, Non-Hovering harvesters continue their gathering and returning operations even though the powering building, the refinery, lost power. Hovering harvesters does not have a single problem whatsoever and bugs that were associated with Westwood's version of powered units logic and hovering harvesters are gone, oddly enough.

[Graion Dilach (graiondilach)]

Powered=yes on the Refinery?

[Rogan (pdrogan)]

Yeah, forgot to mention that... Sorry.

[DCoder DCoder (dcoder1337)]

Reopening per last comment.

[Krozalid (krozalid)]

D, may I know what kind of feedback you need for this one?

[DCoder DCoder (dcoder1337)]

Sorry, it wasn't supposed to be set to feedback - apparently the "Reopen" button goes there automatically. I meant to simply reopen it, since it apparently still has problems.

[Krozalid (krozalid)]

Okay then.

[Renegade (renegade)]

Could whoever can reproduce the harvesters issue please post his debug.log? Believe it or not, debugging data helps debugging an issue. ;)

[Rogan (pdrogan)]

Debug.log uploaded.

Upon recreating the error, I noticed that the problem can occur when a harvester loses power while it is moving to a different Ore/Gem spot after gathering another.

I've also uploaded my rules file used for testing.

EDIT: I've uploaded another Debug.log, but this one tackles on the Magnetron Issue.

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: DCoder
Location: trunk, r1068
Commit contains DLL: Yes
Revision comment:
Related to issue #617 - added command line switch -LOG-EMP to enable verbose EMP logging per Ren's request. Also added invalidators to catch units using both old and new powered unit logics.
SVN: http://svn.renegadeprojects.com/Ares/1068

[Renegade (renegade)]

Drogan, could you test again with -LOG-EMP and post your log, please?
Same goes for all other testers.

Also, report if the game says your INIs are invalid and that's the reason.

[Rogan (pdrogan)]

Ummm, is there any space betweem -LOG and -EMP?
The game didn't seem to output any log file with -LOG-EMP in the command line.

I've uploaded the log outputted when using -LOG -EMP in the command line, anyway. It doesn't appear to be quite different than the previous log though...

[DCoder DCoder (dcoder1337)]

You need -LOG to enable logging as a whole, and -LOG-EMP to log the EMP in more detail.

[Professor_Tesla (professor-tesla)]

I've just tested this issue again, and I reproduced Drogan's bug. I set PowersUnit=HARV on the Soviet Ore Refinery and PoweredBy=NAREFN on the War Miner. I killed power to the refinery, and the miner became darkened and started sparking, but still continued its gathering and returning missions.
The log has been uploaded.

[DCoder DCoder (dcoder1337)]

(Do note that Ares explicitly tells you not to combine the two logics - PowersUnit is not necessary for the new logic.)

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: DCoder
Location: trunk, r1069
Commit contains DLL: Yes
Revision comment:
Related to issue #617 - force victims to 'sleep', makes harvesters also stop like everyone else while disabled
SVN: http://svn.renegadeprojects.com/Ares/1069

[DCoder DCoder (dcoder1337)]

Guys, can you retest those harvesters (and other powered units) now?

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: AlexB
Location: trunk, r1075
Commit contains DLL: No
Revision comment:
Related to issue #617: Support negative EMP threshold other than -1.
SVN: http://svn.renegadeprojects.com/Ares/1075

[Rogan (pdrogan)]

I tried this with r1071, The two problems are still there...

I've attached another debug.log for this revision. (Yeah, it's a typo, sorry about that.)

[YR M0ddEr (yr-m0dder)]

Harvest bug is now fixed.

EDIT: Actually there is a bug. I found it by luck. How to reproduce:
Make a harvest powered by a building,
while the harvest is "sucking" ore, sell the building that is powering it,
now select that harvest, and hold CTRL and force it to fire on ore, it will now continue its harvest mission. Note the harvest must have a weapon(War Miner).

[Rogan (pdrogan)]

So there's another way to reproduce this...
I can confirm YR M0ddEr's findings.

I noticed that harvesters, mostly the War miner, will occasionally stop on its return mission when it is unpowered while finishing an ore spot and moving to another, but it will still gather ore under this state.

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: DCoder
Location: trunk, r1080
Commit contains DLL: Yes
Revision comment:
Related to issue #617 - reject any and all orders to powered down units, including attack; refactored powered unit status checking and added anti-clogging - objects will not shut down while their current cell is also occupied by a building (warfac, barracks, repair depot, shipyard...), makes it more consistent with robot tanks exiting a warfac properly and doesn't clog up the factory hopelessly.
SVN: http://svn.renegadeprojects.com/Ares/1080

[DCoder DCoder (dcoder1337)]

Stealth assignments... Very funny.

[YR M0ddEr (yr-m0dder)]

The only bugs left(AFAIK) is how the game handle unpowered units being build(example when an unpowered unit leaves war factory).
Example of bugs:
http://www.youtube.com/watch?v=npZZSwE6Rus
This bug can also make harvest continue its harvest mission(hard to reproduce, I was able to do it 2/15 times). This bug also happen to Operator logic.

I think, instead of try to fix that(I have no idea how a fix would work), I think how the game handles unpowered units being built system should be changed.
Suggestions:

- You are unable to build units that require power if you dont have the building that is powering them.
If you have a unit that have just been built(its still inside the war factory), and the building that power it is lost, the game should handle them in the current way.

or

- The unit freeze no matter where it is.
If the unit inside a war factory, it will be stuck there, and continue its mission when it get power again(that means you cant build other units from that war factory).
If the units is one a repair depot/ore docking spot, it will get stuck there.

I would like to here other people opinions.

[DCoder DCoder (dcoder1337)]

What YRM said. We need a consensus on how to handle construction of powered units while they're offline.

[Chanterier (speederyr)]

If I had to choose I'd definitely say option 1.. having units stuck in the factory sounds like a no-no to me.

[DCoder DCoder (dcoder1337)]

You can suggest other options if you can think of them... e.g. mimicking the Robot Tank logic, where it drives out of the WF normally but shuts down as soon as it's clear.

Just mind that the WF is not the only place where units can be when an outage occurs - repair bay, shipyard, grinder, tank bunker... that's not even touching garrisons and passengers, which are currently completely indifferent to power outages. No, I don't think garrisons/passengers in this context will be fixed for 0.2.

[YR M0ddEr (yr-m0dder)]

Actually, the damn harvest bug isint fixed. Sell the building that power the ore miners while they are sucking ore, they will go offline but continue their mission.
And, if a harvest get unpowered while its unloading ore(CMON), it will be stuck that way. See image.

[DCoder DCoder (dcoder1337)]

Well, most of the people are voting to leave this as it is at the forums... And quite frankly I'm not interested in going twenty more rounds with this logic right now.

[sansko (sansko)]

Why not try to test what it does if the powerd unit with temporal weapon attacks his needed building?

[DCoder DCoder (dcoder1337)]

Since option 2 won at the forums (http://forums.renegadeprojects.com/showthread.php?tid=1848 ) by an overwhelming majority, I'm considering this resolved for now. Feel free to open new issues for the remaining problems to be considered after 0.2.

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: SteelMirage
Location: trunk, r1120
Commit contains DLL: No
Revision comment:
Related to issue #617- Added "New Powered Unit Logic" section under New & Enhanced In-Game Logic
Related to issue #1362- Added "ChangeOwner=" tag to "Chrono Prisons" section
Related to issue #436- Changed wording in "Generic Prerequisites" section to make examples a bit clearer. (May need some follow up)
SVN: http://svn.renegadeprojects.com/Ares/1120

[DCoder DCoder (dcoder1337)]

Aaaaaand closed. Polishing and improvements, if deemed necessary, will happen after 0.2.