Celebrating 100+ users. Added Isobrew! Nuclear Waste and Ice, effects is "Glowin' All Day" (Luminescence and Radiation Resistance).

@dje353, will add nuclear drinks shortly!

Nuclear waste coffe to make the dupes glowsticks let's go ! :P

Mmm, fair, Discord is almost certainly a better discussion environment for this type of thing. For what it's worth, I can think of at least 3 different locations and at least 4-5 styles for config handling just off the top of my head amongst the mods I use, so ya, it's definitely all over the place out there >.<

I'm totally willing to change how I do configs,but now I've got a couple of mods using this system so I'd like to standardize on a best practice and focus on more interesting development! May I suggest you start a thread on the discord and see if we can align to some kind of consensus on the best practice; what I have it more or less what they suggested and I'd already changed it several times before they even weighed in. Again - I'm not tied to what I have at all, but perhaps best to take into a place where more people can see and comment.

3/3) On a side note, it might be worth changing the config location to the /mods folder, rather than the mod's numbered steam folder, as that entirely avoids the issue of files being overwritten on update, since the config isn't in the numbered folder at all anymore. One mod I use (Customize Buildings) uses `Path.Combine(Util.RootFolder(), "mods")` to point to that mods folder, rather than depending on `Assembly.GetExecutingAssembly()`. That mod (and all of Fumihiko's mods, as far as I know) also uses a versioned config file, with a specific version key at the top level in the JSON, so the configs can be updated as changes to the structure or fields are added, without unconditionally overwriting what the user puts in it. You can an example of that here: https://github.com/Truinto/ONI-Modloader-SimpleMods/blob/master/src/CustomizeBuildings/_CustomizeBuildingsState.cs#L749

(2/3) Having a folder of JSONs would also be nice for sharing potential "sets" of user drinks tailored towards different types of players. As an example, the effects section made me realize that the +1 Athletics from the original espresso is, frankly, kinda pitiful. So I reduced the morale boost on all of them to only +2 (by the time I have an espresso machine and a pincha farm, I don't need another +4), and instead made each one have a sort of themed effect. Espresso was already good for haulers, so now it gives +2 Athletics and Strength. Gravitino got +2 Science and Machinery. Moochiato git +2 Ranching and Farming (because moo!). I added a Slicksterillo made with biodiesel and salt that gives radiation resistance and transit tube speed (because greased!) Not sure if those would make sense for default drinks, but users could submit drink sets that could, at your discretion, be included as default-off drink files with the mod's config folder.

(1/3) Also adding to and the rewriting to the JSON if fields are missing. For example, you added the Duration field to the effects section, and all of my effects suddenly had a duration of 0 because I had not defined that field in my config previously. The mod could have detected that state, filled in a rational default, and written back out to the config file with the updated value and the new structure (while preserving the other content in there, the custom drinks and effects and such). Notably, one thing that CANNOT be done currently, with the "default config" being baked into the assembly, is to *remove* any of the new drinks the mod adds. They can be changed, and additional ones added, via the config, but any drink removed from the config is still added by the mod, because it loads the default additions *and then* the user config. I noticed that when you renamed some of the drinks in the last update, suddenly I had duplicate drinks with slightly different names.

Without knowing anything about the mod, modding of ONI or even having the mod installed: What if you just had several config files? Then you could have a default_recipes.json for the default recipes that are always overwritten (with a warning within the file not to modify it) and a user_recipes.json which contains user recipes and is never overwritten.

Or you could have an entire folder of jsons. Would make exchanging recipes between user much more simple (just put file into directory). Renaming files would deactivate them ("heavens_brew.json0" is not recognised as a json file)

And maybe an additional "disable.json" for disabled recipes. Another one that never needs to be overwritten, but you could easily switch recipes off (and on) with that file.

Now supports other solids (mushroom and muckroot) drinks in the example file. Note: only supports a single solid right now. Most drinks, just like a coffee shop, are still Peppernut (SpiceNut) based.

[author] Just now
@Kaedys, we had a long discussion mod-dev on this, it's a deep topic. Your suggestion is a good one and one I considered. The problem with that is that if I make updates in the internal default config the many items the user doesn't change from the first time they run it, will just stick there forever. It will be painful to determine which they kept because they liked them and which they won't mind if I overwrite. So current based practice is to encourage the user to just make layered on "differences". I'm definitely open to improving this aspect, but I can't commit to those settings I make when i first launch the mod to be the be-all end-all, I want to chance to tune them based on user feedback and playtesting. DM me as a friend if you want to discuss this aspect further.

this is very awesome caffeination

As a recommendation to avoid confusion, could the mod create the file with default contents if it is not found when the mod is loaded? That avoids the issue if the default one overwriting the config when the mod is updated, while still ensuring the file is there to be found by the user (it's also how most other mods work, as far as I understand it).

the User.CafePlusConfig.json file goes in the directory that the mod is installed in. It has the format of the one linked above. That one is not visible; it's embedded in my DLL because otherwise your changes would get overwritten when I update the mod. Copy the one linked above to your steam mod directory alongside the DLL, rename it User.CafePlusConfig.json and make edits to it. You can add new drinks or override my drinks. My suggestion is to keep it minimal and only override / create the new things you want, otherwise you won't get my updates (they will be overwritten. Make sense?

Side note, does this mod create a default config anywhere, if one isn't found? I don't see a file or directory for its config in any of the usual spots, nor is it in the mod's actual directory (which some mods do), and the description isn't precisely clear where to place such a file, if we have to create one manually (especially since mods commonly store configs in one of at least 4-5 different places)

ok! i'll look at it. Thanks for feedback. Maybe upgrading the Juicer is in order too. I was trying to stay in the flavor of the game and not turn it just a generic "make anything" machine. Making things user customizable is a bit of risk as I lock in the internal file formats I've created for external use, and honestly I don't know if people are actually using them (like I did for the ArtifactPlus mod which allows extensive modifications).

Anyway, I do think control over the item ingredient would be worth it. For example, maybe bionics prefer their Petroccino seasoned with Gold Amalgam or Dewdrip instead of Peppernut =P. I also personally think Toasted Mimillets should be a standard replacement for Peppernut in the coffee machine. I think the distinction for me is that I'd likely only be setting a single item ingredient for the coffee machine (though I think it reasonable for the config to *allow* multiples), while the juicer requires several instead.

...honestly, I'd love this level of control over the Juicer, too. I think the Juicer implementation makes sense in the default cluster, but it really should have alternative ingredient options for the DLC clusters. They started doing that for cooking recipes, ex the Megafrond grains are equivalent to Sleetwheat, Pikeapple can be used to make Berry Sludge in place of Bristle Blossom, Ovagro Figs or Pikeapple Skewers can replace Gristle Berries for Mixed Berry Pie, etc .

But the Juicer is still hard locked to specifically Dusk Caps, Bristle Blossoms, and Mealwood, with no alternative options permitted. It's outdated and frankly annoying, because it's much harder to get a juicer up and running in a DLC cluster, and depending on which planets you actually pick, if using a mod to adjust the cluster, it may actually be impossible to get all 3 of those plants.

I thought about allowing controlling the ingredients , it’s pretty straightforward , but I guess at some point it just becomes the same machine as the juicer or any other kitchen appliance .

Yes “All” allows both boop and dupes to have the drink .

新饮料mod

Love the idea. Would it be possible to also control, via the config, what physical items are required for the recipes, instead of it always being peppernut? Also, may be worth noting in your example config that "All" is an option for AllowedUsers.

I left the default (water-based) espresso so that both standard antibiotics can drink it , but yes that’s how I implemented the new tricks.
They have different modifiers as well.

so bio dupes can't drink water/milk and normal dupes can't drink petro/oil?