BaYoNeTTe's mods

Hello space settlers,

I plan to do a bunch of smaller and maybe also slightly bigger mods around various features of the game. Since some of them may be useful, I’ll publish them on Steam. Here you can find additional information (especially about compatibility issues with other mods, if known), report bugs or even request new mods that I may assist in doing. Although my spare time is very limited, so don’t expect too much :disappointed_relieved:

logo StartGamePaused

Once after loading this mod hits the pause button for you (and also after dismissing the welcome dialog on a new game). If you are one of those people like me who may wander off doing other things during the sometimes lengthy loading process, then this mod may be for you.

logo NoLevelUpMessage

Suppresses the city level up messages. Since they have no real meaning in the game anymore and can be quite annoying if your habs downgrade frequently below a level-up threshold, this mod helps you get rid of them.

logo Clean Terraforming Panel

First of all this gives you a steeper color gradient when looking at total progress so you can discern spots not quite at 100% more easily.

Secondly this fixes some calculations regarding Terraforming. It didn’t take into consideration the whole map but only a quarter of it, which should be fixed. More importantly, the map coverage of the individual terraformers now consider only the playable map area rather than the whole world, which should be much more useful.

Keep the game running for at least a minute after loading to get accurate numbers. Terraforming progress is only very loosely saved, so the game first needs to warm itself up after loading.

I am sorry if there are some issues and remaining inaccuracies in this mode. Fixing this was a lot harder than anticipated.

logo Consumption At Start

Resources are removed from the incoming storage at the start of each production cycle, rather than at the end. This will fix several issues you may have with deliveries not being made in time. This also enables Drone Fertilization to work correctly.
Another small change is that buildings with almost full output will stay at 100% progress until at least one of their producibles falls so low that finishing the production won’t waste any of that producible (vanilla IS: as soon as 1 output is missing 1 unit, it will finish production, potentially wasting a bunch of its outputs).
At the same time this update smoothes out production times by reducing a mini-lag of several frames that occurs in each cycle. This makes your production numbers more accurate (the numbers stay the same, but the actual production changes).

Finally, unless your infrastructure is sub-par you will now be able to supply all buildings with their resources before they stop production. So I made all buildings issue resource shortage warnings immediately instead of having a 10s grace period. Same for power. Also applies to habitats.

Car Speed Visualization

When turning on car visualization your cars won’t all be red. Hopefully at least. Cars get color grades: red, orange, yellow or green, based on their speed. They will be green at a speed of 60 or faster, which is a concrete road. I chose this as the limit for green because that is the minimum road level you want to have in late game. If you forget to upgrade some roads, cars will only be yellow on gravel road. Side roads only allow for orange speed but that is ok. If you see red anywhere, then you have a problem in that place. This mod will help you find the places that prevent you from reaching 100% traffic flow.

If you have really many cars, using this mod may impact performance quite a bit. Getting this to work at all required some tricks, so please let me know if there are any issues.

More Raods On Big Stations

The Large Station and the Main Station have a total of 8 input and 8 output roads, so twice as many as previously. The duplicates are next to the original ones, so now inputs and outputs come in pairs. This mod is a quick placeholder for a proper revamp of the (bigger) stations that I want to do at some point.

logo Convenient Laser Targeting

Improves your experience with the laser targeting station in the following ways:

  • Mineral deposits can only be selected when you hold CTRL while clicking. No accidentally lasering your good stuff away. (To de-select, also hold CTRL!)
  • Misclicking doesn’t deselect the targeting station.
  • Holding SHIFT you can select a whole area to be lasered clean (except minerals).
  • Improve the highlighting of selected targets.
  • Add a button to the menu bar that will select a laser targeting station. Doubleclick will zoom to it as well.
  • All targeting stations share a target list. This helps avoid some bugs that exist in vanilla InfraSpace.

Warning: With this mod it is very easy to select many objects at once. The GUI doesn’t like that though and there is no way to unselect an area. If you accidentally select too much, you will have to demolish all targeting stations to quickly deselect. Also, it will still take hours to laser everything into oblivion, because lasering speed is not adressed with this mod.

@Daniel While fixing the Terraforming Panel (see above) I hopefully resolved some bugs (or intended behavior?).

First of all, the individual terraforming types’ map coverage should only relate to the playable map area. The players have no interest in the total world coverage, I think.

To fix this, two places need to change. The first is TerraformingManager.GetTerraformedTypeCoverageArea(). It needs to look something like this:

        public float GetTerraformedTypeCoverageArea(string type)
            int tilesOnPlayableMapPerDim = (int)(progressDim.x * playableAreaSize / worldSize.x + 0.5f);
            return (float)(terraformBuildingsManager.GetTerraformedPointsCountPerType(type)) / (tilesOnPlayableMapPerDim * tilesOnPlayableMapPerDim);

If you look at the original you will see that the playableAreaSize cancel’s itself out in the calculation, thus you end up with dividing by the terraforming tile count of the entire world.

The second part that needs to change is in TerraformBuildingsManager.TerraformerJob.Execute(). I had a really hard time working with this one because I can’t patch the method directly. I guess that’s because of the attribute [BurstCompile] :sob:

My decompiled version probably looks a lot different than your original. It has a ton of local variables that are just decompiled to Num1, Num2 etc. for which I devised new names based on what I thought their meaning was. I will use screenshots for this explanation.

First of all, this code section which is used for the individual terraform type coverage needs to move down into an IF so they are only counting the playable map area:

This will basically be the required changes for the playable map coverage. But the Execute() method also has another severe issues, which is happening here:

The variable I dubbed progressOnMapStart is calculated correctly, but the variable progressOnMapEnd is not. It is using the size of the map, whereas it should really use corner+size, e.g. like this:

int progressOnMapEnd = Helper.ProjectClampInt((int)mapCorner + mapSize, 0, (int)(worldSize - 1f), 0, terraformedProgressDim.x - 1);

The mapCorner is 512 or something, the mapSize is 1024. So you want the range from 512 + 1536 covered. At the moment you are only covering 512 to 1024, which (since we are talking surface area) is only a quarter of the playable map.

Changing this may incur some rounding issue. In my version, I also needed to change the following condition, turning less-than-or-equal to less-than only:

Hope this helps make InfraSpace even better!

Thanks a lot Bayonette!

From a quick glance it seems like you are right. I’ll look into it later this week.

@Daniel I released another mod, Consumption At Start. I consider this an overall improvement to the game, so suggest to considering to take this over into the main game.
But the reason I’m mentioning you is not because of that, but because I found several things while creating this mod. Two tiny bugs I highlighted in separate threads. But there is another issue I learned about that you should pay attention to:

There is an inaccuracy in FactoryProductionLogic.UpdateSimulationThread(). This causes production times to longer by about 10 frames than they are supposed to. For factories with slow cycles this is hardly relevant, but for fast ones (5s, or even faster with efficiency boosts) this amounts to about 4% slower output than you are advertising.

I made a setup with just a sand mine (5s cycle) on a basically empty map, so frame rate was constant. I measured about 10 cycles as accurately as my reflexes allowed, and the real time was always longer than 5s, usually it was around 5.2s. The 200ms is equal to the 10 simulation frames I mentioned. I tried to fix the deficiency with my mod, too, and measured again. The times were spot on 5s, or very slightly around that (measurement inaccuracy).

The problem is here:

			if (productionTimeStep < productionDefinition.timeSteps)
				productionTimeStep = Mathf.Clamp(productionTimeStep + possibleProgressPer10Frames, 0, productionDefinition.timeSteps * 2);
				lastProductionSteps = possibleProgressPer10Frames;
			else if (!OutgoingStorageFull())
				productionTimeStep = 0;

When a production cycle is finished, you simply set the productionTimeStep to 0. This doesn’t account for the fact that production in those 10 frames may have exceeded 100% progress. E.g. if it was at 99.95% in the last update and afterwards it is at 100.45%, then you basically wasted 0.45% of progress. This would be no problem for a sand mine operating at 100% efficiency though, because it makes 1000 progress every 10 frames and needs exactly 25000, so it always hits the number spot on. A second effect is that you need to check for the progress immediately after you added the progress. The current code waits until the next update to check for progress. These 10 frames are wasted, waiting at 100% progress. I think you can even see that on the progress bar if you have very quick eyes. There is a tiny stutter at 100%.

For reference, my implementation:


I also needed to change Produce() and Building.UpdateFrameThread(), but FactoryProductionLogic.UpdateSimulationThread() is the meat of the action.

byte district = WorldScripts.Inst.districtsManager.GetDistrict(__instance.consumerProducer.building.GetPosition());
            __instance.consumerProducer.lastStepPowerProduced = 0f;
            int possibleProgressPer10Frames = Mathf.RoundToInt(100f * __instance.GetEfficiency()) * 10;
            ___lastProductionSteps = 0;
            if ( ( ( __instance.logicOverride != "spaceship"               ) ||
                   ( __instance.productionDefinition.consumables.Count > 0 ) ) &&
                 ( ( !__instance.HasTerraformingLogicOverride()      ) ||
                   ( __instance.consumerProducer.building.HasPower() )       ) &&
                 ( !__instance.OutgoingStorageFull()                         ) &&
                 ( ( ___productionTimeStep > 0             ) ||
                   ( __instance.IncomingStorageFulfilled() )                 ) )
                __instance.couldWork = true;
                if (___productionTimeStep == 0 && possibleProgressPer10Frames > 0)
                    ModifyIncomingStorage(__instance, -1);
                ___productionTimeStep += Mathf.Min(possibleProgressPer10Frames, __instance.productionDefinition.timeSteps);
                ___lastProductionSteps = possibleProgressPer10Frames;
                if (___productionTimeStep >= __instance.productionDefinition.timeSteps)
                    if (__instance.IncomingStorageFulfilled())
                        // immediately produce again
                        ModifyIncomingStorage(__instance, -1);
                        ___productionTimeStep = Mathf.Max(___productionTimeStep - __instance.productionDefinition.timeSteps, 1); // 1 minimum to mark that resources were already spent
                        // no resources, reset progress to 0
                        ___productionTimeStep = 0;
                __instance.consumerProducer.lastStepPowerProduced = __instance.productionDefinition.powerOutput;
                if (__instance.consumerProducer.lastStepPowerProduced > 0f)
                    __instance.consumerProducer.lastStepPowerProduced *= __instance.GetEfficiencyExceptPower();
                __instance.couldWork = false;
                if (__instance.HasTerraformingLogicOverride())
                    Old.buildingModule.terraformerUpdater.UpdateEfficiency(__instance.consumerProducer.building.GetID(), 0f);
            double productionFactor = 5 * 60 * possibleProgressPer10Frames / (double)__instance.productionDefinition.timeSteps;
            foreach (ResourceCost consumable in __instance.productionDefinition.consumables)
                Old.GetSimulator().market.AddConsumptionPerSecond(consumable.resource, consumable.amount * productionFactor, district);
            foreach (ResourceCost producable in __instance.productionDefinition.producables)
                Old.GetSimulator().market.AddProductionPerSecond(producable.resource, (double)producable.amount * productionFactor, district);
            __instance.consumerProducer.lastStepPowerNeeded = (float)GetPowerNeeded.Invoke(__instance, null);
1 Like

It seems you can’t edit posts anymore after 1 month? @Daniel It would be nice if you can change this setting, even if just for me. I really need to edit posts in the modding category for longer than that. There’s also the reference topic, and I plan to have a bigger mod in the future that will also need updates over a longer period of time.

I think there is an open point about laser targets not being highlighted in all cases. Some environment objects don’t highlight properly or only very little. I tried many different settings and in the end what worked best across almost all objects is to set the _EmissionMap to a plain white texture while the object is targeted. You are using the emission map to create some nice glow effect for some stuff, but it’s making setting the emission color useless. I also deleted the special shader cases, because they don’t seem to be relevant for environment objects? Here’s my current version:

public class EnvironmentObjectPatch
    private static int emissionMapID = Shader.PropertyToID("_EmissionMap");

    public static bool SetTint(Color color, EnvironmentObject __instance, ref bool ___tintUpdatedDuringOverrideMaterial, bool ___overrideMaterialActive,
                               ref Color ___tintColorCached, Color ___noTint, int ___emissionColorPropertyID, int ___colorPropertyID)
        bool updateAfterOverrideMaterial = ___tintUpdatedDuringOverrideMaterial && !___overrideMaterialActive;
        if (color == ___tintColorCached && !updateAfterOverrideMaterial)
            return false;
        ___tintColorCached = color;
        ___tintUpdatedDuringOverrideMaterial = ___tintUpdatedDuringOverrideMaterial || ___overrideMaterialActive;
        if (updateAfterOverrideMaterial)
            ___tintUpdatedDuringOverrideMaterial = false;
        bool useNoTint = color == ___noTint;
        MaterialPropertyBlock emissionColorMpb = new MaterialPropertyBlock();
        emissionColorMpb.SetColor(___emissionColorPropertyID, color);
        emissionColorMpb.SetTexture(emissionMapID, Texture2D.whiteTexture);
        for (int i = 0; i < __instance.meshRendererInfos.Count; i++)
            MeshRendererInfo meshRendererInfo = __instance.meshRendererInfos[i];
            MeshRenderer meshRenderer =;
            if (useNoTint)
        return false;

ok, I changed the setting. Can you edit your old posts now?

1 Like

Yes, the button is back. Much appreciated!