I don’t use timer.performWithDelay and still get the messages once in a while. [import]uid: 5712 topic_id: 1885 reply_id: 8885[/import]
I’ve found this happens when you set the alpha and then perform a transition right after it… eg::
object.alpha = 0.6
transition.to (object, {time=1000, alpha = 1})
You can usually avoid it by adding minimal delay…
object.alpha = 0.6
transition.to (object, {delay=1, time=999, alpha = 1})
I’ve made a habit of doing this for all alpha transitions. It seems like the initial alpha setting statement ‘object.alpha = 0.6’ doesn’t take effect right away. The transition starts and sets its steps with the original value (for example 0), and some time in the transition the object.alpha = 0.6 takes effect. Once all steps in the transition have been applied the end alpha value ends up > 1
So the transition calculates on alpha 0 -> 1, but before the transition is complete the alpha gets set to 0.6 which potenitally leaves the alpha anywhere up to 1.6. Because the warning generates at the first ‘step’ above 1, it stops at 1 + one transition step
[import]uid: 8872 topic_id: 1885 reply_id: 18912[/import]
@Tom, didn’t this ever get fixed? I noticed it just now on an alpha transition when using a performWithDelay (as you describe above).
[import]uid: 8353 topic_id: 1885 reply_id: 24024[/import]
@thegwill, I’m sorry to say it haven’t been fixed yet. It’s still on our bug list. [import]uid: 7559 topic_id: 1885 reply_id: 24044[/import]
Is there a way to disable WARNING output? TextCandy seems to be outputting this clamping alpha warning, and for the time being it would be nice to disable this. [import]uid: 4596 topic_id: 1885 reply_id: 37961[/import]
thought it was fixed on daily build…
grrrrrrrrrrrrrrr
c. [import]uid: 24 topic_id: 1885 reply_id: 37962[/import]
The Alpha warning bug was generated when changing the alpha property of an object in a transition.to call. This was resolved in build 484. I just verified that Daily Build 521 does not have the bug.
The Alpha warning will still come up if the alpha property is set to a value less than 0.0 or greater than 1.0.
If there is another test case (a few lines of code, please) that causes this warning, please file a bug report. [import]uid: 7559 topic_id: 1885 reply_id: 37985[/import]
Still there with build 775 …
Console is just impossible to read … [import]uid: 9328 topic_id: 1885 reply_id: 98573[/import]
can’t you set up a math.floor math.ceil to clamp the values…
thought this was fixed… yikes…
c
[import]uid: 24 topic_id: 1885 reply_id: 98577[/import]
The alpha clamp problem was fixed with the Corona transition code a year ago. I’ve seen the problem come up with third party transition routines that Ansca doesn’t have any control over.
If there still is an alpha problem with Corona-supplied APIs, I would like to see sample code that demonstrates the problem. [import]uid: 7559 topic_id: 1885 reply_id: 98669[/import]
Well I have different samples leading to that:
local function subPulseObject( self, alphaS, dur, scaleE )
if v.screen == 1 then
scaleE = 0.35
alphaS = 0.5
dur = mRandom(2500,3000)
else
scaleE = 0.15
alphaS = 1
dur = mRandom(1500,2000)
end
self.alpha = alphaS;
self.xScale = scaleE;self.yScale = scaleE;
self.tween = transition.to(self, {time = dur, alpha = 0, xScale=scaleE\*2,yScale=scaleE\*2,transition=easing.outExpo, onComplete =
function() subPulseObject(self,alphaS, dur, scaleE) end})
end and this one :
local function subBlinkField(event)
local s,d,a
for i=1, 7 do
s = mRandom(n)
d = mRandom(500)
a = (mRandom(8)+2)\*0.1
transition.to(stardots[s],{ time = d, alpha = 0, transition=easing.inExpo})
transition.to(stardots[s],{ delay = d, time = mRandom(400), alpha = a, transition=easing.inExpo})
end
end
[import]uid: 9328 topic_id: 1885 reply_id: 98716[/import]
Please file a bug report with a complete set of project files demonstrating the problem to help use understand the problem.
Thanks,
Tom [import]uid: 7559 topic_id: 1885 reply_id: 101373[/import]
it show up when using the gtween class also
edit: I’m using the last stable build right now [import]uid: 7911 topic_id: 1885 reply_id: 101376[/import]
Ok Tom, I made a very simple 25 lines of code sample that always does the issue.
I try to upload the bug. [import]uid: 9328 topic_id: 1885 reply_id: 102133[/import]