Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Thank You! <3
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.
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
When I leave planet all routers resets.
And sometimes they transfer items from containers that even don't connected to tubes...
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.