WARNING: Attempt to set object.alpha to 1.00667

Solar2D Daily Builds and Public Releases
1

This is a possible bug.

I get the following warning:

WARNING: Attempt to set object.alpha to 1.00667 which is outside valid range. It will be clamped to the range [0,1]

The warning happens on the following line of code:

transition.to(score_label, { time=300, alpha=0})

Considering this should move the alpha from 1.0 to 0.0, it seems to be perhaps setting it above 1.0 for the initial value in the transition. Here’s the declaration of score_label:

local score_label= ui.newLabel{
bounds = { x, y, 30, 10},
text = marble_score[marble_score_index][3],
font = “AmericanTypewriter-Bold”,
textColor = {255, 255, 0 },
size = 18,
align = “center”
}

I originally had textColor={255, 255, 0,255 } which produced the same warning.

Not a big deal since the code runs fine, but I hate warnings. [import]uid: 8776 topic_id: 5027 reply_id: 305027[/import]

2

that’s ok. ignore it. we should have that removed in the next drop. internally, it does not happen on the phones as the binary has the clamped values…

c [import]uid: 24 topic_id: 5027 reply_id: 16491[/import]

3

Carlos, I started getting these messages with the daily builds (though it could also have been a change I made in my code). Still getting it with latest build 301. The value changes every time I run it:

WARNING: Attempt to set object.alpha to -0.3 which is outside valid range. It will be clamped to the range [0,1]
WARNING: Attempt to set object.alpha to -0.14 which is outside valid range. It will be clamped to the range [0,1]

So if it was just a rounding error, you’d think it would round the same way all the time.
[import]uid: 9905 topic_id: 5027 reply_id: 23768[/import]

4

is ok . ignore. they are warnings… they are not on device builds

c. [import]uid: 24 topic_id: 5027 reply_id: 23769[/import]

5

Ok, will tryyyy to ignore them. Hard for me! :slight_smile: [import]uid: 9905 topic_id: 5027 reply_id: 23773[/import]

6

It seems to happen when you set alpha then do a transition right away. I reported the bug before.

It IS a bug tho. If for example you have:

– apha is curently 0.4

object1.alpha = 0.7
transition.to (object1, {time = 600, alpha = 1})

The object1.alpha=0.7 doesnt take effect right away and so the transtion uses the old value of 0.4. The transition creates steps from 0.4 to 1 over 600 ms - lets say 0.1 every 100ms.

The object1.alpha takes effect after some step… lets say after 250ms… we have:

t = 0, alpha = 0.4
t = 100, alpha = 0.5
t = 250, alpha = 0.7 (object1.alpha = 0.7 took effect)
t = 300, alpha = 0.8
t = 400 , alpha = 0.9
t = 500, alpha = 1.0
t = 600, alpha = 1.1
This transition wasnt actually a smooth transition from 0.7 to 1 over 600ms as expected!

you can avoid this behaviour by doing:

transition.to (object1, {delay = 1, time = 599, alpha = 1})

the delay = 1 releases time for the alpha statement to take effect.

[import]uid: 8872 topic_id: 5027 reply_id: 23818[/import]

7

Hey, thanks Kam187, and nice meeting you on IRC today.

I found a few places where I’m doing this in my code and added your delay = 1. Seems to have cleared up the warning. [import]uid: 9905 topic_id: 5027 reply_id: 23835[/import]

8

Cool, glad it helped :slight_smile: Those warning annoyed me too!

Just remmeber keep the total the same, eg delay ‘1’, time ‘300-1’ for 300, as a habit. Otherwise you may time things to 300 and get wierd results since its actually taking 301 ms. The 300-1 rather than 299 lets u see at a glance that its a 300 transition. Helps save mistakes that way! [import]uid: 8872 topic_id: 5027 reply_id: 23877[/import]

9

Good point. In the instances where I made the change, timing wasn’t critical, but having the 299 as a reminder makes sense. [import]uid: 9905 topic_id: 5027 reply_id: 23886[/import]