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.

Rocking!! My players will be so happy! Thanks!

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.

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]

Thanks R0J0hound! Thanks volkiller730! I was really starting to worry here. Thanks!

I was able to isolate the problem in a small capx file.

[attachment=0:3se9gyue][/attachment:3se9gyue]

This capx create a lots of orange sprites every ticks, and moves them inside a green box. On collision with the green box, the orange sprites are destroyed.

That by itself isn't enough to reproduce the issue. You need to first save (using the debugger) and load that savefile (using the debugger). Only by loading the savefile will you start to experiment the issue.

When you look at the javascript console, you can see the size of the savefile. It quickly gets very big, even if all the objects have been deleted.

[attachment=1:3se9gyue][/attachment:3se9gyue]

Steps to reproduce:

1. Open the capx using Construct's debugger.

2. Open the browser's javascript console.

3. Save using the debugger. Notice the savefile's size in the console (about 1 KB).

4. Activate the sprite creation by checking the checkbox.

5. Leave it checked for about 5 seconds, then turn it off.

6. Save again using the debugger. Notice that the issue didn't occurred (savefile is still about 1 KB).

7. Click "Load" in the debugger to load that savefile. (that's the important step!)

8. Activate the sprite creation again.

9. Turn it off after about 5 seconds.

10. Save using the debugger.

11. Observe the issue : The savefile is now 100 times larger!

So... what do I do with this? Is it a bug in Construct?

What is it saving exactly that makes the savefile so large? Looking at what is inside "collmemory", it's just a few numbers for each sprite, but if they don't get removed when the sprites are deleted, then the savefile gets very huge over time. That's kind of a memory leak, right?

Should I fill an official bug?

After more test, I found out that "collmemory" seems related with the "On collision with..." event. In a new empty project, I start to see "collmemory" in the savefile only when I add "On collision with" events. I assume that "collmemory" would mean "collision memory"?

I could see how this could lead to my big savefile problem. In my game, lots of sprites are created, then destroyed when they collide with another object. I'm just wondering why data is saved in these cases.

Any hint?

Hello all,

I have a problem with the savefile of my game but I don't know what it is and where to start my investigation. Maybe one of you will have a suggestion?

The problem:

My game's savefile gets too big over time, and reach the browser's file size limit of 5 MB. The thing is: my savefile is normally only 20-50KB which is way under the 5000KB limit. But over time, the savefile gets bigger and bigger.

I should specify that my game is an idle game (think Cookie Clicker), so it is meant to be left open for days and even month for some of my players. It is also saved and reloaded often hundreds of times. My players with the issue have had the game open for 1-2 months before the savefile reached above 5000KB.

What I tried so far:

1) I asked my player to send me his savefile, which I loaded in the game while running Construct's debugger. I can see in the debugger that everything seems normal. I don't see anything that would indicate a memory leak. I was expecting to see an object with billions of duplicates, but no. There isn't a layout with more than 100 objects in it.

2) I added the behavior "don't save" to most objects that didn't required it (UI elements for example). That didn't help.

3) I tried to create a new empty project where I create and destroy hundreds of objects every tick, and compared the savefile. I could NOT reproduce my issue this way (the savefile remained clean).

The savefile

He's the affected savefile: http://bit.ly/1MlITzU

Looking at it, I can see which section is taking 99% of the space. It starts 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],"58,17632":[58,17632,269421],"58,18070":[58,18070,276300],"58,18653":[58,18653,285566],"58,18667":[58,18667,285801],"58,19836":[58,19836,304567],"58,20152":[58,20152,309332],"58,20310":[58,20310,311876],"58,20956":[58,20956,322135],"58,22376":[58,22376,344412],"58,22637":[58,22637,348509],"58,22703":[58,22703,349869],"58,23228":[58,23228,357859],"58,23685":[58,23685,365071],"58,23855":[58,23855,367876],"58,25208":[58,25208,389170],"58,26185":[58,26185,404569],"58,26278":[58,26278,406022],"58,26463":[58,26463,409113],"58,26761":[58,26761,413675],"58,27026":[58,27026,417827],"58,27711":[58,27711,428661],"58,29000":[58,29000,448719],"58,30517":[58,30517,472695],"58,30543":[58,30543,473110],"58,30879":[58,30879,478351],"58,31540":[58,31540,488785],"58,31647":[58,31647,490430],"58,32104":[58,32104,497702],"58,32379":[58,32379,501990],"58,33637":[58,33637,521774],"58,33748":[58,33748,523725],"58,34339":[58,34339,532881],"58,36110":[58,36110,561142][/code:lczagwcu]

It's followed by about 1500 pages of the same kind of data (yeah, just for fun I tried to print it to see how many pages I would get!) <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile"> 

As you can see, it starts with "[b]collmemory[/b]" which I tried to search on Google and Construct forums, but could not find anything about it. Do you know what that is? Do you know what is this giant list of numbers?

Any hint would be welcome. Thanks!

Oh wow, thanks! I was somehow expecting that it would be considered a normal/expected behavior for Construct, especially since I found a way to prevent this issue with some additional code. But yeah, thanks for the fix. It will make the code so much more clean!

What is the error? Can you copy the error message here or take a screenshot of it?

Problem Description

An object set as global on a layout will create duplicates of itself when revisiting that layout after saving and reloading the game from a different layout.

Attach a Capx

[attachment=0:zu1wp9i1][/attachment:zu1wp9i1]

Description of Capx

This capx has 2 layouts:

Layout 1 has 2 buttons for loading and saving.

Layout 2 has a global object (orange square sprite).

Steps to Reproduce Bug

• 1) Launch the game. You'll see Layout A. Counted object = 0.
• 2) Press Spacebar. You'll be switch to Layout B, and see the orange sprite (global object). Counted object = 1
• 3) Press Spacebar again. You'll be switch to Layout A. The orange sprite is still present. Counted object = 1
• 4) Press Save.
• 5) Close the game and restart it. The orange sprite is gone. Counted object = 0.
• 6) Press Load. The orange sprite is visible. Counted object = 1.
• 7) Press Spacebar. You'll be switched to Layout B. Counted object = 2.
• 8) You can repeat steps # 3 to 7 to create multiple copies of the global object.

Observed Result

The orange square global object is duplicated after loading the savefile and revisiting its layout.

Expected Result

The orange object is not duplicated after loading the savefile. No new copies of the object gets created.

Affected Browsers

• Chrome: YES
• FireFox: ???
• Internet Explorer: ???

Operating System and Service Pack

Windows 7

Construct 2 Version ID

Release 195 (64-bit) - Jan 19 2015

I think the best solution is a better feature to find/review/refactor across the whole project, so you can easily look up all function events and function calls if you want to rename something.

Yes! Very much yes! I loooove functions, but it's always a pain when I want to rename them (or change the parameters, but that's a whole different issue)