Steam 설치
로그인
|
언어
简体中文(중국어 간체)
繁體中文(중국어 번체)
日本語(일본어)
ไทย(태국어)
Български(불가리아어)
Čeština(체코어)
Dansk(덴마크어)
Deutsch(독일어)
English(영어)
Español - España(스페인어 - 스페인)
Español - Latinoamérica(스페인어 - 중남미)
Ελληνικά(그리스어)
Français(프랑스어)
Italiano(이탈리아어)
Bahasa Indonesia(인도네시아어)
Magyar(헝가리어)
Nederlands(네덜란드어)
Norsk(노르웨이어)
Polski(폴란드어)
Português(포르투갈어 - 포르투갈)
Português - Brasil(포르투갈어 - 브라질)
Română(루마니아어)
Русский(러시아어)
Suomi(핀란드어)
Svenska(스웨덴어)
Türkçe(튀르키예어)
Tiếng Việt(베트남어)
Українська(우크라이나어)
번역 관련 문제 보고
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.