I’m Using the “Stop this scene and go back to a previous one” function, and it used to work, however, the scene now changes correctly for a split second to the “game” scene and then just as quickly changes back to the “tools” scene, after repeatedly pressing the button, (sometimes its works 1 on the first try but normally on the 6-7th) the scene changes correctly, but all the audio is cut out and not playing. this is true for the two buttons in the scene. I’m not accidentally changing the scene back in code, in any of the scenes, and I have a “pause” scene that uses the exact same code for the button and works just fine.
Link to video of issue: [2024-09-16 21-37-41.mp4 - Google Drive]
The game is also very weird when I export it, the resolution is wacky, same the the normal game
If anyone has any ideas on optimizing the enemy pathfinding or anything else that would be great. I’ve set it up so the enemies stop spawning after the FPS drops below 45 to make the game playable. The max enemy count on my 3770k 32gig ram system (~12 years old) is 15-17, there are no physics objects in this game, just the platformer, and bouncing bullets. frame rate drops at 0.1 firerate for the bullets
What are the events that open up the tools scene, and resumes the game when control returns to the game scene?
its kind of d “cheat” menu, so you need to press a few numbers at a time, it only triggers once
Could you screen shot the events that open the tools scene, and resume when game control returns from the tools scene?
There is the screenshot, but I don’t know what you mean by “resume when game control returns from the tools scene”
just learned that the audio is cutting out, it’s just a side effect of the glitch, the audio plays if I click the buttons more slowly
There’s a condition you can use for when a paused scene resumes. But it’s not necessary in this case.
But, to your issue:
I think the problem stems from the 4 key press combination. I suspect what’s happening is you press all 4 keys, and the actions are processed. However, that wait 0.1 seconds starts a thread, which runs in the background. In the meantime, GDevelop keeps running, and runs the same 4 keys pressed events over and over.
Given GDevelop runs a game frame about every 0.016 seconds, around 6 of these waits will be executed. When 0.1 seconds has passed, the first wait completes and the tool scene is opened. I’m assuming the waits that are still processing in the background are also paused.
Then when you resume the main scene, the next queued up wait command is actioned, and the tools scene opened up again. Rinse and repeat.
To fix this, add a trigger once condition to the 4 key press check, and you should be good to go.
1 Like
That fixed the issue, i must have deleted the trigger once action while editing. Thankyou