Sometimes (infrequently) after fin my pulp game will crash with this error:
luaL_loadbuffer failed
stack traceback:
[C]: in field 'load'
?: in upvalue '?'
?: in upvalue '?'
?: in upvalue '?'
?: in function <?:3743>
I've seen this happen as have two different people playtesting the same game on their own playdates (the traceback is identical in all cases).
It does not happen reliably so I have struggled to reproduce it.
One idea is that it might be related to button presses on fin while waiting for the game to reload (it not being instantaneous). Following that (unsubstantiated) thought:
In all cases I have always been calling ignore in pulpscript before calling fin.
I added an ignore to the game's load event handler followed by a listen in the game's start event handler, in case disabling input during that loading phase might make a difference. I have seen the crash post making that change so no luck there.
That's exhausted what I can think to try in pulpscript. I suspect it is a pulp engine bug rather than a problem with my pulpscript/project specifically.
It's not a huge issue (fin is only called on game over, the game autosaves succesfully before the crash meaning no progress is lost, and the game doesn't take long to restart) but I thought it worth reporting anyway!
Unfortunately I've already had this reported a couple of times from people playing Resonant Tale. While the impact isn't significant (the game autosaves and you can reload the game to where you would have reloaded on game over anyway) it's obviously not a good look and I would love to be able to fix it!
Does anyone have an idea of how I might debug the crash, or anything I might change in pulpscript to try and mitigate it?
I'd also note that my fin is already inside a wait.
I don't know if it could be related, but I had a lot of trouble yesterday caused by waits on different tiles that would finish waiting in the same frame as the fin call, leading to a crash because inside the waits I was trying to alter something in the room or start a new sound. I had to failsafe all the code inside wait calls by checking if a fin had been called - more details here.
No such luck unfortunately. The last I tried was moving the player to an empty (all black tiles) room and waiting longer before calling fin, but I still (infrequently) get this error on device. Frustratingly other people seem to get the error more frequently than I do and it has been reported quite a lot by Resonant Tale players!
I'd love to be able to fix it in a v1.1 I am planning but I think it might need some panic attention to at least debug.
I made a build that starts the player in a debug room with some exploding pots that can kill the player, triggering a fin through my game over event, and a signpost sprite that would call a custom fin just for the debug room.
I managed to once get the same crash from interacting with the signpost, while someone else testing (who seems to get the crash more than me generally) managed to get the same crash a few times through the exploding pots/game over event. However we both found the frequency of crashes was much lower than in-game. We're talking one in a hundred for me replicating in the debug room compared to maybe one in twenty in-game, which itself is very different to other people's experience of seeing the crash on the majority of game overs when playing the game.
My hope was to create a build that would be easier to test to help in asking for any panic assistance, but frustratingly something seems to be different about it!
At this point I've tried restoring the same variables on load, making sure music is playing on load, filling the room with lots of different tiles, moving the player through several rooms prior to triggering a fin, waiting some time before triggering a fin, and queuing up many event call inside waits of various lengths prior to calling fin.
Scratch weighed in over on discord, I'll just share what he said directly rather than paraphrasing:
I've gone through the FW and that error only appears once -- in playdate.file.load
Strangely enough, there's only one way that seems to trigger the error: if the magic number within the loaded PDZ is invalid. Otherwise it'll try to load it over and over again, and eventually be stopped by the ten-second watchdog (or the callstack overflowing, whichever comes first)
My guess is that the file pointer is somehow not being reset correctly all the time
...which would lead to the pointer being wherever it left off in the file data when it was last read, causing it to not find the signature it's looking for
This has been fixed by Panic! The Playdate was running out of memory trying to reload the game on fin and the size of my game just happened to hover around half of the available memory, making it unreliable to reproduce.