Messages

Wow! I was just looking at your mod, man! What a coincidence hahaha. I had a second of paranoia: "how does he know that I was looking at his mod???".

Well I'm known to people around me as being good with computers 

Yeah, it is certainly something I want to work on, considering the easy patcher isn't updated yet!

In my point of view, adding dependency on a mod should only be done if it's beneficial. Now that vanilla can handle the task, it's pretty much a deathblow to all the mods, which offers conditional patching. I suspect easy patcher might not be updated for the same reason as I'm considering stopping development of the part in ModCheck, which does the same as PatchOperationFindMod: it's pointless to make a mod, which provides a feature provided by vanilla.

The way I see it butchering is for meat. Leather and other products are just byproducts.

Obviously you haven't used BoneMod in a biome with lack of trees. Particularly early on it's valid to butcher for bone because it's much faster than stone cutting, but also much weaker.

And I suspect that only meat can take up way, way more space than the carcass, which is the reason I'd like that option. So meat doesn't overflow the freezer.

That really depends on the animal. If that is what you are thinking and ain't using any mod to change the max stockpile size, you should always butcher animals with less than 75 meat and use colony manager for the rest.

And another mod convert all animal meat into chicken meat, then you just got one animal meat.

Hmm.... this lion tastes like chicken 

Patch for Animal Collab Project (this one is b18, yay!):

I just took a quick look. From what I can tell, this is a candidate for using PatchOperationFindMod. This will allow you to make the patch file trigger only if A Dog Said is loaded, meaning it will work if the patch file is in the main mod and not a standalone patch mod. If somebody fail to add ADS, it will just ignore the patch file. The result is the distribution of just one mod, which is easier for the users and there is no risk that a user ends up using ADS without also using the patch mod.

It's a wonderful feature, which is so far poorly documented and it seems the majority of modders have missed that it was added in B18.

I wish butchering animals allowed you to "Do until". You seem to know what you are doing. Could you add support for this please?

Do until what? Stockpiled meat? leather? bones? Something else from a mod yet to be written? Because butchering can provide lots of different stuff, this becomes somewhat complex. Disassembling mechanoids is also using the butchering code. Sure I would love to get good support for this, but I have to point out that there are more to it than just say "Do until".

I have plans for taking the code I made for BoneMod and release it as a generic library mod to allow xml only mods to add butcher products, which scales for body size, missing body parts etc. If BWM is going to expand in this area it would be a good idea to do some coordination to make the mods interact nicely with each other, hopefully in a generic way where the individual creatures/items can be added in new xml mods and it will just work.

Will mods for A18 work for B18? I'm confused :S

A18 = unstable version 18
B18 = stable version 18
The last A18 has the same build version as B18, meaning anything working in A18 should work in B18.

While technically correct, switching from A to B is causing so much confusion that I'm not sure it was a good idea. Personally I might have picked staying with A until the final release, or just stayed with A forever as that is what people have been taught to use over the years.

Is there anybody, who use the patch operators from ModCheck for conditional patching?
I mean the only real reason to do that is to patch if a mod is loaded or not loaded using ModCheck.isModLoaded and B18 fixed that issue with PatchOperationFindMod.

The reason I'm asking this is that I have run into some limitations and is considering to discontinue PatchOperations and implement my own system. The benefits would be the following (most likely incomplete):

• Allows translated text
  Patching is done prior to loading the language, making translation impossible.
• Much cleaner xml layout
  With complete control of the xml loading code, everything goes as short or long as needed.
• Better control and easier access to fixes
  I just had one error repeat 415 times and fixing that seems... tricky
• ModCheck xml is ignored if user didn't load ModCheck
  Right now that will cause errors, meaning ModCheck is mandatory. A new system will make it optional.
• Xml file should be planned to work with a mod for the mod list in the future

The mod list is not something I have plans for at all for the time being. However with a well defined xml layout and C# code to copy paste to pass the xml file, any mod can read the contents and say add red dots if mod is missing requirements or order is incorrect and even write what is wrong. One beauty of this approach is that if somebody writes such a mod for the modlist, the mod creators can write one xml file to support both mod list and ModCheck, making it really easy to use both.

The only issue is that the new system doesn't support patching based on mod order or mod version. I don't really see a big need for this though, but since those are already released, I feel like I better need to ask. Maybe I should just leave those in the DLL and ignore them. It's not like they will hurt the ability to add a new system.

They're cute and all, but I wish they were aliens rather than farm animals.

We all do. However now I start wondering about milking and shearing. I wonder what it would take to add this ability to humanlike pawns. It would actually be cool to add this feature to the alien framework.

What about the ADS Patch?

Don't make patch mods for your own mod. Use PatchOperationFindMod instead. This allows you to make a patch file, which is only applied if a specific mod is loaded, meaning the main mod can include the patch mod. It's a great step forward, but for some reason the link I provided is more or less the only documentation on it.

Alternatively you can do the same thing (and more) with ModCheck.

In my opinion this feature request is not in the scope of the original idea, so i will not include this.

I completely agree with that statement. We should be careful not to turn mods into a random collection of semi-related or random features. Having said that, a mod for map overlays is not a bad idea. Soil fertility, move speed, dirt level. There are plenty of interesting options for map overlays. Perhaps it would be fitting to propose this to the temperature map overlay mod as it's already a mod about map overlays.

Could you remove the extra work to increase space. In the screenshot you will understand what I'm talking about. This would free up space for the saved settings as it was before.

If you mean not showing the jobs if there is only one job in the category, then I disagree with that approach. The resulting issue would be that if you manually open a category and it won't open, then you don't know if it's because the click didn't register or because it only has one job. It's much better to reveal that there is just one job. Also people would complain saying it's a bug that not all categories can open.

What I think you should do instead is read the popup text from hovering over a category. It actually tells how to open and close each category individually and usually you only want to have one or two open. The ability to open all is not particularly useful and adding lots of mods only makes it worse. It's good to be able to close everything with one click though.

I really like the new system. There are mods, which moves jobs to new categories to allow individual priority settings, but this approach is a lot better. It's (often) easy to overview while at the same time it allows more specific control than any other mod.

That's even better than adding a check
Yeah the only time order matters for patching is if you rely on patching before or after another mod patches and I can't imagine any case where that would be a good idea.

Make sure that "Fertile Fields" appears *after* "Vegetable Garden" in your mod load order.

ModCheck is able to cause your mod to write an error in the log if Fertile Fields is loaded before Vegetable Garden. This is done with the following patch file and ModCheck.dll, which can either be loaded as a standalone mod or added to your mod like harmony is added to each mod.

Code Select Expand

<Operation Class="PatchOperationSequence">
<success>Always</success>
<operations>
<li Class="ModCheck.loadOrder">
<modName>Vegetable Garden </modName>
<yourMod>>[RF] Fertile Fields [a18]</yourMod>
</li>
</operations>
</Operation>
Note: the space after Vegetable Garden is intended because it has to use the string from name in About.xml and apparently Vegetable Garden has such a space. That's not ideal, but at least the current version of ModCheck is strict about this 

Trying to follow along here so pardon my denseness.  Possible quality settings:

Awful
Shoddy
Poor
Normal
Good
Superior
Excellent
Masterwork
Legendary

Correct me if I misunderstand but, vanilla will randomly choose one of the above qualities.  Static will choose quality solely based on your construction skill level (higher skill level equals higher quality - construction skill 20 will craft legendary items consistently).

Here's where I'm not sure.   Quality + -1 and Quality + -2.  So a random quality number (from awful to legendary) would be picked from the game engine and then lowered by -1 or -2?

Vanilla will calculate based on some complex formula, which relies on construction skill, manipulation and possibly other stuff. This means even with really high construction skill, you can still make Shoddy furniture, which can be really annoying, particularly if you decide of making it out of jade or similar hard to get stuff.

If you use static quality it will calculate a quality based on construction skill. Say it's Normal. If it's +-1 it will randomly be from Poor to Good and if it's +-2 it will randomly be Shoddy to Superior. At least that's how I understand what's going on.

By the way, I downloaded your modcheck mod.  Will it help check for mod conflicts (and the reason for the conflict) if the mod developer didn't incorporate your mod to check his mod?

Sadly it's way too simple for that. It's not that I haven't thought about it, but it would take weeks to code at best and what I have made was made in a few days. Also what I made is so simple that it's easy to test and avoid bugs. Autodetection is so complex that it's quite hard to get working reliably. This means it's useless until mods starts to support it, but such mods have started to appear and I suspect it will have a snowball effect. The more mods using it, the more subscribers, the more subscribers, the more likely it is that more mods will add support. The number of subscribers have reached 3 digits already for A18 alone.

This is kind of off topic for this thread though and there is a thread for such questions. It's not like the link is hidden 

Can someone explain what the item quality options do?  I'm reading them (vanilla quality, static quality, static quality + - 1 & static quality + -2 ) and they don't make sense to me.

When you build something with quality, say a bed, this option will be used to determine the quality (poor, good, etc) of the bed. Vanilla is has a large range of possible outputs. This mod however adds a table for which quality to get based on the colonist's construction skill. +-1 and +-2 will then add randomness to that, meaning it will pick a random quality out of 3 or 5 options where the table lookup is in the middle of the range. Selecting static quality means no randomness.

Do plants have to rest in real life?

No and in fact in real life greenhouses are often equipped with artificial lights to make the plants grow 24 hours a day. They can also be heated. When the oil crisis kicked in during the 70s, it was revealed that flowers were grown using both lights and heating and half a liter of oil was used for each flower. People became upset about it because they let the car stay home to save oil and then tons of oil was apparently wasted on flowers, which were meant to be sold and then thrown out after max 2 weeks.

Iceland has large scale heated and lit greenhouses. They learned that they have (by Icelandic standards) very fertile soil and steam coming out of the ground right next door. Seems too strait forward to not put those two together.

Yeah, Steam seems to be the place to post mods.  I got far more users there than from here.  But, that's all right, I like it here.  Lots of helpful, friendly people.

I realize that's the case for players, but it has turned out it's the case for modders as well.

The only bit of trouble I had was which mod name to use, the folder name or the name in About.xml.  I obviously figured it out, but maybe you should throw that in the guide on your Github page to prevent any future confusion.  Other than that, everything was very easy to follow.

Updated and good point. At the time ModCheck activates, it only has access to xml contents and is not really aware of folder or filenames. Well it might be aware of other stuff, but I haven't found out yet. This makes it obvoius that it's the name inside an xml file. I tried to write the guide to not require any knowledge of how the code works, but it seems I missed this one.

That sounds good.  I was going to ask about the patch operation staying the same, since I don't really want to go back and rewrite it all...lol 

Completely as expected 

The thing is that now ModCheck is on steam and for all I know modders will start to depend on the user adding ModCheck rather than downloading the dll. This means if I update on steam and it's not backward compatible, a worst case scenario is that maybe half the mods break. This is of cause completely unacceptable and even the excuse "it's very easy to fix in xml" is not good enough. This means breaking backward compatibility is simply not an option.

If I have to do something, which will break backward compatibility, I will add a new class, possibly based on copy paste of an existing one and then change the new one. Existing mods can then continue to work off the old class. It's entirely likely that I will update the guide to tell modders not to make new mods using the old class, but it will still be there to ensure mods will not break.

If a mod breaks from this (like the user stops using ModCheck), all what will happen is an error in the log each time a ModCheck class is called and all the calls will return false, like mod is not loaded, regardless of it is or not. Other than that, the mods will behave normally, meaning they will often be fully playable. Even if it's not the end of the world to cause problems like this, I will still avoid it as much as possible.

Would something that lets users know about compatibility patches be possible?  For example, I have a patch for Vegetable Garden in my mod.  When someone activates my mod would it be possible to have it say something like "Hey this mod works great with Vegetable Garden!" or something else along those lines?

That's a nice idea. Here is what I'm going to do:

• Add two new optional strings to xml (names still unknown). One is for success, the other is for failure.
• If not empty, the string matching the test result will be written to the log.
• if errorOnFail is set, the fail string will be written as an error (red)
• if errorOnFail and the string is empty, the current strings will be used for error messages

It's nice and simple and it allows great freedom to write whatever you want to the log. Maybe adding default options like "yourMod: detected modName and patched itself to become compatible".

Perhaps have it in green text on the log, a pop-up, or something in the Mod Settings menu?  And, while I'm at it here, maybe also a way to direct them to the Steam/forum page to download it (a url in the xml maybe)?  I'm just starting to learn about C#, so I don't really know what is and isn't doable in regards to this kind of stuff...so don't worry about it if this isn't possible.

All nice ideas, but they all clashes with the design strategy, which is to make a lightweight mod, which adds classes to be called from xml and not touch existing code. By not touching any existing code, the chance for conflicts with other mods is kept at a minimum. It's likely part of the reason why the very same DLL works on both A17 and A18. Not just the same code, but the very same file. The difference between A17 and A18 releases is the number in About.xml and nothing else.

I agree it would be nice to add such info in the mod load menu, but it would have to be done by some other mod. Maybe I will do something like that in the far future, but not anytime soon and it will be in a different mod. It is important that if it conflicts with anything else modding the mod menu, people can turn that feature off without turning ModCheck itself off. With a little creativity, it should be possible to make some xml layout, which can be executed by both mods, meaning you only have to write once that your mod works together with some other mod.