HomeUser Control Panel (unavailable in archive)ForumsTutorialsArt GalleryResourcesMaps

Recognising different custom abilities of same base type.

02-29-2004, 02:09 PM#1
Alfryd
Specifically, I have 3 custom abilities all based off metamorphosis for the same unit, and I'm wondering if there's a JASS function that will allow me to distinguish between them, after the TriggerRegisterUnitEvent has picked one of them up. Thanks for your time.
02-29-2004, 05:23 PM#2
AIAndy
AFAIK, having more than one spell based on the same spell on the same unit causes problems.
02-29-2004, 06:59 PM#3
Cubasis
Yes

This problem is for spells that use orderstrings, that is, ones that you actually "use" (instead of passive skills).

Cubasis
03-01-2004, 09:07 AM#4
Alfryd
Isn't there any workaround? Would assigning different order strings to the custom ability help? Is there any function that can recognise the integer code for the custom ability? No?
03-01-2004, 09:09 AM#5
Cubasis
Alfryd,

You simply can't put a two spells with the same orderstring on the same hero. There is no workaround. The only thing you can do, is choosing different bases that do the same thing. F.ex. Firebolt and Storm Bolt do the same thing, however, they don't have the same order-string.

So you're limited to that.

Cubasis
03-01-2004, 02:06 PM#6
Alfryd
It's not a hero, it's a building. And, they don't have the same order strings. The GUI allows me to change that much. I *assume* they don't put that feature in for cosmetic purposes.

My current approach is to have

Quote:
if ( not ( GetSpellAbility() == udg_testingone ) ) then
return false
endif
return true

Comparing the ability type directly, rather than the spell ID.
Unfortunately, to top things off, the WE GUI actually implements ability types as integers, so the above statement is illegal, and even JASS seems to lacks statements for converting ID numbers into ability types. Correct me if I'm wrong.
What I'd like to do is override the main .ai file to declare global variables of my own for abilities testingone and testingtwo (both based off divine shield,) of type ability. Then, have a trigger running at map initialisation order _seperate_ units with one each of the respective abilities to cast them, then use listeners to record the ability concerned, then use that to check for their use in the one unit with both abilities, which the user would have access to.
Do you see any merit in this approach? If so, how would I override the map .ai file where all the global variables are declared? Sorry to be a nuisance.
03-01-2004, 02:27 PM#7
Cubasis
Hmm

Firstly, and most sadly... Changing orderstrings is buggy I hear. It doesn't work as easily as it should. However, i may be wrong, but I've always heard about the fact that you can't change a spells order-string (even thought there is a field for it in the Object Editor). However, feel free to test it (in-game) and proof me wrong.

Secondly, OrderId and AbilityID's are integers as you say. However, it's easy to access them. In the Object Editor, you can press ctrl+d (i think, for raw mode). Then, your spell's name will show two 4-character codes. The first one (i think) is the individual one appointed to your ability (where-as the other is the ID of the "base" spell).

This 4-character code is in fact a Integer, the same is with Unit-Types (just integers). So, I reccomend you to use: GetSpellAbilityId <-- notice "Id". And compare the integer returned by it, with the AbilityId of your choice.

It's normally better to use the AbilityId's than the Ability-strings themselves, as they are rather limited.

And lastly, wtf do you want to do with .ai file? I don't really understand what you need/want to do there, as AI doesn't affect any of this (depends on what you're doing).


Lastly, you're kinda unlucky to be working with the devine shields, else, i'd reccomend you to instead use dummy-skills, which, when triggered would kick off a trigger that gives the unit a skill to cast, have the unit instantly cast it, and then remove it again after casting it. It's 100% unnoticable, as i've seen it done on many places.


Cubasis
03-01-2004, 02:43 PM#8
Vexorian
The orderstring field does nothing, it just shows the spell's orderstring if it has it, if you change it, nothing will happen.
03-02-2004, 04:06 PM#9
Alfryd
Quote:
The orderstring field does nothing, it just shows the spell's orderstring if it has it, if you change it, nothing will happen.

Blast. Thanks for the clarification, though I'm pretty sure I did get a trigger to tell the difference between 'divineshield' and 'undivineshield'. Maybe strings related to the same base ability are a special case. Or maybe I'm going senile.

Quote:
Secondly, OrderId and AbilityID's are integers as you say. However, it's easy to access them. In the Object Editor, you can press ctrl+d (i think, for raw mode). Then, your spell's name will show two 4-character codes. The first one (i think) is the individual one appointed to your ability (where-as the other is the ID of the "base" spell).

I had tried testing that approach using a standard conversion from a GUI trigger, but for bizarre reasons, utterly beyond my comprehension:
Quote:
GetSpellAbilityId() == 'A00B'
Returns true for divine shield, testingone, and testingtwo. Don't ask me how.

Quote:
And lastly, wtf do you want to do with .ai file? I don't really understand what you need/want to do there, as AI doesn't affect any of this (depends on what you're doing).

In order to record the ability type between triggers, I can't use a local variable (though I suppose I could set up trigger creation functions of my own and pass the recorded ability in the function signature for trigger actions, I like to use the GUI where possible.) So I need some global variables of type ability. If I recall correctly, you can only declare global variables in an .ai file. And it's something I should know how to do anyway.

Quote:
Lastly, you're kinda unlucky to be working with the devine shields, else, i'd reccomend you to instead use dummy-skills, which, when triggered would kick off a trigger that gives the unit a skill to cast, have the unit instantly cast it, and then remove it again after casting it. It's 100% unnoticable, as i've seen it done on many places.

Are you saying that removing the dummy ability from the unit will instantly cancel all it's effects? You see, I had been using dummy abilities based off divine shield for various trigger-based effects on the basis I could rig divine shield to have virtually no effect, unlike, say blizzard, which requires targetting from the user (unsuitable for this application. But if I can remove, then restore, the ability right after casting begins, breaking it's effects, I can select different base abilities and not need to worry about inconvenient spell side effects. Thank you for that.