Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
This is one of my mandatory scripts on all larger ships I make. Love the work you've done.
Are you still willing to update it, there are some things I'd like to se if is possible,
for instance: even when excluded the script turns power back on for doors with [excluded]
Ideally reactors would only be drawn from if all other factors won't be able to fully supply enough energy for a certain amount of time. Using Uranium when it's not necessary is a waste and having a centralized system for management is better than having a dozen PBs for each component, that's why i asked.
Actually, is it possible to sort blocks by powerdrawn? If the script were able to detect when the power wouldn't be enough for more than X minutes (with reactors) and would then try to deactivate the most demanding block (then trying again to check if it's enough (and perhaps with possible arguments)) that would make it a lot more resilient energywise.
This script did used to have a battery management module, but with changes to the power API along with "smart" batteries (i.e. leaving all battery option unchecked), I decided to remove that module.
I haven't checked things lately though...
change this
var subtypeName = item.Content.SubtypeName;
to this
var subtypeName = item.Content.SubtypeId.ToString();
and the script works.
There are several scripts that need this change.
Content.SubtypeName with Content.SubtypeId.ToString()
Other option would be to slow down the oxygen manager to 2-3 seconds, so it does have enough time.
...though I haven't tried recently.
I saw recently that they gave up on oxygen/pressurization, so now it defaults to off in the world settings. Really stupid, IMO, but oh well...
Post your blueprint someplace, doesn't have to be on the workshop, and I'll have a look later in the evening.
You're running stable, I'm guessing? Because I'm sure this script is broken in the development branch. I'll have to switch back to stable and that might take some time because of my slow internet.
If they're at 100%, the airlock won't depressurize and it won't unlock the inner door.
Since hydrogen was added, I switched to having each airlock air vent connected to its own oxygen tank. Seems to work better that way since the presence of an hydrogen tank on the conveyor network will throw off the oxygen manager (because they look the same as oxygen tanks to scripts).
I'm not much for videos, so here's an MS Paint diagram instead [i.imgur.com]. ;)
Then you send the prog block "commands" by using the PB arguments (best to do this on a button panel, like I have on my ship).
1. "space AirlockMain" (don't type quotes) to open the space door
2. "open AirlockDoorInterior" (no quotes) to equalize pressure and open the inner door. Doesn't matter if the interior air vent is pressurized or not, it will try to match pressurization.
There are other commands too described in my docs, but those are the main ones.
It follows the old behavior if no groups are found.
And I dislike tagging too, which is why most of my scripts are block group based. But tagging still makes sense for exclusions.
Alternatively, I've been wanting to make the door auto closing module group-based. It would also make it possible to have different time delays for different sets of doors.
It's something I've found I need, but I'm not sure if it'll be useful to anyone else, so I don't document it. :P