Messages

Just offering some feedback.  I'm not sure on loading times ATM (I got distracted - don't ask!) but will try again and report on that.  I HAVE noticed an error popping up that seems to be related to Fluffy's Mod Manager. 

[ModCheck] Internal failure patching Verse.LoadedModManager.ApplyPatches

I'm not really sure why it's only reported here (and not to me through the forum) when it explicitly states ModCheck. However I updated ModCheck yesterday to fix this problem and it should be gone by now. If not, odds are that you rely on some mod, which includes ModCheck.dll and that mod haven't updated. If you don't feel like waiting for such mods to update, you can add the ModCheck mod.

The problem isn't even a serious one. It just disables the ability to profile xml patching (performance measurement for modders). Everything else should still work just fine.

When I saw this mod, I became very concerned. For this to work you have to use Harmony and patch the same part of the code as ModCheck is patching. This could result in compatibility issues.

I read through your source code and indeed we are getting close with LoadedModManager.ApplyPatches. ModCheck patches with a transpiler and the code will break if another mod applies a transpiler patch to the very same method. You patch the same method with a prefix, which is fine. They can coexist without disturbing each other.

The only compatibility issue I can see is if ModCheck is loaded before Better Loading Mod, then ModCheck will include your Prefix as time spent patching when profiling patching. It will however not show up when telling time spend on each patch or time patching each mod, which are the important numbers. If ModCheck is loaded last, then there is no problem. I do not consider this an issue we should be concerned with. It's way too minor.

You should add a manifest to make your mod work with Fluffy's Mod Manager. When you do that, just list ModCheck as a mod, which should be loaded after your mod if it's present and then we solved the minor profiling issue. You should add a manifest file anyway since your mod needs to be loaded before Core.

I haven't actually done any ingame testing for compatibility, but from what I have read in the source so far I would be really surprised if there is a conflict. Also nobody reported any issues.

Updated to 1.8.1
- Fixed compatibility issue with updated Rimworld. Profiling works again.
- Updated version URL for Fluffy's Mod Manager

The compatibility issue is related to transpiler patching. In order to be sure nothing bad would happen to vanilla xml patching, I decided to only apply the transpiler if the method in question is unaltered. The unstable Rimworld is viewed as modified because the compiler came up with the idea of renaming the autogenerated name f__am$cache0 to f__am$cache2.

I made the modification detector a little less picky, but it did give us a test that it would actually do as intended if Rimworld updates, which is to allow patch operations to continue to work as intended while disabling profiling. Also vanilla xml patching does indeed seem to be unbreakable by ModCheck.

What are the plans for mod support? All it says is "not yet", which is reasonable considering there isn't full vanilla support yet, but it doesn't hurt to plan ahead.

I want to propose making mods use network code exclusively. This means adding some API, which allows mods to call a certain function with certain arguments in sync. This should give the modding freedom needed to allow mods to run completely custom code in network games.

The next problem is what to do if the network mod isn't loaded. Add a DLL, which adds the API and in singleplayer, just call the requested function without calling any network code. Release such a DLL as a standalone like Harmony or ModCheck and any mod using it can add it.

EDIT: I think the best way to implement such a singleplayer DLL is to make it really simple. Just make it assume singleplayer and unconditionally make calls back to the game. No checks for multiplayer and no network code at all. The multiplayer DLL can then use harmony to make a prefix for the singleplayer call, overwriting the calls and make them transmit on the network.

The problem with adding a DLL like that is what if you update it and mods contains an outdated version? It's a potential problem and the best I could come up with is a function in ModCheck, which throws an error on outdated AssemblyFileVersion. Basically it assumes the DLL in question to have the same version in AssemblyFileVersion and AssemblyVersion. It loops through all loaded mods, locates all the DLL files of the name in question and reads the version number. It will then inform you something is wrong unless they are all up to date. It will just be a warning if the newest is read first because then calls will be made to the first. If an outdated is first, then it's an error. Feel free to copy the file in question to add this check. Just be sure to remember to credit me for this function 

Speaking of ModCheck, it should work just fine in network games. While it does have a DLL file, it does all the work prior to reaching the main menu. Also it does the same each time if the mod list is the same, meaning even if it is required to run in sync, it will apply to the design of keeping network sync by making the same calculations on all computers in parallel without network communication. If you can find any way to make ModCheck to cause desyncs while loading identical xml files on all computers, then I would like to know about it.

Released a new version for RimWorld 1.0. The only other change is added support for Fluffy's Mod Manager.

The DLL is still the B19 file, meaning mods including the file will not have to update.

It's still version 1.8 because the version tag is in the DLL. Updating the number means replacing all DLL files in all mods. It seems like a major task for no DLL change at all.

2. Performing ModCheck.isModLoaded, immediately followed by ModCheck.loadOrder causes ModCheck.LoadOrder to fail. Does anyone have a fix for this?

Huh 
The checks themselves shouldn't influence each other at all, other than the obvious failure stops sequence.

• IsModLoaded
• LoadOrder

If the mod isn't loaded, LoadOrder is never called. If the mod is loaded, LoadOrder should be called just like IsModLoaded isn't there at all. If you managed to get it to do anything else, then do tell about it.

3. If performing three or more operations on a single def, use ModCheck.Search to increase performance. The absolute patch is then Defs/SearchResult/ThingDef.

Yeah that's pretty much it. However like with everything else regarding performance you should likely test the result to see if you get the expected result.

Also remember the wiki on GitHub has a full list of operations, complete with explanations of each possible tag for each and how to use it.

I was vaguely aware of ModCheck, but I was under the impression it only provided patches

I wrote a patch operation, which can have 12 tags like ErrorFail and VerboseMessageSuccess. It writes those strings to the log if the criteria from the name are met (skipping empty ones). The success/fail criteria comes from the other patch operation classes because they all inherit this base class. This means you can get the success/fail from patch operations like IsModLoaded or LoadOrder. There is a total of 13 patch operations, including AND, OR and IfElse, meaning the freedom to configure when to write to the log is really high. In B18 it even had wildcards in the strings, which made it possible to insert mod and file currently being patched when writing the log entry, though vanilla changes killed that feature in B19. Interestingly the log writing code is fairly short and simple. The features mainly comes from hooking into existing code written for conditional patching.

Another feature is with verbose logging, it will profile how long each patch spends patching and write that to the log. This has been used by multiple people to figure out which patches are poorly written and slows down the game startup. This is however less useful in B19 because vanilla code made patching a lot faster, meaning it's no longer possible to write a patch, which takes 1-2 seconds to perform. B18 could spend multiple minutes patching.

The fact that you didn't realize the log writing tells me I did a poor job announcing what I have released 

It likely won't change much for the future though. Mod Manager is a much better solution for telling the user to alter the mod load order and/or which mods to load and will/should take over. The only benefit ModCheck has is it allows adding the DLL like Harmony does, meaning the error messages will not be turned off just because the user didn't load some mod like Mod Manager. This means it's not farfetched to imagine some mod creator using both systems in the same mod and I see no reason why it shouldn't work just fine. In other words Mod Creator will not make me change anything in ModCheck, other than adding Manifest.xml to the next release.

I wonder if I can come up with some interesting ideas for ModCheck and Manifest.xml. I did add the ability to read the ModSync version, but unlike ModSync, Mod Manager kind of already does what ModCheck would do the version from Manifest.xml for meaning it's likely not very useful to add a patch operation to check that version.

A few issues.

1: I forgot to remove MOD-E (which apparently isn't a problem, at least not yet). It's loaded first, before Core. Also ModCheck is loaded before Core. This gives Core a red error.

What if a mod needs to be loaded before Core? Also ModCheck doesn't have to be before Core, it just needs to be before any mod containing ModCheck.dll. Any idea on how to set that up?

Granted after adding that requirement, I did make the DLL check for this itself while starting up. However given that there is now a GUI for this, it would have been nice if the check is GUI compatible and not just a log error if somebody did it incorrectly. It's not a critical issue though, particularly because it's only an issue when mixing versions of ModCheck and it's not like I plan to spray out versions frequently.

2: I'm getting spammed with warnings/errors that mods are for the outdated build 0. I used the last number for version of ModCheck meaning it warns that ModCheck is for build 8. While it would be nice to get everybody to use the system correctly, the torrent of warnings hides the red error on Core when I put the mouse on the error list. In other words if it should keep warning about this, at least give it some priority handling, which makes the red error clearly stand out.

# For Modders
Allows modders to create a Manifest.xml file, enabling a bunch of features that should have been in vanilla;
- version checking
- dependency checking
- incompatibility checking
- load order hints

I added precisely the same checks to ModCheck, allowing mods to write an error to the log if the requirements aren't met. I added this for A17 and updated it for each RW release, yet it doesn't look like it has been used much, or at least far less than I had hoped (I know it is in use). I hope a GUI will have better luck. In fact I would prefer people using Mod Manager as it's a better solution. ModCheck will however live on as all checks doubles as checks for conditional patching.

It's kind of weird to see another mod using precisely the same names for the same checks as my own code. I don't think you downright copied me (though I wouldn't mind if you did). It's more like it's the obvious approach like two people inventing the wheel both end up deciding round is the correct shape.

Overall I'm very impressed. Now I'm really looking forward to mods starting to use this. While the download link is useful, the true power is in the mod order/compatibility setup. It looks simple with a few instructions in text, but considering the length of the list you quickly end up with, keeping track of precisely which mod said what and the actual order becomes problematic.

I just realized RimWorld would be perfect for making an Elbonia mod 

Because you need electromagnetism to separate out the useful compounds.

That's factually incorrect. Even in ancient time the Persians made glass beads, which they placed together with iron ore and melted it all. When it cooled down, the impurities in the iron had bonded to the molten glass and was then trapped in the solid glass. This appears to be the main reason why viking swords were stronger than other swords in Europe at the time. Vikings went through rivers all the way to a Persian trading post where they bought purified iron/steel. Certain types of rock can do the same task, though I can't remember which offhand.

There is also the option of hammering out the impurities. Heat the iron/steel to become red hot, hammer it to bend it into U and hammer it together. Heat it again and repeat. Each time this process takes place, a few impurities falls out. While time consuming, it was the way to get high quality iron 200 years ago.

I'm not even sure electromagnetism is used to get the impurities out directly. I think it's used to heat up the steel and then hammer it to shake out the impurities.


In other words a fueled smelter is realistic and I think I have seen one, but I suspect it was for B17. I don't know if there is a recent one.

Ferengi:
-Slight increase to social impact
-Weak fighters
-Men hate women and women are nudists

Where is the lust for money? Mood and debuffs should be highly affected by wealth. A Ferengi who cares as little for wealth as a puny human is not a real Ferengi. In fact mood should depend on the amount of silver stockpiled. The question is how it should be implemented and if it can be done without resorting to DLL writing.

ModSync is very limited in what it can do, it's nowhere near as robust as its predecessor. It really limits what mod authors can use for file hosting and relies on them to keep an extra xml file up to date for it to function correctly. Hardly anyone has adopted it. Your own system would probably be better.

I have a hard time finding anything in that outburst, which would be correct. I can't see any issues with robustness. In fact not using a central server has removed the single point of failure, which could take down everything. The central server only supported GitHub while the new one supports GitHub, GitLab and Direct. The latter means you can provide the links to each file and it allows using any host, even self hosting if you like. The old system relied on an extra xml file as well.

I can't comment on how many mod creators use ModSync, but your attitude creates a "chicken and egg" issue. It's not really an argument.

Your own system would probably be better.

This is the worst modding statement I have seen in quite a while and the main reason why I reply. You are basically stating that each mod should implement a unique system from scratch. That would really be a waste of the most valuable resource in any modding community: manhours of skilled people. There is a tool available. It gets the job done. Why should anybody waste time creating something new to do the very same thing? Besides if we end up with multiple versions of ModSync clones, all configured in different ways and possibly incompatible, we would likely end up with a mess, which is hard to handle for mod creators and worst case it will make mods incompatible for no other reason than how they try to check for updates.

Think of it this way: railroads have a certain gauge (distance between rails). It can be changed and historically it has happened a few times. Each time it has happened, it has been an epic task, both in manhours and money and it has always been to match some other railroad to allow transfer of trains. Today we have a world standard (with a few exceptions). There are arguments to why it isn't the best gauge in the modern world, but it's a more than 200 year old standard and it's what we got. Sticking to not spending resources on new standards and maintaining a common standard is far better than the possible benefits of changes.

You are basically saying we should do the opposite. There is one standard with ModSync. It works well (despite what you said). You argue that we should abandon the standard, make multiple unique and incompatible systems which hurts both mod creators and user friendliness and I fail to see any benefits at all to making a ModSync competitor. If you are unhappy with ModSync, contribute with an improvement. ModSync is open source and that way you can get whatever feature you request without fragmenting the modding community.

Its great to see ModCheck has been fixed to work with the name of the mod. (tho might be diffficult with mods that change their name due to versions)
The first iteration of ModCheck (or at least last time I tried to use it on my own animal mod) checked against *foldernames* which was a complete disaster and totally useless...
But this is awesome means most animal modmakers (myself included) can ditch those ADS patches

ModCheck started out with checking name from About.xml in A17. Vanilla added a check in B18, which read foldernames. Since this is totally useless, I carried on with ModCheck in B18 using the A17 code, which actually worked in B18 without any modifications. The IsModLoaded operation is actually unmodified when I upgraded to B19, meaning apart from a single performance boost change, it's still the A17 code. Don't fix it if it ain't broke.

The big problem in bringing ModCheck to B19 was the Harmony interaction. Vanilla changed every single line it was supposed to work with and I had to basically rewrite the interaction from scratch. The test release changed stuff again and once again I had to rewrite some of the Harmony code. This is however unrelated to ADS and you can ask in the ModCheck thread if you want to know more details about this.

The short version is that ModCheck worked in A17 and B18 for this task and now it works in B19 too. Also I wrote a new template, which is even faster than the ADS template I wrote for B18. Part of the reason why it's faster is because it's optimized for B19 and wouldn't work as well in B18.

After having released ModCheck for B19, I started updating the wiki manual. I wrote an ADS patching guide complete with a template. It's better than any ADS patch I have seen so far because first of all, it's fast. It's really fast, like around 20 times faster than some other ADS patches and that's not counting patches, which screwed up xpath searching.

The other benefit is that it makes use of ModCheck to only apply the patches if ADS is loaded. This completely eliminates the need for standalone ADS patchmods. The modded animal will work without ADS, but if it's there, it will work with ADS as well without any user interaction at all.

Surprisingly few people have noticed this, which is a shame. The screenshots look awesome. I tried downloading it, but I can't get it to work. I can set the RimWorld path and default path, make new file and that's about it. The new file is blank, like it's not reading RimWorld at all and has no knowledge of what the xml files should contain.

I propose you do something regarding getting started. You have the right idea, but if people can't get started, they will discard it right away.

Once it's easy to get started, perhaps even with a tutorial on youtube or something, then work on public awareness. Perhaps place the mod in a steam mod. Not that it really makes sense to have it there, but right now you are in the same situation as I was in when I first released ModCheck. Nobody noticed it at all. I converted it to a steam mod even though it's actually a standalone dll to add just like Harmony. That did the trick and it has 2950 unique subscribers. I was also busy on this forum to make people aware of ModCheck even if they never read the tools subforum (which apparently is the majority of mod creators).

Last but not least: drop the blue text. It's too eye catching and disturbs the reading experience. Orange is the standard color to use here for such a purpose. It blends well into the other colors, highlights the text while at the same time it's not disturbing.