[Solved] GetUnitRed/Green/Blue??

[WereElf]

Is there a way to get unit's coloring values?
I have a fading system, which ruins unit's coloring, and I don't know of any way to remember unit's colors and give them back later...

 

[FUJI]

Theres a snippet or system that is used to get the properties of a unit such as animation and as well as it's color also... but I do not remember where did I see that :/

 

[DracoL1ch]

from jass - no

 

[KILLCIDE]

There is no way to find the default value of a unit's vertex color. The best way to do it is to save the unit-type's vertex colors in a hashtable and retrieve it that way. I believe Magtheridon made a snippet that works similarily.

EDIT:

After reading through the thread, there is also this system.

 

[Wietlol]

ODE would do but it is bugged in 1.27 (it is open source though, so if someone would like to fix it, then he is welcome to do).

 

[Dr Super Good]

This is where SC2 is so good. One can just create a named actor to do the recolour and then remove that actor when you want to restore the colour and the colour then restores to whatever it should correctly be.

In WC3 you will need some tool to read all the tint values from the slk and object editor files and store them in data structures like arrays or hashtables. You then need to simulate all your colouration stacking mechanics with JASS triggers.

 

[Pyrogasm]

This is where SC2 is so good. One can just create a named actor to do the recolour and then remove that actor when you want to restore the colour and the colour then restores to whatever it should correctly be.

In WC3 you will need some tool to read all the tint values from the slk and object editor files and store them in data structures like arrays or hashtables. You then need to simulate all your colouration stacking mechanics with JASS triggers.

I think one of Earth-Fury's old tools used to be able to read values from .slk files, but honestly who knows if any of that code still runs. WereElf could made a struct that stores the current RGB values for a model and then write wrappers to change them that writes the data to the appropriate struct (linked to the unit with a storage system, hash, or looked up using brute force search on a bigass array) before they get altered . If you only have a few units with colors pre-set in the object editor this is probably the quickest solution, but it will disallow you from setting unit colors in the object editor (you have to change the RGB values to whatever color you want when the unit enters the map, for example).

You could also just write your own lookup table for every unit's default RGB values if they're not 255/255/255/0 initially like this and just brute force search for it (not efficient but works/doesn't matter if you're not doing this too often)

globals
    RGBA array UnitColors
    integer TotalUnits //How many different unit types there are in your game whose RGB values are stored by the system
endglobals

struct RGBA
    integer uid  //The rawcode of the unit this RGBA profile corresponds to
    integer R
    integer G
    integer B
    integer A

    method create takes integer UID, integer R, integer G, integer B, integer A
        //whatever is necessary
    endmethod
endstruct

...

//Init function looks something like this:
function Init takes nothing returns nothing
    UnitColors[1] = RGBA.create('Hpea',0,0,255,255)
    UnitColors[2] = RGBA.create('Hfoo',130,193,255,200)
    //etc....
    //This could be automated into a loop or with textmacos
endfunction
...

function GetOriginalRGBA takes integer UnitID returns RGBA
    local integer i = 0

    loop
        exitwhen i >= TotalUnits
        if UnitColors[i].uid == UnitID then
            return UnitColors[i]
        end
        set i = i+1
    endloop

    //If we get here we didn't find a match in our stored array
    return RGBA.createNew() //or some method
endfunction

I would probably initialize it (probably) with a whole bunch of textmacros and ObjectMerger calls to save typing shit out a billion times. Ultimately you still have to cache all the data beforehand and with a willingness to involve some vJASS that makes it all much easier to simplify and compact.

 

[Wietlol]

(You used "unit" instead of "integer".)

In that case, I would recommend a hashtable as looping through hundreds of integers would be much more cpu heavy.
call SaveInteger(.TABLE, unitId, 0, this) // to store the instance at RGBA.create()
local thistype this = LoadInteger(.TABLE, unitId, 0) // to load the instance at RGBA.getOriginalRGBA()

(Units also dont have an alpha from the OE iirc.)

 

[WereElf]

Thanks for all the answers.
I think I will save the unit's RGB value(s) into a hashtable, but instead of a struct - I will just save them as single integer. For example 255200100 would be 255 R 200 G 100 B.
And I will use the following formulas to get each value: R = RGB/1000000; G = RGB/1000 - (RBG/1000000)*1000; B = RGB - (RGB/1000)*1000

 

[Flux]

Thanks for all the answers.
I think I will save the unit's RGB value(s) into a hashtable, but instead of a struct - I will just save them as single integer. For example 255200100 would be 255 R 200 G 100 B.
And I will use the following formulas to get each value: R = RGB/1000000; G = RGB/1000 - (RBG/1000000)*1000; B = RGB - (RGB/1000)*1000

You could also save it represented by a hexadecimal, it is easier in my opinion. Example: Save integer, 0xFFF060 then extraction of each color would just be the same method, but just a different denominator.

 

[Wietlol]

Use better numbers:

function toInt takes integer red, integer green, integer blue returns integer
    return red + green*256 + blue*256*256
endfunction
function getRed takes integer data returns integer
    return ModuloInteger(data, 256)
endfunction
function getGreen takes integer data returns integer
    return ModuloInteger(data/256, 256)
endfunction
function getBlue takes integer data returns integer
    return ModuloInteger(data/(256*256), 256)
endfunction

Not because it is better, but because it is cool.