[Snippet] DummySpellcast

[Adiktuz]

you should do Maggy's suggestion to make the system more efficient...

 

[Magtheridon96]

i wonder why my indentions keep getting ruined. :\

It can happen in cases when you're using WordPad or Notepad or anything like that.

To fix this, erase the tabs and spaces from the beginning of a line and ONLY use tabs.
'\t' is not equal to 4 spaces all the time

 

[mckill2009]

still picks up dead units, it should be like this...

loop
   set p=FirstOfGroup(g)
   exitwhen p==null
   if CastOnAreaLvl_CHECK(u) then
      if((IsUnitAlly(p,pl) and v)...
         //blahhh...

 

[Alain.Mark]

the unit type check is already done by CreateTargetGroup

 

[mckill2009]

yeah but that's slow dude...
call CreateTargetGroup(x,y,r) >>> call GroupEnumUnitsInRange(g,x,y,r,function FuuuILTER)

 

[Magtheridon96]

NEVER pass a filter to enum functions O-O
They're slower ^.^

 

[Alain.Mark]

@mckill2009 it gets inlined anyway

@Magtheridon96, so i need to put it inside the group loop right?

 

[Magtheridon96]

Yes. That's the whole point of the group loop, so you can use checks to filter out units and simple code to manipulate them (Much faster than two threads per unit in a group)

 

[Alain.Mark]

updated.

 

[Magtheridon96]

    //=======================================================================
        private function FuuuILTER takes nothing returns boolean
            call GroupAddUnit(g,GetFilterUnit())
            return false
        endfunction
        
    //=======================================================================
        private function CreateTargetGroup takes real x, real y, real r returns nothing
            call GroupEnumUnitsInRange(g,x,y,r,f)
        endfunction
        
    //=======================================================================
        private module zapdos
            private static method onInit takes nothing returns nothing
                set f=Filter(function FuuuILTER)
            endmethod
        endmodule

You don't need any of this.
GroupEnum puts the units in the group, so that filter is not required. (use null)

Oh and change articuno to moltres :c

 

[Alain.Mark]

thanks. :O i actually didn't know that >.>

edit: updated. removed unnecessary functions to optimize "CastOnAreaLvl". changed the name to "moltres" too for mag

 

[Nestharus]

The reason channeling spells are both useless and idiotic to do on a dummy is because dummies are meant for effects.

Consider this situation. You make a dummy cast a spell after the user runs a spell (why not put the channeling on the user? Who the hell knows >.>). Now you want to cast a spell, but oh no, your channeling is running for 30 seconds. Boom, your entire dummy is now disabled for the next 30 seconds, gg.

You decide to create a queue of dummies to handle the idiotic pointless channeling. Now you have many dummies on the map and you can cast channeling spells, but why? You can easily put the channeling on the unit that is actually casting the spell or on a timer as part of the spell. What's the point of channeling? Who knows.



As it stands, this is currently broken on channeling and I've yet to see any point to ever using channeling on a dummy when timers or putting the channeling on the actual casting unit will suffice without the need for a queue of dummies.

 

[Alain.Mark]

Consider this situation. You make a dummy cast a spell after the user runs a spell (why not put the channeling on the user? Who the hell knows >.>). Now you want to cast a spell, but oh no, your channeling is running for 30 seconds. Boom, your entire dummy is now disabled for the next 30 seconds, gg.

because channeling spells are sometimes annoying for fast-paced games. Don't you think? And what if someone wants to cast a channeling spell but does not want the casting unit to remain pinned on the ground, channeling? And what about that disabled dummy for 30 sec? Who would channel a spell in that duration anyway? be realistic like 0.75-10 sec. man. I for one has a use for channeling spells like dummy casting rain of fire for instance i'd rather dummy cast that spell rather than coding it in scratch.

and if someone really wants to dummy cast for 30 sec... that wouldn't even affect the system that much? :O

 

[Nestharus]

Ahem, if you are pulling off spells one after another, even .05 seconds will mess with the system >.>.


Why not just make the spell non channeling??? >.<

 

[Adiktuz]

then why channel? that's the purpose of channeling anyway, a spell which you need to focus in order to have its effect... and what's unrealistic with a 30 second channel???

also in most good/advanced map, long-term spells [like ur example, rain of fire] are almost always coded because they need damage to be controllable... so they don't use a dummy to channel spells like RoF when they want it to be instant cast for the user... and for those reasons, I made custom systems like Meteor and Nova...

 

[Nestharus]

also in most good/advanced map, long-term spells [like ur example, rain of fire] are almost always coded because they need damage to be controllable... so they don't use a dummy to channel spells like RoF when they want it to be instant cast for the user... and for those reasons, I made custom systems like Meteor and Nova...

You don't seem to get that channel breaks this system until you account for it -.-. You can say all you want that it doesn't, but it does >.>. You can not cast other spells while channeling. You can say channel is useful (even though it isn't), but it still breaks your entire thing regardless, unless you like a system that things can disable for however long they want. I even told you how to account for this.

 

[Alain.Mark]

@Nes, while this system orders a unit to channel. you can still continue casting other spells too if you want (since the system will provide one). How does that break the system? :O

 

[Adiktuz]

HMMMM

ur module is named moltress but you do: implement moltres

//=======================================================================
        private module moltress
            private static method onInit takes nothing returns nothing
                call TriggerAddCondition(DEALLOCATOR,Condition(function DeallocationProcess))
            endmethod
        endmodule
        
...

//===========================================================================
    private struct s extends array
        implement moltres//you lack an s here
        
    endstruct
    
//===========================================================================

 

[Alain.Mark]

i changed the module name instead. :O thanks Adik.

 

[Nestharus]

Got it, nevermind, but for most uses you aren't going to be using channeling, so this is overkill for most things ; ).

 

[Alain.Mark]

hehehe if the user decides not to use the channeling spell support. i'll code in static if's for that situation.

 

[Magtheridon96]

hehehe if the user decides not to use the channeling spell support. i'll code in static if's for that situation.

Nah, because if someone were to use this in a public resource, he'd have to tell you how to configure the DummyCast system as well
Keeping it like this is good.

 

[Nestharus]

Could do DummyCastChannel as an extension lib similar to how I did AdvDamageEvent and UnitEvent.

 

[Alain.Mark]

I'll be separating them into two right now.

edit: i'll be adding static if's instead.


edit: on second thought... how bout an extension module instead >.>

 

[Magtheridon96]

They don't have to be modules. You can use textmacros as well:

//! runtextmacro optional TEXT_MACRO()

This way, you can run them outside of structs too

 

[Alain.Mark]

I tested the separated version vs the original version... it seems that using a "UnitRemoveAbility" function right after issuing an order is slower compared to an event driven deallocation (my original method). so i think i'll be leaving the library as is and intact.

This one is slower (separated lib)

	function CastOnTargetLvl takes unit u1, unit u2, integer id, integer oid, integer lvl returns nothing
		//! runtextmacro DummyCasterUtils__AddSpellLeveled("u1","id","lvl")
		//! runtextmacro DummyCasterUtils__SetUnitXY("u1","GetUnitX(u2)","GetUnitY(u2)")
		call IssueTargetOrderById(u1,oid,u2)
        call UnitRemoveAbility(u1,id) //<- this thing is slower... compared to the deallocation method i use... (which relies on a trigger executes via the EVENT_UNIT_SPELL_ENDCAST event)
	endfunction

Compared to this (the intact and original one)

	//=======================================================================
		private function DeallocationProcess takes nothing returns boolean
                 // the lines here below execute before the "UnitRemoveAbility" above the first example
                 // NOTE: they are event driven.
			set cs=GetTriggerUnit()
			set rcs[w]=cs
			set w=w+1
			call UnitRemoveAbility(cs,GetSpellAbilityId())
			call SetUnitOwner(cs,DEFAULT_OWNER,false)
			return false
		endfunction
	
	//=======================================================================
		private module moltres
			private static method onInit takes nothing returns nothing
				call TriggerAddCondition(DEALLOCATOR,Condition(function DeallocationProcess)) 
			endmethod
		endmodule

i tested it by replacing the "UnitRemoveAbility" functions on both libs by "BJDebugMsg" and assuming that the first one who executes is faster... and guess what that's the result, the automated deallocation wins.

 

[hamsterpellet]

You guys are discussing the scripts, I'm here just for a tiny help:

It's written "-This library's purpose is to make dummycasting more easier." at the beginning of the documentation.

Change "more easier" to "easier". (=

 

[Bribe]

>> implement moltres

i c wut u did thar.

 

[Bribe]

What does this offer that xecast does not? http://www.wc3c.net/showthread.php?t=101150

 

[Alain.Mark]

efficient dummy casting on multiple units (only uses one dummy for instant spells)

 

[Dirac]

Well first of all xecast is broken (lol)
second this aims to support channeling dummies
If I were a mod i would have already graveyard'd this, and i think Nes did a good job explaining why

 

[Nestharus]

Actually, the use of multiple dummies can be a good thing. It can support spell effects like chain lightning (move the dummy). Channeling can also be there for spell effects.


Think of it like this... you do an attack and it creates various lightning rods everywhere (these lightning rods could be dummy units o-o). The lightning rods then shoot off lightning via chain lightning spell : ).


Now... my only thoughts at this point are applying models to the dummy units via attachments (like making it look like a peasant model by attaching peasant model to chest) and so on. Essentially, I think that is the way that dummy casters are going now. I was sort of doing this with the Particle system I was doing, but it can be taken further ; ). They can be used for projectiles or anything really : D.


I think that this should be a standalone resource rather than a huge thing part of a huge caster lib (even if that caster lib can have different features enabled/disabled)). Splitting it up into many smaller resources just seems like a smarter way to go.



So no longer think of DummyCaster as the simple buffer applier. Now think of it as anything. There should also be a constant dummy caster for simple buff application. This could use the general Dummy library. In fact, it should go Dummy (for general stuff) and then DummyCaster : D.

 

[Alain.Mark]

hmmm... the sole purpose of this system while i was making it is just for dummy casting stuff (without attaching fx to the dummy caster)

but for the lightning spell issue, i'll be adding:
> "AllocateCasterEx" -> allows the user to set x,y,z coordinates
> "EnableAutoPlacement" -> enables/disables the auto placement of dummy casters.

 

[Nestharus]

I think that the lib needs to be redesigned to be just general all purpose Dummy lib and a DummyCaster lib.

 

[Alain.Mark]

Im separating the allocator.... the caster function are now going to be optionals.

another advantage is that i would be able to add just any kind of utilities, modularly.

 

[mckill2009]

my looping code is only for multicasting instant spells. (it works)

btw what i meant earlier was my code only uses one dummy caster when casting MULTIPLE times (for instant spells) and recycles dummy casters when casting MULTIPLE times (for channeled/timed spells). try it. it is faster and more efficient since it doesn't use timers and attaching. i meant my post earlier specifically for my libs "CastOnAreaLvl" function.

I dont think so, the 'w' is always 0 at first so if multiple times at first then it will create also multiple times...
The caster also is at the location of the target, what if the user wants it as a
missile unit-target-spell, from angle of caster and target, surely the system
doesnt support that...

if(w==0)then
   //put debug messages and see what I mean...
   set cs=CreateUnit(pl,DUMMY_CASTER_ID,0,0,0)
.......

I said it coz Ive tested it...

 

[Alain.Mark]

it's a recycling error, since i stopped updating this lib, ->here

 

[mckill2009]

yes really...see how many fruit salad it created by pressing it fast...

function Trig_Untitled_Trigger_001_Actions takes nothing returns nothing
    local unit d=AllocateCaster(Player(0))
    call CastOnArea(d,0,0,1000.00,'Aenr',OrderId("entanglingroots"),false)
endfunction

//===========================================================================
function InitTrig_Untitled_Trigger_001 takes nothing returns nothing
    set gg_trg_Untitled_Trigger_001 = CreateTrigger(  )
    call Cheat("iseedeadpeople")
    call TriggerRegisterPlayerEventEndCinematic( gg_trg_Untitled_Trigger_001, Player(0) )
    call TriggerAddAction( gg_trg_Untitled_Trigger_001, function Trig_Untitled_Trigger_001_Actions )
endfunction

 

[Bribe]

I don't know what you're looking for with the "angle" parameter in "CastOnPoint", because I can see you specified a radius already, so what's the angle going to be useful for?

 

[Alain.Mark]

it uses polar coordinates.

 

[Bribe]

Still doesn't make sense, is it offsetting by that amount? Would that be useful for missiles/lightning or does it serve some other unknown purpose?

 

[Bribe]

This event doesn't fire for a lot of abilities: EVENT_UNIT_SPELL_ENDCAST.

That would create some permanent leaks here.

 

[Alain.Mark]

perhaps, but it's not that practical to cast some of those abilities. (btw the lib is still being updated)

 

[Troll-Brain]

This event doesn't fire for a lot of abilities: EVENT_UNIT_SPELL_ENDCAST.

, i didn't know that, can you give one example ?

 

[Bribe]

Charge gold and lumber is one. There was a discussion about some of the others on Anitarf's "Spell Event" library on wc3c recently.

 

[Troll-Brain]

Hmm, so it is "lot of" or "few" ?

That's a big difference.
So far it seems that it doesn't work with some special abilities which don't require a cast, nor mana, but not really with "spells".
Since this library is for "spells" i don't see the issue, until you provide me a "spell" where the endcast event never fire.
Now, pointing that in the comments of the library wouldn't hurt

 

[Bribe]

More than 1 is a lot from where I was coming from. Subjectivity is great.

 

[TriggerHappy]

I'm not sure this system is all that practical.

It would be best to use a dummy preloader/recycler (like DummyUnitStack) and simply issue the order yourself (it's only one line after all).

This also includes a lot of bloat functions that aren't really related to the idea of this script and the textmacros don't make sense.