thenicestguy / se-frugalairlock Goto Github PK

View Code? Open in Web Editor NEW

0.0 2.0 0.0 451 KB

Airlock-management script for the game Space Engineers

License: GNU General Public License v3.0

C# 100.00%

airlock game-space-engineers mdk-se ingame-script game

se-frugalairlock's Introduction

SE-FrugalAirlock (a.k.a. TNG's Frugal Airlock)

An airlock-management script for the game Space Engineers

TNG's Frugal Airlock is a C# script meant for a Programmable Block in the game Space Engineers by Keen Software House. It enables the setup of airlocks: enclosed, airtight spaces that allow engineers to easily pass between low-oxygen zones (i.e., "vacuum") and breathable zones (i.e., "habitat").

Compared to other airlock strategies, TNG's Frugal Airlock places priority on a few key principles, in this order:

No oxygen is ever wasted. When properly set up, an airlock will never vent any O₂ into the vacuum, nor will it use up more O₂ from a main supply than necessary.
The form factor, ergonomics, and user interface of your airlock are up to you. The script requires a few obligatory elements to be in place (obvious things like Air Vents and an airtight structure and less obvious things like drainage tanks), but beyond those it doesn't care about size, shape, or style.
The player should not have to touch the script. Configuring the script to work with your design is done by adding INI-style text to the CustomData of your various airlock-related blocks, from a well-commented template. Blocks that trigger airlock operation are easy to set up with well-documented commands. There is no need to edit the script with a list of block or group names, nor is any naming convention imposed.

Complete details are in the wiki.

How to Use this Repo

Most end users will just want to go straight to the Releases and download the latest ZIP, but not the one marked as "Source Code". The release ZIP contains a "pre-cooked", ready-to-eat script.cs file, and a Template.ini file that provides a guide to configuring your airlocks. To use, just paste script.cs into a Programmable Block. Template.ini will explain its own use, basically, but you'll want to read the the wiki for a complete understanding.

TO DO: This should eventually be available on the Steam Workshop for even easier use. It's not mature enough for that yet.

If you're more interested in the source code and guts, you'll need not only Microsoft Visual Studio (this solution was created in 2019 Community Edition), but also the MDK-SE extension for Visual Studio by malware-dev. MDK-SE does the "cooking" of an organized codebase into a single Space Engineers script, along with lots of other conveniences. It's absolutely indispensible for anyone serious about Space Engineers scripting.

se-frugalairlock's People

Contributors

Watchers

se-frugalairlock's Issues

Code Program constructor to create Airlocks

Scan blocks for the appropriate CustomData and form them into Airlock objects.

Implement queuemode command

It's already documented in the wiki.

Implement forcemode OpenToHabitat

The controller will recognize the forcemode command.
The only supported mode so far will be OpenToHabitat.
The airlock will correctly assess its current state and take the most sensible steps to reach the OpenToHabitat mode without wasting O₂.
The forcemode command will be documented in the wiki.

Implement state saving

The script does not save any state between game loads. This might cause unusual behavior when an airlock is given a command but doesn't correctly remember what state it was in. Serialize and deserialize important members of the Program and Airlock classes.

Add REDISCOVER command

Implement the script's first command: REDISCOVER

With no argument, it forgets and rediscovers all airlocks. If a specific airlock is named, it forgets and rediscovers only that one. If ~~a bad~~ an unknown airlock name is given, it ~~errors out~~ tries to discover the new airlock and accomplishes nothing if it does not exist.

Don't forget to begin a new Command Reference page in the wiki.

OpenToVacuum mode does not drain chamber

To reproduce:

Set up a basic airlock named airlock1. For simplicity, give it only one each of inner door, outer door, fill vent, and drain vent.
Run forcemode OpenToHabitat airlock1
Confirm that airlock operates as expected: pressurized to match habitat, inner doors open, outer doors closed and locked.
Run forcemode OpenToVacuum airlock1.

Expected:

Inner doors close and lock. Chamber depressurizes to match vacuum. When matched, outer doors open.

Actual

Inner doors close and lock, but chamber never depressurizes.

Notes

This is very strange, because examining the details of the components suggests that it should be working. I've observed this seemingly paradoxical state:

Fill vent and drain vent both enabled and set to depressurize.
Filled volume of drain tank actively increasing.
Pressure of chamber remaining at 100%.

This would make sense if the chamber were not airtight or if the fill vent were actively refilling it while the drain vent is draining it. As far as I can see, these are not true. Perhaps something is being manipulated in an incorrect way at a rate too fast to notice.

Implement PressureLight role

Add an optional airlock role: PressureLight

A PressureLight may be any kind of light and is appropriate to place inside the airlock chamber or near any airlock door. The script will control its power, color, and blink rate. At this time, these are not configurable but hardcoded to:

Green: Chamber matches Habitat

Flashing amber: Chamber pressure is changing

Red: Chamber matches Vacuum

REDISCOVER should attempt to make airlocks safe

Docs for the rediscover command claim that affected airlocks will be placed into their safest mode once discovery is done. Currently, modes are not even implemented, so obviously it does not.

No INI template

The end user needs a well-commented template for the INI to include in their airlock-related blocks.

Allow button panels to control airlock cycles

Add the HabitatTrigger and VacuumTrigger roles. Allow these to be assigned to Button Panel blocks. Have the script set up the proper button actions upon discovery.

Airlock does not self-validate

All of an airlock's mandatory blocks can be included into an Airlock object, but it has no way to confirm that its requirements are fully met. Add an IsComplete() method, or something like that.

No Airlock class

Create an "Airlock" utility class to hold all the objects and properties of an individual, discrete airlock.

Fill out Airlock with references to all mandatory blocks.

Ignore the nice-to-have blocks for now. Just make sure you can get from an Airlock to its necessary features like inner and outer doors. Populating these comes later.