Hello, I am making a new game on scratch based off of an old game I made in 2018, this new game is made following one of the griffpatch's side scrolling Mario tutorials he made, with level loading and saving. I am making my game rely heavily off of this mechanic, as I don't want to make a full side scroller but a game where the people would make levels then share them in the comments for example, so it is one of the main features I want to work well but one thing i have noticed within the game while testing is that for some odd reason, sometimes when saving or loading a level, it gets extremally skewed or cut up into offset chunks, i have no idea why this is happening, i have tried looking for the issue in the code and change some of the value, but still even with all this, the issue remains, i even cross checked my code with griffpatch's own code in his example project and i verified that they are the exact same, yet it seems to work in his game with no issues while it entirely breaks my game, so i have come here to ask for help and also asked griffpatch himself on youtube but i doubt he will answer as he has so many fans and people wanting to talk to him,

i have examples of what my level is supposed to look like here:


and then what the level actually looks like after a couple save and load cycles


if you would like to see my code, i would suggest going to the project here: https://scratch.mit.edu/projects/717534337/editor/ and going to the “level store” sprite, as it has multiple scripts and would be difficult to put here in it's entirety.

I do hope someone has an answer to what could be happening, because it would probably save my project, and would help me immensely
anyway i wait for a response and will be back soon, goodbye and thank you.

Sorry, but I tried it and nothing seemed wrong

I'd recommend working out which of the stages is ging wrong. If you understand how the save-coding should work you should be able to create a code manually and test that the loading works. If that works then does saving produce the same code?

If any stage of sving/loading changes the code there is obviously an issue and providng us with a test code may mean you get help more quickly.

I can't solve it.

So instead of giving an answer, here are other bits of information:

• It seems you are storing the tiles starting from the bottom left, going up the columns and then across the rows. That's fine except you are trying to save the world so that the tiles are ordered with rows first and then columns? It's overcomplicating both the saving and loading, you can just treat the level as a single 1 dimensional list (which it already is) and save that directly.
  

  set [tile index v] to [1] // 1 counter to go through each item in the list
  repeat ((GRID HEIGHT) * (GRID WIDTH))
  ...
  change [tile index v] by (1)
  end

  …instead of…
  

  repeat (GRID HEIGHT)
  repeat (GRID WIDTH)
  
  end
  
  end

  
  
• Try stepping through the blocks. I like to pull apart scripts and click each block, watching what happens to variables and other things.
  
  
• Try testing with much smaller levels (if possible). This will make stepping though blocks much quicker and easier but it will also enable you to do things such as creating save codes manually that you can use to test things. This can also show if the saving or loading is to blame, if your manually created save matches what your saving script is generating, then it might be the loading script that is not reading it correctly, for example.
  
  
• Your save script is not set to “run without screen refresh”. You probably should change that as saving takes too long and what's shown in the level store list could be a previous save.
  

StrangeIntensity wrote:

Sorry, but I tried it and nothing seemed wrong

the strange thing is that it only works sometimes, like 8 times out of 10 it will work correctly, saving and loading the stage normally, but 2% of the time it shows what happens in the images i showed, sorry should've been more specific in original text but you should find it after spending a slight amount of time working on a level,

awesome-llama wrote:

I can't solve it.

So instead of giving an answer, here are other bits of information:

• It seems you are storing the tiles starting from the bottom left, going up the columns and then across the rows. That's fine except you are trying to save the world so that the tiles are ordered with rows first and then columns? It's overcomplicating both the saving and loading, you can just treat the level as a single 1 dimensional list (which it already is) and save that directly.
  

  set [tile index v] to [1] // 1 counter to go through each item in the list
  repeat ((GRID HEIGHT) * (GRID WIDTH))
  ...
  change [tile index v] by (1)
  end

  …instead of…
  

  repeat (GRID HEIGHT)
  repeat (GRID WIDTH)
  
  end
  
  end

  
  
• Try stepping through the blocks. I like to pull apart scripts and click each block, watching what happens to variables and other things.
  
  
• Try testing with much smaller levels (if possible). This will make stepping though blocks much quicker and easier but it will also enable you to do things such as creating save codes manually that you can use to test things. This can also show if the saving or loading is to blame, if your manually created save matches what your saving script is generating, then it might be the loading script that is not reading it correctly, for example.
  
  
• Your save script is not set to “run without screen refresh”. You probably should change that as saving takes too long and what's shown in the level store list could be a previous save.
  

thanks! i'll try these suggestions and get back to you with whether they work, btw the overcomplicated saving and loading through columns is something griffpatch suggested to try and get level code size down, so i was just going with what he said, but i will try to make it simpler for the time being to see if that works!

AMSASH wrote:

thanks! i'll try these suggestions and get back to you with whether they work, btw the overcomplicated saving and loading through columns is something griffpatch suggested to try and get level code size down, so i was just going with what he said, but i will try to make it simpler for the time being to see if that works!

i'm back, so i tried some of the suggestions people have here and honestly i'm still stuck on this, i've changed how my level saves and loads to make it less complicated, i've tried going through the blocks to notice anything wrong and even try deconstructing the level saving and loading and i still have nothing, the same problems occur, (just now up and down instead of left to right). i'll go into more detail though, i've been testing this with some of my friends to get them to experience it for themselves and see what the conditions are when it happens, and so i have narrowed it down the slightest bit, one thing i know is that this happens during the loading part of the code i'm pretty sure, as everything only breaks when loading, for example here is a video from my friend who was making a level and testing for me (he is running a turbowarp 16:9 version of the game but code wise they are identical (i know that because the scratch version was uploaded from my turbowarp sb3))
link to video
i also know that the bug is NOT consistent, for some reason the code works 9/10, which is why people haven't been able to find it, but for that one 10 percent of the time the code just bugs, which i don't know why it's so infrequent and inconsistent.
other than that i can try rewriting the level saving and loading code, but since i already checked it being the same as the tutorial i'm following i am not sure that will help
i suggest people to go to my game again and really poke around in there and try going in and out of edit mode several times and making either small levels or huge levels with lots of blocks, idk, anything to prove that the bug is reproducible and to find whatever that will make it clear to what triggers to bug

I could try whats wrong here. But isn't it the newer simplified version now?

AMSASH wrote:

…
… but i will try to make it simpler for the time being to see if that works!

AMSASH wrote:

AMSASH wrote:

thanks! i'll try these suggestions and get back to you with whether they work, btw the overcomplicated saving and loading through columns is something griffpatch suggested to try and get level code size down, so i was just going with what he said, but i will try to make it simpler for the time being to see if that works!

i'm back, so i tried some of the suggestions people have here and honestly i'm still stuck on this, i've changed how my level saves and loads to make it less complicated, i've tried going through the blocks to notice anything wrong and even try deconstructing the level saving and loading and i still have nothing, the same problems occur, (just now up and down instead of left to right). i'll go into more detail though, i've been testing this with some of my friends to get them to experience it for themselves and see what the conditions are when it happens, and so i have narrowed it down the slightest bit, one thing i know is that this happens during the loading part of the code i'm pretty sure, as everything only breaks when loading, for example here is a video from my friend who was making a level and testing for me (he is running a turbowarp 16:9 version of the game but code wise they are identical (i know that because the scratch version was uploaded from my turbowarp sb3))
link to video
i also know that the bug is NOT consistent, for some reason the code works 9/10, which is why people haven't been able to find it, but for that one 10 percent of the time the code just bugs, which i don't know why it's so infrequent and inconsistent.
other than that i can try rewriting the level saving and loading code, but since i already checked it being the same as the tutorial i'm following i am not sure that will help
i suggest people to go to my game again and really poke around in there and try going in and out of edit mode several times and making either small levels or huge levels with lots of blocks, idk, anything to prove that the bug is reproducible and to find whatever that will make it clear to what triggers to bug

Or… I mean… just redo the whole system… much easier than debugging it, am I right?

AMSASH wrote:

StrangeIntensity wrote:

Sorry, but I tried it and nothing seemed wrong

the strange thing is that it only works sometimes, like 8 times out of 10 it will work correctly, saving and loading the stage normally, but 2% of the time it shows what happens in the images i showed, sorry should've been more specific in original text but you should find it after spending a slight amount of time working on a level,

Which is why working with an example and looking at the data makes sense. I still don't have time to investigate but what you describe sounds like you might have some data which gets missed or encoded incorrectly. For example if you encode 100 values as 2-digit values but for some reason one value gets encoded as 1 or 3 digits or gets missed completely (eg isn't recognised) then everything after that point will be off. That would be spotted if you looked at the data rather than the (programming) code.

Create a simple save code using your knowledge of how it works. Check it loads OK. If that works try saving and check the new version against the old one. If they match try repeating several times in case there is something happening that makes it inconsitent (at which point looking at the programming code becomes relevant). If no problems occur try making a more complicated save code. Share your findings including the save code details.

Yes, as deck26 wrote, it is good if you have wrote down encoding format which we can look at and compare it with the scripts.

I found it!

The letter r in your a to z list does not exist. There's an e instead so you probably just typed it in wrong.

If a tile repeated 18 times, it would be encoded as an e instead of r. The level loader would only load the tile 5 times.

awesome-llama wrote:

I found it!

Nice work

awesome-llama wrote:

I found it!

The letter r in your a to z list does not exist. There's an e instead so you probably just typed it in wrong.

If a tile repeated 18 times, it would be encoded as an e instead of r. The level loader would only load the tile 5 times.

ahh thank you, sorry then it just being a dumb silly little mistake of my own but thank you for finding this