HomeUser Control Panel (unavailable in archive)ForumsTutorialsArt GalleryResourcesMaps

Devour

02-06-2009, 10:48 PM#1
Av3n
Click image for larger version

Name:	Devour_Pic.jpg
Views:	476
Size:	55.7 KB
ID:	40546Devour
Made by Av3n

Simple spell, which replicates Devour without the UI change (which personally I hate) and also absorbs mana, includes a progress bar which is perfect. I appreciate criticism and any suggestions to the code since I'm still new to the know-how-to-do code even though I have been coding for a long time.

RequirementsNote that the test map come with these systems as well.
As well the requirements for the systems listed above are in the test map and in the links provided.


Expand Devour:

-Av3n
Attached Images
File type: jpgDevour_Pic.jpg (55.7 KB)
Attached Files
File type: w3xDevour.w3x (26.1 KB)
02-07-2009, 01:23 AM#2
moyack
lovely... but expect the critic. There's stuff to improve :)
02-07-2009, 02:29 AM#3
Av3n
Yeah I know xD. I haven't even set up the thread yet, nor the map to even say it's ready to get moved.

I haven't coded in awhile as well. Anything you want to point out?

-Av3n
02-08-2009, 10:37 PM#4
moyack
Ok, my comments:

for portability, set an initializer function and make that function private:

Collapse JASS:
library Devour initializer init needs SimError

Make the variable trigger as local.
You can use only one EFFECT_TYPE instead separate ones, it gives to the user one place to edit the effects.
You can use a more accurate event to detect if a unit is going to cast the spell and allow you to reuse the Conditions function to detect the spell cast. Change the onOrder by returning nothing so it can be an action. See those changes here.

Collapse JASS:
private function OnOrder takes nothing returns nothing
     local unit u = GetTriggerUnit()
     if IsUnitInGroup(u,isDevouring) then
        call SimError(GetOwningPlayer(u),SpellErrorMessage)
        call PauseUnit(u,true)
        call IssueImmediateOrder(u,"stop")
        call PauseUnit(u,false)
     endif
     set u = null
endfunction

private function init takes nothing returns nothing
    local trigger t = CreateTrigger(  )
    call TriggerRegisterAnyUnitEventBJ( t, EVENT_PLAYER_UNIT_SPELL_EFFECT )
    call TriggerAddCondition( t, Condition( function Conditions ) )
    call TriggerAddAction( t, function Devour.create )
    set t = CreateTrigger(  )
    call TriggerRegisterAnyUnitEventBJ( t, EVENT_PLAYER_UNIT_SPELL_CAST )
    call TriggerAddCondition( t, Condition( function Conditions ) )
    call TriggerAddAction( t, function OnOrder )
    set isDevouring = CreateGroup()
    set isDevoured = CreateGroup()
    set devourTimer = CreateTimer()
    set index = -1
    set Devour.onLoopFunc = function Devour.onLoop
    set targetE = GetAbilityEffectById(SpellID,EFFECT_TYPE_SPECIAL,0)
    set exeE    = GetAbilityEffectById(SpellID,EFFECT_TYPE_SPECIAL,1)
    set finishE = GetAbilityEffectById(SpellID,EFFECT_TYPE_SPECIAL,2)
    call Preload(targetE)
    call Preload(exeE)
    call Preload(finishE)
    set t = null
endfunction

Well, it seems you're using one timer to manage all the spells, that's not bad, but... because this spell is focused for heroes, doing that is exaggerated, because it's less chances of being cast respect a custom unit ability. I suggest to make it dependable of TimerUtils and use a timer per spell cast., which means that the timer variable will say bye bye.

WAit for more comments... on MSN
02-09-2009, 01:52 AM#5
Av3n
Yeah I was thinking TimerUtils would be better for the execution accuracy and kills off 2+ vars and the indexing stuff.

-Av3n
02-10-2009, 06:23 AM#6
Av3n
I'm keeping the way I done the effects since it just that much easier object editor wise.

Switched to TimerUtils for accuracy over performance (Well not really if you use Red Flavor).

-Av3n
02-18-2009, 11:03 AM#7
moyack
Moved so people can give feedback.
02-18-2009, 11:50 AM#8
Anitarf
I think one timer method is always better for periodic stuff, although in this case it maybe isn't because you're using such long periods; why do so, though? It's much more intuitive to define it in damage per second rather than damage per x seconds, especially since the original devour ability also uses dps...

For cancelling the spell, you should use the order event.

When cancelling the spell if the unit is already full, why press the hotkey?

This is wrong: call SetWidgetLife(D.cast,GetWidgetLife(D.cast)+(D.dam-GetWidgetLife(D.targ))) So is the mana part.

Quote:
Originally Posted by moyack
Moved so people can give feedback.
If he wants to submit it, he should do it himself. If not, then don't waste the reviewers' time by moving it here.
02-18-2009, 12:14 PM#9
moyack
Quote:
If he wants to submit it, he should do it himself. If not, then don't waste the reviewers' time by moving it here.
Av3n wants to submit this spell, and as you can see, I gave my review. He could move it, I know, but I did it because is my way to authorize him to release it to the public, because initially it was only for my project.
02-18-2009, 01:51 PM#10
xombie
The idea of re-making a warcraft ability that perhaps could've been done better by Blizzard themselves is nice, but there is no way I'm going to ever use a spell that requires 4 additional libraries to import. Thats luggage.
02-18-2009, 02:32 PM#11
Rising_Dusk
It requires 3, and as far as I'm concerned TimerUtils should be used in any map anyways. LastOrder/AbortSpell should be in any map that needs custom spell error messages. That it requires these three libraries is not extra luggage, it is a sensible necessity for a spell such as this.
02-18-2009, 02:51 PM#12
xombie
LastOrder requires another library behind it to support it, so thats 4. Also, TimerUtils isn't something that all maps should have, there are quite a few alternatives. Y'know, pretty soon you're not going to be able to go to wc3campaigns.net and download a spell without also downloading several other systems. This isn't very good for uniting the wc3 community, but who says thats at all what anybody here wants to do.

I just pulled this out of the Triggers forum:
http://www.wc3c.net/showthread.php?t=104584

//Requires:
// - TimerUtils
// - Table
// - ABuff
// - ADamage
// - SimError
// - LastOrder
// - AbortSpell

What happens if something goes wrong, ever? Your map is entirely gone to shit because there is no way in hell you're going to be debugging 7+ "helpers" and then your own code.
02-18-2009, 03:18 PM#13
Rising_Dusk
Quote:
Originally Posted by xombie
LastOrder requires another library behind it to support it, so thats 4. Also, TimerUtils isn't something that all maps should have, there are quite a few alternatives. Y'know, pretty soon you're not going to be able to go to wc3campaigns.net and download a spell without also downloading several other systems. This isn't very good for uniting the wc3 community, but who says thats at all what anybody here wants to do.
If you include the SimError requirement of AbortSpell, then I agree with you.

Secondly, TimerUtils is as close to a timer handling standard as we have. If you don't use it in your maps, it is your own fault and your own loss. It is the best way to handle timers (recycling) and offers different flavors (at no compatibility penalty to the user) for user preference.

Thirdly, there are no compatibility errors between Table, TimerUtils, SimError, LastOrder, AbortSpell, or Anitarf's systems. We go to extreme lengths to ensure that users don't face compatibility problems when we approve scripts. If there are any compatibility dilemmas that may arise, we require users specifically list them in the first post. (UnitUserData for example) At that point, if the user still experiences them, it is their own fault.

Having many libraries is the point of libraries. They exist to be used, in unison and as necessary, for the abstraction of common or repetitive code within maps. I personally use something like 21 libraries from the database for one of my current maps and experience zero conflicts or troubles. I even find use for those libraries in many of my spells, making them that much more valuable.

Quote:
Originally Posted by Xombie
This isn't very good for uniting the wc3 community, but who says thats at all what anybody here wants to do.
Standards are exactly the way to unite the WC3 scripting community.
02-18-2009, 05:05 PM#14
darkwulfv
I think what he's trying to get at is with so many systems, debugging can become a shit not because of cross-system conflicts, but because you don't know what system is causing the problem in the first place.

Quote:
Standards are exactly the way to unite the WC3 scripting community.
And that's why we have 3-4 versions of multiple systems. (Timer Handling, Unit data, etc. etc.)

ONTOPIC OMG:

I highly suggest a "progress" bar, since the original devour showed the unit's health so you knew how much longer it had to go. I think it'd add a nice touch.
02-18-2009, 05:28 PM#15
moyack
Well, to finish this offtopic: systems posted here have something called support and hard review, and if any submitter has a resource in the database, it has to give support to that spell/system/sample. So... if users have problems with a system they must:

1. Check if they have a bug in their code and not in the system.
2. Post the issue in the resource thread so the script developer can check this problem.

So in general, using other systems makes your modding faster and supported.

If I see other comment offtopic, it will be deleted.

On topic: Devour.onLoopFunc variable can be avoided... in fact I dont' understand how using it you can keep it organized.