- Joined
- Feb 5, 2009
- Messages
- 4,668
Hello all. I am unsure if this has been explored before, or if this will be of particular use to anybody, but I would like to share what I have found in regards to Engineering Upgrade of late.
Now, from what I can gather it is fairly well established that Engineering Upgrade is a rather finicky ability to work with, which is a particular shame as it could open up so much possibilities if it were to be made available to work with Unit abilities. Used incorrectly it can crash the game, and it has a buff that it doesn't seem to use to apply Spiked Carapace to any models that support the required attachment points.
However, there is a particular area I would like to explore with it, and that is what it is designed to do - replace abilities. In effect, that is what it does, although the practical application thusfar is to replace abilities with a slightly altered version of themselves. This can be exploited to make certain things previously deemed impossible to become possible.
Take the Paladin, for example. By default, its skillset is Holy Light, Divine Shield, Devotion Aura and Resurreciton. By making a custom Engineering Upgrade (Hero) Skill with 1 Level, designating it to replace this skillset with that of the Death Knight, you can, through triggers, add the custom ability to the Paladin to replace its moveset. This effectively enables you to alter what abilities are available for learning, but it does run into some complications:
Say you take Battle Roar, and then apply an Engineering Upgrade effect to replace it with Bash. You will still be able to active Battle Roar, but instead of applying a 10 damage bonus at level 1, it will apply 20 - based directly off of the percentage chance of Bash occurring at level 1. Additionally, this will stun the caster and only last for as long as Bash would normally last. It is likely this can produce some wildly unusual effects.
The main part, however, I was particularly interested in was the potential applications to have one hero as a baseline, and present the opportunity for various classes to be applied. So, you have up to four dummy skills (five if you use a second Engineering Upgrade ability), all ready to be replaced with brand new skills based upon a selected hero class. However, to overcome the aforementioned problems, some tweaking is required.
For preliminary debug testing, a scenario was created - replace a dummy ability with Holy Light. When the new Holy Light ability is cast, the game would deliver a message detailing the ability name, the tooltips, extended and default, for both learning and normal, as well as the path of the research icon. All of the tooltips and the ability name were perfectly reflective of Holy Light - the icon research path, however, was of the original ability. This was of particular interest, as the icon shown in what the hero could learn was Holy Light, rather than the original dummy ability. This is likely due to the information stored in the Engineering Upgrade of what the original ability was.
Armed with this information, it became clear that attempting to customize the ability's icon or tooltips for the individual unit, even with recent capabilities in GUI, was a no go. As far as the game was concerned, the hero did not have either ability in question, and as such it was unable to edit it. If you edit the dummy ability for all cases via triggers, the new information will present itself - but this would not be effective as a solution.
Bizarrely enough, however, it was found that if you added Holy Light via triggers before learning it from the dummy ability being used to learn it, it demonstrated everything perfectly. The ability functioned perfectly, and you could level it the rest of the way up and the game would treat it as though it was exactly the way it should be. And thus, all that was left was to set it up so that if it was your first time learning a skill, the skill would be removed and added back again.
Unfortunately, this was not able to be done in raw GUI - the GUI code is severely limited in its capabilities to determine what a hero's "learned skill" is, but despite this, it was found to be fully functional when used as a replacement for "ability being cast". And thus, this code was born:
So, given all that, I am curious to see what people's thoughts are concerning this, and hope it might help somebody with a problem that this kind of solution might be able to solve for them.
Now, from what I can gather it is fairly well established that Engineering Upgrade is a rather finicky ability to work with, which is a particular shame as it could open up so much possibilities if it were to be made available to work with Unit abilities. Used incorrectly it can crash the game, and it has a buff that it doesn't seem to use to apply Spiked Carapace to any models that support the required attachment points.
However, there is a particular area I would like to explore with it, and that is what it is designed to do - replace abilities. In effect, that is what it does, although the practical application thusfar is to replace abilities with a slightly altered version of themselves. This can be exploited to make certain things previously deemed impossible to become possible.
Take the Paladin, for example. By default, its skillset is Holy Light, Divine Shield, Devotion Aura and Resurreciton. By making a custom Engineering Upgrade (Hero) Skill with 1 Level, designating it to replace this skillset with that of the Death Knight, you can, through triggers, add the custom ability to the Paladin to replace its moveset. This effectively enables you to alter what abilities are available for learning, but it does run into some complications:
- If you have, for example, already learned an ability before the Engineering Upgrade skill has been applied, all that will change is the button location.
- Say, for example, you for some reason wanted to replace Holy Light with Death Pact rather than Death Coil - by applying the Engineering Upgrade skill when you already have the ability, it will keep Holy Light, but relocate it to where Death Pact would normally be.
- Strangely enough, this will change the mana cost of Holy Light to the mana cost of Death Coil. With consideration that Tinker's use of Engineering Upgrade is perfectly functional, it seems reasonable to deduce that this is purely due to incompatible data fields failing to replace one another in this particular instance.
- If you already have Engineering Upgrade, and decide to learn the newly acquired Death Coil spell, you will appear to still get Holy Light, but the ability will possess the properties of Death Coil. The effects also do not transition entirely, so when you cast your new spell, it will still use the Holy Light effect, but there will be a slight delay for when Death Coil would normally hit the target - it will then play the animation of Death Coil hitting the target, without the missile appearing, and damage living targets while healing Undead.
Say you take Battle Roar, and then apply an Engineering Upgrade effect to replace it with Bash. You will still be able to active Battle Roar, but instead of applying a 10 damage bonus at level 1, it will apply 20 - based directly off of the percentage chance of Bash occurring at level 1. Additionally, this will stun the caster and only last for as long as Bash would normally last. It is likely this can produce some wildly unusual effects.
The main part, however, I was particularly interested in was the potential applications to have one hero as a baseline, and present the opportunity for various classes to be applied. So, you have up to four dummy skills (five if you use a second Engineering Upgrade ability), all ready to be replaced with brand new skills based upon a selected hero class. However, to overcome the aforementioned problems, some tweaking is required.
For preliminary debug testing, a scenario was created - replace a dummy ability with Holy Light. When the new Holy Light ability is cast, the game would deliver a message detailing the ability name, the tooltips, extended and default, for both learning and normal, as well as the path of the research icon. All of the tooltips and the ability name were perfectly reflective of Holy Light - the icon research path, however, was of the original ability. This was of particular interest, as the icon shown in what the hero could learn was Holy Light, rather than the original dummy ability. This is likely due to the information stored in the Engineering Upgrade of what the original ability was.
Armed with this information, it became clear that attempting to customize the ability's icon or tooltips for the individual unit, even with recent capabilities in GUI, was a no go. As far as the game was concerned, the hero did not have either ability in question, and as such it was unable to edit it. If you edit the dummy ability for all cases via triggers, the new information will present itself - but this would not be effective as a solution.
Bizarrely enough, however, it was found that if you added Holy Light via triggers before learning it from the dummy ability being used to learn it, it demonstrated everything perfectly. The ability functioned perfectly, and you could level it the rest of the way up and the game would treat it as though it was exactly the way it should be. And thus, all that was left was to set it up so that if it was your first time learning a skill, the skill would be removed and added back again.
Unfortunately, this was not able to be done in raw GUI - the GUI code is severely limited in its capabilities to determine what a hero's "learned skill" is, but despite this, it was found to be fully functional when used as a replacement for "ability being cast". And thus, this code was born:
Code:
function Trig_Ability_Fix_Conditions takes nothing returns boolean
if ( not ( GetUnitAbilityLevelSwapped(GetLearnedSkillBJ(), GetTriggerUnit()) == 1 ) ) then
return false
endif
return true
endfunction
function Trig_Ability_Fix_Actions takes nothing returns nothing
call UnitRemoveAbilityBJ( GetLearnedSkillBJ(), GetTriggerUnit() )
call UnitAddAbilityBJ( GetLearnedSkillBJ(), GetTriggerUnit() )
endfunction
//===========================================================================
function InitTrig_Ability_Fix takes nothing returns nothing
set gg_trg_Ability_Fix = CreateTrigger( )
call TriggerRegisterAnyUnitEventBJ( gg_trg_Ability_Fix, EVENT_PLAYER_HERO_SKILL )
call TriggerAddCondition( gg_trg_Ability_Fix, Condition( function Trig_Ability_Fix_Conditions ) )
call TriggerAddAction( gg_trg_Ability_Fix, function Trig_Ability_Fix_Actions )
endfunctionSo, given all that, I am curious to see what people's thoughts are concerning this, and hope it might help somebody with a problem that this kind of solution might be able to solve for them.
