Jump to content

[MOD][1.5.9] MaterialColor + OnionPatcher


Recommended Posts

A modification pack for Oxygen Not Included:

MaterialColor + OnionPatcher

version 1.5.9

  • Improved temperature overlay with customizable temperature ranges (effect immediately visible in game after pressing Apply)
    • By default the temperatures are more distinguishable and both Red Orange and Turquoise colors are disabled as they are redundant

image.png.b9f4d66a150058bd796621a9648cffe2.png

Temperature gradient on metal tile from -250C to 2000C

Modded

image.thumb.png.7a69e43a19734cef5dc6cde7fe19264f.png

Vanilla

image.thumb.png.78ea311d95a98f12867833c9efa36ed2.png

  • Positions of dragged user interface are saved between game reloads
  • Fixed freeze at 51% on creation of new world with OnionPatcher enabled

Change log

Spoiler

1.5.8

  • Fixed injection error in version 1.5.7, where RemoteDoors.dll was required, but not included in the archive (RemoteDoors.dll is not required anymore)
  • Changed default values for world size, now they reflect vanilla world size
  • Removed obsolete "Show additional info about errors" option in Configurator

1.5.7

  • Made gas overlay customizable

image.png.20c37b0f0372d30d8ad4099583f9a803.png

  • Changed default gas overlay range to 100g - 2.5kg
  • Removed no longer compatible debug log (which caused crash in version 1.5.6)

1.5.6

  • Improved gas overlay pressure algorithm
  • Allowed logic bridges to be placed over logic gates, as requested by @Saturnus (logic bridges are moved to backwall layer)
  • Fixed uninstall script
  • Show info if there are non-critical issues with injection

1.5.5

  • Added improved gas overlay (replaces default oxygen overlay, can be disabled in Injector), suggested by @octoshrimpy

image.thumb.png.7bfeb3de7a5481174b5f4c1ebd81f08f.png

5a3995d915cd8_steamgeyser.png.b04752dfb1986c8f987e94a0e11449f6.png

  • Replaced blank icon on overlay button with one made by @octoshrimpy

image.png.d03b82f291246a55eed50303491bb003.png

  • Reduced lag on overlay change

1.5.4

  • Added a feature to reposition all in-game UI (Requested by octoshrimpy)5a38055885cd7_draggableGUIpreview.thumb.png.ff90281daaaeec744792998f33ca80e2.png
    • Hold Alt and drag with left mouse button
    • All positions will be reset back on game restart
  • Fixed a bug, where utilities were losing their tint after leaving from their overlay
  • Added tabs to remove clutter both in Injector and Configurator

image.png.42317b07fded34df427b290fc0f508fe.pngimage.png.1bd7f4de51fa06f77e096a9f65534d2d.png

  • Brought back legacy tile color handling (Requested by @eggsvbacon )
    • Toggle-able in Configurator

1.5.3

  • Added an option to change gas and liquid pressure switches max values same as temperature switch (suggested by @Neotix)

image.png.960308ba8bf3963eaac2739525f3be17.png

5a35930c02158_liquidswitch.thumb.png.6b26fad512bcc0c4700774419b395d70.png5a359307e7317_gasswitch.thumb.png.d4901c81fb4c0cd0ca51348daac582af.png

1.5.2

  • Added an option to change max temperature for temperature sensor

image.png.ccf2ffdcb5ffbc78bfdfdbae90a710e5.png

It defaults at 1000 Celsius and each change needs a re-patch

ExtendedTemperatureSensorRangePreview.thumb.png.bea2e68c81bc127518dd384867754b75.png

Suggested by @Speadge

  • Added missing color offset for insulated tile
  • Fixed tile highlighting
  • Invalid locations for tiles are now shown in red properly (same as vanilla)

1.5.1

  • Updated for Tubular Upgrade
  • Unified tiles with buildings
    • Mesh and airflow tiles are now properly colored
  • Small retune of a few colors
  • Remote doors are obsolete, so the modification is disabled by default

1.5

  • Updated for Automation Upgrade
    • Updated new and changed buildings
    • Added new materials' colors
  • Temporarily changes to most json files will not take effect immediately, disable and enable the mod to see changes (using hotkey Alt+F6 or button in overlay menu)
  • Added option to disable overlay menu button and hotkey in Injector. It can be disabled if any new patch makes it no longer compatible.

1.4.1

  • Reactivated MaterialColor overlay menu button and hotkey
  • Open remote doors no longer destroy more matter than regular sealing and unsealing
  • Remote doors mod is also enabled by default again
  • Potential spoiler:

UnlockedElementsInOilUpdate.thumb.png.52301d3d976596601ce4650315a31518.png

Mercury, Steel, Electrum, Pyrite from the oil update are now valid materials, so I have properly colored them.

1.4

  • Updated for the oil update
  • Temporarily disabled overlay menu button and hotkey, as it was broken by the update and I need to fix it
  • Remote doors are now disabled by default as I've found out that they destroy matter when left open

1.3.2

  • Added remotely controlled doors, if wire is connected to the mechanized airlock, it will close when power is applied and open when there's no power.
GIF
  • Remote doors can be disabled in the Configurator

image.png.89d6b1fa477949a5e42bc7a21fbf509b.png

1.3.1

  • There can be multiple configuration files for colors now. They are loaded from their directories alphabetically, where the "b.json" overrides the "a.json".
  • Improved configuration of OnionPatcher. Custom world size and seeds can now be toggled.

image.png.e1e5fcdb80cabbcd43cde4153110ea17.png

 

  • Configuration files are now split between several files now.

Element color infos

image.png.a051f8ab7db163828e8cbe26aed36a18.png

Type color offsets
image.png.9a77534d60f4aa256244df45f2e3ba03.png

  • Camera size is now properly updated.

    1.3

  • Thanks to @Moonkis we have incorporated OnionPatcher into MaterialColor. More info about the mod on the original thread:

  • OnionPatcher is now configurable in the new extended Configurator.

 

6kbhqXv.png

  • If prefer to use only one of the mods or if the next updates breaks one of the mods you can disable them completely in the Injector.

N2LHape.png

Beside the features of the OnionPatcher itself, there are other changes that the merge brought:

  • New folder structure with separated log for every application.

FeqnsbA.png

  • Injector is now aware if the assemblies are already patched or not. This makes game updates easier.
  • Prompt to delete configuration files on Uninstall.

OnionPatcher source on GitHub

1.2.3

  • Posted mod open-source on GitHub
  • Added command-line switch for Injector "-i" to inject and "-d" to enable debug console

1.2.2

  • Improved color handling of ruins' buildings and tiles
  • Fixed colors of missing types
  • Added missing offset for FarmTile building

1.2.1

  • Fixed bug at creating a new world

1.2

  • Updated for Outbreak Upgrade

New buildings

  • Changed iron ore offset to match new texture

Iron ore scrubber

1.1

  • Toggle mod on and off with a click on overlay menu

Overlay menu button

  • Use a rebindable hotkey to toggle mod (default: Alt+F6)

Controls panel - Rebindable hotkey

  • Optional alternate color palette (choose from ColorMode combobox) using in-game debug colors

Configurator - ColorMode

  • Example of alternate palette

Alternate sculptures

  • Doesn't work with the Outbreak Upgrade

 

Functionality

As it's hard to differentiate between, for example abyssalite and granite tile or gold amalgam and wolframite thermal regulator, I've decided to create a modification that changes color of buildings and tiles depending on material they are made of.

 

Thermo regulators example

Stone sculptures example

Sensors range

Sensors range can be set in Injector (each change needs re-injection)

https://cdn.forums.klei.com/monthly_2017_12/image.png.960308ba8bf3963eaac2739525f3be17.png

Default max values are set like in the image:

  • Temperature sensor - 1000°C (Vanilla 200°C)
  • Gas sensor - 25 kg (Vanilla 2 kg)
  • Liquid sensor - 10 T (Vanilla 2 T)

https://cdn.forums.klei.com/monthly_2017_12/5a359305b33fb_gasswitch.png.a12d2e04e955622df3fcb5ce91d60834.pnghttps://cdn.forums.klei.com/monthly_2017_12/5a359309a16b1_liquidswitch.png.3fcfb8abccbc530b52704b53d4910c88.png

Extended ranges can prove helpful when using high pressure vent or when working with naturally occurring high pressure environments

 

Legacy tile color handling

This can be set in Configurator to bring back old tile handling, where mesh tiles, gas permeable tiles and tile blueprints (tiles designated for construction) show a color of gas inside them instead of showing a color of material they are made of.

 

As of version 1.5.1 all tiles behave like buildings.

 

Tested on versions:

1.5.1 - 1.5.8

  • Tubular Upgrade (246040+)

 

Spoiler

1.5

  • Automation Upgrade (240229+)

1.4 - 1.4.1

  • Oil update

1.2 - 1.3.2

  • Outbreak Upgrade (229689 - 232512)

 

1.0 - 1.1

  • 220993 - 221865

 

Requirements

  • .NET Framework 4.5.2


Download

 
1.5.9

Old versions

 

Installation

  1. Extract downloaded file to Oxygen Not Included root directory (where OxygenNotIncluded.exe is located)
  2. Run Injector.exe.
  3. Press Patch.

Patching also creates backup of your Assembly-CSharp.dll and Assembly-CSharp-firstpass.dll that can be restored by pressing Restore Backup in Injector.

 

Update

  1. Uninstall, see Remove.
  2. Install again, see Installation.

 

Disable

If you want to temporarily disable this modification.

  1. Run Injector.exe.
  2. Press Restore Backup.

 

Remove

In case you want to get rid of this mod completely. Beware, mod configuration files will be removed too. Back them up if you did change them (see Advanced section).

  1. Run UninstallMaterialColor.ps1 PowerShell script.
  2. Press "y" if you want to remove config files too.

 

Source

This mod is now available open-source on GitHub:

Source

 

More examples

Geyser blocker off with abyssalite tiles

Example room

 

Warranty

I do not take any responsibility for broken saves, corrupted game or any other damage. Use this software at your own risk.

 

Advanced (partially outdated)

Spoiler

 

For every building there is offset to get possibly closest color to gray/white. These offsets can be modified while the game is running. They are located in


Mods\MaterialColor\Config\TypeColorOffsets

Game will reload them as soon as you save the file.

 

As every structure is now white we can paint them with color based on the element they are made of. So for every element there is element color info located in


Mods\MaterialColor\Config\ElementColorInfos

Same as for type color offsets, these are automatically reloaded after you save changes to this file and are immediately visible in game.

As there are a lot of not implemented resources in the game I didn't bother to give everyone of them a color. If material or structure doesn't exist in adequate json config file they will by default have a default color.

 

Configurator

image.png.89d6b1fa477949a5e42bc7a21fbf509b.png

Injector

N2LHape.png

 

 

Donate

Bitcoin

PayPal

I'm currently experiencing some issues with PayPal, please use BitCoin instead.


I would greatly appreciate some feedback.

image.png

Link to comment
Share on other sites

i love the mod with the different materials, but i am unsure about the mesh tiles, because maybe i would like to see if they are made out of wolframite too.

would like to see if ONI itself can be changed to make such mod addable via the (Steam)Workshop

Link to comment
Share on other sites

This is great man. Good idea for the first mod, simple and useful.

Ever wondered about making more generic injector/loader/api? From your, ekhm, bytecode, I can tell that there are some nice lines you got there that could be reused many times ;) 

Link to comment
Share on other sites

@noisycat I'm surprised that you're digging through my code :D

If you're familiar with C# you can already use some of my libraries in your own application. Of course they are quite messy and not prepared for this nor documented, it will be better in future releases. Also I think it's easy enough to use directly  tools that I'm using (reddit question and answer).

I think there are not enough people interested for some kind of generic mod loader. You would still need to actually use C# to achieve anything, or it would require a lot of work from me, but I'll consider it. If You have any suggestions about it, feel free to elaborate ;)

Link to comment
Share on other sites

I am familiar with both of those tools, I used one of them on your assemblies xD Btw, thank you for using wpf and not those crappy winforms xD

Of course I am talking about C# mods, something like abstracting your Core.dll to a mod. A generic loader (injector) would only need to replace/instrument some methods - like your DefaultInjector, but preferably from config or Plugin class.

Well, in my head it looks like this:

  1. Loader loads all .dll's from Mods folder.
  2. Every mod is built referencing mod api core assembly, let's say (ModApi.dll)
  3. Each dll contains some information about name, author, instrumentations and so on probably by finding classes inheriting ModApi.Plugin class
  4. Mod Loaders job would be to patch and revert ONI assembly with Cecil - like you do with this mod, but instead of fixed instrumentations use instrumentations defined in the class.

Additionally, it would be a nice option to track instrumentation collisions, for example when two mods want to replace same function. I'd settle on two basic instrumentations: replace and inject. Replace wipes out the function body and replaces it with user defined code and inject does pretty much the same as InjectAsFirstInstruction(), that is calling plugin method when something in game happens (event-like, yay).

Something along that lines, of course the first step is to allow easy method overrides and make getting protected/private fields simple - it needs some thinking and time, but for sure can be done. Write me a PM with some way to contact you (steam would be great) if you want to talk a bit about this.

Link to comment
Share on other sites

@noisycat  Nice ideas ;)

The mod is pretty much already granulated so maybe creating simple modding api from it wouldn't be that hard :p

2 hours ago, noisycat said:

Something along that lines, of course the first step is to allow easy method overrides and make getting protected/private fields simple - it needs some thinking and time, but for sure can be done.

As you checked the inside-out of my mod you have probably noticed the first step is already done you can use CecilHelper and InstructionRemoveHelper classes, they only need some wrapping.

Now I'm working at version 1.1 and tomorrow I'll need to make it compatible with the Outbreak Upgrade :D

Link to comment
Share on other sites

18 minutes ago, Scorpio King said:

Does not seems to work with Outbreak update? Or its cos of OnionPatcher i use?

Might be, there is two versions of OnionPatcher (reason stated in OP) have you tried the new (or both) version in the top of the OP? I don't think (from skimming) that they should clash.

Link to comment
Share on other sites

I love this idea of colour coding tiles based on material used - and it's something i've talked about on stream for many moons now :D

I'm not so keen on this idea, as it seems a little pointless to me?  : 

On 20/08/2017 at 1:14 AM, Etiam said:

Mesh, gas permeable tiles and tile blueprints

Mesh tiles, gas permeable tiles and tile blueprints (tiles designated for construction)  are special. Instead of showing a color of material they are made of they show a color of gas inside them.

Awesome work though buddy - hopefully it'll inspire the devs to implement this soon, as it's a wonderful aesthetic change to make bases feel more custom/stylistic.

@Cheerio - is this doable ;)

Link to comment
Share on other sites

@Lifegrow Thanks for you feedback! As I mentioned above, this was done by mistake.

On 8/20/2017 at 10:04 AM, Etiam said:

@Hanmac That was my primary goal about the mesh tiles, but I have failed to implement it. It was a bug that changed into a feature ;)

As i couldn't get the color of mesh and gas permeable tile with the same approach as with the standard tiles, all I've got was the element inside the cell itself. I could left the mesh tiles with a default color, but instead I've decided to leave it like it is.

Tile blueprint can be useful, for example if you want to verify if there is only one element in a gas tank (select tile, and just hover over the area of the tank).

Gas permeable and mesh tiles can be used, if placed alongside the walls, as an indicator of various unwanted gases in a chamber. If the upper half of the meter is pink, it means half of the room is filled with hydrogen. Same applies for CO2, Chlorine, etc.

Maybe I'll try to fix it in future releases, probably as an toggleable option in the Configurator.

Link to comment
Share on other sites

Man... I thought a patch broke this mod, but after an uninstall and reinstall its working on the lastest version.  I'm so glad, because after playing with this mod I do not ever want to go without it.  Seriously, thank you for creating this!

Link to comment
Share on other sites

On 23/08/2017 at 4:07 PM, Etiam said:

I think there are not enough people interested for some kind of generic mod loader. You would still need to actually use C# to achieve anything, or it would require a lot of work from me, but I'll consider it. If You have any suggestions about it, feel free to elaborate ;)

I agree with you. Modding right now seems not very fitting. The game receive big update on a regular basis which are likely to break mods. Many of the things we may want to patch may be added into the game by the devs sooner or later. (That is the case for Onion Patcher and Material Color)

But the history repeats itself. You are already two modders to develop the same thing (the patcher) and none of you have released their code. This is what happens on most of the modded games.

  1. More and more people develop mods to the game and we are starting to see incompatibilities between the mods.
  2. At some point, someone declares that its enough, it can not continue like this and develop a generic patcher to the game.
  3. He is not the only one. On some games we can have three or four dominating patcher trying to manage the compatibilities between them.
  4. Some modders don't like some patchers so depending on the patcher the player use he may have access to different range of mods but seldom to all the mods he wants to use.
  5. Some incompatibilities from mods can be solve by developping a common interface for modding and a core module which adds to the game to merge modifications and integrate them in the code. (This work very well for tabled data which can be append each other but when all mods try to modify the game at the same time, only one will win)
  6. In some cases, a scripting language is used to help mods integrate each other. Hopefully it's an existing language (Lua, Python, etc.) but often it's a brand new language, perfectly impracticable,  designed by the patcher developer.

Developing a generic patcher early has a huge advantage if it is well done. It dictates a way to integrate mods and will ease (not solving, but helping a lot) all the incoming compatibilities problems.

If one of you two happen to don't have time to maintain your mods anymore or loose interest to the game, your work will be lost. It would be really cool if you could put your patcher code in common and distribute your code - at least the patcher code - on a public repository (gitlab, github, etc.) where we could submit merge request. Thus the community could have a generic patcher which can evolve even if you decide to stop working on it, and add functionality you don't necessarily need on your mods. Moreover it could help people like me who wants to try some things but don't want to dig into the assembly code.

Link to comment
Share on other sites

On 9/2/2017 at 11:41 PM, zennyrpg said:

Man... I thought a patch broke this mod, but after an uninstall and reinstall its working on the lastest version.  I'm so glad, because after playing with this mod I do not ever want to go without it.  Seriously, thank you for creating this!

Thanks. Mod will probably still work for any small patches and hotfixes ;)

 

On 9/3/2017 at 2:18 PM, Cilya said:

I agree with you. Modding right now seems not very fitting. The game receive big update on a regular basis which are likely to break mods. Many of the things we may want to patch may be added into the game by the devs sooner or later. (That is the case for Onion Patcher and Material Color)

But the history repeats itself. You are already two modders to develop the same thing (the patcher) and none of you have released their code. This is what happens on most of the modded games.

  1. More and more people develop mods to the game and we are starting to see incompatibilities between the mods.
  2. At some point, someone declares that its enough, it can not continue like this and develop a generic patcher to the game.
  3. He is not the only one. On some games we can have three or four dominating patcher trying to manage the compatibilities between them.
  4. Some modders don't like some patchers so depending on the patcher the player use he may have access to different range of mods but seldom to all the mods he wants to use.
  5. Some incompatibilities from mods can be solve by developping a common interface for modding and a core module which adds to the game to merge modifications and integrate them in the code. (This work very well for tabled data which can be append each other but when all mods try to modify the game at the same time, only one will win)
  6. In some cases, a scripting language is used to help mods integrate each other. Hopefully it's an existing language (Lua, Python, etc.) but often it's a brand new language, perfectly impracticable,  designed by the patcher developer.

Developing a generic patcher early has a huge advantage if it is well done. It dictates a way to integrate mods and will ease (not solving, but helping a lot) all the incoming compatibilities problems.

If one of you two happen to don't have time to maintain your mods anymore or loose interest to the game, your work will be lost. It would be really cool if you could put your patcher code in common and distribute your code - at least the patcher code - on a public repository (gitlab, github, etc.) where we could submit merge request. Thus the community could have a generic patcher which can evolve even if you decide to stop working on it, and add functionality you don't necessarily need on your mods. Moreover it could help people like me who wants to try some things but don't want to dig into the assembly code.

Thanks for your feedback!

Of course I don't want to let my work be lost. We will try to make some kind of open-source modding API if time allows ;).

Also I'm already in touch with the developer of the OnionPatcher @Moonkis . We want to merge our projects together and make the result open-source too!

For now it's all still in the planning phase.

Link to comment
Share on other sites

On 2017-09-03 at 2:18 PM, Cilya said:

[...]

 

2 hours ago, Etiam said:

Thanks. Mod will probably still work for any small patches and hotfixes ;)

 

Thanks for your feedback!

Of course I don't want to let my work be lost. We will try to make some kind of open-source modding API if time allows ;).

Also I'm already in touch with the developer of the OnionPatcher @Moonkis . We want to merge our projects together and make the result open-source too!

For now it's all still in the planning phase.

Like @Etiam said we have already talked a bit behind the scenes of merging each others work as a short term solution, and then refractor them into their own mods once an API is developed (long term solution).

I frankly don't buy the whole "It's too early"-argument, as most breakage is small. More often than not, it's pretty easy, or a feature becomes obsolete anyways so it doesn't matter. OnionPatcher, whilst being a very small focused mod on unlocking some goodies, has only broken once, and it's been out for a long time. I mod because it's fun, that's my drive, and because it's a great learning experience, and getting familiar with it early is a lot better than later. The early stages is where the most fun lies, it's exciting, fresh and unchartered!

OnionPatcher should have been (admittedly) put on Github a long time ago, but I have been incredible busy with a huge move/job-change so it completely slipped my mind. As soon as I have my new place in a somewhat decent state, it's going up on Github. In a good tl;dr I was lazy and I will own that mistake.

Modding communities tends to develop in that order where you get a ton of crazy software that does the same thing, but different. That's just kinda how software development works. Usually it's healthy and it leads to new alliances and better programs, of course users suffer a bit because compatibility is a pain to maintain during this time, however at some point this usually ebbs out and a select few becomes the "standard". It's just kind of how these things work, no matter in what point of the games life-cycle we are in.

I have no doubt that Klei will add modding of their own, it's already been a legacy feature in ONI so they have definitely toyed with the idea, considering how well it worked for DS/DST.

Just my two cents.

Link to comment
Share on other sites

8 minutes ago, Moonkis said:

Modding communities tends to develop in that order where you get a ton of crazy software that does the same thing, but different. That's just kinda how software development works.

It's how it works, not how it should work. It works like that because people don't talk or don't find an agreement. I'm happy to see you both already talked together.

 

11 minutes ago, Moonkis said:

In a good tl;dr I was lazy and I will own that mistake.

I wouldn't consider that a mistake. Perhaps you just need more people supporting your work to consider useful to do it.

 

12 minutes ago, Moonkis said:

At some point, I have no doubt that Klei will add modding of their own, it's already been a legacy feature in ONI so they have definitely toyed with the idea, considering how well it worked for DS/DST.

I have no doubt they will allow modding either. But perhaps not as powerful as your patcher is. Custom maps and POI, custom materials, custom textures. But not necessarily the ability to change anything in the engine.

Link to comment
Share on other sites

Hi guys,

I love mods and always look for utility mods who make the game more realistic, like yours. And happy to know a second one exist.

I encouter a little problem who isn't one I think but I like to know how things work. For a lot of my games on Steam, when mods modify original gamefiles, I just make  a copy of the game in specific folder. I do that cause steam don't like for a lot of game (or perhaps those I have) mods not comming of the workshop. and check gamefile and replace modified gamefiles to originals one.

 So I do it for ONI but your mod don't work in another folder. I would post it don't work but I try in the steam folder and he work great.

my question is why ?

 

PS: sorry for my bad english, it's not my native language

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...