So good to be back. Since we don’t have access to the casenum data, what is the “fix” for getTunerVolume? Are we going to get more reliable return data?
Release notes for build 2014. through 2014.2185
Fix getTunerVolume() for casenum 25702
Transitions with easing.continuousLoop are broken. The value, being transitioned, goes bananas through zero.
And I need a parameter in transition call to disable setting transitioned variable to the end value after the transition ends.
The way it’s now, easing functions are not honored and I can’t make cool effects with custom easing functions.
For example I need an enemy walking left and right continuously with sine easing. I prepare my easing function and it performs perfectly, and at the end of the cycle enemy returns to the starting point. But due to this transition behaviour a flickering occurs between each iteration. Enemy jumps from starting point to end point and then back to starting point. Very annoying.
Please please fix the problem with rounded rectangles.
This little code should result in 2 identical squares, except upper square has rounded corners. Instead it produces this:
[lua]-- Resize a rounded rectangle, output should be a square 100 by 100
local roundedRect = display.newRoundedRect(display.contentCenterX, 150, 25, 25, 5)
roundedRect.width, roundedRect.height = 50, 50 – Try commenting out this line to see difference. Size will be correct but corners not rounded correctly
roundedRect.width, roundedRect.height = 100, 100
– Correct 100x100 rect for comparison
local rect = display.newRect(display.contentCenterX, 350, 100, 100)[/lua]
Just paste into main.lua and run to see it.
- Device All
- OS/Version All
- Not worked since G2 was released. Case 38847, reported 3,5 months ago. I
jonjonsson, this is not a bug. It works that way by design.
You have to create a big rounded rect first and scale it down if you need different sizes. Or recreate the rect each time you want to resize it.
So I resize a rounded rect to 100x100 and get a 200x200 instead is not a bug? What is the reasoning? Worked fine before G2 as well.
Ah, you are talking about the sizes. Sorry. Yeah, that’s not right. xScale, yScale work correct I assume?
Thanks for the help. I’m not seeing any problem with xScale, yScale. But yeah the corners do not look nice after a scale.
Hey everyone. Walter asked specifically for regression bugs. These are bugs that were not in 2100 but are currently in 2187.
If you are going to report a bug in this thread it needs to a) be a regression bug. This isn’t an open time to ask that a bug you need fixed to be fixed. If we tackle all the bugs we won’t be putting out a release build any time soon. Please only regression bugs. We will work on non-regression bugs after the release.
If you are going to report a bug in this thread include all four of Walter’s requested information pieces (and the 5th bonus one).
Thanks
Rob
But some of the issues above are regression bugs from before 2100… what about them? Bugs not found in G1 but now present in G2… Walter doesn’t want to know about them?
Hi Rob, all of bugs about transitions appeared between public release 2072 and public release 2100, I expected to have it fixed in the next public release, and, since this post is about the next public release, that’s why I wrote about them. If you only want to know about regression bug between 2100 and 2187, well, this is not, because the transitions works in 2187 as bad as it does in 2100 (sorry).
If you are still interested in fix this bug here is the information with the steps walter asks for:
1. Devices , all of them
2. OS , all of them
3. Sample files : https://www.dropbox.com/s/8xww9vnd1medyom/Bug.zip
4. Description :
This sample file uses storyboard to represent the problem with transitions, onComplete and transitions cancel because it was the only way I can reproduce it. You will see the enterScene event firing twice, if you remove the fade transition changing scenes it works fine, if you comment the transition.cancel line, it works fine, if you add a timer.performwithdelay (even with 0 time) before calling transition.cancel it works fine.
5. Daily Build: 2085, (with 2082 and before works perfectly).
There are other bugs with transitions API, all of them seem to appeared in 2100, I provided you links to the forum posts where other Corona users reports them, and sometimes, corona staff answers saying they are investigating it…
Thank you for your time and your help with this.
local webView = native.newWebView(0, 0, display.contentWidth, display.contentHeight) webView.x = display.contentWidth \* 0.5 webView.y = display.contentHeight \* 0.5 webView:request("http://www.upworthy.com/matt-damon-asked-a-cheery-13-year-old-what-shell-do-with-her-free-time-her-answer-gave-him-pause?c=reccon1")
Above code launches a webView and loads a webpage with a YouTube video embedded.
If you run it in iOS devices (iPhone/iPad), the video cannot be played. (After you click on play, the loading indicator spins a bit, and then nothing happens)
The video can be played in Simulator & Android devices.
I believe I played YouTube video in a webpage before with an iOS device.
Is this a regression bug?
@joe528 does it work with build 2100? If it works with 2100 but not now, it’s a regression bug.
@ksan, we want to know about all bugs, but by filing them in the bug reporting mechanism. We think 2187 is at a point where it can be released. If you think about people who only use public builds, we are not looking for bugs they already have but bugs that would be put upon them they don’t currently have. Does that make sense?
@GulliermoFG, it sounds like this is an issue that folks running 2100 already have, so it would not be the kind of bug Walter is looking for.
Rob
With the latest build 2187, newLine StrokeWidh is no longer reliable. Was working perfectly with 2156, 2179 and 2100
We are drawing line in our list and now line height is no longer the same. Even if we ask 2 pixels, it is sometimes 3, sometimes 2. Nothing in our code has changed. Has always been working before. bet when we installed on 2187, kaboom. Problem in the sim, on android (every single devices we have) and on all iOs devices.
@GulliermoFG, thanks for the data and a complete zip of your project! We’re looking into it.
@nmichaud, we need a test case before I can escalate it.
Something along the lines of what @GuillermoFG provided would be greatly appreciated, as we can reproduce what you’re seeing, and focus on debugging rather than burning cycles second-guessing what exactly your situation is.
@Walter : Here you go :
- With the latest build 2187, newLine StrokeWidh is no longer reliable. Was working perfectly with 2156, 2179 and 2100
Devices, all of them
-
OS, all of them
-
Sample files : https://dl.dropboxusercontent.com/u/6274808/bugline.zip
Hope this help, because this is a major showstopper for us.
That helps, but I still need a description of how to reproduce the issue?
For example, I just compared 2187 against what the version you saw it working (2179), and I don’t see any difference in the width of the green line.
Simply run the code under a galaxy s3, and you will see the list with the line drawn with different strokeWidth. I even put a screenshot to show you. I simply run it under our S3, take a screenshot and that’s it. It is is to reproduce.
I have a problem for use social plugin for Twitter! When i am trying to share image via twitter using social plugin. i got error image could not be loaded.
i am pro subscriber of Corona.
i am using Build: 2014.2170
Thanks.
@jonjonsson, thanks for the detailed info. Looks like we’ve got this in the system as case 28847. We’re looking into this.