Thanks for getting bcak to me and the link. I agree that asset bundles / Addressables is going to be the way for us long term. Since I bought the source version I plan to eventually refactor the character prefab loading system to use Addressables instead to reduce memory and also because we're building for WebGL and are already hitting the ceiling there for how much we can have loaded into memory at runtime.

Seems like most of the garbage collection is happening from the use of LINQ in various places. For example, from FluxStateTracker.cs beginning at line 559

                // Inputs being held down (charges)
                controlsScript.inputHeldDown = state.inputHeldDown.ToDictionary(entry => entry.Key, entry => entry.Value);
                

                // Projectiles
                controlsScript.projectiles = new List<ProjectileMoveScript>();
                foreach (ProjectileMoveScript projectile in state.projectiles) {
                    if (projectile != null) controlsScript.projectiles.Add(projectile);
                }

                
                // Buttons Pressed
                controlsScript.MoveSet.lastButtonPresses = new List<ButtonSequenceRecord>();
                foreach (ButtonSequenceRecord btnRecord in state.moveSet.lastButtonPresses) {
                    controlsScript.MoveSet.lastButtonPresses.Add(new ButtonSequenceRecord(btnRecord.buttonPresses, btnRecord.chargeTime));
                }

                // Cooldown Timers
                controlsScript.MoveSet.lastMovesPlayed = state.moveSet.lastMovesPlayed.ToDictionary(entry => entry.Key, entry => entry.Value);

ToDictionary() is the 2nd worst method in terms of garbage collection which is probably why it's steadily climbing there.
https://www.jacksondunstan.com/articles/4840

Because getting UFE 2 to a production ready state for us is going to require a bunch of refactoring and UFE 3 is on the horizon I wonder if @Mistermind would be willing to work something out with us. I'd gladly preorder the source version and contribute to the codebase. I'm paying for the top tier patreon right now to get access to the repo but it seems that the UFE 2 repo has been abandoned in favor of UFE 3 development.

Edit: a few other issues we've run into that I plan to dig in and fix

* If two players begin a search for a match at the same time, neither will find a match and both will set up a room. There's no timeout to go back and search again so they'll both just sit in their room indefinitely thinking no one else is online to play

* Randomly get a bunch of "end of stream" errors in the console from PUN. haven't been able to troubleshoot and dig in yet.

* The one scene and instantiation flow seems to be causing quite a few issues. Plan to replace this with scenes and singletons for anything that needs to be persistent.

* Several other small things we plan to fix. Would much rather put this energy towards UFE 3 though.

I was originally using the prefab route but when we started to run into memory resource issues in WebGL I switched to the resources method based on the recommendation of the final bullet in the Notes section here:

http://www.ufe3d.com/doku.php/character:prefabs

I haven't dug into the flux scripts enough to understand what's going on in the places that LINQ is used but will need to do that it seems. In a fighting game, with all the rapid mashing of buttons that LINQ caused GC in every frame is probably where the steady GC allocated memory issues are coming from.

Another issue that I think is going on is the lack of object pooling. There's some kind of preloading / memory allocation happening for the projectiles and hit effects that I think is also attributing to the problem. Will need to also rework that likely in order to instantiate a pool and recycle for all of the particle/hit effects.

With all of this work I'll be doing, I'd much rather invest this energy in UFE 3 if that were possible. Happy to contribute.

Looks like three other devs went down the same path that I have and none of them pursued a solution. Might try disabling the netcode rollback and see if that helps at all.

The input dictionary declaration breaking the input system doesn't sound like good times. We're using rewired for controller support so that will probably add a layer of difficulty to the improvements.

Between these performance issues, now likely needing to get rid of the netcode rollback, and having to abandon Fuzzy AI for WebGL we've had to make a lot of compromises for a $500 framework. Really hoping we can just get our hands on an early version of UFE 3 rather than pouring more energy into this version that is being moved away from.

Possibly but the UFE 2 repo I'm paying for access to on Patreon hasn't been updated in 8-9 months.

We're going live with a public beta at the end of the month so time isn't on our side. Hopefully @Mistermind pops in sometime soon and provides some input.

I'm using the resource load method for both the characters and the stages.

No custom scripts or prefabs unless a stage that is loaded by resources that contains prefabs within it is an issue.

Based on my profiling and other's experience here in the forums it seems like most of the GC is coming from the input system, flux classes, rollback netcode. After disabling the rollback netcode, users have reported fewer disconnects but then timing of blocks and counters is a mess since host has the advantage then. Used the map recorder for all characters but didn't make a difference with disconnects.

Profiler shows about 170mb-230mb of GC used memory depending on if preloading hit effects/stage are enabled. Warm all shaders crashes play mode every time so that's been off for a while.

edit: Tested the versus only deployment method and no difference to the total memory or GC memory used.