Icon will not go darker

ID:141519
 
Feb 8 2009, 6:32 pm
Code:
mob/verb
    TL()//test lighter
        SKINTONE+=16
        icon = 'Icons/Mob.dmi'
        icon_state = "Body"
        if(SKINTONE>=0)
            icon += rgb(SKINTONE,SKINTONE,SKINTONE)
        else
            icon -= rgb(SKINTONE,SKINTONE,SKINTONE)
    TD()//test darker
        SKINTONE-=16
        icon = 'Icons/Mob.dmi'
        icon_state = "Body"
        if(SKINTONE<0)
            icon -= rgb(SKINTONE,SKINTONE,SKINTONE)
        else
            icon += rgb(SKINTONE,SKINTONE,SKINTONE)


Problem description:

What should happen:
Player presses either TL or TD and h(is/er) icon should go either lighter (TL) or darker (TD). The icon will go lighter, and than will go back to its original when TD is clicked enough. However, when clicking TD to make it go darker, the icon refuses to do so.

IE:
Player clicks TL (Lighter)
Icon goes lighter
Player clicks TD (Darker)
Icon returns to normal
*Problem*
Player clicks TD (Darker) again, when icon is normal
Nothing happens.

When the icon goes lighter by 2 steps, I want the darker verb to go to 1 lighter, not revert. Same with the darker steps.

SKINTONE is defined somewhere else
Feb 9 2009, 5:25 am
 
mob/var/SkinTone=0
mob/verb
    Lighter()
        usr.SkinTone+=16
        usr.icon='Icon.dmi'
        if(SkinTone<0)   usr.icon-=rgb(abs(usr.SkinTone),abs(usr.SkinTone),abs(usr.SkinTone))
        else    usr.icon+=rgb(abs(usr.SkinTone),abs(usr.SkinTone),abs(usr.SkinTone))
    Darker()
        usr.SkinTone-=16
        usr.icon='Icon.dmi'
        if(SkinTone<0)   usr.icon-=rgb(abs(usr.SkinTone),abs(usr.SkinTone),abs(usr.SkinTone))
        else    usr.icon+=rgb(abs(usr.SkinTone),abs(usr.SkinTone),abs(usr.SkinTone))

Can't use negatives in rgb()
Feb 9 2009, 11:40 am
In response to Falacy
You shouldn't be subtracting like that, anyway, Blend() should be used instead.
Feb 9 2009, 2:19 pm
In response to Jeff8500
Jeff8500 wrote:
You shouldn't be subtracting like that, anyway, Blend() should be used instead.

How would Blend() at all help in this situation o.O at best you'd end up with the same results that you would from just using rgb(), except that Blend() would probably use up even more CPU.
Feb 9 2009, 2:59 pm
In response to Falacy
They're the same, and icon arithmetic is being phased out of the language.
Feb 9 2009, 3:55 pm
In response to Jeff8500
Jeff8500 wrote:
They're the same, and icon arithmetic is being phased out of the language.

You'd still have to use rgb(), and Blend() would most likely create 2 new icons, instead of just one.
Feb 9 2009, 5:58 pm
In response to Falacy
Blend() would create two icons? This makes no sense, Blend() returns only one icon. Unless, of course, you're referring to the icon datum, in which case, yes, he would have to make two. Eventually you will not be able to use icon arithmetic, and your code will break.
Feb 10 2009, 3:13 am
In response to Falacy
Falacy wrote:
You'd still have to use rgb()

Um, actually you never have to use rgb(), but it's just a small proc that returns a text string, so it doesn't matter so much.

and Blend() would most likely create 2 new icons, instead of just one.

How so?

Jeff8500 wrote:
Unless, of course, you're referring to the icon datum, in which case, yes, he would have to make two.

(I'm not seeing why you'd need to do this, either)

Eventually you will not be able to use icon arithmetic, and your code will break.

Well, on that one; the 'eventually' may well be almost around a decade or so until such features are removed, heh, as they're being 'phased out' for a while; maybe BYOND 5.0 or 6.0, since it's doubtful they'll suddenly remove them in a random update release; then again they may just keep it in to avoid code incompatibility, as people are still relying on it.
Feb 10 2009, 4:24 am
In response to Kaioken
Kaioken wrote:
Um, actually you never have to use rgb(), but it's just a small proc that returns a text string, so it doesn't matter so much.

What did rgb() do back in 3.x? The same thing it does now?

and Blend() would most likely create 2 new icons, instead of just one.

How so?

Blend() creates a new icon by combining 2 previous icons. If you use rgb() in place of an icon: "In addition to blending with an icon, an rgb() value may also be specified. This is treated identically to an icon of that same solid color."
I assume this means it has to create the rgb()ed icon, and then create the merged version of the two icons.

Jeff8500 wrote:
Eventually you will not be able to use icon arithmetic, and your code will break.

Yes, I'm sure they'll completely get rid of it; so that old games become completely nonfunctional, that would be genius of them.

Kaioken wrote:
Well, on that one; the 'eventually' may well be almost around a decade or so until such features are removed, heh, as they're being 'phased out' for a while; maybe BYOND 5.0 or 6.0, since it's doubtful they'll suddenly remove them in a random update release; then again they may just keep it in to avoid code incompatibility, as people are still relying on it.

I haven't seen any chatter, or any efforts to remove icon maths since I started here on BYOND several years ago. If anything I've seen improvements and additions made to the currently existing ways to perform it. Where exactly are you guys getting the idea that this is being phased out?
Feb 10 2009, 5:23 am
In response to Falacy
Falacy wrote:
What did rgb() do back in 3.x? The same thing it does now?

Yes, but without including alpha.

[...] This is treated identically to an icon of that same solid color."
I assume this means it has to create the rgb()ed icon, and then create the merged version of the two icons.

I'd assume not; the fact it's treated the same doesn't necessitate it actually creates an equivalent DMI (but making a solid-color image wouldn't be taxing anyway); I'd guess it just calculates the color and applies to the icon.

Yes, I'm sure they'll completely get rid of it; so that old games become completely nonfunctional, that would be genius of them.

They wouldn't really be; old games wouldn't tend to be suddenly recompiled in a new version (in which case the programmer could also fix the code), and games that were already compiled using icon arithmetic will still have their bytecode intact, which will likely end up still functioning (at least when executed by a DS version that is compatible with the world version).

I haven't seen any chatter, or any efforts to remove icon maths since I started here on BYOND several years ago.
[...] Where exactly are you guys getting the idea that this is being phased out?

Then shame on you, since you haven't even read the Reference entry for icon arithmetic for full several years in which this info was there. =P

If anything I've seen improvements and additions made to the currently existing ways to perform it.

Improvements to icon arithmetic? :S Where? The only things I'd consider that are improvements to the /icon datum, which is essentially the evolved, newer form of it.