Super Factory Manager ( SFM )

When I leave the server and come back it stops working until I break and replace cables.

TODO: test the rebuild button to make sure it fixes it like how replacing the cables fixes it.

I believe this bug is due to some modded inventories not invalidating their capabilities when the chunk is unloaded.

This causes SFM's capability cache to retain references to objects that have since been abandoned by their tile entity.

SuperFactoryManager/src/main/java/ca/teamdman/sfm/common/cablenetwork/CapabilityCache.java

Line 101 in 0b3faec

lazyOptional.addListener(x -> remove(pos, capKind, direction));

Here is a situation where BigReactors isn't invalidating the capability, leading to SFM being unable to draw energy after rejoining a server.

java_capVjFDemZ.mp4

This theoretically could lead to undetectable item loss, where the source inventory is properly invalidated and restored but the destination is not invalidated leading to items being deposited into a handler that isn't the one that doesn't save its changes.

SFM does try and detect situations where it accidentally voids items, but when the capability itself is rotten this probably won't help.

SuperFactoryManager/src/main/java/ca/teamdman/sfml/ast/OutputStatement.java

Line 180 in 0b3faec

    
           "!!!RESOURCE LOSS HAS OCCURRED!!! Manager at {} in {} failed to move all promised items, found {} {}:{}, took {} but had {} left over after insertion.",

It should be possible for SFM to listen to chunk unload events to manually purge the cache.

If I can get the chunk unload event handler to happen after invalidateCaps is called, we could probably even try and detect when a mod has leaked its capabilities and raise some hell in the console. Should probably make this a config option to help people avoid log spam in case I mess up the logic or if there's a lot of blocks that don't invalidate stuff properly.

Could also make it so that breaking a manager block invalidates the cable network, since people probably expect replacing the manager to fix problems.

Some lines from the logs of a player who was hitting this issue

1m44s ago [TRACE] - power: BlockPos{x=4174, y=72, z=20} Block{biggerreactors:reactor_power_tap}[assembled=true,connectionstate=disconnected,facing=east]
1m44s ago [DEBUG] Gathering slots for IO statement 
INPUT forge_energy:: FROM power EAST SIDE
1m44s ago [DEBUG] Gathering for: net/minecraftforge/energy/IEnergyStorage
1m44s ago [TRACE] Gathering capabilities of type net/minecraftforge/energy/IEnergyStorage against labels power EAST SIDE
1m44s ago [TRACE] Capability cache HIT for BlockPos{x=4174, y=72, z=20} net/minecraftforge/energy/IEnergyStorage direction=east
1m44s ago [DEBUG] Capability net/minecraftforge/energy/IEnergyStorage BlockPos{x=4174, y=72, z=20} direction=east present
1m44s ago [DEBUG] Gathering slots in range set: [ALL]
1m44s ago [DEBUG] Slot 0 - skipping - 0
1m44s ago [INFO] Discovered 0 input slots
1m44s ago [DEBUG] No input slots, skipping

In this case, the power tap energy handler is reporting 0 energy after a relog: Slot 0 - skipping - 0 despite the reactor having power when manually observing the GUI

Share to