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.