hey Geez,

Hello Sen.
This should be resolved for the next major update.
Regards,
Geez

Update here I was calling GetScreenSize too early - in HandlerAttached. Calling it in OnUpdate eventually gave me correct size.

It was user error - author was creating emat with same name in same folder structure without realizing it will get same GUID (initial GUID generation is based on name & local location) - https://discord.com/channels/105462288051380224/920710335156060160/1267722686981869578

So I followed MarioE's advice on discord and his insight into excluding the directorys from windows security fixed the symptoms atleast. I'll attach the log anyway to see if its any help.

Unfortunately not planned for reforger :(

Can you please also attach your workbench logs of a session (perhaps this exact one in the video). Console.log will be enough.

Possibly but would that effect performance if the objects were still there just disabled?

slope 3d : Using the "Fill surface layer (clear others)" operation on a material.

Update: Seems like I get stuck no matter what, re-pasting a old backups Default layer fixes the problem for maybe 15min before the error shows up when trying to go into Camera mode.

Just an update from today: Need to make a small HotFix... Prefab Update with 4kb size but had to upload 3,8GB... makes no fun

Update: Copy pasting old backup default works as a temporary fix, but error might show up after awhile. The only thing I tweaked/touched in the Default layer is the TimeandWeatherManager. It's not solved yet then.

Update: Nevermind, problem is back after ive only placed down some concrete prefabs and adjusted the weather a little bit.

Solved my problem by copy pasting a Default layer from a older back up save to my new save. Not sure which entity inside of my default layer caused the problem. But atleast I know somewhat where the issue was located. You may lock close this task.

Coming back to this to see if server side memory leaks are a vanilla issue currently, or could it be my own scenario causing them?

Wow, I didn't expect that. That makes fragmentation all the more important.

I think most players for Arma Reforger are actually on xbox, or maybe by now its 50/50.

Limiting stuff for XBOX... i think over 90% playing Arma on PC?

In T182469#2636082, @dedmen wrote:

Furthermore, workbench publishing should do more for fragmenting the mod internally

This is also a major concern for me. Installing an update for me means waiting 10 seconds for the download. And then waiting 10 minutes for it to re-write the files to incorporate the patches.
In Arma 3 that would rewrite one or two small PBO's with a few hundred MB. With 3rd party launchers that can do smart patching, it can even do it without rewriting by just plugging new data onto the end.
In Reforger I wait for it to rewrite gigabytes data.
That's even more terrible on consoles that are more write speed limited.

192 byte update? Sure one sec, let me rewrite 17GB of data.

This is just a example of the game itself, but same thing happens to mods alike.

Furthermore, workbench publishing should do more for fragmenting the mod internally

Maybe we can also compare all Files with the CRC Checksum and only uploading the updated files. If you just like to make a small Hotfix, you have to upload the whole 4,8 GB

I second this point from RHS perspective. Splitting mods into multiple mods is NOT the right solution to the problem. Please up this limit accordingly. We are living in the 21st century, my browser eats 5 GB of RAM in a single session.