安裝 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(越南文)
Українська(烏克蘭文)
回報翻譯問題
1. is it a persistent slowdown or more of a lagspike?
2. does it happen when the interface is closed? (for all i know it shouldn't, there is nothing in the mod that actively does anything unless the interface is opened)
3. does it happen when opening the inventory as well?
4. do you have other mods installed that interact with containers somehow? (the interface for this mod is using the same basic system that boxes or the inventory use to display items, just with different interactions on clicking them. i guess if another mod tried to interact with slots in the interface expecting them to work like normal itemslots it could cause issues? but that would probably be very hard to fix)
Also, I'm creating my own C# patch generator that should be decently robust and able to handle both workshop and non-workshop mods, plus some sanity checks and the like, and it'd be easier than trying to reverse engineer your python and existing patches to figure out how they work.
Also, there is no crash log for the patcher, the closest thing would be to run it from an already open terminal (so it doesn't close automatically) and just look at the output