System SpellStruct

[Narks]

massive code duplication?

 

[Jesus4Lyf]

massive code duplication?

Alright, I can add that, but it'll be permanent and irreversible at runtime.
Currently you can like... change the spell a struct is for during the map.

Hm, I could add a thistype.permenantRegister('Axxx'). I don't think that has any code issues, since it's all MUI anyway.

 

[Narks]

Yeah, that would be awesome.

 

[Jesus4Lyf]

May I ask why two spells do the same thing?

 

[Kenny]

Might be a stupid question but...

Does this function correctly when a spell is fired twice consecutively for a specific unit? Would the first instances variables and stuff get over-ridden?

I ask this because you say it uses unit attachment via hashtables.

Anywho, besides that, this is awesome and I'd definately like to see it get out of Beta. The script is far easier to read as well, good job with that.

 

[Narks]

Well, my map, you can learn any combination of spells.

So I don't want hotkey conflicts.

So I kind of have 5 abilities for each spell. One for each slot on the command UI...

 

[Jesus4Lyf]

So I kind of have 5 abilities for each spell. One for each slot on the command UI...

Fair enough...

Does this function correctly when a spell is fired twice consecutively for a specific unit?

I'd say yes, but I might need to look into it further. The attachments are just for events, really. Firing a spell twice consecutively would work fine - is it possible to fire the same spell concurrently? Does finish cast of death coil fire after it's possible to start casting again? I don't think so - the assumption I made when I wrote this. Let me know if you find otherwise. <3

>The script is far easier to read as well, good job with that.
Thanks.

>I'd definately like to see it get out of Beta.
Yea, me too. I'm reluctant because it's so huge that it's difficult to test thoroughly. Perhaps I should just bite it and do it, see what comes up...

 

[Kenny]

>Does finish cast of death coil fire after it's possible to start casting again? I don't think so - the assumption I made when I wrote this. Let me know if you find otherwise.

I was actually kinda thinking about when you use timers within a spellstruct.

Example:

Unit A fires spell B at 10 seconds of game time with a duration of 10 seconds. (Lets say the duration is random).

Unit A fires spell B again at 11 seconds of game time with a duration of 5 seconds.

Since you use unit attachment, does it mean that the first instance of spell B has been reset (or over-ridden) once unit A fires the second instance? What happens to all the groupEnum methods (and the majority of non-static methods that need unit attaching for that matter)?

I'm pretty sure you would understand what I am saying, even without my terrible example and explanation. But I just find it hard to find out for myself by looking through the script (too complex for me, plus I have no idea about hashtables). And I can't test at the moment.

 

[Jesus4Lyf]

Yea, I was wondering for a sec how I did it when I read your issue. Turns out I've coded around that already.

Turns out after onStopCast fires, I detach the instance from the unit, and destroy it when all locks are removed or autoDestroy is set back to true. Since stopping a timer removes a lock (which was added when it started), it can potentially destroy the struct at that point, etc.

Basically, I made sweet garbage collection. :thup:

And to get back to your question, the point is that the struct is saved on the unit until the last event fires, and then the unit no longer has the struct attached.

 

[Executor]

Edit: Forget it I'm stupid

Good Job

 

[Jesus4Lyf]

Bump!

Bug free? People happy to call it release?

 

[BlackRose]

NO.

It bugged for me .__.
Unless it's my own fault again :'(
Attached map. Why does SpellStruct fire for the Blink spell?

Also, 3:04 AM. Wow.

 

[Jesus4Lyf]

It bugged for me .__.
Unless it's my own fault again :'(
Attached map. Why does SpellStruct fire for the Blink spell?

Thanks for the bug report. It was essentially a vJass bug to do with function interface evaluation. Turns out evaluating 0 typecasted to a function interface returns the last value that function interface returned, not 0.

>3:04 AM. Wow.
Was 4:04 AM. :thup:

Anyway, that should do it. Version 1.0.6. Release.

 

[BlackRose]

    private method periodic takes nothing returns nothing
        local real x = GetUnitX( this.targetUnit ) + this.SPEED * Cos( this.getAngleToTargetWidget() + ( bj_DEGTORAD * 180 ) )
        local real y = GetUnitY( this.targetUnit ) + this.

How come I can't just do:
[ljass]local real x = this.targetX + this.SPED * Cos( blah blah )[/ljass]

When I do, spell no more work D:
Although this.targetX just call's [ljass]GetUnitX()[/ljass] doesn't it?

 

[Jesus4Lyf]

    private method periodic takes nothing returns nothing
        local real x = GetUnitX( this.targetUnit ) + this.SPEED * Cos( this.getAngleToTargetWidget() + ( bj_DEGTORAD * 180 ) )
        local real y = GetUnitY( this.targetUnit ) + this.

How come I can't just do:
[ljass]local real x = this.targetX + this.SPED * Cos( blah blah )[/ljass]

When I do, spell no more work D:
Although this.targetX just call's [ljass]GetUnitX()[/ljass] doesn't it?

No, targetX is an event response. It is the ground the spell was targetting. Think carrion swarm/flamestrike/blink/other point target spells.

 

[Jesus4Lyf]

Bump.

 

[Jesus4Lyf]

Bump.

 

[Jesus4Lyf]

Bump.

 

[Immolation]

Awesome sauce.
I won't use it anyway, since I prefer to make spells myself the old fashioned way. When I'll be old and pr0 like the gurus out there, then I'll use it to satisfy my borednessity(gotta love this word ).

~Immo

 

[Nestharus]

I'd prefer a framework of macros linked into a common library hidden away in the back over the evaluations in this : ). It'd be more efficient and thus make me want to use it ;o.

As it stands, it looks pretty (brilliant interface as I always say).

But all of your resources look pretty ;p, even the ones with fugly textmacros all over the place o-o. Yea, it's a time saver and is written wonderfully, but double the evaluations per event isn't cool : (.

Since i haven't made a framework for myself yet, I'd def use this at the moment for spell contests and what not as it is a massive timer saver =). It allows people to focus more on content than all the background spell crap ;p.

But again, I'd prefer a framework of macros linked to common background library.