[Solved] Making spell inactive while another active

Level 12
Joined
Jul 5, 2014
Messages
551
I didn't see any question of that kind, so I'm not sure if it's possible. I have a hero with both defend and shield bash ability. However, I want the shield bash only usable if he's not in defend mode. Is there some way to make shield bash inactive (as if being silenced but only for that spell) while defend is active? Or hiding/making shield bash unavailable while it's active? Or it's can't be done without the "remove ability" option?
 
Level 29
Joined
Sep 26, 2009
Messages
2,594
I assume each player can have that hero only once? If so, you can leverage ability Techtree Requirements.
  • Create an upgrade that does not do anything by itself (i.e. Flare upgrade).
  • Name the upgrade for example 'Defend mode must be inactive'.
  • Set this upgrade as Techtree Requirement for your Shield Bash ability.
  • When you want to prevent the hero from using Shield Bash, just set the upgrade's level to zero
  • When you want to allow usage of the ability, set the upgrade to level one
  • Player - Set the current research level of Defend mode must be inactive to 0 for Some_Player
In game, when player cannot use the ability, he will see on mouseover the following message:
Code:
Requirements:
- Defend mode must be inactive
or some other message if you named the upgrade differently.

If you are on older versions of WCIII, I believe you cannot decrease upgrade level. So instead of upgrade use a unit - create a dummy unit with the name 'Defend mode must be inactive', set the unit as Shield Bash requirement, and when you want to allow usage of Shield Bash place the unit into map for that player, otherwise remove the unit for that player.
 
Level 12
Joined
Jul 5, 2014
Messages
551
I assume each player can have that hero only once? If so, you can leverage ability Techtree Requirements.
  • Create an upgrade that does not do anything by itself (i.e. Flare upgrade).
  • Name the upgrade for example 'Defend mode must be inactive'.
  • Set this upgrade as Techtree Requirement for your Shield Bash ability.
  • When you want to prevent the hero from using Shield Bash, just set the upgrade's level to zero
  • When you want to allow usage of the ability, set the upgrade to level one
  • Player - Set the current research level of Defend mode must be inactive to 0 for Some_Player
In game, when player cannot use the ability, he will see on mouseover the following message:
Code:
Requirements:
- Defend mode must be inactive
or some other message if you named the upgrade differently.

If you are on older versions of WCIII, I believe you cannot decrease upgrade level. So instead of upgrade use a unit - create a dummy unit with the name 'Defend mode must be inactive', set the unit as Shield Bash requirement, and when you want to allow usage of Shield Bash place the unit into map for that player, otherwise remove the unit for that player.
I have 1.26 version. Is that capable of the tech decrease? The unit requirement is clever and it would make things even better than I expected because it gives off the notification for the player. However, defend has no cooldown, so if the player keeps turning off and on defend, it begans piling up an unavoidable unit leak, even if the unit is removed. I'm not sure how big of a problem would that become after a while. This is an RPG campaign with having this hero by default, so there's no other base-related factor.
 
Level 30
Joined
Aug 29, 2012
Messages
1,382
I think this action already existed back then

1720619447510.png


It's a bit less player friendly since it will hide it completely from the command card but it's as straightforward as it gets
 
Level 12
Joined
Jul 5, 2014
Messages
551
I think this action already existed back then

View attachment 479104

It's a bit less player friendly since it will hide it completely from the command card but it's as straightforward as it gets
Yeah, I've noticed that accidentally after I couldn't find it intentionally, lol. It's so simple and straightforward but visually, the other is perfect. I could even make it work but I'm not sure about the memory leak. What's the worst leak a player can create with defend in like 4-5 hours?
 
Level 30
Joined
Aug 29, 2012
Messages
1,382
Well units themselves don't leak so if you just clear the point they're created at, it's good. But anyway since your spell is either ON or OFF, that's only 2 dummy units per player, because you'll need to remove them for your tech tree requirement to be missing
 
Level 12
Joined
Jul 5, 2014
Messages
551
Well units themselves don't leak so if you just clear the point they're created at, it's good. But anyway since your spell is either ON or OFF, that's only 2 dummy units per player, because you'll need to remove them for your tech tree requirement to be missing
Are you sure? The leak guide said that even if you properly remove a unit, it still takes up a small amount of memory.

 
Level 30
Joined
Aug 29, 2012
Messages
1,382
I doubt it'd have any noticeable consequences, but for the sake of the argument, let's pretend it's the case, so here's an alternative still based on Nichilus' idea:

Pre-place 1 dummy unit per player in a remote corner of the map, and when a player disable defend, you change the owner of their dummy tech requirement to e.g. neutral passive, and when they enable defend, you change it back to them. That way you don't have to worry about creating hundreds of units
 
Level 12
Joined
Jul 5, 2014
Messages
551
I doubt it'd have any noticeable consequences, but for the sake of the argument, let's pretend it's the case, so here's an alternative still based on Nichilus' idea:

Pre-place 1 dummy unit per player in a remote corner of the map, and when a player disable defend, you change the owner of their dummy tech requirement to e.g. neutral passive, and when they enable defend, you change it back to them. That way you don't have to worry about creating hundreds of units
Uh, now I feel dumb not thinking of this. That would also spare me from dealing with the region.

I found an exploit though: targeting a unit for shield bash then going into defend won't stop the execution. Can I interrupt it without issuing a "stop" order? Would a disable/enable trigger without wait noticable when using defend?
 

Uncle

Warcraft Moderator
Level 73
Joined
Aug 10, 2018
Messages
7,866
When toggling Defend on you could Add an unusable Shield Bash ability to your Unit(s) to act as it's "disabled icon". IE: A passive that does nothing and has a special icon. Then remove said ability when toggling Defend off. This would give the illusion that the Icon never disappeared.

To detect the usage of Defend, you need to use Orders, in particular the Event "A unit issues an order with no target", then in the Conditions you check for either of these Issued orders -> "defend" or "undefend".

Note that on 1.31+ you can Disable/Hide abilities for a specific Unit rather than for a Player.
 

Uncle

Warcraft Moderator
Level 73
Joined
Aug 10, 2018
Messages
7,866
Are you sure? The leak guide said that even if you properly remove a unit, it still takes up a small amount of memory.
Pro tip for memory leaks when working in GUI. Do NOT concern yourself with any leaks besides:

Unit Groups, Player Groups, Points, and Special Effects.

That's it, everything else is bullshit until you advance to Jass/Lua.
 
Level 12
Joined
Jul 5, 2014
Messages
551
When toggling Defend on you could Add an unusable Shield Bash ability to your Unit(s) to act as it's "disabled icon". IE: A passive that does nothing and has a special icon. Then remove said ability when toggling Defend off. This would give the illusion that the Icon never disappeared.

To detect the usage of Defend, you need to use Orders, in particular the Event "A unit issues an order with no target", then in the Conditions you check for either of these Issued orders -> "defend" or "undefend".

Note that on 1.31+ you can Disable/Hide abilities for a specific Unit rather than for a Player.
The requirement solution solved the deactivated shield bash but the issue I have no is that you can still use it if you targeted someone with it before going into defend. Not even disabling the ability removes that (the shield bash is based on Channel). I'm trying to find a way to cancel the target without using stop command.
 

Uncle

Warcraft Moderator
Level 73
Joined
Aug 10, 2018
Messages
7,866
The requirement solution solved the deactivated shield bash but the issue I have no is that you can still use it if you targeted someone with it before going into defend. Not even disabling the ability removes that (the shield bash is based on Channel). I'm trying to find a way to cancel the target without using stop command.
Try changing some settings on Channel under the Options category.

Otherwise, "A unit begins casting an ability" -> "It's shield bash" -> "It's disabled" -> "Order unit to Stop".

That isn't perfect but it'll prevent the ability from ever being used while disabled.
 

Uncle

Warcraft Moderator
Level 73
Joined
Aug 10, 2018
Messages
7,866
Where's the disabled ability checking condition?
Probably doesn't exist, you'll have to track the information yourself in your own Boolean array variable.
  • Actions
    • Set Variable Is_Shield_Bash_Disabled[(Player number of ... )] = True
    • Set Variable Is_Shield_Bash_Disabled[(Player number of ... )] = False
  • Conditions
    • Is_Shield_Bash_Disabled[(Player number of ... )] Equal to True
 
Level 12
Joined
Jul 5, 2014
Messages
551
Probably doesn't exist, you'll have to track the information yourself in your own Boolean array variable.
  • Actions
    • Set Variable Is_Shield_Bash_Disabled[(Player number of ... )] = True
    • Set Variable Is_Shield_Bash_Disabled[(Player number of ... )] = False
  • Conditions
    • Is_Shield_Bash_Disabled[(Player number of ... )] Equal to True
I've set this up but didn't seem to do anything.

  • Anti Exploit
    • Events
      • Unit - A unit Begins casting an ability
    • Conditions
      • (Ability being cast) Equal to Shield Bash (Captain)
      • BashDisabled Equal to True
    • Actions
      • Unit - Order (Casting unit) to Stop
 

Uncle

Warcraft Moderator
Level 73
Joined
Aug 10, 2018
Messages
7,866
I've set this up but didn't seem to do anything.

  • Anti Exploit
    • Events
      • Unit - A unit Begins casting an ability
    • Conditions
      • (Ability being cast) Equal to Shield Bash (Captain)
      • BashDisabled Equal to True
    • Actions
      • Unit - Order (Casting unit) to Stop
Is BashDisabled equal to true? I'd have to see where and how you're setting it.
 
Level 12
Joined
Jul 5, 2014
Messages
551
Is BashDisabled equal to true? I'd have to see where and how you're setting it.
I set it to false as an initial value. Then I set them true and false depending on whether defend is active.

  • Defend
    • Events
      • Unit - A unit Is issued an order with no target
    • Conditions
      • (Triggering unit) Equal to The Captain
      • (Issued order) Equal to (Order(defend))
    • Actions
      • Set BashDisabled = True
  • Stop Defend
    • Events
      • Unit - A unit Is issued an order with no target
    • Conditions
      • (Triggering unit) Equal to The Captain
      • (Issued order) Equal to (Order(undefend))
    • Actions
      • Set BashDisabled = False
 

Uncle

Warcraft Moderator
Level 73
Joined
Aug 10, 2018
Messages
7,866
I set it to false as an initial value. Then I set them true and false depending on whether defend is active.

  • Defend
    • Events
      • Unit - A unit Is issued an order with no target
    • Conditions
      • (Triggering unit) Equal to The Captain
      • (Issued order) Equal to (Order(defend))
    • Actions
      • Set BashDisabled = True
  • Stop Defend
    • Events
      • Unit - A unit Is issued an order with no target
    • Conditions
      • (Triggering unit) Equal to The Captain
      • (Issued order) Equal to (Order(undefend))
    • Actions
      • Set BashDisabled = False
Alright, so if you're 100% sure that Anti Exploit is running it's Actions (confirm with an Action that proves this) then perhaps you'll need to do a little more to interrupt the ability:
  • Actions
    • Unit - Pause (Triggering unit)
    • Unit - Order (Triggering unit) to Stop
    • Unit - Unpause (Triggering unit)
Or maybe:
  • Actions
    • Unit - Remove Shield Bash from (Triggering unit)
    • Unit - Add Shield Bash to (Triggering unit)
 
Level 12
Joined
Jul 5, 2014
Messages
551
Alright, so if you're 100% sure that Anti Exploit is running it's Actions (confirm with an Action that proves this) then perhaps you'll need to do a little more to interrupt the ability:
  • Actions
    • Unit - Pause (Triggering unit)
    • Unit - Order (Triggering unit) to Stop
    • Unit - Unpause (Triggering unit)
Or maybe:
  • Actions
    • Unit - Remove Shield Bash from (Triggering unit)
    • Unit - Add Shield Bash to (Triggering unit)
I gave a periodic check to see if my boolean is true or false. The boolean works fine. However, isn't "began casting ability" starts when your ability gets the green frame? Because if that's the case, the ability was "began cast" while the boolean was false and the unit keeps moving with it even while it's true.
 

Uncle

Warcraft Moderator
Level 73
Joined
Aug 10, 2018
Messages
7,866
I gave a periodic check to see if my boolean is true or false. The boolean works fine. However, isn't "began casting ability" starts when your ability gets the green frame? Because if that's the case, the ability was "began cast" while the boolean was false and the unit keeps moving with it even while it's true.
It's not going to interrupt it's movement, it'll interrupt the literal cast.

But a periodic check isn't a great way to test if the trigger runs it's Actions or not. You'd want an Action that is guaranteed to work regardless of any possible circumstances. A text message or anything glaringly obvious:
  • Actions
    • Player - Add 1000000 Gold to Player 1 (Red)
Anyway, to interrupt the movement you'll need to issue a Stop order to any Units with the order to use this ability, which may or may not work. Since the ability is based on Channel your Order is equal to the Base Order Id.
 
Level 12
Joined
Jul 5, 2014
Messages
551
It's not going to interrupt it's movement, it'll interrupt the literal cast.
Okay, so I see the ability didn't go to cooldown, which means it's interrupted. However, it wasn't interrupted enough to stop the dummy unit casting the actual spell. However, the dummy is so fast, that even the instant pause or turning off/on the dummy's trigger didn't prevent it from executing.
 

Uncle

Warcraft Moderator
Level 73
Joined
Aug 10, 2018
Messages
7,866
Okay, so I see the ability didn't go to cooldown, which means it's interrupted. However, it wasn't interrupted enough to stop the dummy unit casting the actual spell. However, the dummy is so fast, that even the instant pause or turning off/on the dummy's trigger didn't prevent it from executing.
Not too sure what you mean, Dummy unit? When are you creating a Dummy unit? Post all of your triggers, please.
 
Level 12
Joined
Jul 5, 2014
Messages
551
Not too sure what you mean, Dummy unit? When are you creating a Dummy unit? Post all of your triggers, please.
Like I said, the shield bash is based on channel. So I have a dummy unit that actually does the shield bash (aka a melee firebolt). So, the interruption of the channel ability don't seem to prevent the dummy from doing the spell the channel meant to trigger.
 

Uncle

Warcraft Moderator
Level 73
Joined
Aug 10, 2018
Messages
7,866
Like I said, the shield bash is based on channel. So I have a dummy unit that actually does the shield bash (aka a melee firebolt). So, the interruption of the channel ability don't seem to prevent the dummy from doing the spell the channel meant to trigger.
Okay, so you're triggering the Dummy to cast the spell. So just prevent that trigger from running if the Boolean is True.

Begins casting -> If Boolean = True -> Interrupt
Starts effect -> If Boolean = False -> Run actions
 
Level 12
Joined
Jul 5, 2014
Messages
551
If you're using the tech tree system like we discussed above, you can probably add your tech dummy unit as a requirement for your dummy firebolt spell, that way it couldn't cast the spell unless shield bash is activated :D

View attachment 479139
Geez, that's another easy solution I overlooked. Thanks!

Okay, so you're triggering the Dummy to cast the spell. So just prevent that trigger from running if the Boolean is True.

Begins casting -> If Boolean = True -> Interrupt
Starts effect -> If Boolean = False -> Run actions
Chaosium's suggestion solved the issue without triggering.
 
Level 45
Joined
Feb 27, 2007
Messages
5,578
You can also just… check the current owner of the dummy requirement unit. If it’s owned by Neutral Passive then the ability is disabled; if it’s not owned by Neutral Passive then the ability is enabled. No need to introduce a manually-updated Boolean (though that is simple to do).
 
Level 45
Joined
Feb 27, 2007
Messages
5,578
I don’t think you understood what I wrote there; nobody else suggested that in this thread. Since you are using a dummy to toggle the requirement, you can check the current state of the dummy to see if the spell cast is valid. Using a begins casting event and checking the dummy owner (like you were doing with the boolean) means you can prevent the cast from going through entirely (as Uncle suggested).

The problem with Chaosium’s solution (though it’s clever) is that the main hero spell will still be cast even though the dummy can’t cast the Firebolt. That means mana cost, cooldown, and any triggers that detect spell casts will still occur. Even though the dummy spell never goes off so nothing actually happens. If the hero spell has no mana cost and no cooldown then yeah there’s no difference.
 
Level 12
Joined
Jul 5, 2014
Messages
551
I don’t think you understood what I wrote there; nobody else suggested that in this thread. Since you are using a dummy to toggle the requirement, you can check the current state of the dummy to see if the spell cast is valid. Using a begins casting event and checking the dummy owner (like you were doing with the boolean) means you can prevent the cast from going through entirely (as Uncle suggested).

The problem with Chaosium’s solution (though it’s clever) is that the main hero spell will still be cast even though the dummy can’t cast the Firebolt. That means mana cost, cooldown, and any triggers that detect spell casts will still occur. Even though the dummy spell never goes off so nothing actually happens. If the hero spell has no mana cost and no cooldown then yeah there’s no difference.
So, you're referring to solving the mana/cooldown issue of pre-casting the channel-ability before defend is activated? Right now, I have this trigger for it.

  • Bash
    • Events
      • Unit - A unit Begins casting an ability
    • Conditions
      • (Ability being cast) Equal to Shield Bash
    • Actions
      • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
        • If - Conditions
          • BashDisabled Equal to True
        • Then - Actions
          • Unit - Order (Casting unit) to Stop
        • Else - Actions
          • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
            • If - Conditions
              • BashDisabled Equal to False
            • Then - Actions
              • Set Basher = (Position of (Triggering unit))
              • Unit - Create 1 Dummy for Player 2 (Blue) at Basher facing Default building facing degrees
              • Set BashCaster = (Last created unit)
              • Unit - Add Bash to BashCaster
              • Unit - Set level of Bash for BashCaster to (Level of Shield Bash for (Triggering unit))
              • Unit - Order BashCaster to Neutral - Firebolt (Target unit of ability being cast)
              • Unit - Add a 1.00 second Generic expiration timer to BashCaster
              • Custom script: call RemoveLocation(udg_Basher)
            • Else - Actions
 
Level 10
Joined
Jan 26, 2019
Messages
90
What's the worst leak a player can create with defend in like 4-5 hours?
One day a man who made a good hero defense on reforged came to me for help.
He had problems with leaks, with every hour the FPS dropped more and more (at 1.26 this would have already led to a critical error).
I checked the code of his map for the presence of known default GUI functions that contain leaks.
1720726296029.png
One of the main problems was the CountLivingPlayerUnitsOfTypeId function which was used frequently by periodic timers throughout the game.
The reality is that many GUI functions contain leaks that the GUI user cannot fix, the only way is to use the YDWE PK editor in which these leaks have been fixed.
If you are making a map for 1.26 but do not use YDWE PK then you will suffer.
You will either have to refuse of many of the leaked functions, or try to replace them through "Custom Code"
All other leaks depend only on you (for example, creating a location and not deleting after using)
 
Level 12
Joined
Jul 5, 2014
Messages
551
The reality is that many GUI functions contain leaks that the GUI user cannot fix, the only way is to use the YDWE PK editor in which these leaks have been fixed.
If you are making a map for 1.26 but do not use YDWE PK then you will suffer.
You will either have to refuse of many of the leaked functions, or try to replace them through "Custom Code"
Inserting custom codes is not a massive work. And my map doesn't count living units periodically.
 
Level 45
Joined
Feb 27, 2007
Messages
5,578
You’ve already solved the issue, WarCortez, presuming the boolean BashDisabled is properly set to true/false. I was showing that you didn’t need to use the boolean at all, since the current owner of the dummy requirement unit is the same information… but automatic (not requiring you to set BashDisabled manually).

I know that you are learning so I thought showing how you could use pre-existing information to achieve the same thing could be illustrative. You may one day encounter another similar situation and think to use pre-existing information as I have shown here.

Regarding your trigger, there’s no reason for the second nested if that checks BashDisabled = false. Why? It’s a boolean variable so can only ever have the value true/false, so if the first If check failed (causing the Else actions to run) then by default BashDisabled must be false and there’s no need to check it again.
 
Level 12
Joined
Jul 5, 2014
Messages
551
You’ve already solved the issue, WarCortez, presuming the boolean BashDisabled is properly set to true/false. I was showing that you didn’t need to use the boolean at all, since the current owner of the dummy requirement unit is the same information… but automatic (not requiring you to set BashDisabled manually).

I know that you are learning so I thought showing how you could use pre-existing information to achieve the same thing could be illustrative. You may one day encounter another similar situation and think to use pre-existing information as I have shown here.

Regarding your trigger, there’s no reason for the second nested if that checks BashDisabled = false. Why? It’s a boolean variable so can only ever have the value true/false, so if the first If check failed (causing the Else actions to run) then by default BashDisabled must be false and there’s no need to check it again.
I put it the second check because when I put the action into the else area, you could avoid the spell's cooldown if you instantly cast it after turning off defend. I'm not sure why but after I did it like this, it didn't happen again.

However, I now did some testing. I've tried your version which didn't reproduce this and I've tried putting the dummy casting in the else and it also didn't repeat it. However, sometimes the stun remains permanent. If I cast the spell again, it wears off properly but some of the quick casting after undefending makes it permanent for some reason.
 
Level 45
Joined
Feb 27, 2007
Messages
5,578
As I said the check is literally pointless. If a boolean variable isn’t true then it has to be false so there is no possible scenario where both If-blocks would hit their else actions. (Pedantically yes it could be uninitialized entirely and thus neither true nor false, but I believe the thread would just crash when evaluating such a variable. And these are GUI variables which are always initialized automatically.)

Is the main hero spell based on channel with either “disable other abilities” or “pause unit” equal to true?

Maybe I misunderstand and it’s the targeted unit that is stunned indefinitely. The only way that could happen is if that targeted unit is paused in some way, as pausing also pauses all buffs and such spel effects. Otherwise an infinite stun would occur from a 0 duration Firebolt, which you are obviously not doing.

Feels like a nothingburger but the only other thread I could pull on is that if the dummy is fully dead and garbage collected by the time the Firebolt impacts the target, perhaps it can’t load the spell data fields and uses a 0 duration stun.
 
Level 12
Joined
Jul 5, 2014
Messages
551
As I said the check is literally pointless. If a boolean variable isn’t true then it has to be false so there is no possible scenario where both If-blocks would hit their else actions. (Pedantically yes it could be uninitialized entirely and thus neither true nor false, but I believe the thread would just crash when evaluating such a variable. And these are GUI variables which are always initialized automatically.)

Is the main hero spell based on channel with either “disable other abilities” or “pause unit” equal to true?

Maybe I misunderstand and it’s the targeted unit that is stunned indefinitely. The only way that could happen is if that targeted unit is paused in some way, as pausing also pauses all buffs and such spel effects. Otherwise an infinite stun would occur from a 0 duration Firebolt, which you are obviously not doing.

Feels like a nothingburger but the only other thread I could pull on is that if the dummy is fully dead and garbage collected by the time the Firebolt impacts the target, perhaps it can’t load the spell data fields and uses a 0 duration stun.
I'm aware that it this is what common sense would dictate but when the test results are wacky, I have to try variating. My punching bag dummy is paused (otherwise it keeps wiggling and I can't test out the instant switch) but this duration thing is bizarre. Normally, the paused unit gets a proper amount of stun, this only occurs if I cast shield bash as quickly as I can after undefending. My channel ability's duration is on 0, the only thing I can think of is that somehow, the sudden use would use that data for the firebolt spell.

EDIT: nope, changing the dummy skill's duration has no impact on the permastun issue. I unpaused the punching bag dummy and turned off the hero's auto-attack, and the issue didn't happen again. So apparently you were right, the pause messes things up although no idea why.
 
Last edited:
Level 45
Joined
Feb 27, 2007
Messages
5,578
I unpaused the punching bag dummy and turned off the hero's auto-attack, and the issue didn't happen again. So apparently you were right, the pause messes things up although no idea why.
pausing [a unit] also pauses all buffs and such spell effects [active on that unit when paused or applied to a unit while it is paused]
I would personally avoid EVER using the PauseUnit function. It can introduce weirdness with triggered spells and their buffs.
 
Level 12
Joined
Jul 5, 2014
Messages
551
But the paused effect is not constant. Normally using the skill as intended didn't pause the effect.

I would personally avoid EVER using the PauseUnit function. It can introduce weirdness with triggered spells and their buffs.
Ever? That particular case was merely testing. But there are many cases where I need units not to move around, either for cinematic of a dialogue reason. How should I do these without pausing?
 
Level 45
Joined
Feb 27, 2007
Messages
5,578
I mean outside of scripted cinematics; avoid PauseUnit within things (triggers) that may intersect with normal gameplay. I would use a stun for such things in normal gameplay. I’m sure there are non-pause solutions to do what you need in the cinematics while preventing unwanted behavior (changing unit owner but not color, adding/removing cargo hold, sneakily casting silence on a group of units, etc.).

Pausing before the buff is applied vs after it’s been applied may have different behavior. I really couldn’t tell you what was causing the infinite stun without messing with a test map myself.

Another large reason not to use Pause/Unpause is that if multiple different sources pause a unit simultaneously, the first one to unpause will unpause the unit completely, even if some other trigger expects it to still be paused. The newer function PauseUnitEx uses a counter system internally to avoid this issue (every pause is +1, every unpause is -1, and the unit is only unpaused at values 0 or less), but it doesn’t exist in 1.26.
 
Level 12
Joined
Jul 5, 2014
Messages
551
I mean outside of scripted cinematics; avoid PauseUnit within things (triggers) that may intersect with normal gameplay. I would use a stun for such things in normal gameplay. I’m sure there are non-pause solutions to do what you need in the cinematics while preventing unwanted behavior (changing unit owner but not color, adding/removing cargo hold, sneakily casting silence on a group of units, etc.).

Pausing before the buff is applied vs after it’s been applied may have different behavior. I really couldn’t tell you what was causing the infinite stun without messing with a test map myself.

Another large reason not to use Pause/Unpause is that if multiple different sources pause a unit simultaneously, the first one to unpause will unpause the unit completely, even if some other trigger expects it to still be paused. The newer function PauseUnitEx uses a counter system internally to avoid this issue (every pause is +1, every unpause is -1, and the unit is only unpaused at values 0 or less), but it doesn’t exist in 1.26.
So, just for the record, your issue with the pause is getting spells applied on the unit while being paused and getting multiple pauses?

Outside cinematic, I usually relied on pause when:

- there's a cinematic-like scenario, like having a dialogue with an npc and I don't want the player leave and talk from the other side of the room

- when there are units on standby for cinematic

- occasionally a short scenario when the character takes a look at something and comments on it
 
Level 45
Joined
Feb 27, 2007
Messages
5,578
It will affect/prevent some orders from being issued (even via trigger), will suspend buffs and other such effects indefinitely which you may not want or might not play nice with timed triggers that expect buffs to have finite durations, and opens a can of worms for any triggers that interact with the unit while paused if they don’t expect it to be paused (or vice versa if not using PauseUnitEx). It also removes the command card buttons which might or might not matter in a given situation.

Pausing is not inherently bad, it just introduces an avenue for unexpected behavior when gameplay triggers interact with paused units. If you only pause for cinematic purposes and always remember to pair your pause/unpause actions you are probably fine. Your uses seem acceptable. I jumped on this train of thought because I misunderstood and thought you were Pausing in gameplay triggers without realizing what that would effect.

Someone else may come by and have a perspective different than mine or tell me that my fears are unfounded.
 
Top