Burst Laser v3.2

[_Guhun_]

That's pretty cool. One should be able to design some sc2-like attacks using this

I don't' know much about vJASS, but I've seen those libs often enough to think it isn't much of a problem having that many requirements, except compatibility if someone uses a similar system to one that you use.

The amount of customization is really good, I couldn't think of anything to add. Sweet lightning effects, btw.

 

[Spellbound]

That's pretty cool. One should be able to design some sc2-like attacks using this

I don't' know much about vJASS, but I've seen those libs often enough to think it isn't much of a problem having that many requirements, except compatibility if someone uses a similar system to one that you use.

The amount of customization is really good, I couldn't think of anything to add. Sweet lightning effects, btw.

Yeah, that's true, but I was still hoping of being able to produce something with fewer requirements. I guess it can't be helped
Thanks for the comment

 

[zv27]

Too many external libraries for simple spell.
Why?

 

[Spellbound]

It's not a spell, it's a customisable custom attack system.

 

[zv27]

It's not a spell, it's a customisable custom attack system.

Oupss hahaha

 

[Emm-A-]

hey Spellbound,
I think, that the visuals are truly excellent! It looks really great, but unfortunately, with it being a custom attack system, it is unlikely to be implemented by a lot of users.
Sry I did not take the time to examine your code, but do you think, uploading the core as a module, that may be used by the combat system or just freely as a point target spell makes sense?

 

[Spellbound]

Hmm, that wouldn't be that hard to accomplish. Good suggestion, I'll see what I can do.

EDIT: Well since nothing ever works out the way to plan it, so has the update to make this not uniquely a custom attack system. I *think* my id allocation library may be the culprit, but all the other allocation methods I've found require structs, and structs are like Mandarin to me, so fuck that.

Unless I magically grow more neurons and programming starts making sense to me, this system is staying like that, sorry That is, after I fix that apparent bug where some unit's lightning effects are somehow being replaced by one another.

PS: anyone wishing to improve upon it is welcome to.

 

[Spellbound]

Okay, wow, I finally managed to fix this damn thing. Special thanks to Aniki and especially IcemanBo for debugging this.

 

[IcemanBo]

Hey there.

In static method Interruption_Event "0" could be just saved as counter, instead of saving each loop run a new value.

    set this.f_is_laser_dead[iLoop] = true
    set this.f_fading[iLoop] = false
    if this.f_laser[iLoop] != null then
        call DestroyLightning(this.f_laser[iLoop])

^inside fade-- on loop start already is checked that lightning is not null, and is the dead variable actually needed? I mean it's always checked if it's null already.

Hm, doesn't it look a bit weird if lightnigs stay and fade slowly out, if the unit gets interrupted, like moves away? In theory lightnings could still be visible for like a second or so? What you think?

Make private what can be private.

if BL_NumberOfLasers[id] > MAX_LASERS then
    set this.laser_num = MAX_LASERS
else
    set this.laser_num = BL_NumberOfLasers[id]
endif

^it's totaly fine, but just wann show some BJs are actually useful: set this.laser_num = IMaxBJ(this.laser_num, MAX_LASERS)

or 3.14159 -> could just be bj_PI ^^

lightning laser
^is this member needed? maybe it was from an older version, and also:

private integer array data

private constant integer OFFSET = 0x100000

It's no harm to do, but technicaly seen nulling/falsing these is not needed, at least not for leaks:

            set this.laser_string = null
            set this.launch_string = null
            set this.impact_string = null
            set this.area_string = null
           
            set this.grounded = false
           
            set this.follow_target = false
            set this.floating_launch = false
            set this.impact_lock = false
            set this.range_lock = false
           
            set this.attack_type = null
           
            set this.uninterruptible = false
            set this.hit_all = false
            set this.friendly_fire = false

set this.f_duration[iLoop] = this.f_duration[iLoop] - 1//0.0312500
^why use a constant value of "1" btw to subrract the value? It should always directly relate to the interval, in this case to "0.0312500".

The onIndex initialization works fine, but is the step necessary, as you actually can only refer to the unit type, when an attack starts?
[vJASS] - Learning Structs
^similar like the in bottom of the post.

======

^Most of the points are not so relevant. But do you also experience mass lags and FPS drop?
I could not normaly fight honestly, do you or someone have same problem?
I'm not sure where the source exactly is, and I havent done any debugging, but from the looks I couldn't really spot something mainly wrong in the brust code.

 

[Spellbound]

Hey there.

In static method Interruption_Event "0" could be just saved as counter, instead of saving each loop run a new value.
.

Do you mean this line? call SaveInteger(hash, id, COUNTER_KEY, counter) and turn it into: call SaveInteger(hash, id, COUNTER_KEY, 0)?

    set this.f_is_laser_dead[iLoop] = true
    set this.f_fading[iLoop] = false
    if this.f_laser[iLoop] != null then
        call DestroyLightning(this.f_laser[iLoop])

^inside fade-- on loop start already is checked that lightning is not null, and is the dead variable actually needed? I mean it's always checked if it's null already

Hmm, I guess not.

Hm, doesn't it look a bit weird if lightnigs stay and fade slowly out, if the unit gets interrupted, like moves away? In theory lightnings could still be visible for like a second or so? What you think?

It would, but I suppose it's up to the player to decide how they want to fade their lightnings. The duration might be high but fading should probably remain a low number. Still, I added the FloatingLaunch specially for that, so the that lightning would remain on at it's launch coordinates regardless of where the attacker went. I suppose I could add a line or something to end the duration of the lightning and start the fadeout immediately... not sure how to proceed there.

Make private what can be private.

Right. Made the destroy and ApplySfxAndDamage private. Can you have private statics as well?

if BL_NumberOfLasers[id] > MAX_LASERS then
    set this.laser_num = MAX_LASERS
else
    set this.laser_num = BL_NumberOfLasers[id]
endif

^it's totaly fine, but just wann show some BJs are actually useful: set this.laser_num = IMaxBJ(this.laser_num, MAX_LASERS)

or 3.14159 -> could just be bj_PI ^^

Oh, neat, definitely going to use bj_PI, though I'll keep the if BL_NumberofLaser[id] > MAX_LASERS then since it save me from having another function call. Still useful in less demanding systems though.

lightning laser
^is this member needed? maybe it was from an older version, and also:

private integer array data

private constant integer OFFSET = 0x100000

Ah, yes, vestigial variables. I'll remove 'em.

It's no harm to do, but technicaly seen nulling/falsing these is not needed, at least not for leaks:

            set this.laser_string = null
            set this.launch_string = null
            set this.impact_string = null
            set this.area_string = null
       
            set this.grounded = false
       
            set this.follow_target = false
            set this.floating_launch = false
            set this.impact_lock = false
            set this.range_lock = false
       
            set this.attack_type = null
       
            set this.uninterruptible = false
            set this.hit_all = false
            set this.friendly_fire = false

Cool, I was unsure whether these had to be nulled. Code needs a trim anyway.

set this.f_duration[iLoop] = this.f_duration[iLoop] - 1//0.0312500
^why use a constant value of "1" btw to subrract the value? It should always directly relate to the interval, in this case to "0.0312500".

That's because the duration of the laser and the fade duration are different. A laser might last 5 seconds but fade in 3, so I just use the smallest amount (.03125) and use an integer to count the intervals instead. Also the lightning needs to be moved

The onIndex initialization works fine, but is the step necessary, as you actually can only refer to the unit type, when an attack starts?
[vJASS] - Learning Structs
^similar like the in bottom of the post.

I'm not sure I follow. Do you mean the event registrations or the handler codes?

^Most of the points are not so relevant. But do you also experience mass lags and FPS drop?
I could not normaly fight honestly, do you or someone have same problem?
I'm not sure where the source exactly is, and I havent done any debugging, but from the looks I couldn't really spot something mainly wrong in the brust code.

I also experience massive lag during tests.

That's really weird. The only lag I experience with this new version is from a discarded spell I tried to make using the system. I really don't experience any lag at all, just 1 - 2 frame drops when things get a bit chaotic with the lasers all over the place. I'm also running an ENB on top of things, but I don't even have that beast of a PC. I've tested the system many times and have not experienced any significant lag :/

The other lightning strikes from an attack could also do damage than simply standing there for visuals. Then the attacks would be more interesting.

There is a variable called LaserLingerInterval[ID] that indicates how many times your special effects and damage will repeat for as long as your laser is active. The calculation is (LaserDuration[ID] + LaserFadeTime[ID]) / LaserLingerInterval[ID]. I think I misread what you wrote, lol. The other lightning effects DO deal damage. The damage may look insignificant if you set LaserDivideDamage[ID] to true, but the damage is being dealt.

 

[Spellbound]

Which unit, specifically? Is it the Gryphon Rider / Gargoyle / Archmage / Spellbreaker / Rifleman? The lag could be cause by SpecialEffectZ so I you can, try testing it with the Gryphon Rider and see how the frames do.

 

[IcemanBo]

Do you mean this line?

Yo, it could run once then, instead of in each loop. (just tiny optimization)

It would, but I suppose it's up to the player to decide how they want to fade their lightnings. The duration might be high but fading should probably remain a low number. Still, I added the FloatingLaunch specially for that, so the that lightning would remain on at it's launch coordinates regardless of where the attacker went. I suppose I could add a line or something to end the duration of the lightning and start the fadeout immediately... not sure how to proceed there.

Ah ok, sounds reasonable. Maybe, yes,..maybe it makes sense to loop through all lightnings onInterrupt and start fading them instantly?

Can you have private statics as well?

Sure. You could also go the other way around make private struct MyStruct and then make things explicitly public that need to be public.

Cool, I was unsure whether these had to be nulled.

If you're interested in reading some up some details Memory Leaks.

so I just use the smallest amount (.03125) and use an integer to count the intervals instead.

I see, but imo the proper way would be to define the correct timeout, and then substarct the interval of it (.03125).
This way it also be correct if *why ever* the .03125 is changed. My thinking is: it relates to the timeout, so then make it also a relative value, instead of an not absolute.

I'm not sure I follow. Do you mean the event registrations or the handler codes?

Ehm, I'm not sure I understood. But with my way it would assign values onInit for each unit type, while your does for each unit onIndex.

not experienced any significant lag

Hm oké, strange. But I definitly have them. Will try to report closer what maybe makes it, soon.

 

[Spellbound]

Yo, it could run once then, instead of in each loop. (just tiny optimization)

So this, then?

        private static method Interruption_Event takes nothing returns nothing
            local integer id = GetHandleId(GetTriggerUnit())
            local integer counter = LoadInteger(hash, id, COUNTER_KEY)
            local thistype this
            loop
                exitwhen counter < 1
                set this = LoadInteger(hash, id, counter)
                if not this.uninterruptible and this.interval > 0. then
                    call PauseTimer(this.tmr_volley)
                    set this.laser_num = this.laser_index //This is set in case of interruption
                endif
                set counter = counter - 1
            endloop
            call SaveInteger(hash, id, COUNTER_KEY, 0)
        endmethod

Ah ok, sounds reasonable. Maybe, yes,..maybe it makes sense to loop through all lightnings onInterrupt and start fading them instantly?

Hmm, I am having trouble understanding the hashtable and how the counter/COUNTER_KEY stores stuff. So if I was to do [/lass]set this.f_duration[index] = 0[/icode], would I have to create a new loop inside the existing loop and run it from 1 to laser_num and set their durations to 0?

Sure. You could also go the other way around make private struct MyStruct and then make things explicitly public that need to be public.

Right, done.

I see, but imo the proper way would be to define the correct timeout, and then substarct the interval of it (.03125).
This way it also be correct if *why ever* the .03125 is changed. My thinking is: it relates to the timeout, so then make it also a relative value, instead of an not absolute.

Oh, I never thought of it that way. Which way would be have the smallest performance hit, though? I can use a constant for the smallest interval and have the timer subtract that constant from the duration and fade times.

Ehm, I'm not sure I understood. But with my way it would assign values onInit for each unit type, while your does for each unit onIndex.

I don't know, checking for unit type doesn't sound very malleable. What if the laser is a weapon type that the unit can switch on an off?

Hm oké, strange. But I definitly have them. Will try to report closer what maybe makes it, soon.

I hope you're successful. I really don't lag at all when I test this. You could try setting the gryphon rider's LaserLaunchFX[ID] in the BurstLaser Indexing trigger to null and see if it still lags. If it doesn't, that means AddSpecialEffectZ is the culprit.[/quote][/QUOTE]

 

[IcemanBo]

So this, then?

Basicly yes. If you want you can also do a if statement first if counter is even bigger than 0.

Hmm, I am having trouble understanding the hashtable and how the counter/COUNTER_KEY stores stuff. So if I was to do [/lass]set this.f_duration[index] = 0[/icode], would I have to create a new loop inside the existing loop and run it from 1 to laser_num and set their durations to 0?

Inside the existing loop of the interruptio trigger you currently loop through all existing instances. So yes I think you need a second loop inside so you can loop through all the lightnigs which are binded to the instance, and then set "fading = true" blindly for all.
If you feel we can chat about these hashtable stuff or so, it's really actually pretty easy if you got it once.:)

Oh, I never thought of it that way. Which way would be have the smallest performance hit, though? I can use a constant for the smallest interval and have the timer subtract that constant from the duration and fade times.

" instead of an not absolute." -> " instead of an absolute." of course, but you understood it. ... hm I'm not sure I understand the part with "smallest interval". I think something like ~0.03125000~ is okay/smooth when it's used to be up to date with unit movements.

I don't know, checking for unit type doesn't sound very malleable. What if the laser is a weapon type that the unit can switch on an off?

I see, sounds reasonable. It seems I limited the usage a bit in my thoughts.^^

 

[Spellbound]

Basicly yes. If you want you can also do a if statement first if counter is even bigger than 0.

Eh, I think I'll leave it as-is.

Inside the existing loop of the interruptio trigger you currently loop through all existing instances. So yes I think you need a second loop inside so you can loop through all the lightnigs which are binded to the instance, and then set "fading = true" blindly for all.
If you feel we can chat about these hashtable stuff or so, it's really actually pretty easy if you got it once.:)

Perhaps, but I seem to be getting a handle on it, but I'll need a lot more practice to be able to use it comfortably. Just to be safe, though, can you verify the position of exitwhen iLoop == this.laser_num in this function? I'm not sure if it should be before or after the duration and fading variables.

        private static method Interruption_Event takes nothing returns nothing
            local integer id = GetHandleId(GetTriggerUnit())
            local integer counter = LoadInteger(hash, id, COUNTER_KEY)
            local integer iLoop = 0
            local thistype this
            loop
                exitwhen counter < 1
                set this = LoadInteger(hash, id, counter)
                if not this.uninterruptible and this.interval > 0. then
                    call PauseTimer(this.tmr_volley)
                    loop
                        exitwhen iLoop == this.laser_num
                        set this.f_duration[iLoop] = 0
                        set this.f_fading[iLoop] = true
                        set iLoop = iLoop + 1
                    endloop
                    set this.laser_num = this.laser_index //This is set in case of interruption
                endif
                set counter = counter - 1
            endloop
            call SaveInteger(hash, id, COUNTER_KEY, 0)
        endmethod

" instead of an not absolute." -> " instead of an absolute." of course, but you understood it. ... hm I'm not sure I understand the part with "smallest interval". I think something like ~0.03125000~ is okay/smooth when it's used to be up to date with unit movements.

"smallest interval" is just my way of saying .03125 seconds. But both methods do the same thing, however, so idk if it's worth changing the way the duration and the fading is timed. If subtracting time has better performance, then I will change it.

I see, sounds reasonable. It seems I limited the usage a bit in my thoughts.^^

That what I did myself initially, then Emm-A- suggested it might be limiting to make thing only a custom attack system, so I remade it to work with spells as well

 

[IcemanBo]

I'm not sure if it should be before or after the duration and fading variables.

writing loop-exit condition on top is in most cases the best way, because when the exitwhen is at bottom, the loop will always run at least once, even the condition won't met.
But it's enough if it loops until this.laser_index, so
exitwhen iLoop == this.laser_num
->
exitwhen iLoop >=this.laser_index

If subtracting time has better performance

It was not really suggestion because of performance, but it just makes more sense for me.

----

The AddSpecialEffectZ function was/is a reason for the extreme fps drops, I don't think it can be used to have it called so often and dynamicly.
The mass creation seems to heavy. If there are similar functions often called it's probably also too heavy.

 

[Spellbound]

I was afraid that might be the case. The initial versions of the system use dummy units but that lagged my pc to hell and back, so the only alternative I can think of is to use one dummy unit and use it to control the Z of the destroyed special effect. The only problem is that the unit can't reliably move to all the coordinates if they happen to be occurring within very short time periods, not to mention most special effect will travel along with the unit. I did a test with the Riflemen and their launch animations just wouldn't play, and if two of them fired at practically the same time one of them wouldn't play the impact special effects as well. The following function just isn't reliable:

       private method ApplySfxAndDamage takes real launch_x, real launch_y, real launch_z, real impact_x, real impact_y, real impact_z returns nothing
            local unit u = null
            if FX_DUMMY == null then
                set FX_DUMMY = CreateUnit(Player(15), 'dumi', 0., 0., 0.)
            endif
            //Launch
            if this.launch_string != null then
                call SetUnitX(FX_DUMMY, launch_x)
                call SetUnitY(FX_DUMMY, launch_y)
                call SetUnitZ(FX_DUMMY, launch_z)
                call DestroyEffect(AddSpecialEffectTarget(this.launch_string, FX_DUMMY, "origin"))
            endif
            //Impact
            if this.impact_string != null then
                call SetUnitX(FX_DUMMY, impact_x)
                call SetUnitY(FX_DUMMY, impact_y)
                call SetUnitZ(FX_DUMMY, impact_z)
                call DestroyEffect(AddSpecialEffectTarget(this.impact_string, FX_DUMMY, "origin"))
            endif
            //Area
            if this.area_string != null then
                call SetUnitX(FX_DUMMY, impact_x)
                call SetUnitY(FX_DUMMY, impact_y)
                call SetUnitZ(FX_DUMMY, impact_z)
                call DestroyEffect(AddSpecialEffectTarget(this.area_string, FX_DUMMY, "origin"))
            endif

            ... etc

I have no idea how to circumvent not using AddSpecialEffectZ :/
I mean, Memory Hacking would certainly remove the need for some libraries, but I think that's waaaay out of my league.

 

[IcemanBo]

New dummy units don't need to be created each time. The same ones can be used, maybe a recylce system would help.

I'm not sure it's a good idea to use memory hack for official submissions at the moment. Even you might use it for your personal projects, though.

 

[Tal'Rarity]

Could try a dummy pool which is a term I use that means create a whole bunch of dummy units as game starts though not all at once, just a few at a time then combine that with a dummy recycler. Should be able to bypass that dumb lag then.

 

[Spellbound]

Well if the SpecialEffectZ was lagging for you, then the dummy method is going to be worse because the initial version of the system used dummies - from a recycler. It was lag hell. I tried a new version with DummyRecycler and it's just the same result all over again.

I could try something different which is to have two dummies per instance - one for launch and one for impact - rather than two per laser. It could work, but just out of curiosity, I've attached the dummy version. Does it lag less or more than the AddSpecialEffctZ version?

EDIT: At the peak of the fight vs riflemen, I get about 20 fps drop if I use two dummies per instance rather than per laser. Far more manageable, but there will still be a need to modify certain special effects to not update their position when playing their death animations.

 

[IcemanBo]

Can't test it these days.

 

[IcemanBo]

Was there some change or so with lags/fsp drops? Or maybe someone has done tests?

 

[Spellbound]

The map attached on post #21 uses two dummies per lightning effect. Since I don't get lag with AddSpecialEffectZ I wanted to see if the lag with the dummy units was less or worse.

v2.2 (attached here) uses up to two dummy units per instance, not lightning effect. The lag is less severe, but now the impact effects just jump around with the dummy. I need a 3D artist to help me understand how to modify effects to make it work with this, then it'll be viable.

 

[IcemanBo]

Oh. ..

Have you tried to use enough dummies so it won't "jump" with the units, but not with creating mass units, but with using something like

Dummy Recycler v1.25
[Snippet] DelayedDummyRecycler
[Snippet] Unit Recycler

I would preload like 30-50 dummy units or so at init, and then would give it a try.
New creation is always pretty heavy, so it might also help a bit when done too often.

Have not read code now again how exactly the code manages effect creation, but too massive effect spam can also cause some FPS drop.
Maybe adding some sort of timeout, to create effects only each 0.1-0.2 seconds instead of each 0.03125000 seconds would maybe little help, too. (idk, if it would be the case for you)

Next week or so I can probably test again, too.

 

[Spellbound]

I am already using Dummy Recycler, though I didn't know you could preload dummies. Isn't Warcraft III bad with handling large numbers of units though? (Most of the stuff I do, I plan them with the idea that they would be usable in an altered melee. So, large armies.).

v2.1 uses a dummy for every lightning effect with Dummy Recycler.

 

[IcemanBo]

Isn't Warcraft III bad with handling large numbers of units though?

Yes, but hidden + paused dummies is better than normal units for sure!

v2.1 uses a dummy for every lightning effect with Dummy Recycler.

Ok, this sounds pretty right to me then.

 

[Spellbound]

v2.1 lags a lot when your have a bunch of units though. The cluster of riflemen to the right is meant to stress-test what an actual melee combat may contain (even if it's a bit much). There is a significant amount of lag that is reduced when I use only two dummies per instance. Idk, I can't really tell if the lag is just me expecting too much of my system and using 2 dummies per laser is enough.

 

[AGD]

Hey SpellBound I've a suggestion

Instead of attaching the configuration data (which is based on the unittype) to uDex when a unit enters the map, I guess it would be better to just attach them directly to the unittypeId and then just run the configurations once on map init.
Example:

library BurstLaserConfiguration

    private struct Init extends array

        static method getIndex takes integer unittype returns integer
           //convert the unittype to a small integer so you can use them on arrays
        endmethod

        static method onInit takes nothing returns nothing
            local integer id = getIndex('hrif')

            set vars[id] = value
            //...

            set id = getIndex('hpea')
            set vars[id] = value
            //...

            //Same for other unittypes

        endmethod

    endstruct

endlibrary

Or better if you can even attach the configuration to an abiliy instead of the unittype or unituserdata so that a unit can have multiple laser attacks at once.

 

[Spellbound]

Huh, I was unaware that you could actually do that. I think someone else tried to explain that method to me before but I didn't get it until now
It would be cool to have multiple laser attacks, tho there is one issue think could arise from this: if you want to modify the laser (like say you want to increase the colour of a laser if the unit has a specific buff), wouldn't that change the laser for all units of the same type/with the same ability instead of working individually?

 

[AGD]

It would be cool to have multiple laser attacks, tho there is one issue think could arise from this: if you want to modify the laser (like say you want to increase the colour of a laser if the unit has a specific buff), wouldn't that change the laser for all units of the same type/with the same ability instead of working individually?

There's a way to handle it. Upon the lasers' creation, you're gonna apply the default color configuration (The one set on map init) and if the user wants to manipulate the color (or damage for example) of the lasers of a certain unit, you could just give them methods for editing the stats of a specific laser instance, then they can freely manipulate the stats dynamically most preferably upon creation since you've already provided them the events. Now, what you have to add is another method to retrieve the current fired/started lasers. But of course you could think of another design for this, It's just an example.

 

[Spellbound]

Well I don't think I have the energy to keep working on this system. As soon as I find a way to circumvent the lag, I'm not gonna touch this.

 

[KILLCIDE]

@Spellbound If that's the case, I will set this to Awaiting Update for now.

 

[Spellbound]

@KILLCIDE MAJOR system rework. I stess-tested this and it's not leaking anymore. Would really appreciate it if one of the code mods could take a look at it

PS: I use a unit group to store dummies and recycle them afterwards. The group is them destroyed because it's per-attack-instance. Should I use a hashtable instead? Is group creation/destruction slower than hashtables?

 

[KILLCIDE]

iterating through objects in a unit group would be slower than hashtables. Though the difference would be negligible.

 

[Spellbound]

Well, I've updated the system to use a hashtable instead of a unit group for dummies. Didn't really make much sense to keep creating/destroying unit groups over and over again.

 

[nhocklanhox6]

Oh my, it's sooo awesome, love it soooo much ><. I really love the lightning

 

[KILLCIDE]

A lot of libraries, but the system is rad. The demo and API are also pretty simple to follow. The only downside are the bugs you mentioned in the README and the lightning effects getting all wonky on air units over terrain.

Needs Fixed

• Nothing

Suggestions

• A brief description of the configurables required to setup a weapon would be appreciated. I know some of them are pretty self explanatory, but others are not (especially the booleans).
• For Setup Arsenal, look into modules.
• You should really look into encapsulation. Pretty much everything is public and it just feels wrong. Like here "...These variables are meant to be readonly, so DO NOT SET THEM TO ANYTHING." Why not make them readonly or private so that they will get an error if they attempt to do something?
• Delete the Unused Stuff folder. There is really no point of that being there

Status

Approved
​

 

[Spellbound]

I completely forgot to reply to this lol

• A brief description of the configurables required to setup a weapon would be appreciated. I know some of them are pretty self explanatory, but others are not (especially the booleans).

I'll see about updating the Setup Arsenal with proper documentation. They're in Assign Weapon as opposed to Setup Arsenal because the latter trigger was created at a later date. Assign Weapon was originally a combination of both.

• For Setup Arsenal, look into modules.

Can you give me a brief example of module would work for Setup Arsenal? I've never worked with modules before.

• You should really look into encapsulation. Pretty much everything is public and it just feels wrong. Like here "...These variables are meant to be readonly, so DO NOT SET THEM TO ANYTHING." Why not make them readonly or private so that they will get an error if they attempt to do something?

Hmm, I'll do some research.

• Delete the Unused Stuff folder. There is really no point of that being there

Well they're mostly there a backups for overlooked ideas but I guess I can remove them for uploading to the Hive.

Thanks for the review!

 

[Lt_Hawkeye]

Hey, Spellbound, any chance you may update to utilize the new sfx natives to mitigate the lagging problems?

 

[Spellbound]

I spent the day trying to update it but for some reason I'm getting quite severe lag with it even with all dummies removed. I'm hardly an expert on optimisation, but I'd say this system should be used sparingly at best given how much inherent overhead is present within it. The number of calculations and if checks it contain just so it can be more customisable is a bit absurd, now that I'm taking a new look at it. That, and the fact that it has a baked-in dependency on Damage Engine is not exactly a good thing, especially if you want to use something else (or no DDS at all, since that's a possibility with 1.31 now).

I'll keep chipping away at it, but I can't promise that anything will come of it. The current version seems to be stable enough as it is so it might be best to not update it at all and avoid accidentally breaking everything.

 

[P3in]

Hello, what does this mean? It stops the attacks/spell from triggering the special effect

 

[Spellbound]

erm

Is that from the test map directly or did you modify something in it?

 

[P3in]

It's from the test map, it was the first time testing it, as i want to make summon units that behave like locust swarm, but only 1 unit at a time, and add one of these effects to his attack.

 

[Spellbound]

I just tested it and I didn't get any errors. What version or warcraft 3 are you running this on?

 

[P3in]

patch 1.28.5

 

[Spellbound]

Specifically when did these error messages pop up?

 

[P3in]

After i do 5-6 casts, or after 10-15 seconds of game time if i don't cast it

But also when the map starts, i have 1 text with 1 error, but as i cast, or i don't and time elapses, i get a full screen of them like showed above

 

[Spellbound]

Strange... I'll look into it.

 

[P3in]

Thank you !