安装 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(越南语)
Українська(乌克兰语)
报告翻译问题
I left that location and went somewhere else. After like 2 jumps I tried to change my apparel but all of them were set to the apparel policy currently active.
I had 4 apparel policies, Default, Draft, Duster and Parka. I took off with parka and on the new map all the apparel policies were showing parka.
So to try and fix this i jumped back to the location of my grav anchor and all of a sudden my apparel policies were working again.
Unfortunately i took off after that to see if that fixed the issue but it didnt, and a raid happened on the grav anchor location and destroyed the anchor. So now im just stuck with the issue.
Because I put down a Grav anchor on tile and then moved around. When i was away my settings were reset and nothing was saved. But when I returned to the site with the Grav Anchor my setting returned. Is this supposed to happen?
It's pretty small and most of these are also popular ones. None of these should be an issue in my opinion expect vanilla expanded framework maybe. If VEF is really the culprit, I suspect you'd want to find out.
What I mean by reset: I have three policies (Default, Space and Planet). Space and Planet keep getting overridden resulting in all policies having the same apparel configuration again.
All the settings are transferred EXCEPT areas (schedule and animal areas). This is because you moved to a NEW map where the areas do NOT exist. So you need to recreate the areas; this is a feature.
I assume behind-the-scenes that every time you move your gravship to a new map all custom zones get recreated and assignments updated, and this mod needs to replicate that logic.
I deleted my comments about compatibility with Complex Jobs and have created a discussion instead as i noticed a few comments in the list about the same thing.
Hopefully this means you can provide insights into the Discussion so its all in one place and easier to find, rather than having to read / reply to the same comments over and over again :)
Thanks in advance!
-Third tentative fix to 'null pointer exception' bug when saving pawn states;
The error should not happen so what I'm trying to do is to avoid the crash. I've added more logs to further help understand how often it could happen (while trying to prevent the crash)
Is there any way you could patch it so this option could be kept astive without red error?
i was suspecting "automate work prio" mods.
i was playing around with the work policy feature, and had all "automate work prio" mods deactivated and it still on some random trigger changed the work prios to something that wasnt working. i had most of the time just the default policy.
if needed i can provide logs.
(Misc robots) the robot window does not close anymore. Would be amazing if you could fix this, thanks for your work. Until then I have to deactivate your very good mod :(
I checked for incompatble mods but didn't found anything which could be the reason