I know that feel

me too,but singleplayer

yes. router input-output location settings do not always save, or they save inconsistently.

Having the same issue.

any work around for this? I get the same issue but I would like it if they could save.

I think the autor said he would update this

Same issue would love if anyone finds a work around thanks

Finally fixed. Sry

Nguyên văn bởi TP:

Finally fixed. Sry:bbtcat:

Thank You! <3

uhm... i start to make my routing again and now are they loss less information in routers than before, but they are putting random inputs/outputs in some cases :s (that can be happening cause i'm using a lot of routers, i will test more and send more informations)

EDIT1:
when the chunk where the router is, load first, or the router erase the configuration of all the inputs/outputs who doesn't load yet, or he try to send this input/output for some who have loaded in the same chunk.

I'm not quite sure what you mean. Does it select a container right next to the original input/output?

yes, i test with all close (5 blocks between them) and a far away (like 50 blocks), if i go away and return, the game sometimes reload the router and one of the containers but not both at the same time for example, in these case, the input/output just gone.

if we have 3 containers, it clean all the inputs/outputs or put in the first container detected (one time he put in the far container of 5 i connect with 4 routers).

i will print some and record, it will probably more easier to show you

Nguyên văn bởi TP:

Finally fixed.

Not working for me :(
When I leave planet all routers resets.
And sometimes they transfer items from containers that even don't connected to tubes...

I've had routers actually start transferring items into other routers' filter slots, mucking up a nontrivial automated beehive farm repeatedly - this irritated me enough to start debugging the problem myself, and I think I've pinned it down. At least I didn't have to look any further than router.lua.

It looks like the Starbound engine actually pools and recycles objects (or at least EntityId values can be reused for different entities over time) so just checking if the references to input and output are valid is not enough - they can remain valid yet change to point to a completely different object. If I reacquire references to the containers at inputPos and outputPos on every call to routeItems() regardless of apparent validity of the references, the router never accidentally latches onto the wrong objects.

A full clean-up would require permanently eliminating input and output from the storage table, storing only inputPos and outputPos, but probably adding them back to the table returned from getConfig() so the UI doesn't break.

Consider it confirmed. The router settings have been completely stable with this modified version of routeItems():