System Status

[Jesus4Lyf]

>Try not to miss that post where I suggest you to add silence and attack disable and that other useful stuff.
Noted. When I have time, I will get things done.

 

[Jesus4Lyf]

Try not to miss that post where I suggest you to add silence and attack disable and that other useful stuff.

Done. I had some fun with the object merger.

//! i makechange(current,"Nsi1",0,"\00\00\00\00\01\00\00\00\01\00\00\00\01\00\00\00\00\00\00\00\4e\73\69\31\00\00\00\00\02\00\00\00\01\00\00\00\02\00\00\00\00\00\00\00\4e\73\69\31\00\00\00\00\03\00\00\00\01\00\00\00\03\00\00\00\00\00\00\00")

:thup:

Intending to add bonus stuff to this too, like damage and agility.

 

[Viikuna]

Nice.

I didnt try the test map yet, because I got a feeling that its not updated yet.



I just gotta say that this [lJASS]Status[unit].add [/lJASS] syntax looks fucking ugly IMO, but I guess that wont make you change it...

Normal functions would look way better: [lJASS]StunUnit( unit, boolean )[/lJASS] and [lJASS]ModifyUnitStunStatus( unit, integer )[/lJASS] for making sure that unit stays stunned/unstunned, even if it has multiple stun/antistun buffs applied in it.



But at least do something to this: [lJASS]if TwistedByTheDarkSideOfTheForce[YoungSkywalker].hasBecome then[/lJASS]

Its some Yoda talk from StarWars for suck sake! [lJASS]if Stunned[caster].is then[/lJASS]



Anyways, maybe Im getting too focused to these syntax thingies. If it works, people can always write their own wrapper functions to make it look good again.


Anyways, this kind of stuff is really useful, and I hope it makes more people to use ABuff like buff systems for doing these timed effects, instead of relying on Blizzards own buff thingies.

 

[Jesus4Lyf]

I just gotta say that this [lJASS]Status[unit].add [/lJASS] syntax looks fucking ugly IMO

There is a huge purpose behind it.

local Status target=Status[unit]
call target.addLock() // status is in use, don't recycle unit index.
call target.addSilence()
call target.addStun()
call TriggerSleepAction(1.0)
call target.removeStun()
call target.addDisarmMelee()
call TriggerSleepAction(2.0)
call target.removeSilence()
call target.removeDisarmMelee()
call target.removeLock() // unit index may be recycle if unit was removed in this time.

Think about that.

 

[Viikuna]

Well, yea. Hrm. I generaly like that kind of unit structs for stuff that unit already has. ( Damage, attributes, evasion, spell power, stuff rom UnitProperties for example )

These effects are not really part of the unit, but something that comes from outside. ( Now when I type this, it feels kinda stupid. I guess its just matter of taste then, eh )

call unit.stun()
set unit.damage=unit.damage+1

Anyways, this is why I dont like your example:

local Status target=Status[unit]
call target.addLock() // no, the index is supposed to be recycled when unit is removed. There exists no excuses.
call target.addSilence()
call target.addStun()
call TriggerSleepAction(1.0) // TSA sucks.
call target.removeStun()
call target.addDisarmMelee()
call TriggerSleepAction(2.0) // TSA sucks.
call target.removeSilence()
call target.removeDisarmMelee()
call target.removeLock() // no need for any locking

This looks much better:

private function onSpellCast takes nothing returns nothing
   call UnitBuffUnit(SpellEvent.CastingUnit, SpellEvent.TargetUnit, BUFF_TYPE)
   call UnitMagicallyDamageUnit(SpellEvent.CastingUnit, SpellEvent.TargetUnit, X)
endfunction

private function onBuffAdd takes nothing returns nothing
   local buff b=GetTriggerBuff()
   call SilenceUnit( b.target, true)
endfunction

private function onBuffRemove takes nothing returns nothing
   local buff b=GetTriggerBuff()
   call SilenceUnit( b.target, false)
endfunction

private function Init takes nothing returns nothing
   call BuffTypeRegisterAddEvent(BUFF_TYPE, onBuffAdd)
   call BuffTypeRegisterRemoveEvent(BUFF_TYPE, onBuffRemove)
   call RegisterSpellEffectEvent(SPELL_ID, onSpellCast)
endfunction

Some global trigger for clearing shit for all spells, no need for locking:

private function onDeath takes unit u returns nothing
    // among the other things:
    call UnitRemoveAllBuffs( u )
endfunction

private function init takes nothing returns nothing
    call OnUnitDeath( onDeath, true )
endfunction

 

[Jesus4Lyf]

TSA was only there for example, of course.

I noticed this:
>the index is supposed to be recycled when unit is removed. There exists no excuses.
>Some global trigger for clearing shit for all spells, no need for locking
If you have a 30 second silence and the unit is removed and recycled in that time, and the new unit who gets the index gets silenced, it will be interrupted when the 30 seconds expires. This is solvable either using some global buff system or by locking the status struct, nothing is lost really by either method. Technically, the status should be removed when the unit dies though, you're right. I still like coding like a maniac.

Example:

Spoiler

Full pseudo-code example for simple silence with unit removal protection.

struct Silence extends SpellStruct
    implement SpellStruct
    private Status status
    private method onTimeout takes nothing returns nothing
        call .status.removeSilence()
        call .status.removeLock()
        call .stopTimer(.onTimeout)
    endmethod
    private method onEffect takes nothing returns nothing
        set .status=Status[.targetUnit]
        call .status.addLock()
        call .status.addSilence()
        call .startTimer(.onTimeout,3.0)
    endmethod
    private static method onInit takes nothing returns nothing
        set .abil='Axxx'
    endmethod
endstruct

This sys will handle either or, but also I'm intending to add things like bonus damage/stats, for which storing the status object might be a neat efficiency perk.

 

[Narks]

I think your example, Viikuna, is a bit out of context here - Status adds the effects that buffs just happen to use, while you have posted an example for a system that handles buffs themselves, rather then their effects.

EDIT: I'm stupid, and you are right, it does look better

 

[Viikuna]

Well, locking is indeed needed for flying/knockbacked corpses, in case you remove index on death, but then again, if you remove it when unit gets removed from the game there should not be any reasons to lock index.

At least I cant think any right now.



Then again, it doesnt relaly hurt to have that feature, even though there isnt any real uses for it.


Anyways, I think this is cool. If you are planning to do some bonus mod thingy, like UnitProperties, make sure that people can easily add their own properties, such as some elemental power/resistance thingies they wanna use in their spells&systems.

// these you are probably gonna add, am I rite?
set unit.damage = unit.damage + 10
set unit.armor = unit.armor + 10
set unit.agility = unit.agility + 10
set unit.healthRegeneration = unit.healthRegeneration + 10
set unit.maxMana = unit.maxMana + 10 // etc.

// UnitProperties evasion module has these, they are cool:
set unit.attackMiss = unit.attackMiss + 10
set unit.attackEvasion = unit.attackEvasion + 10

// people should be able to add stuff like:
set unit.fireResistance = unit.fireResistance + 10
set unit.frostSpellPower = unit.frostSpellPower + 10 // etc.

 

[Jesus4Lyf]

set unit.damage = unit.damage + 10

Probably call unit.addDamage(10), unit.removeDamage(10).

// people should be able to add stuff like:
set unit.fireResistance = unit.fireResistance + 10
set unit.frostSpellPower = unit.frostSpellPower + 10 // etc.

Doesn't AIDS/Damage already allow that?

 

[Viikuna]

Probably call unit.addDamage(10), unit.removeDamage(10).

Whats wrong with unit.modifyDamage(10) and unit.modifyDamage(-10)?

Doesn't AIDS/Damage already allow that?

Well, you could create different struct for that stuff. I just like to have one big unit struct for all unit related stuff. ( Like UnitProperties )

So you can do stuff like:

// frost armor activated
local properties u=GetUnitProperties( caster )
set data.bonus=u.frostPower*.15
set u.armor=u.armor+bonus

 

[TriggerHappy]

I'm sorry but this just seems like a ripoff of UnitStatus now.

 

[Jesus4Lyf]

Well, you could create different struct for that stuff. I just like to have one big unit struct for all unit related stuff. ( Like UnitProperties )

Users can't add things to a struct without modifying the system internally though, right? Although a new AIDS struct doesn't allows status.doMyThing, you can typecast between structs, which is kind of a plus.

>Whats wrong with unit.modifyDamage(10) and unit.modifyDamage(-10)?
Nothing. I thought maybe it looked nicer to have an add and remove (remove would inline to .add(-x) anyway). Which do you prefer?

I'm sorry but this just seems like a ripoff of UnitStatus now.

*Waves hand dismissively.* This originally only stunned. UnitStatus was released 12 days after this, and likewise only stunned (and was called StunUnit). It featured nearly the same interface (I don't go there and call it a ripoff, this is the open source world - if something good is written for one platform (AIDS) we should write it for another also (AutoIndex) - why not). We then had the suggestion to add other stuff in this thread. UnitStatus added them first, but this was always also going to have them anyway. Now I've finally done it.

So "sorry" if it looks like I ripped off a system which seems to have been a copy of mine in the first place. Regardless, I still intend to include add/remove invulnerability, pause, spell immunity, invisibility, hiddenness, etc, and I wouldn't be surprised, disappointed or upset if UnitStatus then continued to do the same. I guess you should consider it "collaboration".

 

[Kenny]

At the risk of making this more like UnitStatus, which TriggerHappy will dislike, is there any chance of adding a Disable function as well.

It is basically like a stun, but no effect and stuff. You can use it to disable units during knocbacks and jumps without making it look crap by pausing units or stunning them. I'd like the option.

 

[Viikuna]

I think Dusk does disable with stack of dummy casters and aerial shackles. ( He released system like this some time go. )

Anyways, disable is good to have too.

add/remove invulnerability, pause, spell immunity, invisibility, hiddenness,

Spell immunity should just be a one boolean. You should trigger all your spells anyways, so you can just do something like this:

private function onSpellCast takes nothing returns nothing
   if IsSpellImmune( SpellEvent.TargetUnit ) then

/* or something like this:
  
   if GetSpellResistance( SpellEvent.TargetUnit ) > GetSpellPower( SpellEvent.CastingUnit ) then

*/   set SpellEvent.AbilityId=0 // no spell triggers will run now for channel event.
      call IssueImmediateOrder(SpellEvent.CastingUnit,"stop")
      call SimError(GetOwningPlayer(SpellEvent.CastingUnit),"Target is resistant to your spell!" )
   endif
endfunction

private function Init takes nothing returns nothing
    call RegisterSpellChannelEvent(0, onSpellCast )
endfunction

Invisibility is a good idea. I think it could have its own system, though. You could do way more than just normal wc3 invisibility stuff. Like have multiple levels of invisibility and detectors, as well as different ways they interract with each other.

For example: the range invisible unit is revealed is:

local real a=(detectorLevel/invisibilityLevel)*sightRange
if a>sightRange then
   set a=sightRange
endif 
return a

edit.

Which do you prefer?

If you wanna do it with methods, use modify( 10 ) and modify( -10 )
If you wanna use method operators, it could be:
set .damage=.damage+10 and set .damage=.damage-10
Id personally wanna have them both.

And I think that [lJASS]damage.add( GetRandomReal( -10,10) )[/lJASS] looks better than [lJASS]damage.remove( GetRandomReal( -10,10)*-1. )[/lJASS]

So, Id myself just go for .add or .modify or whatever you wanna call it. Nothing wrong with using negative values for decereasing.

 

[Jesus4Lyf]

is there any chance of adding a Disable function as well.

No, Stun does exactly that.
If you want the stun effect, you must add it yourself.

>You should trigger all your spells anyways, so you can just do something like this
That means you can target a spell on a spell immune unit, but it will fail, but not throw the UI style error.

With the invis, I intend to implement 3 invisibilities. Beak on attack/spell, break on attack/spell and fade again, and never break.

As for a detection system, that can build on this.
As for a magic immune system, that can build on this (but this will give a lovely natural wc3 ui error when targetting spell immune units with spells).

 

[Kenny]

No, Stun does exactly that.
If you want the stun effect, you must add it yourself.

Oh okay. I didn't realise that the system did not add the effects as well.

Does the stun buff have an icon and description?

I can't wait to test this out, probably some time tomorrow.

 

[Viikuna]

No, Disable is needed.

You might have a spell that makes unit stun resistant by decereasing that stun counter by 1000 or some other big number, but you still wanna disable unit during the leap attack spell.

 

[Kenny]

You might have a spell that makes unit stun resistant by decereasing that stun counter by 1000 or some other big number

That is a really cool idea. It would require the stunLevel struct member to be public and a check if the add method, but it could give rise to lots of cool spell implementations, like "will block the next 3 stuns on this units for the 15 seconds or something". (There could be another way, but that's how I'd do it).

I'd like to see Disable and Stun done separately. And If what I was saying before is correct, that would also mean that each could have their own buff and buff description.

Users can just add the effects themselves if they know how to use the lua thingy. Which I am trying to figure out, so I can add them.

 

[Viikuna]

Well, I would do this stuff with 2 functions: [lJASS]StunUnit( unit, boolean )[/lJASS] for normal stunning and [lJASS]ModifyUnitStunStatus( unit, integer )[/lJASS] for stuff like that.

edit. And same thing for silence, disarm and ensnare too.

edit.

With the invis, I intend to implement 3 invisibilities. Beak on attack/spell, break on attack/spell and fade again, and never break

The core should be as simple as possible to make it easy to build different invisibility systems.
I know that the ones you mentioned are most common ones, but I still dont think they should be included to main part of the system.

SetUnitInvisible( unit target, boolean invisible ) // makes unit invisible
DetectInvisibleUnit( unit target, player detector, boolean detect ) // makes player to see unit, even though its invisible

IsUnitInvisible( unit who )
IsUnitDetected( unit who, player detector ) // these natives exists eh,?

// Is it possible to make unit so invisible that the owning player dont see it? Dont think so.
// What about owning players allies? Do they see that invisible unit always?

Now then again, we could have some unit invisibility data thingies, for both invisibility and detecting.

module InvisibilityModule

    integer invisibility = 0
    integer detector  = 0

    /*  Now, to make this stuff work properly, it would probably need some fast periodic timer to
         go through all the invisible units in the map, and check if there are any detectors near them.

         Then it would use these invisibilty and detector values and calculate stuff using some formula 
         to find out wheter the unit is supposed to be visible for enemies

         Normal wc3 way would have just one level for both invisibility and detection. 1,0 means that unit is not    
         detected. 1,1 means that unit is detected.

   */
endmodule

Then after this, there should probably be some sample thingies, like those you mentioned before: enemies detect unit for X second when it casts spells and/or attacks.

edit.

just noticed this:

That means you can target a spell on a spell immune unit, but it will fail, but not throw the UI style error.

Well, the idea is to give all the sim error thingies, and trigger stuff so that it looks like a real thing.

I know that the example I posted, does not do that. Unit will still try to move close enough target to cast the spell, and only then it finds out that target is spell immune. Doing it properly would require you to take orders in account too. If all or most of your spells are based on channel, which means that you can pick those order strings, it might not be too hard to make sure that some [lJASS]GetIssuedOrderId() > X[/lJASS] thing applies for all your spells that use this spell immunity stuff, or something like that.

 

[Jesus4Lyf]

@Viikuna, regarding invisibility detection.
This is a WC3 status system designed to shift the focus in object data to a focus on JASS code to make development easier, not a JASS system designed to provide new or interesting functionality.

I feel that someone should specialise in such a thing themselves, rather than try to handle it poorly here.

Well, the idea is to give all the sim error thingies, and trigger stuff so that it looks like a real thing.

Whilst I like your view in theory, I find there to be value in creating things which are quickly understandable and repeatable for projects which don't have an infinite time frame for completion.

I think one good thing has come out so far, which is the notion of negative values for stun levels to be useful. I'm not sure about modifying the stun level with an integer. I feel that may be crossing an encapsulation line I'd rather not mess with (ie. perhaps that had best be a system built on top of this, specific to a map). But we will see.