wc3campaigns
WC3C Homepage - www.wc3c.netUser Control Panel (Requires Log-In)Engage in discussions with other users and join contests in the WC3C forums!Read one of our many tutorials, ranging in difficulty from beginner to advanced!Show off your artistic talents in the WC3C Gallery!Download quality models, textures, spells (vJASS/JASS), systems, and scripts!Download maps that have passed through our rigorous approval process!

Go Back   Wc3C.net > Resources > Code Resources > Scripts
User Name
Password
Register Rules Get Hosted! Chat Pastebin FAQ and Rules Members List Calendar



Reply
 
Thread Tools Search this Thread
Old 10-23-2009, 09:32 AM   #16
grim001
requires vJass
 
grim001's Avatar


Code Moderator
 
Join Date: Nov 2006
Posts: 1,540

Submissions (10)

grim001 is just really nice (277)grim001 is just really nice (277)

Send a message via AIM to grim001
Default

Ok, I have spent some time looking at this, and I think it's pretty cool. I will probably use it myself for some things eventually, and not need to finish DamageMod, since I really hate working on that thing.

Questions/Suggestions:
  • I see that you've made improvements in the area of damage prevention. I'm not going to bother to test that it works perfectly, because that is very time consuming, and I'm sure you've tested it quite a lot. Do you know if there's any possible situation where it can still fail, other than receiving damage that exceeds the life bonus value?
  • You don't keep the unit's life proportional when the bonus HP is added, which make life bar flickering an issue in some situations. Is there any way to fix that without introducing other problems?
  • Is it safe to use UnitDamageTarget within the damage detection callbacks? If not, you could provide a safe version.
  • I'd personally prefer if the interface events were named onDamage, onDamaged, it reflects the naming scheme that's been commonly used for events and looks prettier.

Criticisms:
  • You should have the object merger call enabled by default, that is pretty much how all other scripts have been doing it. Also, Earth-Fury recently told me something about how the ObjectMerger works that I have confirmed through testing. If you save the map with the object merger call, disable it, then save the map again, the ability will not exist. You have to run object merger call, then close and re-open the map for it to become permanent. You might want to update your documentation to reflect that.
  • It is nice to provide compatibility, but there is such a thing as going overboard. The number of scripts here is going to confuse and scare away some people. If you think about it, versions of DamageEvent do not need to exist for IDDS and LLDD. People who have those scripts in their library and don't switch to DamageEvent probably prefer that syntax, and it would be lame to use two different methods of damage detection in one map.
  • What is needed instead are IDDS and LLDD versions of DamageModifiers. In this case, you can even use static ifs to make it all into one script, which optionally supports either DamageEvent, IDDS, or LLDD. It would not throw the proper compile error if you lacked any damage detection system, but that is less confusing than the multitudes of scripts that exist right now.
  • Although Table is a little bit of a syntax upgrade for end users, it is not much of a boon in system making, now that it doesn't serve the purpose of consolidating gamecaches. If you turn your table version into a hashtable version, you can then make DamageModifiers use hashtables by default, and optionally utilize AutoIndex if it's in the map.
  • A delay is created the first time the extra life ability is used. You can optionally require AbilityPreload to preload the ability.
  • The final result would be one version of DamageEvent, and one version of DamageModifiers that optionally requires DamageEvent, IDDS, LLDD, AutoIndex, and AbilityPreload.

About using extends:
It is the truth that many people will avoid this system just because they either don't like or don't understand using extends. But aside from that, there is the legitimate problem that you can't extend more than one interface. That means you can't mix your damage/damaged events with structs that extend other interfaces, which would be a very useful thing to do. Imagine mixing those events with a struct extending from a buff system, for example.

It used to be impossible to do anything about that, but now that modules have become more powerful, something can be done. First you would have to port the damage modifiers over to using function interfaces rather than extends, which will be preferable and more understandable for many people to use. It would then be possible to create a module which restores the current functionality, with the added benefit of not needing to extend anything.

Well, how do you port the current functionality to function interfaces? The way you are currently using extends is to provide three things to the user: a way to associate damage/damaged functions with units, a way to associate priorities with those functions, and a way to facilitate attaching data to that specific DamageModifier. So what if you do it this way?:

Expand JASS:

Say you ported it to this setup, how do you restore the current functionality using a module? Well, it would be best to let me handle that, since I am making a system which creates modules for this sort of thing, and supports every approved damage detection system. If you want to discuss how it works you can find me on IRC. But suffice to say it would look something like this for the user:
Expand JASS:

Last edited by grim001 : 10-23-2009 at 10:35 AM.
grim001 is offline   Reply With Quote
Sponsored Links - Login to hide this ad!
Old 10-23-2009, 03:14 PM   #17
Anitarf
Procrastination Incarnate


Development Director
 
Join Date: Feb 2004
Posts: 8,186

Submissions (19)

Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)

2008 Spell olympics - Fire - SilverApproved Map: Old School Alliance TacticsHero Contest #2 - 3rd PlaceSpell making session 2 winner

Default

Quote:
Originally Posted by grim001
  • I see that you've made improvements in the area of damage prevention. I'm not going to bother to test that it works perfectly, because that is very time consuming, and I'm sure you've tested it quite a lot. Do you know if there's any possible situation where it can still fail, other than receiving damage that exceeds the life bonus value?
As far as I know, the code accounts for all eventualities (aside for, as you mentioned, the bonus hp ability being inadequate). I haven't tested all possible cases systematically, but I have tested several complicated situations and the code performed as expected (although I had to spend some time figuring out myself what exactly to expect).

Quote:
  • You don't keep the unit's life proportional when the bonus HP is added, which make life bar flickering an issue in some situations. Is there any way to fix that without introducing other problems?
That's one compromise I had to make in order to ensure that players get bounty correctly whenever the damage is supposed to kill a unit. The system always keeps the unit's life at the correct absolute value, rather than a relative value, to make sure that when the damage resolves, the unit gets killed by the original damage packet no matter how much the damage was increased/decreased; this also simplifies the rest of the code, making it easier to ensure robustness in other cases.

You will only notice the flickering regularly if most of the damage packets in the map are higher than the unit's max hp, which is the only case when the bonus hp ability is used.

Quote:
  • Is it safe to use UnitDamageTarget within the damage detection callbacks? If not, you could provide a safe version.
It is safe. The system can accept additional damage packets both before and after the original damage packet resolves.

Quote:
  • I'd personally prefer if the interface events were named onDamage, onDamaged, it reflects the naming scheme that's been commonly used for events and looks prettier.
You're right, I will change this.

Quote:
  • You should have the object merger call enabled by default, that is pretty much how all other scripts have been doing it. Also, Earth-Fury recently told me something about how the ObjectMerger works that I have confirmed through testing. If you save the map with the object merger call, disable it, then save the map again, the ability will not exist. You have to run object merger call, then close and re-open the map for it to become permanent. You might want to update your documentation to reflect that.
My, mistake, it was supposed to be enabled but I forgot when copying it to the post. I didn't know about the object merger issues, never experienced the problem. I'll fix that too.

Quote:
  • It is nice to provide compatibility, but there is such a thing as going overboard. The number of scripts here is going to confuse and scare away some people. If you think about it, versions of DamageEvent do not need to exist for IDDS and LLDD. People who have those scripts in their library and don't switch to DamageEvent probably prefer that syntax, and it would be lame to use two different methods of damage detection in one map.
Well, my concern are public resources. A user could download two spells, one that uses IDDS and one that uses DamageEvent. From the JESP manifest onward we have been striving to write spells and systems that can be used even by people who lack the skill to modify them, so there's no guarantee that our user could edit either of these two spells so they would use only one DD system.

The idea was that in such cases, DamageEvent could interface with the other damage detection system instead of wasting resources with it's own damage event trigger. I agree that the method of accomplishing this (having three different versions of the library) is awkward and I intend to change it to a single library with optional requirements instead.

Quote:
  • What is needed instead are IDDS and LLDD versions of DamageModifiers. In this case, you can even use static ifs to make it all into one script, which optionally supports either DamageEvent, IDDS, or LLDD. It would not throw the proper compile error if you lacked any damage detection system, but that is less confusing than the multitudes of scripts that exist right now.
The problem is that it's DamageEvent that requires DamageModifiers, not the other way around. That's because DamageEvent calls DamageModifiers first, before any other response, and DamageModifiers then returns the modified damage back to the damage detection system. It's a two-way communication initiated by the damage detection system, so DamageModifiers can only work with DamageEvent or a modified third party DD system.

Quote:
  • Although Table is a little bit of a syntax upgrade for end users, it is not much of a boon in system making, now that it doesn't serve the purpose of consolidating gamecaches. If you turn your table version into a hashtable version, you can then make DamageModifiers use hashtables by default, and optionally utilize AutoIndex if it's in the map.
Well, I like using Table in lieu of native hashtables because it's a lot more readable, making it easier for me to develop and maintain code. However, having a single version of DamageModifiers instead of two might be worth the change, especially since maintaining a single copy of the library is easier in the long run; I'll think about that.

Quote:
  • A delay is created the first time the extra life ability is used. You can optionally require AbilityPreload to preload the ability.
Agreed, will add that.

Quote:
About using extends:
It is the truth that many people will avoid this system just because they either don't like or don't understand using extends. But aside from that, there is the legitimate problem that you can't extend more than one interface. That means you can't mix your damage/damaged events with structs that extend other interfaces, which would be a very useful thing to do. Imagine mixing those events with a struct extending from a buff system, for example.
I think the first statement is a poor argument; it is after all also the truth that many people will avoid this system because it's in vJass and not GUI.

I can see the problem with extends, however, could you not use delegate to work around that? I've seen some people have been enthusiastic recently about the module-based coding style, but I still prefer the multiple struct approach myself. A damage modifier, for example, makes more sense to me as a struct itself (which can then be a member or even a delegate of other structs) than a property/module of any struct. I don't think either approach is functionally superior so mine should be a perfectly valid stylistic choice and I'd like to keep it as it is, unless you disagree.
__________________
Anitarf is offline   Reply With Quote
Old 10-23-2009, 11:52 PM   #18
Karawasa
Element Tower Defense
 
Karawasa's Avatar
 
Join Date: Feb 2006
Posts: 1,094

Submissions (2)

Karawasa has a spectacular aura about (78)Karawasa has a spectacular aura about (78)Karawasa has a spectacular aura about (78)

Approved Map: Tropical TagApproved Map: Element TD

Send a message via AIM to Karawasa Send a message via MSN to Karawasa
Default

Quote:
Originally Posted by Anitarf
Have you tested that? When I tried that with a negative value, I got a damage event with a total of 0 damage. Unless you can actually produce a negative damage event in a test map, shut up.

If you want a map go play Element TD. You can heal units with negative damage; that's exactly how the healing creeps work.
__________________

Element Tower Defense - Premier WC3 Custom Game
Karawasa is offline   Reply With Quote
Old 10-23-2009, 11:53 PM   #19
Rising_Dusk
Obscurity, the Art


Projects Director
Project Leader: OD
 
Join Date: Feb 2006
Posts: 9,729

Submissions (27)

Rising_Dusk has a reputation beyond repute (1192)Rising_Dusk has a reputation beyond repute (1192)Rising_Dusk has a reputation beyond repute (1192)Rising_Dusk has a reputation beyond repute (1192)Rising_Dusk has a reputation beyond repute (1192)Rising_Dusk has a reputation beyond repute (1192)Rising_Dusk has a reputation beyond repute (1192)Rising_Dusk has a reputation beyond repute (1192)Rising_Dusk has a reputation beyond repute (1192)

Hero Contest #3 - 1st PlaceApproved Map: Desert of ExileApproved Map: Advent of the ZenithHero Contest #2 - 1st PlaceHero Contest - Third place>

Send a message via AIM to Rising_Dusk Send a message via MSN to Rising_Dusk
Default

You really shouldn't do that.
__________________
Rising_Dusk is offline   Reply With Quote
Old 10-24-2009, 02:51 AM   #20
grim001
requires vJass
 
grim001's Avatar


Code Moderator
 
Join Date: Nov 2006
Posts: 1,540

Submissions (10)

grim001 is just really nice (277)grim001 is just really nice (277)

Send a message via AIM to grim001
Default

Quote:
Originally Posted by Anitarf
That's one compromise I had to make in order to ensure that players get bounty correctly whenever the damage is supposed to kill a unit.
Would it be possible to only do this when you know the damage will be fatal?

Quote:
Originally Posted by Anitarf
The problem is that it's DamageEvent that requires DamageModifiers, not the other way around.
However, you can change the design a bit to get around this by calling RunDamageModifiers from within DamageModifiers using a function registered with any damage detection system. The only problem would be that the final modified damage value wouldn't be passed through to other events, however how can correct that for IDDS by using the SetDamage function it includes. LLDD relies on the native event responses, but you could make a function that returns the modified damage value.

Quote:
Originally Posted by Anitarf
I think the first statement is a poor argument; it is after all also the truth that many people will avoid this system because it's in vJass and not GUI.
It's not an argument; it annoys me that people fear extends. But making it understandable for a wider audience can only be considered an upside. I found the function interface example from my last post to be pretty elegant, too.

Quote:
Originally Posted by Anitarf
I can see the problem with extends, however, could you not use delegate to work around that?
No, delegate can't be used for event handling. If you put a delegate DamageModifier struct inside another struct, that doesn't accomplish anything useful. You still can't move the events into the parent struct, they still need cyclical references to access data from one another.

Quote:
Originally Posted by Anitarf
I've seen some people have been enthusiastic recently about the module-based coding style, but I still prefer the multiple struct approach myself.
Extends is not supposed to be used just to add events to units, it is for specializations of object-types: for example, a specific kind of buff. (It took me a while to realize this, but there is a reason some of my old interface-based systems ever saw the light of day, it is because they were so impractical to use.) It absolutely makes sense to have events from multiple sources within one struct. Take this for example:
Expand JASS:
Without modules, the BuffSystem would have to support periodic events and damage detection on its own, which is not modular at all. In fact it's horrible and leads to 2000 line monolithic systems. If you thought that separate structs were a good idea, why did you include damage detection support in ABuff? You could have used a separate struct for those events.

Here's what it would have to look like without modules (this is painful to code):
Expand JASS:
At 32 lines vs 54 lines (excluding whitespace), it winds up taking almost twice as many lines of code.

Quote:
Originally Posted by Anitarf
A damage modifier, for example, makes more sense to me as a struct itself (which can then be a member or even a delegate of other structs) than a property/module of any struct.
A damage modifier is not anything but a unit event that returns a value. Taking this position to the extreme, we would see that any event can be handled using an interface. Why is it that no one uses inheritance for things that can be handled with function interfaces? It's because example A makes way more sense than example B:

Example A:
Expand JASS:
Example B:
Expand JASS:
The above example is lame, because it shows the improper use of extends just to bind events to a unit. Systems that do this become a pain in the ass to use in conjunction with other systems that do the same thing because they are mutually exclusive from the same struct.

Anyway, whether you want to change the basic way the system works is up to you, it is still approvable either way once the other issues are dealt with.

Last edited by grim001 : 10-24-2009 at 03:24 AM.
grim001 is offline   Reply With Quote
Old 10-24-2009, 06:02 PM   #21
Anitarf
Procrastination Incarnate


Development Director
 
Join Date: Feb 2004
Posts: 8,186

Submissions (19)

Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)

2008 Spell olympics - Fire - SilverApproved Map: Old School Alliance TacticsHero Contest #2 - 3rd PlaceSpell making session 2 winner

Default

Quote:
Originally Posted by grim001
Would it be possible to only do this when you know the damage will be fatal?
I'd need to change how the core works. Right now, it doesn't care if the damage will be fatal at all, it just modifies the unit's life by the damage modifier and makes sure it remembers if there are any leftovers (since it can't set the life above the unit's maxlife or below 0.406 which would kill the unit), if another damage event occurs in response then those leftovers are carried over and added to the new event's modifier. It also keeps track of the total damage dealt, if that exceeds the unit's max life then the survival ability is added. This explanation is too long. it just makes sure the modifiers are applied to the unit's life correctly without killing the unit in the process. Actually tracking what the unit's life should be and whether the damage will kill it would be a lot more complicated and less robust. It probably is technically possible, but I really don't want to go down that road.

Quote:
However, you can change the design a bit to get around this by calling RunDamageModifiers from within DamageModifiers using a function registered with any damage detection system. The only problem would be that the final modified damage value wouldn't be passed through to other events, however how can correct that for IDDS by using the SetDamage function it includes. LLDD relies on the native event responses, but you could make a function that returns the modified damage value.
That would be an uglier solution in my opinion. I want the modifiers to be distinct from the regular event responses, rather than just being another one of them, which brings me to your next point:

Quote:
No, delegate can't be used for event handling....
Quote:
Extends is not supposed to be used just to add events to units,...
Hey, I agree, but:
Quote:
A damage modifier is not anything but a unit event that returns a value.
And has a priority. And the returned value modifies the damage. It's a lot more complicated than just a simple event listener; if you want that then use DamageEvent. I consider DamageModifier much more a part of an event than a response to it, and a more complicated object than a mere response, that's why responses are a function interface and modifiers are an interface.

Besides, there's no functional difference, it's just syntax. You could still easily write a wrapper library that would provide a modifyIncomingDamage module and a modifyOutgoingDamage module while using DamageModifiers internally.


Edit: Okay, I fixed up DamageEvent, now it's a single library. I still need to consider whether to join the two versions of DamageModifiers in a similar fashion, when I decide that I'll also fix up the other errors (ability preloading, objectmerger call, method names). Also, I removed the ADamage compatibility library, I'll post it in the ADamage thread instead once this gets approved and that gets graveyarded.
__________________

Last edited by Anitarf : 10-24-2009 at 08:52 PM.
Anitarf is offline   Reply With Quote
Old 10-25-2009, 12:20 AM   #22
grim001
requires vJass
 
grim001's Avatar


Code Moderator
 
Join Date: Nov 2006
Posts: 1,540

Submissions (10)

grim001 is just really nice (277)grim001 is just really nice (277)

Send a message via AIM to grim001
Default

Quote:
Originally Posted by Anitarf
Actually tracking what the unit's life should be and whether the damage will kill it would be a lot more complicated and less robust. It probably is technically possible, but I really don't want to go down that road.
Well, I don't blame you, I tried to do that with DamageMod and it was extremely difficult, and I never quite got it working perfectly.

Quote:
Originally Posted by Anitarf
You could still easily write a wrapper library that would provide a modifyIncomingDamage module and a modifyOutgoingDamage module while using DamageModifiers internally.
It is not quite possible. It's because DamageModifier structs are analogous to a specific-unit-event, whereas the function interface setup is analogous to an any-unit-event. It would require vex to add onCreate, allow onCreate within modules, and allow onDestroy within modules. It would also require over twice as much code and an extra TriggerEvaluate per event.

Like I said, I can't force you to change it, but I don't see any situation where it is more elegant, I only see lots of situations where it is more of a hassle, and usually takes twice as much typing.

Anyway, let us know once you've made all the changes you want to make.

Last edited by grim001 : 10-25-2009 at 12:20 AM.
grim001 is offline   Reply With Quote
Old 10-26-2009, 12:25 AM   #23
Anitarf
Procrastination Incarnate


Development Director
 
Join Date: Feb 2004
Posts: 8,186

Submissions (19)

Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)

2008 Spell olympics - Fire - SilverApproved Map: Old School Alliance TacticsHero Contest #2 - 3rd PlaceSpell making session 2 winner

Default

I ended up deciding to keep two versions of DamageModifiers for now, I might merge them in the future though if I find more reasons to do it. I otherwise fixed the rest of the small issues DamageModifiers had (method names, ability preloading, objectmerger calls) as well as adding some xedamage support to DamageEvent (it now automatically ignores xedamage's dummy events).

Quote:
Originally Posted by grim001
It is not quite possible.
I don't really know since I didn't look much into modules yet, but I got the impression from your first post that you could do it if I were using the function interface format (function AddOnDamageModifier(unit, DamageFunc, priority) --> integer). Since I know it's possible to write a wrapper library that translates my interface to a function interface I assumed making the module would be possible with the current syntax as well.
__________________

Last edited by Anitarf : 10-26-2009 at 12:35 AM.
Anitarf is offline   Reply With Quote
Old 10-26-2009, 02:58 AM   #24
grim001
requires vJass
 
grim001's Avatar


Code Moderator
 
Join Date: Nov 2006
Posts: 1,540

Submissions (10)

grim001 is just really nice (277)grim001 is just really nice (277)

Send a message via AIM to grim001
Default

Well, now that I think about it... even as function interface, it still works as a specific unit event. So an automatically functioning module isn't possible either way without those additional module features.

It'd still take an extra triggerevaluate (DamageMod instance method --> module static method --> instance method) compared to the function interface approach (module static method --> instance method), but oh well.

So if you're done with all the changes you want to make, I'll try to look at it tonight...

Last edited by grim001 : 10-26-2009 at 02:58 AM.
grim001 is offline   Reply With Quote
Old 10-26-2009, 11:56 AM   #25
grim001
requires vJass
 
grim001's Avatar


Code Moderator
 
Join Date: Nov 2006
Posts: 1,540

Submissions (10)

grim001 is just really nice (277)grim001 is just really nice (277)

Send a message via AIM to grim001
Default

OK, I tested it and everything works fine, I only have two comments:
  • You use xe's preload function in a struct onInit method, so the preloading unit won't exist yet. This is more like a problem with xe, so I made a post in the xe thread asking for vex to fix it.
  • I think it would be better to merge the Table and AutoIndex versions together, although it would be nice if "requires libraryA or libraryB" was possible.

Anyway, I think this is ready for approval now, so I'll approve it and graveyard ADamage.
grim001 is offline   Reply With Quote
Old 11-01-2009, 08:21 PM   #26
Mr.Malte
User
 
Mr.Malte's Avatar
 
Join Date: Apr 2008
Posts: 286

Submissions (2)

Mr.Malte is on a distinguished road (11)

Default

I use this in a starcraft map and make protoss shields with it.
But the function that blocks the damage only fires when the unit has already been attacked one time.
here is the function:

Collapse JASS:
scope Energyshield initializer init
    function onDamage takes unit damaged, unit source, real damage returns nothing
        local real angle
        local unit u
        local integer ID = 'e001'
        
        if Basics_GetUnitRace(damaged) != PROTOSS or GetUnitState(damaged,UNIT_STATE_MANA) < 2.5 or IsUnitPaused(damaged) then
            return
        endif
        
        set angle = Atan2(GetUnitY(source)-GetUnitY(damaged),GetUnitX(source)-GetUnitX(damaged))
        if damage > GetUnitState(damaged,UNIT_STATE_MANA) then
            call SetUnitState(damaged,UNIT_STATE_LIFE,GetUnitState(damaged,UNIT_STATE_LIFE)+damage-GetUnitState(damaged,UNIT_STATE_MANA))
        else
            call SetUnitState(damaged,UNIT_STATE_LIFE,GetUnitState(damaged,UNIT_STATE_LIFE)+damage)
        endif
        call SetUnitState(damaged,UNIT_STATE_MANA,GetUnitState(damaged,UNIT_STATE_MANA)-damage)
    
        // GetUnitZ + Units fly height
        if GetUnitZ(source) - GetUnitZ(damaged) > 200. then
            set ID = 'e002'
        endif
        
        if IsUnitType(damaged,UNIT_TYPE_MECHANICAL) or IsUnitType(damaged,UNIT_TYPE_STRUCTURE) then
            set u = CreateUnit(Player(12),ID,GetUnitX(damaged)+40.*Cos(angle),GetUnitY(damaged)+40.*Sin(angle),angle*bj_RADTODEG)
            call SetUnitScale(u,1.2,1.2,1.3)
            call SetUnitFlyHeight(u,40.,0.)
        else
            set u = CreateUnit(Player(12),ID,GetUnitX(damaged)+26.*Cos(angle),GetUnitY(damaged)+26.*Sin(angle),angle*bj_RADTODEG)
        endif
        call UnitApplyTimedLife(u,'BTLF',.8)
    endfunction
    
    private function init takes nothing returns nothing
        call RegisterDamageResponse(onDamage)
    endfunction
endscope
Mr.Malte is offline   Reply With Quote
Old 11-01-2009, 08:42 PM   #27
Anitarf
Procrastination Incarnate


Development Director
 
Join Date: Feb 2004
Posts: 8,186

Submissions (19)

Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)

2008 Spell olympics - Fire - SilverApproved Map: Old School Alliance TacticsHero Contest #2 - 3rd PlaceSpell making session 2 winner

Default

Your code doesn't work the first time because you can't set a unit's hp above it's max hp, so when you try to increase the unit's life to nullify the damage the life doesn't get increased and so the damage isn't "prevented" like you think it should be.

This is only one out of many problems we encounter when trying to prevent damage; that's precisely why I wrote the DamageModifiers library, so it handles all the nuances of damage prevention for you. You should use DamageModifiers instead of a DamageEvent response.
__________________
Anitarf is offline   Reply With Quote
Old 11-03-2009, 10:22 PM   #28
Sinnergy
User
 
Sinnergy's Avatar
 
Join Date: Apr 2009
Posts: 173

Sinnergy has little to show at this moment (8)

Default

perfect.
Just a question, do I need to trigger all damage via trigger when using the system?
__________________
Current Project:
Rise of Sinnergy v1.00
Sinnergy is offline   Reply With Quote
Old 11-03-2009, 10:47 PM   #29
Anitarf
Procrastination Incarnate


Development Director
 
Join Date: Feb 2004
Posts: 8,186

Submissions (19)

Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)

2008 Spell olympics - Fire - SilverApproved Map: Old School Alliance TacticsHero Contest #2 - 3rd PlaceSpell making session 2 winner

Default

Quote:
Originally Posted by Sinnergy
Just a question, do I need to trigger all damage via trigger when using the system?
No. You can deal damage with attacks and spells as well.
__________________
Anitarf is offline   Reply With Quote
Old 11-04-2009, 01:00 AM   #30
Sinnergy
User
 
Sinnergy's Avatar
 
Join Date: Apr 2009
Posts: 173

Sinnergy has little to show at this moment (8)

Default

So does the system has the ability to detect attack damage and spell damages?
__________________
Current Project:
Rise of Sinnergy v1.00
Sinnergy is offline   Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off


All times are GMT. The time now is 08:44 PM.


Affiliates
The Hubb The JASS Vault Clan WEnW Campaign Creations Clan CBS GamesModding Flixreel Videos

Powered by vBulletin (Copyright ©2000 - 2018, Jelsoft Enterprises Ltd).
Hosted by www.OICcam.com
IT Support and Services provided by Executive IT Services