Інсталювати 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