I have a problem with setting dcolor (or dcolour, both are just the same) through tpt.set_property(). 

dcolor is encoded as 0xAARRGGBB, where AA is the alpha (opacity) value, and RRGGBB are red, green and blue. The problem is, I can't set the alpha value greater than 7F, or let's say, I can't go beyond 0x7FFFFFFF, therefore we can't get full opacity. When any dcolor value is larger than this (like 0x80000000 or 0xFF000000), it becomes decimal -2147483648 (don't know hex for negatives).

This ONLY happens in a lua script. Not in the console, PROP tool, or deco tools.

Here's a sample lua script. Add it to the simulation, unpause, check the deco through console.
Expected color: Full black ; Result: Dark magenta (black deco transparency + element color)

elements.allocate("A", "TEST")
 elements.element(elements.A_PT_TEST, elements.element(1)) --just dust
 elements.property(elements.A_PT_TEST, "Name", "TEST")
 elements.property(elements.A_PT_TEST, "Description", "TEST")
 elements.property(elements.A_PT_TEST, "Colour", 0xBE33EF) --magenta element

function tst(i,x,y)
 tpt.set_property("dcolour",0xFF000000,i) --here be deco
end
tpt.element_func(tst,elements.A_PT_TEST)

TL;DR

 - In a lua script, setting dcolor greater than 0x7FFFFFFF fails.
 - dcolor -2147483648 results when this happens.

 - We can't set the dcolor to be fully opaque.

EDIT:

Problem solved, but just a workaround.

To set dcolor to have full opacity, add -16777216 to a 24-bit color (0xRRGGBB).

For example:

tpt.set_property("dcolour", -16777216 , id)  --pitch black
tpt.set_property("dcolour", -16777216 + 0xFF0000 , id)  --bright red (which 0xFFFF0000 or 0xFF0000 alone can't do)

@jacob1 (View Post)

It's 92.1, and I'm on Windows. I think this happened starting from version 92.0 onwards.

@jacob1 (View Post)

 Oh wait. It seems that previous versions of TPT used unsigned numbers (in this case, unsinged long), while newer versions used signed numbers (signed long). See edit from the first post, that's why adding -16777216 works. Signed long ranges from -2,147,483,648 to 2,147,483,647 (which is 0x7FFFFFFF, and that's why)

Btw, I tried the gfx functions, and gfx.getHexColor is almost the same, like:
gfx.getHexColor(0xAB,0xCD,0xEF) is the same as 0xABCDEF
but not with alpha values. getHexColor(0xAB,0xCD,0xEF,0xFF) is (0xABCDEF - 16777216).

So it's just the change in data types, eh? xD I'll just need to recompose the hex values in my autorun.lua file.