Codea 2.3.8 (82)

Just loaded the latest version 2.3.8 (82) of Codea. Report any problems here.

Is this a public beta build? TestFlight is only showing build 81 for me.

It’s an update thru the App Store for normal Codea, not a beta thru TestFlight. My latest beta shows as 2.5 (80).

Oh… well then. :stuck_out_tongue:

yes, I didn’t notice it too, because app store did not report the update of the ‘original’ version…
thank you for the reminder :slight_smile:

@Simeon The find/replace works a lot better now. I was going to suggest an update to it awhile back, but it’s nice to have something updated before it’s requested.

hmmm, it has not shown up as an update. The app store indicates i have to purchase the 2.3.8 version?

@piinthesky If you have the beta version, you have to go to the App Store, purchased, and reload that version. Then you can do the update.

If you put a color() function in two lines, all the other color() statements after this can not show the color picker UI, pls see the screenshot below:

<img src=“” /img>

Try putting the newer color selectors into a new line, it will then work.

@TokOut thank you for the advice, but I think it is a bug.

I’m going to copy paste what I wrote as a seperate discussion here:

I tried out the new update and I have some problems! Codea freezes and quits when I try to edit shaders from the code. Also going through the lua-code has become slow and laggy. Otherwise nice update!

@MMGames can you elaborate on going through the Lua code becoming slow and laggy? I was a bit worried about this, what device are you using?

Will try editing shaders from code to fix your problem there.

@dave1707 thank you! @se24vad also suggested I keep the last search result from Find/Replace even when you dismiss and re-activate the option. I’ll look into doing that too.

Hi @Simeon Can you see my words? It seems that my suggestion was transparent?or unseen? :smiley:

And pls see the below, the color picker button was separated from the corresponding color(), they are in different lines:

<img src=“” /img>

@Simeon Something I just noticed. Undo doesn’t work across tabs. If I delete something in a tab and go to another tab and delete something, undo will work in the tab I’m in, but won’t undo anything in the other tab even if I switch to it. It doesn’t work in version 1.5 either, so it’s never worked. Might be an irritation to someone at some point.

@Simeon I am using the iPad air 1. When opening a project it loads for like 0.5-1 seconds before showing the code. When I open a tab inside a project the same thing happens. The movement when scrolling through the code lags behind, it jumps some distances instead of the smooth movement before. Hope it helps!

@Simeon I’m running version 82 on an iPad Pro 1 and when I open a project (Cargo-Bot), it loads almost instantly. When I open a tab, it opens almost instantly and the scrolling appears smooth. I loaded version 82 on my iPad Air 1 and tried loading Cargo-Bot. It didn’t load as fast as on the iPad Pro, but it was still fast, less than 1/2 second. Same with opening different tabs and scrolling. @MMGames Do you have a lot of other apps running along with Codea. Have you tried shutting down your iPad and starting it again with just Codea running.

@dave1707 Yes, I have tried to restart and only open codea, but it is still the same. I have never had this problem before, even with other applications in the background

@MMGames After trying Cargo-Bot several times, one thing I noticed was opening a tab the first time took maybe longer than .5 sec, but not a second. Opening the same tab a second time was a lot faster. As for scrolling, I might have seen the scrolling problem, but maybe it was just the way I was dragging my finger. I’m not sure. I’ll keep trying to see if I can get it to happen. Maybe I just have to catch it at the right time. Maybe this is similar to the physics problem I reported in the other post. Every now and then the draw function seems to skip and not plot something or re-plots the previous plot instead of the current one.

@dave1707 @MMGames I did make the editor slower because the existing concurrency code was unsafe (and could lead to crashes). I was a bit heavy handed in adding thread safety to the editor code and I expect that this is what you’re seeing.

I’ll look at profiling this code to see where improvements can be made.