Object Cleanup

• Unpowered
• Why skip solar panels by default?
• Attributes and Subtypes
• Joints
• Examples

If a cleanup is to be run, SEMU will loop through the SectorObjects and when it hits a CubeGrid (e.g. a space station or ship), it'll run a check to see if it should be removed.

The following commands are involved with a cleanup;

• [--cleanup-unpowered]
• [--cleanup-include-solar]
• [--cleanup-missing-attrib]
• [--cleanup-missing-subtype]
• [--ignore-joint]

Unpowered

The unpowered cleanup is basically what it says. It'll clean up objects that don't have;

1. an enabled reactor with fuel in it or
2. a battery that is charged and either set to discharge or semi-auto
3. if the [--cleanup-include-solar] has been used, enabled solar panels

Why skip solar panels by default?

It's nice and easy to detect the existence of a solar panel, it's rather difficult to check if it's powered or not.

To make that determination, it's orientation to the sun would need to be calculated and checks to see if the sun is being blocked need to be made, either blocked by itself or another object.

Doing this purely from the save file is next to impossible and a world simulation would likely be required, which would be overkill just to check if a solar panel was being powered.

You can force the matter using [--cleanup-include-solar], but it won't check to see if it's working so you run the risk of having dead objects with dead solar panels floating about.

When used with the Subtypes / Attrib cleanup commands, it will be an AND comparison. Even if an object matches the required attribs or subtypes, if it doesn't have power, it's going to be removed. Likewise, if it has power but doesn't have at least one of the required attribs or subtypes, it will still be removed.

Attributes and Subtypes

[--cleanup-missing-attrib], [--cleanup-missing-subtype]
Using these commands, you can specify what objects are required for an object not to be cleaned up.

A Subtype is a definition of what kind of block it is. E.g. LargeHeavyArmorBlock

An Attribute is a special tag given to some XML nodes of blocks within CubeGrids and could also be called Categories. Whereas you could use the subtypes "LargeBlockLargeReactor", "LargeBlockSmallReactor", etc... you can just the attrib "MyObjectBuilder_Reactor" which encompasses all reactors.

The list of attribs & subtypes are an OR comparison. So as long as the object has at least one block that matches the given attributes or subtypes, it will be marked as OK.

These two commands work together. E.g. if you've got a set of required attributes and subtypes and an object has the subtypes but not the attributes, it's still safe because it's got at least one of the required subtypes.

Attributes
DO THIS LIST

Subtypes
DO THIS LIST

Joints

Joints include motors (rotors and stators) and pistons (pistontops and pistonbases). Unfortunately, SE has stopped recording joint entities in the saves and the joints themselves are calculated when the game loads. If a rotor is really close to a stator when the save is loaded, it will join them.

This means that by just reading the save, it's not easily possible to check that out. Until it can be worked out how to map those joints, all objects that have a joint on them will never be removed for fear of breaking things.

This can be ignored by using [--ignore-joint] but by using it, you accept the fact that it will likely produce 1-ended joints with parts of an object cluster being removed while others remain.

Examples

Nice and easy, if it's not powered, remove it.
--cleanup-unpowered

Want all objects to have a powered beacon to survive?
--cleanup-unpowered --cleanup-attrib MyObjectBuilder_Beacon

Want to keep things that have power providers, even if they're dead?
--cleanup-attrib MyObjectBuilder_Reactor MyObjectBuilder_BatteryBlock MyObjectBuilder_SolarPanel