System Smooth Unit Modification

Viikuna · Oct 13, 2009

Well, the code I posted probably tells how to use readonly. Just use readonly keyword and make sure that you only try to set those values inside struct.

Also, I noticed you added out of bounds checks for those appearance members, which is good.

You should probably do it like this though:

JASS:

local real red2
set .red=.red+addred // we leave .red unaffected by bounds check
set red2=.red
if red2 &lt; 0 then // red2 is .red, but with bounds checked,
   set red2=0    // so it can be used for vertex color change
else
   if red2&gt;522 then
       set red2=522
   endif
endif
call SetUniVertexColor(.unit,red2,// etc..
endif

So you can for example incerease green and blue by 10000 without bugging. This can be useful for undoing all vertex color changes that make unit more red by decereasing those.

edit.Oh yea, it kinda ruins this hook thingy, damn.

Komaqtion · Oct 13, 2009

Viikuna · Oct 13, 2009

Well, whatever, do what seems best to you. It will be pretty cool anyways.

Komaqtion · Oct 13, 2009

Just one question... Why 522 ? :S

JASS:

red2&gt;522

Shouldn't it be 255 ?

Jesus4Lyf · Oct 13, 2009

Wouldn't the hook thingie badly slow down the periodic stuff...

Komaqtion · Oct 13, 2009

Yeah, I removed it

Thanks

Btw, I'm making some test spell now, and I thought I'd make a "Shockwave-like" spell, but the projectile will (After some distance) start decreasing in size, and when it gets really small it'll implode and damage an area

Also, maybe shoot out small projectiles as it moves :S

What do you think ?

I also have this, which is OK imho

JASS:

scope Rage initializer Init

    globals
        private constant integer ABILITY_ID = &#039;A000&#039;
        private constant integer SPELLBOOK_ID = &#039;A002&#039;
        private constant integer DAMAGEBONUS_ID = &#039;A001&#039;
    endglobals
    
    private struct Data
    
        integer lvl
        unit caster
        player owner
        
        static method create takes unit u, player p, integer lvl returns Data
            local thistype this = thistype.allocate()
            
            set this.caster = u
            set this.owner = p
            set this.lvl = lvl
            
            return this
        endmethod
        
        private method onDestroy takes nothing returns nothing
            call UnitRemoveAbility( this.caster, SPELLBOOK_ID )
            call SmoothScaleChange.create( this.caster, 1.0, -( this.lvl * 0.25 ) )
            call SmoothColorChange.create( this.caster, 1.0, 0.0, 255.0, 255.0, ( this.lvl * 42.5 ) )
            
            set this.caster = null
            set this.owner = null
        endmethod
        
    endstruct
    
    private function Rage_Ends takes nothing returns nothing
        local Data d = GetTimerData( GetExpiredTimer() )
        
        call d.destroy()
        call ReleaseTimer( GetExpiredTimer() )
    endfunction
    
    private function Spell_Check takes nothing returns boolean
        return GetSpellAbilityId() == ABILITY_ID
    endfunction

    private function Rage_Actions takes nothing returns nothing
        local timer t = NewTimer()
        local unit u = GetTriggerUnit()
        local player p = GetOwningPlayer( u )
        local integer lvl = GetUnitAbilityLevel( u, ABILITY_ID )
        local Data d = Data.create( u, p, lvl )
        
        call UnitAddAbility( u, SPELLBOOK_ID )
        call SetPlayerAbilityAvailable( d.owner, SPELLBOOK_ID, false )
        call SetUnitAbilityLevel( u, DAMAGEBONUS_ID, d.lvl )
        call SmoothScaleChange.create( u, 1.0, d.lvl * 0.25 )
        call SmoothColorChange.create( u, 1.0, 0.0, -255.0, -255.0, -( d.lvl * 42.5 ) )
        
        call SetTimerData( t, d )
        call TimerStart( t, ( d.lvl * 5. ) + 5., false, function Rage_Ends )
        
        set t = null
        set p = null
        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 Spell_Check ) )
        call TriggerAddAction( t, function Rage_Actions )
    endfunction

endscope

Increase size a bit, and he becomes "redish" and a bit transparent

(Though, as I said a in posy #9, it bugs a bit

)

quraji · Oct 13, 2009

Jesus4Lyf said:
Wouldn't the hook thingie badly slow down the periodic stuff...

Why? Please don't tell me hooks in vJass are anything but an extra function call...

(I haven't seen hook code post-vJass)

Either way, the alternative is to let the user possibly screw this up totally. And maybe people still want to use SetUnit* instead of ModifyUnit* in some cases...

Azlier · Oct 13, 2009

>Why? Please don't tell me hooks in vJass are anything but an extra function call...

An extra function call, a TriggerEvaluate, and maybe some other stuff.

quraji · Oct 13, 2009

Azlier said:
>Why? Please don't tell me hooks in vJass are anything but an extra function call...

An extra function call, a TriggerEvaluate, and maybe some other stuff.

Ugh...anything more than Event?

Jesus4Lyf · Oct 13, 2009

>Ugh...anything more than Event?
Hooking should be faster than making an event fire through hook, and then attaching to that, if that's what you're asking.

Point in this case is that's an awfully frequent TriggerEvaluate for smooth colouring. Hooks shouldn't be used on natives that will likely be called periodically, imho.

quraji · Oct 14, 2009

>Hooking should be faster than making an event fire through hook, and then attaching to that, if that's what you're asking.

I meant your system. Although I'm not quite sure that's what I was thinking of...

>Point in this case is that's an awfully frequent TriggerEvaluate for smooth colouring. Hooks shouldn't be used on natives that will likely be called periodically, imho.

Do you really think it would be bad? Doesn't key timers use TriggerEvaluate?

Anyways, as I see it, there are three options:

1. Hook the SetUnit* functions.
2. Replaces the SetUnit* functions with custom ones and hope the user uses those instead.
3. Do nothing and the system breaks if the user does happen to use one.

Jesus4Lyf · Oct 14, 2009

>I meant your system. Although I'm not quite sure that's what I was thinking of...
>>Hooking should be faster than making an Event fire through hook, and then attaching to that, if that's what you're asking.

My bad. Was meant to be Event.

It's not that bad, but it's avoidable... I think either provide a custom function, or don't. I don't see why you need anything other than "modify"... I mean, it would screw up colour stuff when you subtract and then later add for a spell or something.

quraji · Oct 14, 2009

>My bad. Was meant to be Event.

Ah. Well I originally was asking do the hooks work like Event (add function as condition to a trigger, call TriggerEvalute, etc.). I haven't seen the code for them yet.

>It's not that bad, but it's avoidable... I think either provide a custom function, or don't. I don't see why you need anything other than "modify"... I mean, it would screw up colour stuff when you subtract and then later add for a spell or something.

Even if it were slow I'd still opt to add them, because they'd only be used in the case where the user tries to use the native SetUnitWhatever functions anyways (and thus only slowing it down in situations that would break the system for that unit anyways...rather have slower or broken?). I still think setting the unit properties could be useful, even though I do like modify more.

Komaqtion · Oct 14, 2009

So... What should I do ?!?!

Did you come up with a conclusion ?

quraji · Oct 14, 2009

Komaqtion said:
So... What should I do ?!?!

Did you come up with a conclusion ?

Well I can't decide for you but here's the rundown.

The problem: Since your struct tracks the unit's rgba and scale values through modifying them inside your functions, it does not update if the native SetUnitWhatever functions are used. This will obviously screw up any future use of that unit's struct, as the unit's actual values will not match the struct's.

The solutions:
1. Hook the native SetUnitWhatever functions and update the struct values accordingly. Fail-safe, but comes with a possible performance hit if used frequently (according to Jesus4Lyf).

2. Provide your own SetUnitWhatever functions that update the struct. Instruct users to replace any occurrence of those native functions with yours. Simpler, but if the user misses an occurrence of a native function or forgets, then the problem resurfaces.

[del]3. Both[/del]. This would be the best solution, but it is not worth implementing in vJASS (this would work great in cJASS). This is because in vJass the custom Set functions would trigger the hook anyways, defeating the purpose of the custom function. In cJass you can avoid this situation (call hooked functions without triggering the hook).

It's up to you =]

Gwypaas · Oct 14, 2009

Why dont you use ARGB? It's like the standard in every color management situation because it's so damn easy to use AND powerful.

quraji · Oct 14, 2009

Gwypaas said:
Why dont you use ARGB? It's like the standard in every color management situation because it's so damn easy to use AND powerful.

What?

Viikuna · Oct 15, 2009

Jesus4Lyf · Oct 15, 2009

And how is Toadcop wrong? That was my first thought also...

(Far from a standard too, mind you.)

Komaqtion · Oct 15, 2009

Ok, so should I implement ARGB then ?

And how is Toadcop wrong? That was my first thought also...

Huh ?!

System Smooth Unit Modification

No Marlo no game.

You can change this now in User CP.

No Marlo no game.

You can change this now in User CP.

Good Idea™

You can change this now in User CP.

zap

Old World Ghost

zap

Good Idea™

zap

Good Idea™

zap

You can change this now in User CP.

zap

hook DoNothing MakeGUIUsersCrash

zap

No Marlo no game.

Good Idea™

You can change this now in User CP.

Log in

The Helper Discord

Share this page

Affiliates

Network Sponsors