Attach Effect and temporal

Bug #1059189 reported by YR M0ddEr
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ares
Fix Released
Low
Graion Dilach

Bug Description

When a unit is frozen by a temporal weapon, the AttachEffect.Animation is not hidden, it still plays as usual.

Changed in ares:
status: New → In Progress
assignee: nobody → Graion Dilach (graiondilach)
importance: Undecided → Medium
Revision history for this message
YR M0ddEr (yr-m0dder) wrote :

Some notes, this feature works in most cases I tested. Good results:
Unit attach effect still have its the effect:
- after it have been warped by chrono sphere
- after it have teleported.
Unit(with attach effect tags) delivered by unit delivery or paradrop play its attach-things immediately.
Unit can not get any new attach effect while it is under iron curtain protection(maybe should be optinal? The attach effect is not always a negative effect).
Animation can have StartSound that loops while the attach effect is active.

Revision history for this message
mevitar (mevitar) wrote :

Do you mean that units can't get an AE from a weapon on them, or their initial AE doesn't work?

I think weapons should not give AE for targets under an Iron Curtain effect. Iron Curtain protects from being affected by *any* weapon, harmful or not. And i'm not talking about the lore behind the Iron Curtain, but how the logic works. Weapons can't put AE on the IC'd object because they don't affect it at all (and thus, don't have anything to put the AE on), not because Graion coded it that way.

If weapons with AE would become an exception, then we might as well give SubjectToIronCurtain=yes/no to the projectile/weapon/warhead/whatever. It would be more reasonable (and would have a more universal use) than creating a one-case exception only for AE (which, to work at all, might need the "ignore Iron Curtain" part implemented for weapons anyway).

Revision history for this message
Graion Dilach (graiondilach) wrote :

What Mev said, the points regarding AE-Iron Curtain are A) unrelevant to this bug and B) not bugs but feature. Except if it turns out AttachedTechnoEffect code can't attach when unit is ICd.

Revision history for this message
YR M0ddEr (yr-m0dder) wrote :

Those weren't considered as bugs. It was just posting testing results.

Revision history for this message
Graion Dilach (graiondilach) wrote :

Solved in version 13.163.5.

Added a new tag, AttachEffect.TemporalHidesAnim, if false/not set, the anim plays continuously.

Changed in ares:
status: In Progress → Fix Committed
Revision history for this message
Graion Dilach (graiondilach) wrote :

Code was a failure. Back to the planning board.

Changed in ares:
status: Fix Committed → In Progress
Revision history for this message
Graion Dilach (graiondilach) wrote :

TemporalHidesAnim failed due to some WW shenanigans which I couldn't debug for now. I consider the issue as a minor setback which shouldn't prevent AE to progress further.

The issue's priority will be set to low, I will still experiment with it, but I don't treat is as a crucial one.

Changed in ares:
importance: Medium → Low
status: In Progress → Triaged
Revision history for this message
Graion Dilach (graiondilach) wrote :

Fixed in version 13.175.462.

Changed in ares:
status: Triaged → Fix Committed
Changed in ares:
milestone: none → 0.4
Revision history for this message
4StarGeneral (4stargeneral) wrote :

Temporal weapons now hide AE effects on an enemy unit, but only move the affect behind (think ZAdjust) the unit if it is friendly. AE is also permanently behind said friendly unit after Temporal'd.

Revision history for this message
mevitar (mevitar) wrote :

Same, Temporal doesn't remove the AE. In fact, the AE animation will still play, and it will be able to damage anything around normally, as if nothing happened.

Revision history for this message
Graion Dilach (graiondilach) wrote :

AttachEffect.TemporalHidesAnim defaults to false. Does the above happens even if it's directly specified?

Revision history for this message
4StarGeneral (4stargeneral) wrote :

AttachEffect.TemporalHidesAnim=yes, AE is removed on enemies, AE not removed on allies.
AttachEffect.TemporalHidesAnim=no, AE is not removed from either enemy or ally.
Untagged, AE is not removed from either enemy or ally.

Hope that makes sense.

Revision history for this message
Graion Dilach (graiondilach) wrote :

Yes, the report does make sense now.

Uploaded a new DLL version (13.210.1131) which should really fix this.

Revision history for this message
4StarGeneral (4stargeneral) wrote :

13.210.1131: The Big Four now respect Temporal warheads and lose their AE image. They do not lose their effects though (for example animation damage), whether or not this is intended.

Revision history for this message
mevitar (mevitar) wrote :

I can confirm that it works, although with some exceptions, so i'll explain exactly what i tested below (tested in 13.210.1131).

AttachEffect.TemporalHidesAnim=no
* the AE pauses while the temporal effect lasts, but the animation still goes on, dealing damage normally if has any <this works>
* if the temporal effect is broken, AE resumes from where it paused, and the animation restarts (it will play from its first frame again, even if it was on the middle frame just before temporal effect ended) <this works, although graphically it might look bad>
* if a unit has a permanent AE animation on it, the animation will always play constantly while the unit is being warped away (even if normally the animation plays for a moment and has a long delay before it appears again! more than that, it will instantly appear on the unit each time it is warped away, even if the time for that didn't come yet) <this doesn't work like it should>

AttachEffect.TemporalHidesAnim=yes
* an object affected by an AE loses the AE animation and the effect itself pauses while being affected by a temporal warhead (however, if the animation has any sound on it, the sound will still play!) <this works, except for sound>
* AE animation will still appear when a warhead hits a unit that is being warped away, just as if the warhead had AttachEffect.TemporalHidesAnim=no on it (the timer won't move, and the effect will be paused, but the animation will still play) <this doesn't work like it should>
* if a unit has a permanent AE animation on it, there's no difference from what happens with AE warheads (the anim vanishes, but the sound will still play) <this works, except for sound>

I think i didn't miss anything...

Revision history for this message
mevitar (mevitar) wrote :

BTW, i tested it on allied units. Didn't test if it's the same with enemy units attacking me or with enemy AE.

Revision history for this message
4StarGeneral (4stargeneral) wrote :

These same things happen on enemy units.

to quote mevitar:
* an object affected by an AE loses the AE animation and the effect itself pauses while being affected by a temporal warhead (however, if the animation has any sound on it, the sound will still play!) <this works, except for sound>

As mentioned, I've had animation damage also working despite the animation not showing. (same as if DetailLevel was set lower than default)

Thanks for putting more detail into it Mevitar :)

Revision history for this message
Graion Dilach (graiondilach) wrote :

Changed the animation handling in 13.212.726. Now animations will be deleted and not paused under temporal. This should fix the issues above.

Revision history for this message
mevitar (mevitar) wrote :

Nvm the last point under AttachEffect.TemporalHidesAnim=no. I was using CHRONOSK as AE anim on the unit, and it looked like if the AE returned each time i attacked it with a Temporal=yes weapon...

Revision history for this message
mevitar (mevitar) wrote :

AE warheads still put animation on objects already affected by a Temporal=yes warhead, whether they have AttachEffect.TemporalHidesAnim= set to 'yes' or 'no'.

Other issues are fixed in 13.212.726.

Revision history for this message
Graion Dilach (graiondilach) wrote :

...

Okay, that's a facepalm moment of mine. It'll be fixed soon.

Revision history for this message
Graion Dilach (graiondilach) wrote :

13.219.250 shall fix that issue.

Revision history for this message
mevitar (mevitar) wrote :

Fixed.

Changed in ares:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.