Getting rid of actors from memory

So I posted this in the discord but as it's a holiday weekend I haven't had any response and thought I'd ask on the forum to avoid my issue ending up scrolling off and being missed.

I seem to be having a rather severe garbage collection problem; specifically, there is no garbage collection. I've been testing this a fair bit since it was reported to me and from what I've worked out, every time a new actor-type (type specifically, not every individual instance of an actor) appears for the first time, the game begins to use more memory.

However, this memory is *never* cleared. Even when memory is added as a result of an actor that is part of an atlas appearing, leaving the scene the actor is atlas'd to does not remove the memory used by that actor.

I have tried to troubleshoot this with telemetry, but doing so causes the game to no longer compile, and become unable to compile even after disabling telemetry until the project is cleaned. I attached the error log from that to this post. I also tried turning on "dispose images" in the settings but that leads to the game crashing a few seconds after starting up.

Is there anything I can do to get the game to clear out the memory? My best guess is that it's trying to keep everything in memory to load faster, but eventually there's just too much stuff and it crashes the game.

Does cleaning the project before compiling with telemetry enabled allow compilation to work?

That allowed the telemetry to work, thanks. It looks like there are references to Luyren's PlayerControl behavior piling up in the hundreds over just a few minutes of play, but I am not able to read it well enough to understand where the issue is coming from exactly or how to fix it. I tried attaching the telemetry results to this post, but it seems its too big to attach.

I'm not sure how that behavior works, since I've never used it. If it is somehow keeping references to actor types then that might prevent GC from freeing the memory allocated to those resources.

Is the Player Control behavior referencing hundreds of actor types, or some other resource?

Unfortunately, I don't know how it works exactly either. It does look like it has a lot of events "listening" for triggers from it's updating event, would that cause it to remain in memory? I'll attach a screenshot of that.

As far as I know the only thing that could be pilling up memory usage for that particular behavior is if you are using the very first version of it (from around 2 years ago I think), and even in that case the excessive memory usage was related to the "split" text block, nothing related to actors. Even in the worst case I don't think that by itself would be enough to slowdown a game.

Are you adding things to a list somewhere in your game...? Maybe you forgot to clear old things and it just keeps growing...?

I may be looking at the old version of Player Control, but I see a lot of string operations. That doesn't necessarily mean the number is "excessive" though. There are several classes you will see thousands, even millions, of allocations for. b2Vec (for collision detection) is another example. This is normal.

Even if the number of allocations in Player Control was excessive, the symptoms should be different. It's an actor behavior, so once the scene changes (and hence the actor in the scene is removed), nothing should be left to point to the variables it is using and GC would free it all up.

It is worth checking that you have the most recent version of the Player Control behavior, though. Otherwise, I wouldn't expect that behavior to be the culprit. I would expect big items (sound resource files, for instance) to be the problem. Number of allocations of classes like strings or b2vecs is more likely to affect CPU time, not storage volume.

I do know I am using an older version of player control because the newer version didn't work; I recall working with Luyren on it a while back trying to get the new slope system but had to revert it because something wouldn't work. I don't know if it's *the* older version that had that issue, or just *an* older version.

Though if it is more likely to be something else, maybe I'm not reading the telemetry right? Its my first time to use it, so I may not be looking in the right place to find the actual problem. I just uploaded the telemetry results to dropbox, so here's the link to it. https://www.dropbox.com/s/cc4hbei3agl6bqm/Succuquest%20Telemetry%20Results?dl=1

The thing with the old version of the Player Control at the end of the day won't matter for the issue at hand as far as I can tell, so I say you don't have to worry about it.

Only sugegstion I can offer is to remove actors from the scene one by one to find if it's a specific type or amount that's causing the issue, and then disable all behaviors and test, reenabling them one by one until you find the root cause.

I noticed this point where 100MB worth of graphics resources are loaded. A significant chunk of time is also spent rendering. What were you doing about 1 minute into the playtest?

One minute into the playtest would be right at the end of the tutorial and entering the first area in the game. I cannot fathom where 100mb worth of assets would be loaded in though. The assets that load in for the first time at that time are

The music for that area: 3MB
Background 1: 2.6mb
Background 2: 2.4mb
Background 3:  2.8mb
Sword Bandit assets: 300kb (3 instances)
Gun Bandit assets: 200kb (2 instances)
Slime assets: 150kb (2 instances)
Tileset 1: 75kb
Tileset 2: 26.2kb
Tileset 3: 172kb
UI: roughly 50kb between them

Even accounting for me missing a few things, it can't be more than 12-13mb worth of stuff loading in at that moment.

Edit: also, the entire game in total is 180mb large with all it's assets combined, so that would be like loading half of all the game's assets at once...

Storage on disk and and storage in RAM may not match, though. Image data, for example, is stored on disk in a compressed form (such as .png) where in RAM it would be decompressed