SaveState growing when using on Collision

0 favourites
From the Asset Store
Particles support animations, collisions, effects and etc.
  • Problem Description

    The save state increases over time when saving and loading. It seems to happen when creating objects that are then destroyed "on collision".

    Attach a Capx

    [attachment=0:2oj2q7yq][/attachment:2oj2q7yq]

    Description of Capx

    The capx creates a sprite every tick that immediatly gets destroyed on collision. Then every second the state is saved then loaded.

    Steps to Reproduce Bug

    Basically exactly like the capx, but...

    • Every tick create a sprite so it overlaps a second object.
    • Using the "on collision" condition check for a collison between the sprite and object and then destroy the sprite.
    • Periodically save then load the game state.

    Observed Result

    After a few saves and loads of the state, the save state gets bigger and bigger. Looking at the JSON string the section after "collmemory" gets longer and longer.

    Expected Result

    That the savestate would remain the same size

    Affected Browsers

    • Chrome: untested
    • FireFox: YES
    • Internet Explorer: untested

    Operating System and Service Pack

    Windows Vista sp2

    Construct 2 Version ID

    r199

    Further discussion on the bug found here:

  • Based on my investigation, I should add that it's the loading that is the key to reproduce the issue.

    If you just save and never load, the savefile won't get larger.

    As soon as you load once, you can see the savefile getting larger and larger every time you save.

    The part that gets larger in the savefile is a thing called "collmemory" (for collision memory?) It becomes filled with numbers like this:

    "1734838404821996":{"ex":{"collmemory":{"58,2268":[58,2268,28460],"58,2578":[58,2578,32750],"58,3123":[58,3123,40578],"58,4188":[58,4188,57365],"58,4268":[58,4268,58824],"58,4742":[58,4742,66165],"58,5010":[58,5010,70619],"58,6248":[58,6248,90052],"58,6331":[58,6331,91371],"58,6544":[58,6544,94751],"58,7030":[58,7030,102474],"58,9446":[58,9446,140590],"58,9516":[58,9516,141699],"58,9572":[58,9572,142783],"58,12193":[58,12193,183862],"58,12404":[58,12404,187362],"58,12577":[58,12577,189900],"58,13907":[58,13907,210833],"58,15106":[58,15106,229678],"58,15433":[58,15433,234811],"58,15494":[58,15494,235766],"58,16088":[58,16088,245144],"58,16893":[58,16893,257748], .... [/code:17xxl71o]
  • Nesteris, I suggest that you follow the instructions in this post:

    and submit your bug using the template from that post as a new post instead of as a reply to this one.

  • Should be fixed in the next build, thanks for the report.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Rocking!! My players will be so happy! Thanks!

  • Should be fixed in the next build, thanks for the report.

    Now that Contruct r206 has been released (which includes the fix on this issue), I did some tests and I'm not sure the situation is better.

    Ashley, is your fix supposed to "clean" a savefile that is already full of the ghost data? For example, if I use a savefile that was created on my game in Construct r200, and I load it in my game running in Construct r206, should it remove the corrupted data and reduce the savefile size?

    I'm testing this right now and it doesn't seem to clean it. The savefile remains super big and seems to keep expanding as before.

  • No, the fix won't clean any existing files, but it should prevent any new files from being bloated.

  • So, if I understand correctly from what you're saying, the issue will continue to occurs (the savefile will get bigger) unless my players erase their savefile and start a new one?

  • narFsnw

    The fix makes the files so they won't get bigger.

    You can clean the user's saves yourself using a regex expression. Here's a test of such an expression.

    https://dl.dropboxusercontent.com/u/542 ... eaner.capx

    Basically doing this should clean the save. After that load again with the "load state from json" action.

    RegexReplace(SaveStateJSON, """collmemory"":\{.*?\}", "", """collmemory"":{}")[/code:285hm3p4]
    Basically it will remove everything in the collmemory section.
  • Very good idea, R0J0hound !

    One thing though: do you know why it only clean the first collmemory and not the others? I'm not good enough with regular expressions to see why, but right now, it only clean the first collmemory.

  • narFsnw

    Ah, I thought there was only one. You need to add "g" to the third parameter I think? In the capx it's just "".

  • Yup! That worked! It cleans every collmemory now. Excellent!

    Here's the final line, as a reference:

    RegexReplace(SaveStateJSON, """collmemory"":\{.*?\}", "g", """collmemory"":{}")[/code:2vsjvf20]
    
    I really need to learn regex for real!
  • narFsnw

    I only know enough to get by and even then I usually reference this:

    https://developer.mozilla.org/en-US/doc ... xpressions

  • Ashley Unfortunately, i'm sad to report that the fix does not entirely solve the issue. It did solve the issue in R0J0hound 's small test capx, but in the context of my game, the issue still occur. Some (not all) "collmemory" sections keep expending.

    Problem is, depite my best efforts, I've been unable so far to reduce my project to a small capx that would contain just the issue. Starting from an empty capx, I'm just unable to reproduce the issue. Starting from my game and removing stuff, the issue comes and goes without me being able to understand it.

    Any ideas or advices?

  • Ah! I finally managed to reproduce the issue in a small capx. I'll write a new bug report in a moment...

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)