“trigger once” condition is not global. “scene finished pre loading” condition is still true when the scene changes so it will play the sound. It doesn’t mean that the scene is pre-loaded again.
Nowaday, most devices have a lot of RAM so keeping every asset in memory is rarely an issue. Reloading assets from the device storage drains a lot on the battery and must be avoided as much as possible.
What about the “Scene exists” condition? Why does that work? Whats the priority on that? Whats the point since they allways exist, if you stop one another preloads on the back, they always exist, you sure that cant be it?
I’m a revolutionary!..lol…joke aside,…
I wasn’t rite, because indeed scene changes and only globals are kept…
What i learnt at my expenses is that you must check every damn global and every object binded to them before and after the swap…
I doubt it’s your case but definitely is mine… and if they could cause a lag??..i don’t really know.
About your memory leak issue i’m not a dev but maybe you could try to manually compile your game to an exe to see if your lag happens in the real game too…it could be a preview sync issue?
Sometimes i do this to check mine and while i notice some lag in editor…there is none in the compiled game
Its not a preview thing issue, i already compiled that game before starting this thread, its the same on there.
Also i had a look at the documentation, no real info about Scene Exists…
Scene Exists, checks if a Scene Exists… Which it does, even tho i never told it to load that scene or changed to that scene or did anything with that scene, So why does it exist?!
Please answer me that
And also, the way i tested it, the preload with sound experiment, was with an external event page, the same one linked to diferent scenes and not using anything to trigger them at the start of the scene, only triggering when the scene was preloaded, this always made ti ring on scene changes.
I tried it in diferent ways, using events from seperate scenes, external events linked to diferent scenes, etc, they always acused scenes being loaded other then just on the start of the game.
I think i get the scene exists thing, didnt know you could generate new scenes with events and that the ones on the editor are the ones you “declared” i guess? if thats the case then it makes sense i supose.
Theres still something not right with the loading in the background, it really cant be that hard to poke around under the hood and check if everything is in order considering its not just me having this issue and ever since i stopped using scene changes, i stopped having issues…
As every engine GD is not perfect.
Even Unity had and still have some lag issue and unknown fatal crashes.
Same with UE5…(there are still ppl w8ing for fixes).
GD devs are really active and surely they are already on the matter, but i doubt your fix will come soon.
ALL you can do for now is to adapt your game on the current ver and prepare it for when a fix will come.
I too have an unfixed behaviour that stopd me to expand my game but for now i’m focusing on other things and hopefully one day i’m gonna have the chance to implement it back.
I read something that made me think you could create a scene with events, i just tried and you cant… which would make sense… so… “Scene Exists” makes no sense to me or why it would trigger as true if i never changed to that scene before…
@MagicBiscuit Thank you for reporting this issue and giving an project to reproduce it.
The memory leak is in the FlexBox extension. This extension was created before there were 2 tiers lists. We moved it to the community tier list and added a warning in the description about the memory leak.
Thank you @davy for taking time to dig into the issue.
So the problem lies in this extension that seems to create “DOM” (HTML) elements in memory and never release them when a scene is changed.
Note that this is not a problem of the game engine: there is no leak for scenes, variables are not leaked (and would not create anything similar to a slowdown before multiple hours at least, if not days - variables are super tiny in memory), GDevelop is safe on this side.
Sadly it’s not always easy to check if extensions have such problems. In this case it would be great if someone can fix the extension, but we can’t support all the community extensions so for now we added a warning.
Im glad you were able to find the issue, and that makes perfect sense, since the people with this problem were making RPGs, and the Flex Extension is great for making UIs, Inventory Stuff like Items and such… Thats why we had issues with similar game types…
I really hope the author can fix it since its such a cool extension, any way to contact him saying what happened?
Thanks again for everything, sorry iv i came across as a rude prik at times, but i was so sure there was a memory leak, tested it in so many ways, it was frustrating, sorry about that.
Like i said before, i love GDevelop, i hope it only keeps getting better!