https://copy.com/bzdkhHrGFv800qrc

Local storage would be what persists through sessions, so you have to use that.

If the chance of rolling the same numbers is low (for example your range is 1-100, and you wanna fill 6 fields), I would probably just do a while loop (roll -> check if number is present; if it is, reroll; end loop when number is not present).

If the number of fields is closer to the range of values you are filling into them, I would do something like:

this would circumvent unnecessary retries, but need a bit more memory, since you build an array (but memory would only be a problem for big ranges)

Can anyone please tell me which size the resulting apks have for a basically empty project? Thanks

Setting your sprite visible every tick might be a workaround, but not a real solution. You should really find the cause of the problem (= you need to understand what's going on). I'm not willing to download your project, because it is too big.

You can invert the "is flashing"-event. Problem would be that in the event of flashing, you would do nothing, meaning you would end up with an invisible sprite during flashing duration just like you had initially. That's because you did not remove the cause of your problem.

Since your sprite has the flashing behaviour, you should check if it's flashing from the start (you can see that in the debug as well). If you activate the flashing every tick in some event this could lead to the behavior you are witnessing.

Further: events run from top of the event sheet to bottom. Your "every tick: set visible"-event made your sprite visible. That means the event making it invisible is located ABOVE that event. Move your visible-event upwards in the event sheet in steps and watch if you can see the sprite or not. Once you can't anymore, the event causing the bug must be somewhere between the current position of the event and the last position of the event that you checked.

the event triggered from confirming the selection:

• : unlock easy levels
• if list selected item >= 1: unlock medium levels
• if list selected item >= 2: unlock hard levels

or

the event triggered from confirming the selection:

• : unlock easy levels
• if list selected item >= 1: unlock easy and medium levels
• if list selected item >= 2: unlock all levels

How you "unlock" your levels depends on your code, probably you'll use some flags you can check against.

So since you found out there's a problem with the sprite getting set invisible every time, you have to find the line of code that sets it to invisible every tick (or whatever).

To do that:

use the search function (CTRL + F) in event sheets, use "set invisible" as search term (without the quotes). I suppose in one of your relevant sheets there will be an event setting your sprite to invisble.

If there is none, then my only idea would be something like a (third party?) behavior or code, that somehow leads to that... but it's unlikely.

You have a C2-License, so start your layout in debug mode.

Select the player sprite object. It should be marked with a red box around it. If you don't see the red box, the sprite's position is not within camera view.

If you see the box, but no sprite is shown, check:

the player sprite objects opacity, visibility, frame, animation, layer.

If opacity is 0, you will not see it.

If visible is false, you will not see it.

Check in the editor if the current frame of the playing animation contains a visible image.

Check the point of Origin - maybe it is far off the edges of your character's image and thus your sprites position is way off.

Check if other objects share the layer with the sprite or are on a layer above the player sprite and if so, if they could overlap it (Z-Order).

Set animation speed of your sprite proportionally to your speed value. (probably in the event that determines/changes your speed)

You find it under sprite -> animations -> set speed.

Your example didn't lag for me. But I think it is good practice to only run code when necessary.

I'm not very familiar with the current learning ressources besides the manual. I think all the functionality besides own javascript plugins etc. is covered there. The examples of C2 give some additional hands on experience.

I can't give the best tipps, because I'm not a pro myself.

Important things to know (in no particular order):

• if / else
• use of for-loops
• use of while-loops
• data types (boolean, numeric, string, dictionary, array)
• functions
• how picking objects works
• expressions https://www.scirra.com/tutorials/77/nat ... onstruct-2 and https://www.scirra.com/manual/126/system-expressions

The hard thing currently for me is organizing and writing my code in a way, so that it is not (strongly) intertwined with itself. That's why currently I'm looking at some programming design patterns ( http://gameprogrammingpatterns.com/contents.html ). It might be hard to follow, if you are not comfortable with a programming language similar to C++.

perhaps like this:

https://copy.com/q764O1j4hVDisxEY

If you have multiple players, you would need to put the inventory and playersubstances array into the container of player.

Doing stuff every tick like checking if any of the potions can be made or mobed really isn't what you should do, performancewise. Code should only run when you collect a substance imo.

Hmm, looks like construct doesn't create the subfolders physically but instead dumps everything into the same (main) directory.

So one way you could do subfolders would be adding the folder names and files after export to html. But you will probably run into problems with other exporters, where maybe you can't change the file structure.