System Smooth Unit Modification

[Jesus4Lyf]

I don't think so. I might not even use it at all if you did.

 

[quraji]

Ok, so should I implement ARGB then?

I don't think so. I might not even use it at all if you did.

Yeah, I wouldn't bother.

Maybe if you using Zinc or cJass and you could define the methods to use the ARGB structs if the user already had the library, but otherwise don't force them.

 

[Komaqtion]

Well, I don't know (And don't really intend to learn) cJASS or Zinc... Is it recommended ?

Also, I've fixed the bug with the test spell... And also made another one (Nearly finished )

What else was it you wanted me to do ?
Or can this get reviewed soon ?

EDIT: Ok, just came up with an idea... Maybe you'd like to be able to queue up the modifications, so that if the unit is currently scaling and you scale it again, you can queue the last scale so that when the first one is done, the next one starts ?
(Hope you know what I mean )

Anyone would want this (I would XD), and maybe wanna give me a hand to do it ? :S

 

[Jesus4Lyf]

>cJASS or Zinc... Is it recommended ?
It is not actually allowed, let alone recommended.

You'll likely strike logic issues with queuing. Between queued and non-queued modifications. (I wouldn't bother, personally.)

I don't see a nice way to make it make sense.

 

[Komaqtion]

Hehe XD Ok, then...

Well, review any1 ?

 

[quraji]

Well, I don't know (And don't really intend to learn) cJASS or Zinc... Is it recommended ?

vJass pretty much has everything you need, so if you're not particularly itching to learn a new syntax don't worry about it. But if you're bored, it can be fun
I myself am having a bit of fun with cJass defines, and Zinc with it's interesting syntax and static if

>cJASS or Zinc... Is it recommended ?
It is not actually allowed, let alone recommended.

You sound like a nazi You're allowed to use it, just if you submit it you need to couple it with a vJass alternative (as it is the standard here at the moment). Although Zinc will probably be accepted by itself soon (especially since JassHelper compiles it anyways). cJass is still struggling a bit but it seems a handful of people are using it.

Ok, just came up with an idea... Maybe you'd like to be able to queue up the modifications, so that if the unit is currently scaling and you scale it again, you can queue the last scale so that when the first one is done, the next one starts ?

Interesting idea. Could be a little tricky to implement nicely but would be cool. I'll see if I can come up with something.

 

[Vexorian]

vJass supports static ifs just like Zinc. So there would be no need to jump to another ship just for them.

ARGB can behave as an optional module somehow, unfortunatelly this makes it struct-only when you just want it as an optional requirement. it would not surprise me if you could do some static if stuff to make it an optional requirement for this though.

It usually works like this:

struct mystruct
    method recolor takes integer a, integer r, integer g, integer b returns nothing
    endmethod
    implement optional ARGB
endstruct

This way if the map has the ARGB library, your struct gains a method recolorARGB() that takes ARGB arguments.

I guess you could pull out something like this:

function somethingSomethingByARGB takes integer x returns nothing
    static if ( LIBRARY_ARGB) then
           call bleh ( ARGB(x).red, ARGB(x).green, ARGB(x).blue ) ...
    else
           debug call BJDebugMsg("somethingSomethingByARGB called but ARGB is not in the map!")
    endif
endfunction

(Not saying that you should, I don't really get where in your library would it fit to add ARGB support).

PS: set col = 0xFF448909 is incredibly easier to use than col = something.create(0xFF448909) ... col.destroy(). ARGB is meant so that the user can have constants such as constant ARGB initialColor = 0xFF450023 , most people are already quite used to such hex codes due to tooltips, so it is easier that way... It is not standard but it is great at solving this color setting issue that is so common.

Regardless of whether you use ARGB or not or whatever, I don't really get why your library takes reals, and your example uses negatives... Pretty much in Jass we are used to integers 0-255 for red, green , blue...

 

[quraji]

>vJass supports static ifs just like Zinc. So there would be no need to jump to another ship just for them.

No [ljass]//! zinc[/ljass] required? Cool.

>...I don't really get why your library takes reals, and your example uses negatives... Pretty much in Jass we are used to integers 0-255 for red, green , blue...

Yeah, I wouldn't mind if there were a couple functions that faded to an aarrggbb endpoint instead of having to modify the values by a certain amount.

 

[Komaqtion]

Yeah, I wouldn't mind if there were a couple functions that faded to an aarrggbb endpoint instead of having to modify the values by a certain amount.

Yeah, I'll add too, that's how I wanted it in the first place

And I'll use integers instead of real then

But how would I go about doing this:

PS: set col = 0xFF448909 is incredibly easier to use than col = something.create(0xFF448909) ... col.destroy(). ARGB is meant so that the user can have constants such as constant ARGB initialColor = 0xFF450023 , most people are already quite used to such hex codes due to tooltips, so it is easier that way... It is not standard but it is great at solving this color setting issue that is so common.

? :S:S

 

[quraji]

But how would I go about doing this:

Vex invented that struct where it doesn't actually hold any values...but it's id is the value. So instead of have a struct "color" hold integers red, green, blue, alpha...it contains no data, but the struct id holds the aarrggbb code in the form of hex.

So if you choose, you can optionally support this through one of the methods Vex showed below (optional module, or static if).

 

[Komaqtion]

Well, could you give me an example ? :S
Sorry but still don't understand XD

And also, should I add the "specific-value-change" to all three scale/fade and timescale, or just timescale and scale ? :S

Because if I add it to fade, it's going to get very manu arguments... :S

Here's how I have scaling atm:

    struct SmoothScaleChange
    
        private integer ticks
        
        private real increment
        
        private unit u
        
        private method periodic takes nothing returns boolean
            set this.ticks = this.ticks - 1
        
            call ModifyUnitScale( this.u, this.increment ) // This will save the scale of the unit in a struct using AIDS...
            
            debug call BJDebugMsg( "SUM Scaling: " + R2S( Appearance[ this.u ].scale ) )
            
            if this.ticks <= 0 then
                call this.destroy()     // When ticks becomes 0 (Meaning that the scaling is done) destroy it ! <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin    :D" loading="lazy" data-shortname=":D" />
                
                return true
            endif
            
            return false
        endmethod
        
        implement T32
        
        static method create takes unit Scaler, real Time, real scaleMod, real endScale returns thistype
            local thistype this = thistype.allocate()
            local real scale = GetUnitScale( Scaler )
            local real scalechange = endScale - scale
            
            set this.u = Scaler                                        // Which unit to scale XD
            
            // How much the scale will change each PERIOD...
            
            if scaleMod == 0.0 then            
                set this.increment = ( ( scalechange * T32_PERIOD ) / Time )
                set this.ticks = R2I( scalechange / this.increment )          // How many times the timer must fire...
            else
                set this.increment = ( ( scaleMod * T32_PERIOD ) / Time )
                set this.ticks = R2I( scaleMod / this.increment )          // How many times the timer must fire...
            endif
            
            call this.startPeriodic()
            
            return this
        endmethod
        
    endstruct

Is that good ? :S

 

[Immolation]

The documentation is REALLY messy, and you don't explain really well how to use the color/alpha functions.

 

[Komaqtion]

Oh, ok... Will update it too then

But, I really want to know if I should do those changes above to the fading part too...
Because if I do it, then that struct 's create method will get alot of arguments :S

Your thoughts ?

 

[Immolation]

1) In your documentation you name some functions that don't exist
2) Your example about changing color/alpha value is messy. Try to make it more simple.

Also, question:
What happens if you increase a unit's scale by and then decrease it while it is still increasing?

 

[quraji]

Komaqtion,
I whipped up an example of a way to queue the modifications. I did it really quick before class so it doesn't have comments or anything (it tested to work, but there's probably a bug somewhere). I can make a neater/commented version if need be.

Attached is a map with only the SmoothScaleStruct and its queue example and a test script. Press 'esc' in game to see it in action.

EDIT: I tested it again and it does seem to bug if you press 'esc' a ton. Sometimes the footmen stop scaling and I even got one that somehow scaled up a HUGE amount and stuck there (you could only see his legs on screen). Weird. Nonetheless, the example still gives you an idea how to go about it.

 

[Komaqtion]

Thanks, quiraji !!!
Well, it's 10 o'clock in the evening here so I'll probably test it tomorrow, and I'll look into the code and see if I can find the bug too

(Hopefully I'll be able understand the code without comments )

 

[Uberplayer]

library UnitAppearance requires AIDS
    
    struct Appearance extends array
    
        //! runtextmacro AIDS()
        
        real scale
        
        real alpha
        real red
        real green
        real blue
        
        private method AIDS_onCreate takes nothing returns nothing
            set this.scale = 1.00
            
            set this.alpha = 255.00
            set this.red = 255.00
            set this.green = 255.00
            set this.blue = 255.00
        endmethod
    
    endstruct
    
    function ModifyUnitScale takes unit whichUnit, real increment returns nothing
        local Appearance this = Appearance[whichUnit]
        
        set this.scale = this.scale + increment
        call SetUnitScale(whichUnit, this.scale, 0.00, 0.00)
    endfunction
    
    function ModifyUnitVertexColor takes unit whichUnit, real alphaIncrement, real redIncrement, real greenIncrement, real blueIncrement returns nothing
        local Appearance this = Appearance[whichUnit]
        
        set this.alpha = this.alpha + alphaIncrement
        set this.red = this.red + redIncrement
        set this.green = this.green + greenIncrement
        set this.blue = this.blue + blueIncrement
        call SetUnitVertexColor(whichUnit, R2I(this.red), R2I(this.green), R2I(this.blue), R2I(this.alpha))
    endfunction

endlibrary

//! zinc

library SmoothUnitMod requires T32, UnitAppearance
{

//===========================================================================

    type ModificationFunction extends function(unit, real);

    function SetScale(unit whichUnit, real increment)
    {
        ModifyUnitScale(whichUnit, increment);
    }

    function SetA(unit whichUnit, real increment)
    {
        ModifyUnitVertexColor(whichUnit, increment, 0.00, 0.00, 0.00);
    }

    function SetR(unit whichUnit, real increment)
    {
        ModifyUnitVertexColor(whichUnit, 0.00, increment, 0.00, 0.00);
    }

    function SetG(unit whichUnit, real increment)
    {
        ModifyUnitVertexColor(whichUnit, 0.00, 0.00, increment, 0.00);
    }

    function SetB(unit whichUnit, real increment)
    {
        ModifyUnitVertexColor(whichUnit, 0.00, 0.00, 0.00, increment);
    }

//===========================================================================

    public struct SmoothMod
    {

        private unit whichUnit;
        private real increment;
        private ModificationFunction modFunc;
        
        //===========================================================================

        static method scale(unit whichUnit, real duration, real value)
        {
            SmoothMod sm = SmoothMod.allocate();
            
            sm.whichUnit = whichUnit;
            sm.increment = value / duration * T32_PERIOD;
            sm.modFunc = SetScale;
            
            sm.ticks = R2I(duration / T32_PERIOD);
            sm.startPeriodic();
        }
        
        static method alpha(unit whichUnit, real duration, real value)
        {
            SmoothMod sm = SmoothMod.allocate();
            
            sm.whichUnit = whichUnit;
            sm.increment = value / duration * T32_PERIOD;
            sm.modFunc = SetA;
            
            sm.ticks = R2I(duration / T32_PERIOD);
            sm.startPeriodic();
        }
        
        static method red(unit whichUnit, real duration, real value)
        {
            SmoothMod sm = SmoothMod.allocate();
            
            sm.whichUnit = whichUnit;
            sm.increment = value / duration * T32_PERIOD;
            sm.modFunc = SetR;
            
            sm.ticks = R2I(duration / T32_PERIOD);
            sm.startPeriodic();
        }
        
        static method green(unit whichUnit, real duration, real value)
        {
            SmoothMod sm = SmoothMod.allocate();
            
            sm.whichUnit = whichUnit;
            sm.increment = value / duration * T32_PERIOD;
            sm.modFunc = SetG;
            
            sm.ticks = R2I(duration / T32_PERIOD);
            sm.startPeriodic();
        }
        
        static method blue(unit whichUnit, real duration, real value)
        {
            SmoothMod sm = SmoothMod.allocate();
            
            sm.whichUnit = whichUnit;
            sm.increment = value / duration * T32_PERIOD;
            sm.modFunc = SetB;
            
            sm.ticks = R2I(duration / T32_PERIOD);
            sm.startPeriodic();
        }
        
    //===========================================================================

        implement T32;
        
        private integer ticks;
        
        private method periodic() -> boolean
        {
            this.ticks = this.ticks - 1;
            if (this.ticks <= 0)
            {
                this.destroy();
                return true;
            }
            else
            {
                this.modFunc.execute(this.whichUnit, this.increment);
                return false;
            }
        }
        
    }

}

//! endzinc

You could get some ideas from this. (notice that my Unit Apperance uses reals instead of integers, so increasing/decreasing color by less than 1 is possible)

 

[Komaqtion]

WHY ZINC !!!!!!!!!!!

And it's not even supported yet !
Please do it in vJASS...

 

[Uberplayer]

Zinc because it's plain awesome.

And I do not care if Zinc is not supported for resources. I am not submitting this. Plus, I didn't write this for you to copy paste.

I don't know why I started writing this. Immolation had some problems with yours, so perhaps that's reason. I thought your implementation (struct per modification) and structure (code scattered all over) suck badly, so I made my own.

I didn't really like struct per modification type so I used static method per modification type instead. And also you have functions which no sane vJasser would ever use .

What are the debug messages doing there? No one would ever know where those messages are coming from.

That horrible SUM text in the header is horrible. It really is .

 

[Komaqtion]

Well, sorry... Didn't mean to sound angry but for the first, I don't understand (And don't plan on learning to understand) Zinc... So I wouldn't know even what that Zinc script does.
And also, because of me not knowing Zinc, then to use that script I'd have to copy&paste it, meaning that I would be submitting a Zinc resource, and not getting this approved (Since it's not supported...)

And, then to the documentation... I don't really want to update that until I have all the functions done, so yet again I ask you:
Should I add the "specific-value-change" to all three scale/fade and timescale, or just timescale and scale ? :S

And is there something else you'd wish to see in this library ?

EDIT: Also, quirajii, your trigger seems to (Even if I just scale once) give me the debug error:
"T32 ERROR: Struct #0 had startPeriodic called while already running!"

And then, when I do even more scaling, like 10 - 20 at one time, WC3 crashes, but I get many of these errors before it freezes:
"Double free of type: SmoothScaleChange"

I now noticed that WC3 doesn't entirely freeze, just that I can see a HUGE footman (The units which are scaling) becoming even bigger, but it "hacks" like &%@$ !!...

Any ideas on how to fix it ? :S