I think people overstate the usefulness of the eco management, except for maybe the mass fab parts + prevent stall to keep shields up late game.

Maybe integrate some of the UI features and if/when mass fab management is in the base game the mod can be removed from the vault. I haven't been maintaining it for years anyway.

New UI options available for all players and better performance by providing sim-side data:

• Mex overlay for level / upgrade status
• Build status% of your teammates nukes / anti
• Mex upgrade: One click / right click assist start mex upgrade

Features which already moved into FAF:

• Upgrade shields multiple levels at once
• Queue up acu/scu enhancements with shift
• Auto build mex storage rings

Features that can be removed:

• Autoshare

Only shares resources with other ecomanager players. Had a use in the RAS air builds @ setons but now useless, replaced by one click share in the UI.

Only nice thing is when the ACU dies it instantly dumps all units / mass / energy to the rest of the team instead of 5+ second delay

• Energy throttle

Basically only useful for mass fabs and somewhat prevent shield stall late game. Otherwise mess up more than it helps

• Mass throttle

Not very efficient and cannot compete with someone semi-competent manually upgrading mexes.

@jip game_15190526.log

Played a fafdevelop game where ACU upgrade after it should finish got stuck and acu was constantly -7 mass.

(I was assisting ACU with cybran t1 assault bot)

This error popped up in the log:

warning: Error running OnStartBuild script in Entity url0107 at 25034d08: ...gramdata\faforever\gamedata\lua.nx5\lua\sim\unit.lua(901): attempt to call method IsUnitState' (a nil value) stack traceback: ...gramdata\faforever\gamedata\lua.nx5\lua\sim\unit.lua(901): in function UpdateAssistersConsumption'
...gramdata\faforever\gamedata\lua.nx5\lua\sim\unit.lua(971): in function UpdateConsumptionValues' ...gramdata\faforever\gamedata\lua.nx5\lua\sim\unit.lua(852): in function SetActiveConsumptionActive'
...gramdata\faforever\gamedata\lua.nx5\lua\sim\unit.lua(2570): in function <...gramdata\faforever\gamedata\lua.nx5\lua\sim\unit.lua:2533>

Before deleting any replays, consider the following:

• New format for .fafreplay, compressed achive of the scfareplay-file and the json-data without the final b64-encoding

Comparsion of size:
scfafreplay: 1222 KB
fafreplay-current: 260 KB (21.2% of original size)
fafreplay-zip: 196 KB (16.0% of original size)
fafreplay-7z:: 141 KB (11.5% of original size)

• Publish the replay vault (maybe IPFS?) so people can mirror / clone the replays for historic reasons.

• Create a service that collects local replays from players to be able to repair current broken / missing ones in vault

EDIT:
Did some more testing and the compression numbers were a bit messed up earlier. I've updated the post now with my results.