Listen to a special audio message from Bill Roper to the Hive Workshop community (Bill is a former Vice President of Blizzard Entertainment, Producer, Designer, Musician, Voice Actor) 🔗Click here to hear his message!
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?
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 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.
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?
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
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
C0Memory leaks For a quick lookup on most important actions, read Things That Leak. Introduction Object Leaks Reference Leaks Miscellaneous Conclusion C1Introduction If your computer's memory keeps occupied with stuff you already lost access to, it's called memory leak. It slows down the...
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
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?
You can create one unit per player. When you want to disable Shield Bash, just change owner of that dummy unit to Neutral Passive and back to original owner when enabling Shield Bash.
Thanks, it works well. However, even disabling and re-enabling the shield bash doesn't prevent an execution of it if the target was given before going into defend for some reason.
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.
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.
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.
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:
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:
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.
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.
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.
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.
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.
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
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.
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
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).
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).
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.
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
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.
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)
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"
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.
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.
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.
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.
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.
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?
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.
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.
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.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.