What do these natives do?

[Zwiebelchen]

native AddSpellEffect takes string abilityString, effecttype t, real x, real y returns effect
native AddSpellEffectById takes integer abilityId, effecttype t,real x, real y returns effect
native AddSpellEffectByIdLoc takes integer abilityId, effecttype t,location where returns effect
native AddSpellEffectLoc takes string abilityString, effecttype t,location where returns effect
native AddSpellEffectTarget takes string modelName, effecttype t, widget targetWidget, string attachPoint returns effect
native AddSpellEffectTargetById takes integer abilityId, effecttype t, widget targetWidget, string attachPoint returns effect

Never noticed these... any idea what they do? Are these just a different kind of special effect? If so, what is different to special effects? After all, they just return an effect anyway.

All of these natives take an additional field called "effecttype".
When searching for constants in the function browser, these are the following:

constant effecttype EFFECT_TYPE_AREA_EFFECT=ConvertEffectType(4)
constant effecttype EFFECT_TYPE_CASTER=ConvertEffectType(2)
constant effecttype EFFECT_TYPE_EFFECT=ConvertEffectType(0)
constant effecttype EFFECT_TYPE_LIGHTNING=ConvertEffectType(6)
constant effecttype EFFECT_TYPE_MISSILE=ConvertEffectType(5)
constant effecttype EFFECT_TYPE_SPECIAL=ConvertEffectType(3)
constant effecttype EFFECT_TYPE_TARGET=ConvertEffectType(1)

 

[LeP]

They look up the sfx path set in the object editor and then create the sfx.
The effecttype specifies which field is looked up.

 

[Zwiebelchen]

Okay, I did some testing on this.

It seems like they behave just like normal special effects; however, the difference is that these dynamically refer to object data.
You enter the name or rawcode of the spell and can then use the "effecttype" field to get the particular model assigned to this field. This seems to include custom objects aswell, not just the default spells.
Interesting fact: it seems that unit rawcodes are also valid IDs, which allows to get these data fields for units aswell. For example, you can get the "special" (when a unit got killed by a siege weapon) "target" and "missile" art of units by rawcode.
However, it seems like there is no way to get the actual unit model with this; only those additional art fields.


However, this still opens up an interesting possibility, especially for missile systems:

function CreateMissileEffectFromUnit takes unit caster, unit missiledummy returns effect
    return AddSpellEffectTargetById(GetUnitTypeId(caster), EFFECT_TYPE_MISSILE, missiledummy, "origin")
endfunction

Possible applications: a system that automaticly creates a triggered missile that will actually *miss* the target (and travel onwards) when a unit evades an attack.
Or a missile reflection shield kind of spell that visually throws a missile back (or simple deflect it into the ground). Just create a missile onDamage and create the effect based on the damaging unit's rawcode.

 

[BPower]

I only saw it once in Vexorians Rolling Boulder spell
call DestroyEffect( AddSpellEffectById(RollingBoulder_SpellId(),EFFECT_TYPE_SPECIAL,x,y) )

"Art - special" of the ability id in the object editor was set to:

"Objects\Spawnmodels\Naga\NagaDeath\NagaDeath.mdl"

 

[Zwiebelchen]

Using actual spell IDs seems pretty useless to me, since those are rarely used in a dynamic way (which means you can just enter the filepath directly).

The only real use-case of this could be a snippet that "repairs" all channel-based abilities so that the missile and lightning field actually do something.

On the other hand, getting the missile art of a unit seems extremely useful for all kinds of cool reflective/deflective shenanigans.

 

[iNfraNe]

I have long been using these functions (well, to be specific GetAbilityEffectById(ABILITY_ID, EFFECT_TYPE, INDEX)) in elimination tournament. It's very elegant actually to set the type of missile in the object editor