Installa Steam
Accedi
|
Lingua
简体中文 (cinese semplificato)
繁體中文 (cinese tradizionale)
日本語 (giapponese)
한국어 (coreano)
ไทย (tailandese)
Български (bulgaro)
Čeština (ceco)
Dansk (danese)
Deutsch (tedesco)
English (inglese)
Español - España (spagnolo - Spagna)
Español - Latinoamérica (spagnolo dell'America Latina)
Ελληνικά (greco)
Français (francese)
Bahasa Indonesia (Indonesiano)
Magyar (ungherese)
Nederlands (olandese)
Norsk (norvegese)
Polski (polacco)
Português (portoghese - Portogallo)
Português - Brasil (portoghese brasiliano)
Română (rumeno)
Русский (russo)
Suomi (finlandese)
Svenska (svedese)
Türkçe (turco)
Tiếng Việt (vietnamita)
Українська (ucraino)
Segnala un problema nella traduzione
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.