invisibility

[GIMLI_2]

hi,

i wanna make an invis skill.
it should:
-increase movementspeed
-not deal bonus damage if you attack out of invis

there are some possibilities:
take the windwalk of blademaster and set bonus damage to 0, but then the 0 bonus damage appears and that looks unprofessional

take the sorceress invisibility and let a dummy unit cast it on you, it gives no bonus damage but also no movement bonus. of course i could trigger the movement bonus, but is there another possibility?

maybe someone knows if you can remove the ugly bonus damage floating text after windwalk? or is there another invis skill (except of permanent invisibility)?

 

[rulerofiron99]

In the windwalk ability, there is a field Level 1 - Data - Backstab Damage = True. Set it to false, and no text will appear.

 

[GIMLI_2]

sure?, i think i tried that out, but it still appears.

another question:

if i got lets say 10 triggered abilities and i need for each one a caster and target variable
should i create for each trigger an own variable or should i create one array variable for every trigger?

ty for fast answering

 

[TwoVenomous]

sure?, i think i tried that out, but it still appears.

another question:

if i got lets say 10 triggered abilities and i need for each one a caster and target variable
should i create for each trigger an own variable or should i create one array variable for every trigger?

ty for fast answering

a new variable for both caster and target.

 

[edo494]

if those spells are instant you are fine with as much variables as your biggest trigger requires
If it is over time or after time it may override the old data making the spell to bug but you can save those values to hashtable and then retrieve them but that is harder to code

 

[GIMLI_2]

but if i do it with array and give the first trigger:
Caster[1] = Casting unit
Target[1] = Targeted unit

and the second
Caster[2] = Casting unit
Target[2] = Targeted unit

then it cant overwrite anything, right?

i just thought that theres only 1 variable for so much triggers.

maybe some1 can tell me whats positive and negative about using 1 array or new variables for each trigger. ofc the array variable costs more kb, but i use only one

 

[edo494]

well as I said, you dont need array if the spell is instant but its not that big deal
no they wont override because the memory of index 1 of array is saved in different place of memory then index 2

 

[Ezekiel12]

maybe someone knows if you can remove the ugly bonus damage floating text after windwalk?

Set the allowed target list targets to 'None'.

The Backstack Damage boolean is actually mislabeled by Blizzard. In fact its the field Never Miss as seen on critical strike abilities.

 

[GIMLI_2]

so i should use arrays instead of using new variable in each trigger?

@ezekiel12: ty it works

 

[edo494]

it doesnt matter really

 

[GIMLI_2]

it does a bit, i just asked cause i have so much variables in my variable list that i have to search if i need one.

 

[ap0calypse]

Well, it actually depends.

As far as I know, you only need these variables to create all kinds of spells and systems:

• 1 Hashtable variable,
• 2 unit variables,
• 3 point variables,
• 1 force (player group) variable,
• A few integers and reals (they're always useful),
• A boolean (optional),
• A unit group (optional)

I'm going to go with around 12 variables. That is unless you use indexing and/or waits somewhere.
Of course, if you've got some systems where you need items, you can create that too.
It's just that a hashtable can store anything you like, and the rest are just temporary variables.

 

[GIMLI_2]

i use unit indexer instead of hashtables

 

[defskull]

If the spell is intstant, just name the variable starts with "temp" like tempCaster or tempTarget, you can also make it TempUnit1 and TempUnit2.

This will save your variable amount rather than making each copy variable for each spells (inefficient).

The condition is: YOUR SPELL HAS INSTANT-EFFECT (does not include any delay or wait - or such)

 

[edo494]

it doesnt matter because if you download 2 spells from hive in GUI you will have 10, 20 variables because there are most likely no GUI spells with shared global variables

 

[ap0calypse]

Same goes for vJass-spells, you just don't really notice it .

Anyways, you're right. It's a problem that I really dislike, mainly because it can be avoided (with certain naming conventions).
This is especially true for hashtable-spells/systems: since everything is stored in hashtables (only 1, preferably), all spells/systems can share all variables.
The thing is that nobody does this. There's no such naming convention, so variables are something like "UGGD_Damage_Per_Second" (just a stupid example off the top of my head), of course you're going to end up with way too many variables if you just throw in new temporary variables all the time.

You can try to replace all variables of each spell/system you import, but that takes time and if you're not familiar with it, it might break the triggers.

 

[defskull]

@edo
That is why I started to name my (most of it) variables starts with "temp" and ends with the Variable Type.
TempString, TempUnit, TempLocation, etc.

So when they import it, they could just merge with it (I don't know for others) but this thing should be emphasized upon posting a Spell Resource to make it easier and efficient for others who want to import it.

 

[ap0calypse]

@edo
That is why I started to name my (most of it) variables starts with "temp" and ends with the Variable Type.
TempString, TempUnit, TempLocation, etc.

I've been doing that for a long time as well, though I use camelcasing with the first letter being lower-case (such as "tempUnit1", "tempString", "tempLoc1").
Aside from that, I also always have integers behind them, even though I don't always have a second of that variably type ("tempLoc1" would be a good example: even if I only have 1 tempLoc, it will always have the '1' attached to it, because other systems might require those).

It would be good if the entire GUI-community uses standard variable names like that.
I don't particularly mind "TempVar", though naming conventions state that variables preferably begin with a lower-case, hence the "tempVar" - even though "udg_" is a default prefix.