GUI Spell System v1.8.0.0

[Daffa]

Tried it to make a simple spell and worked great. Much easier once I get the hang of it

Maybe I'll get it into upload list of mine despite it's simplicity.

 

[Bribe]

Cool, let me know if you need any help with using it

 

[Tasyen]

I want to call a Function with different arguments depending on ally and enemy Filter is set.
From the source code you accessed them with Spell_i_Head[Spell__Index] is that safe/recommented?

Lines in the "OnEffect"-Trigger:

• If (All Conditions are True) then do (Then Actions) else do (Else Actions)
  • If - Conditions
    • Spell_i_AllowAlly[Spell_i_Head[Spell__Index]] Equal Spell_i_AllowEnemy[Spell_i_Head[Spell__Index]]
  • Then - Actions
    • Custom script: call function(a)
  • Else - Actions
    • Custom script: call function(b)

 

[Bribe]

It's safe, but it's ugly. If you want to reference the user config settings for the group filter, it's currently the only way which works outside of a separate variable.

The only time this would be unsafe is if you were changing the values of anything internally. Referencing them isn't a problem.

 

[Tasyen]

I do not change the filters during run time in this spell; Therefore seems to be better to precalc that in an variable in the config then;

 

[Bribe]

Yeah that's the way I would do it.

 

[Spacebuns]

What is in today's update :O

 

[Bribe]

What is in today's update :O

Automatic buffing as well as some unimportant bug fixes.

I'll update the documentation later, but essentially this allows you to configure a buff for your spell and a dummy unit will cast the spell automatically based on the buff ability and order ID.

The ability needs a range of 99999 and the mana/cooldown should be 0.

 

[Bribe]

I'll be re-documenting all of the API for my resources because I've found it is simply much easier to read and understand in a table format. @dtnmang you wanted to know what's new in the latest release - it's mostly the 3 new variables at the end of this table:

Name	Type	Use Frequency	Description
Spell__Ability	Ability	Always	The ability you're writing the spell for.
Spell System Config <gen>	Trigger	Always	Run this trigger when all configuration for the spell is set.
Spell__Trigger_OnEffect	Trigger	Pretty much always	Set to the trigger you want to run when the spell effect starts.
Spell__Trigger_OnFinish	Trigger	Sometimes	Trigger runs when the unit's casting is complete or interrupted.
Spell__Trigger_OnCast/Channel	Trigger	Almost never	Trigger runs as per the Casting Events Guide
Spell__Trigger_OnLoop	Trigger	Very frequently	Set to a trigger which runs after Spell__Time seconds.
Spell__Time	Real	Very frequently	When the OnLoop trigger is set, it will be run after this length of time.
Spell__Duration	Real	Sometimes	Automatically runs the OnLoop trigger every Spell__Time seconds until the duration runs out.
Spell__DurationPerLevel	Real	Occasionally	Spell__Duration will increase dynamically by this much per level.
Spell__Filter_AllowX	Booleans	Frequently	General configuration for targets allowed to be automatically enumerated.
Spell__UseTargetGroup	Boolean	Sometimes	Allows you to remember a group of target units for each spell instance to be tracked in Spell__TargetGroup.
Spell__AutoAddTargets	Boolean	Occasionally	Will add all units picked in range to Spell__TargetGroup and only pick new units which aren't already in it.
Spell__BuffAbility	Ability	Occasionally	An ability which would be used to apply a buff to a unit, ie. Slow or Banish. The Object Editor range should be maxed out and it should have 0 mana cost/cooldown.
Spell__BuffOrder	Order	Occasionally	Set to the Order a unit requires to cast said buff ability. If this, BuffAbility and AutoAddTargets are set, a dummy unit will automatically and instantly cast the ability on picked units in range.

Note: this table is only what can be set from the Config trigger for each spell. I'll do another table for what you can do from an event response and another with what you can do with a unit group.

 

[Spacebuns]

if the spell is a single targeted spell and Spell__BuffAbility and Spell__BuffOrder are set (but Spell__AutoAddTargets not) will the Spell__Target be automatically affected with Spell__BuffAbility?

 

[Bribe]

No, it only works when you use it with Spell__In Range. Yours is a good idea though - especially if the spell is based off of channel or needs a second effect.

 

[SpasMaster]

I really want to use this, but I have 1 big concern. In the past I dealt with the OP Limit, due to having too many operations running on <Map Initialization>.
This system appears to set multiple variables for every spell that would use the system on the <Map Initialization>. Could this be problematic in a bigger map with many abilities and triggers?

 

[Bribe]

No, because each time you register call to this system it creates a new thread, avoiding the op limit completely. There's nothing this system does which could ever come close to reaching even 10% of the op limit.

 

[SpasMaster]

Alright, man, that's great! Thanks for the confirmation.
I can't wait to use this, I've always been fan of your work!

 

[Bribe]

I was worried I might need to update this with the renumbering of event IDs, but this had been using the constants for some time now just because I felt it was better practice. Chalk one up to not being too hacky.

The only update to this that will be released when the patch goes live is to update the demo spells to use the new kick ass special effect natives.

Projectile systems are going to get balls over dick crazy performance improvements.

 

[Tasyen]

Can I suggest a small change:

• Currently when trying to register an invalid spell (twice, no spell), Spell System rejects it.
  • I think Spell Sytem should also print out an proper Error-Message in this case.

 

[Bribe]

I can add this once I release the update for 1.29.

 

[Tasyen]

nice, thanks.

 

[Bribe]

Update to use bj_MAX_PLAYER_SLOTS instead of 16, allowing it to work with 1.29 and prior.

 

[Mirage1]

IDK if this question has been made before but I want to add the second line: (Not counting comments)

if udg_Spell_i_BuffAbil != 0 and udg_Spell_i_BuffOrder != 0 then
            //Auto-buff units added to group:
            call UnitAddAbility(udg_Spell_i_PreloadDummy, udg_Spell_i_BuffAbil)
            //THE LINE BELLOW
            call SetUnitAbilityLevelSwapped( udg_Spell_i_BuffAbil, udg_Spell_i_PreloadDummy, udg_Spell_i_Level )
            //THE LINE ABOVE
            call IssueTargetOrderById(udg_Spell_i_PreloadDummy, udg_Spell_i_BuffOrder, u)
            call UnitRemoveAbility(udg_Spell_i_PreloadDummy, udg_Spell_i_BuffAbil)

But udg_Spell_i_Level and udg_Spell_i_Caster does not returns me nor the ability level or the casting unit. I know nothing about jass (just like jon snow ) but i'm trying to make the buff ability to match the casting skill's level to make proper use of Entagling Roots dps scalling without having to trigger it someway. It would be easy to do this GUI myself but I would like to see this function inside the code.

EDIT
By the way all the rest is already part of the code except the second line which obviously contains some noobish crap made by me.

 

[Tasyen]

       call SetUnitAbilityLevel(udg_Spell_i_PreloadDummy, udg_Spell_i_BuffAbil[i], udg_Spell__Level)

udg_Spell_i_Level[i] will not work here, i refers to the index of the used spellType but one needs the current spellcast instance data.

Using the buffplacer dummy to deal damage will destroy correct ownership of damage.
-> gold/exp/lumber gain on kill will not be provided.

 

[Bribe]

Yeah that was an oversight on my part to exclude a buff level. I'll add it on a future date.

 

[Mirage1]

Thank you guys

EDIT:

Hello again. I'm back still to talk about the buffing part. It now levels properly with the spell level but when the buff is a damaging one the casting unit and his allies gain no EXP for the kills. This happens because the owner of the casting unit is Neutral Extra and can be easily solved by changing Aspect of Alliance of Neutral Extra towards the players.

But still I think that there will be some cases where this won't be doable so can you make the buff caster's owner equal to the casting unit/hero's owner?

EDIT 2:

Also I discovered the buff functionality recently by accident when looking at Whiplash's triggers after years using this system. There is no mention about it in the system samples. I don't know even how exactly it works and who will be affect by the buffs. It's a very cool functionality which could receive a bit more attention in documentation and maybe even be improved a bit.

 

[WyrmSlayer]

Question:

Example I have 2 spells. Spell A and Spell B.
The spells are quite complicated, they use "stages"
so.. the question is, IS 1 variable called "Spell_Stage" (array) enough for both the spells? or do I need to use 2 variables, "SpellA_Stage" for Spell A and "SpellB_Stage" for Spell B?
Ofcourse, the spells should be MUI, and both the mentioned variables will use the "Spell__Index"" integer

 

[Bribe]

Question:

Example I have 2 spells. Spell A and Spell B.
The spells are quite complicated, they use "stages"
so.. the question is, IS 1 variable called "Spell_Stage" (array) enough for both the spells? or do I need to use 2 variables, "SpellA_Stage" for Spell A and "SpellB_Stage" for Spell B?
Ofcourse, the spells should be MUI, and both the mentioned variables will use the "Spell__Index"" integer

I replied on YouTube. Did that answer your question?

 

[Spacebuns]

Spell Duration per Level might not be working properly (doesn't add duration) and Set InRange Max too (on the first loop of the OnLoop trigger the number of units that get put into InRangeGroup still overrides this limit)
This was on 1.26.

 

[Bribe]

Spell Duration per Level might not be working properly (doesn't add duration) and Set InRange Max too (on the first loop of the OnLoop trigger the number of units that get put into InRangeGroup still overrides this limit)
This was on 1.26.

I will want to see your test map where you have seen these glitches. This doesn't sound possible unless you were working on an old version of the system.

 

[Spacebuns]

Nope, latest version. I think it has been undetected since previous versions as well, that's why I avoided using DurationPerLevel.
In this map you can test using the Warden's Fan of Knives ability. Now there are 3 problems I can pinpoint:

• Spell__DurationPerLevel ignored by the system, the loop only run on Spell__Duration's value.
• On the first cast of the spell, Spell__InRangeMax = 1 gets ignored on the first loop (fireball hits all peons in range). Later casts seem to have no problem.
• The text displays "Actual time passed = 4" but it shows up when Fan of Knives has cooled down 5/9 of the way, which is 5 seconds (should be 4 seconds). So, intended string is correct, but timing is not. I think this is related to the Spell__Expired check. I suspect this is because after Spell__Duration actually ends, the system only checks for Spell__Expired after another Spell__Time instance is run. If that is the case, the delay between Spell__Duration and Spell__Expired check should be as small as possible.

 

[Tasyen]

Based on SpellSystem code Spell__DurationPerLevel is only read when creating a new Spell, Therefore it can not be used inside onEffect/OnChannel etc triggers, one needs to setup spell__Time, spell__Duration and Spell__DurationPerLevel in the config, inside the onEffect one loads this values with "Spell__startduration = true".

On the first cast of the spell, Spell__InRangeMax = 1 gets ignored on the first loop (fireball hits all peons in range). Later casts seem to have no problem.

As soon one writes onto Spell__InRange, Spell System will instantly calculate the InRangeGroup. The next line (InRangeMax = 1 in your Trigger) will have no effect on the current InRangeGroup calculation, it will affect the next InRangeGroup.

 

[Spacebuns]

Huh, thanks for clarification, guess I didn't read the documentation carefully. But my third point still stands. With a significant Spell__Time there might be a timing problem for spells that depend on Spell__Expired to create an end-of-spell effect.

 

[Bribe]

Huh, thanks for clarification, guess I didn't read the documentation carefully. But my third point still stands. With a significant Spell__Time there might be a timing problem for spells that depend on Spell__Expired to create an end-of-spell effect.

It sounds like you're misusing the variable Spell Expired and its relation to the duration. The in-game events and any timers you set aren't tethered together.

Best approach is to use the EndCast event and do your wrap-up stuff from there. Timer wouldn't even be needed in that case.

 

[Spacebuns]

What is this EndCast event? Can you explain how Spell__Expired is related to the spell system? My first time using a Spell System map, Spell__Expired was used to determine a loop's end, so I just used it for all my spells from there.
And why need 3 different checks for an ability's expiration (Spell__Expired, Spell__Running, Spell__Duration <= 0.00)?

 

[Spacebuns]

I have run into another problem. In this map, the spell Fan of Knives is supposed to create a lightning ball that grows in size for 2 seconds, then at the end of the spell duration it explodes, dealing damage. But a few seconds after, the spell inexplicably automatically finds a Spell_InRangeGroup and deals damage to units in it again, when no action is taken.

 

[Bribe]

What is this EndCast event? Can you explain how Spell__Expired is related to the spell system? My first time using a Spell System map, Spell__Expired was used to determine a loop's end, so I just used it for all my spells from there.
And why need 3 different checks for an ability's expiration (Spell__Expired, Spell__Running, Spell__Duration <= 0.00)?

There is a difference between Spell__Expired and Spell__Running. The latter measures if the caster has stopped casting (based on in-game circumstances which depend on the object editor data of the casting time / any spell interruption.

The former measures if the timer duration has expired. The duration <= 0.00 check should not be needed and is only used by the system internally to compare the Spell__Expired variable with the duration (in case a new duration was set by the user).

I won't be able to open the map you attached for a while. Every time I turn on my netbook it is downloading a new Windows 10 update and the thing takes forever being an Atom N450.

 

[Tasyen]

Wierd, after explosion + dealing damage spell__Duration reloads with 5.010 seconds (right after the group loop). If none was hit the spell ends correctly.

you could add this line after the group block it will force an spell instance end:

• Set Spell__Duration = 0.00

 

[Mirage1]

Thank you guys

EDIT:

Hello again. I'm back still to talk about the buffing part. It now levels properly with the spell level but when the buff is a damaging one the casting unit and his allies gain no EXP for the kills. This happens because the owner of the casting unit is Neutral Extra and can be easily solved by changing Aspect of Alliance of Neutral Extra towards the players.

But still I think that there will be some cases where this won't be doable so can you make the buff caster's owner equal to the casting unit/hero's owner?

EDIT 2:

Also I discovered the buff functionality recently by accident when looking at Whiplash's triggers after years using this system. There is no mention about it in the system samples. I don't know even how exactly it works and who will be affect by the buffs. It's a very cool functionality which could receive a bit more attention in documentation and maybe even be improved a bit.

I'm quoting myself because as it seems my post has been ignored or unseen for some time so here comes the need to say it again: damaging buffs like Entangling Roots does not grant EXP or gold when they kill an enemy unit because the caster's owner is Neutral Extra. Please change the buff dummy's owner to Spell__CasterOwner. If I knew how to do it I would do this myself. However it would be a great addition to the system if this is implemented as default and also if more documentation about the buffing is added.

 

[Bribe]

The issue is that those buffs are not supposed to deal damage. I cast everything from a single dummy unit and changing ownership won't help if another spell just changes its owner a second time.

Do your damage using the built in system timers and rely on buffs just for their non damaging effects (ie. just the immobilization).

Edit: but yes the documentation should mention this).

 

[Tasyen]

I think you should support buffing invisible Units, Bribe. Currently invisible Units won't be buffed, cause neutral extra (dummy spellcaster owner) does not see them.

 

[Spacebuns]

I think you should support buffing invisible Units, Bribe. Currently invisible Units won't be buffed, cause neutral extra (dummy spellcaster owner) does not see them.

We can just add True Sight to the dummy unit that is created though

 

[Bribe]

We can just add True Sight to the dummy unit that is created though

That may not be the right solution, unless one were to massively expand the sight radius of this dummy unit and also the true sight ability. Requires more object editor data to be changed and also screws with other dummy units' vision.

Perhaps a fogmodifier with truesight could be created in behalf of the Neutral Extra player. It'll need more testing.

 

[Spacebuns]

Setting Spell filter to not allow magic immune targets will exclude Invulnerable targets, but does setting it to allow magic immune targets include Invulnerable targets in the InRange Group enum?

 

[Bribe]

Yes, however I believe 1.29 added an "Is Invulnerable" checker so I can create a 1.29+ only version (like I did with Damage Engine) if you want that additional control.

 

[Spacebuns]

Yes, however I believe 1.29 added an "Is Invulnerable" checker so I can create a 1.29+ only version (like I did with Damage Engine) if you want that additional control.

I'd rather have a version that's compatible for all patches using a "Level of Invulnerability Not equal to 0" checker. I don't trust 1.29 yet

 

[nedio95]

I'd rather have a version that's compatible for all patches using a "Level of Invulnerability Not equal to 0" checker. I don't trust 1.29 yet

What if the unit is invulnerable in a non-spell way ?

regards
-Ned

 

[Bribe]

What if the unit is invulnerable in a non-spell way ?

regards
-Ned

Yeah that's exactly it. There's Divine Shield, Neutral Hostile Invulnerable, Big Bad Voodoo, custom spells, the first half second of Sleep... ultimately it's too much to include for just one resource.

I'd rather have a version that's compatible for all patches ... I don't trust 1.29 yet

1.29 is the only way to play on Battle.net, but what I'm saying is that I would still have 2 versions out. The main one, unchanged, and a standalone 1.29-exclusive one which has no backwards compatibly.

 

[Spellbound]

You could also adapt IsDestructableTree into IsUnitInvulnerable for pre-1.29 versions and use that to find out if a unit is invulnerable or not.

 

[Bribe]

Here is a new 1.30 (maybe 1.29 as well) copy of Spell System.

The only change to the system is the addition of a checker for BlzIsUnitInvulnerable. Therefore, I am only attaching the map to this post (and not updating the actual resource).

Additionally, the Demo Map with the Whiplash ability using the new spell effect movement technique. In it, I found that the original Whiplash had a memory leak (two of the effects were not getting destroyed at the end (specifically at index 15), but the effects were getting "removed from visibility" because the dummy they were attached to got removed.

The effect natives seem to be just as smooth as when they were attached to the unit, but without the overhead of needing to be attached to a unit. Therefore, maps using this new technique will not only be using fewer handles, but quite likely have much less overhead on the CPU.

If someone wants to do a benchmark using the new natives vs moving a dummy with the effect attached, I'd be grateful. I'm sure every single missile system out there will want to be updated.

I haven't updated The Big Dipper yet, as the dummy unit movement is tethered to Knockback2.5D. I might eventually switch it over to just using the effect movement.

 

[Pinzu]

Would seem to be redundant thing to benchmark, but I guess it wouldn't be the first time blizzard surprised us? ^^

 

[Daffa]

I was hoping to get this done before my sleep but I've been failing with the InRange. Either I use it wrong or it being an ass (tried using hardcoded value, same effect).

The InRange was suppose to be radius detection in my spell for damage of the ability, but it keeps failing no matter how many attempts I made to make it work (I attach messages to show the range of the spell used <Amaterasu_Range[Spell__Index]> and InRange variables)

Map attached.

 

[Bribe]

I was hoping to get this done before my sleep but I've been failing with the InRange. Either I use it wrong or it being an ass (tried using hardcoded value, same effect).

The InRange was suppose to be radius detection in my spell for damage of the ability, but it keeps failing no matter how many attempts I made to make it work (I attach messages to show the range of the spell used <Amaterasu_Range[Spell__Index]> and InRange variables)

Map attached.

Here. The issue was you had the target point of the group pick at the caster's position rather than the target point of the ability.