1.2? :o

I made an update of this for RimWorld 1.1
https://steamcommunity.com/sharedfiles/filedetails/?id=2035333096
Since I do not know witch mods use this it is not tested very much, so any users of this is welcome to test it with their mods.
Hope this helps!

Just adding support for a 1.1 update as I think this is a great mod!

updet?

Rimworld 1.0 and a bunch of mods (the majority updated to v1.1) here. Since I installed ModCheck (to the top right below Core and HugsLibs), from Steam I got no more logs when starting the game and so far my big final stage game runs smoother.

@Thetaprime I think you're mistaken. The last thing the author said was from August of last year.

Where does he say that exactly?

Quit asking for 1.1 fools. Read a few entries down and the author states he would like to do it, but no ETA.

1.1

update for 1.1?

is look like lots modder need this for update there mods for directly check mods probleme. i reaaalllyyy hope this going updated to 1.1

Newer version 1.0 of modcheck and custom portraits stopped working

need 1.1

I am hoping this will be updated to 1.1 in the near future?

will this mod get update to support game version 1.1?

Hello, nightingale. "The only problem with load order comes from mods including an outdated version of ModCheck. If that is the case, then the newest version of ModCheck needs to be first. If this happens, then ModCheck will provide an error, which should make the issue easy to fix, both for players and mod creators." Does this mean if we get errors from mods with outdated modcheck versions we need to put ModCheck closer to the Core mod, or is it the other way around?

After unsubscribe the mod will cause errors....

Hi nightinggale!
Your mod is a good Thing, I think.

Just made a Russian translation of the description on this page, and About.xml.

Hello Nightinggale,

The game reports me many outdated verison of modcheck.dll. For example:

[Tropi[CKAPP] Rainforest Mod] Using outdated ModCheck.dll
Verse.Log:Warning(String, Boolean)
ModCheck.VersionChecker:IsNewestVersion()
ModCheck.HarmonyStarter:.ctor(ModContentPack)...

And:

[Bulk Stonecutting] Using outdated ModCheck.dll
[Disinfectant stand.] Using outdated ModCheck.dll

What can I do to fix this issue? Report this to the people who developed these mods
or you gonna fix this?

Thank you in advance. Have a nice day and thank you for your mod!

Solved it, got the file from your main site and it worked, while the file on steam seems to be corrupted

Hello, trying to get this to work but seem to have simialr issues, this mod conflicts somehow with core... dont know what I can do to fix it

Anyone know why ModCheck might be disabling RimThemes?

As always you can download ModCheck from the release page [github.com]. ModCheck started out as GitHub only, moved to Steam, but never stopped being released on GitHub.

I'm not sure Fluffy messed up. Steam has been messing up mod releases for multiple mods released recently and not just in Rimworld.

Aaaand, I can't download this mod. Can somebody make a version, what you can put in mods folder and upload it somewhere?

@Makor M240 you're not he only one: Mod Manager is the one to blame. Author of that mod (Fluffy) decided to publish non-tested version and greatly fucked-up. Also, I have the exact same problem as you(((

Not sure what's going on, but I opened my game today and a whole bunch of mods that were still subbed, were saying not installed, I unsub and sub modcheck and they all reinstalled, but now modcheck itself is the last one refusing to install no matter what I try. I don't know if this is a Modcheck issue or if something else weird is going on. Just wanted to put it out there in case I'm not the only one.

Roger that.

Last time a bug was discovered in ModCheck, it was the topic in a forum thread for two weeks before anybody bothered to inform me. I could then fix it overnight and it really needed to be fixed.

It's generally a bad idea to assume warnings are harmless just because nobody fixes the issue. It could be a severe issue not discovered by whoever is supposed to fix it. When there is a warning for a mod, report it if nobody reported it already.

Generally speaking mod creators ad ModCheck without telling me, which is ok. However it means I don't have a list of mods to review for ModCheck issues. As a result, users reporting warnings/errors is the way to go to fix all the mods.

ok. I thought it seemed kinda odd. As for the other mods that are using the outdated ModCheck files. Is it just up to the mod authors to update them? Is it worth caring about or letting them know?

I've seen this log come up in several different mod lists with several different mods. A few of which are pretty big-name mods. Megafauna, Job Splitter, etc. I guess I figured if no one has said anything by now it must not be that big of a deal..?

The reason why it complains is because you mixed versions, or rather there are mods, which includes ModCheck, which haven't updated to use the newest version.

It should list the mods with old versions of ModCheck. However it should never list ModCheck itself as outdated and if ModCheck is loaded before Core, then it should be first. I'm not really sure why the error shows up. All it should show would be the warnings on the following lines about various mods using outdated ModCheck.dll files.

Considering the changes in the last few versions of ModCheck, you are unlikely to encounter problems. However it's not ideal that the error message triggers. Something isn't 100% right.

Getting this showing up on my logs

[ModCheck] using outdated ModCheck.dll. Update all outdated ModCheck.dll files and/or load ModCheck mod first in modlist

Not game breaking. Just wondering how/why/what?

ModCheck is loaded before Core.

i just wanted to say this mod is the greatest thing since sliced bread :D i had a barely stable rimworld save that was becoming fairly unplayable with my 129 mods enabled, found this glorious gem and put it in my save and bam the game is now almost completely stable :D save for the small stutters here and there but point is. this mod is a game changer for hardcore modders and i do recommend it

Well which ever mod has it, was updated as I only use mods from workshop. I haven't done any manual installs for a few years now.

Mods can include ModCheck.dll and that way depend on it even without adding ModCheck as a dependency. The proper fix is updating those mods, but as a player you can get the updated ModCheck by loading this mod.
Most ModCheck users aren't aware they are using ModCheck because they get it from some other mod, possibly without even mentioning it. Usually it's fine, but the recent RW update broke something and I had to release a bugfix release of ModCheck, hence the error.

o.o well i feel silly been looking for the cause of the error [modcheck] and it was as simple as this XD i didnt notice on any of my mod's dependency of having this lawl oh well no errors for me now. "makes side note to go threw all his mods that he sub to later to find and mark the ones needing it"

@KongMD:I finally spotted the error.
Writing to the log depends on the success/fail status of the operation it is written in while completely ignoring other operations. ModCheck.LogWriter can't fail, meaning you have to use MessageSuccess even in the failed operation. MessageFail will always be ignored for LogWriter.

It seems so obvious to use the failed version for the failed class that I didn't spot it while proofreading the xml file. However it is working precisely as the manual stats it should work and I don't plan to change it.

I can't spot any issues with either xml or the ModCheck source in question. Also it worked the last time I tested this. Also I didn't see any problem causing changes in PatchOperationAdd. Apparently I need to go back to ingame testing :(

I've reviewed all of the documentation in detail, but it doesn't seem to work as designed. I've put together a working patch that demonstrates the issue with the code, here: https://pastebin.com/CkKxWwry
The ModCheck.IfElse <passed> and <failed> elements are never evaluated when the <test> element has a bad patch.

@KongMD: It's in the manual, specifically Log writing [github.com]. It should cover your needs.

I'm looking to patch defs if a certain mod is installed. If any of those patches fail, I'd like ModCheck to error out, and tell the user in a friendly way what patch failed, i.e. "RBSE Compatibility: Failed on patch name (patch name)". This isn't possible with vanilla, because the code that logs the error, `PatchOperation.Complete()`, will only run on the parent PatchOperation. In other words, child Sequences will never log errors, even if the patching fails. The game will only log errors from the parent sequence.

Can the ModCheck.Sequence class have an optional field <failMessage> that will log an error immediately if something in the sequence fails? It would be a similar implementation as the ModCheck.Log class, and would address the limitation with child Sequences that I mentioned above.

Alternately, if there's a way to do what I'm looking for in the mod already, please let me know :)

That error happens when a mod includes ModCheck and that mod didn't update. Subscribing to ModCheck and loading ModCheck first will fix the problem.

The proper solution is to get all mods to update the included ModCheck. However I can't update mods released by other people. I assume those mod creators will update soon because they get the error message as well.

I also don't have ModManager, if that is what that part means

I don't have this mod installed and I'm getting the message "[ModCheck] Internal failure patching Verse.LoadedModManager.ApplyPatches". I uninstalled the beta too and I'm still getting this error, also still without ever having modcheck

I much appreciate the update nightinggale!

thanks for the work man

Thank's nightinggale, I appreciate your work.

I released a new version, which works with both stable and unstable branches.

I also made the "Rimworld modification detection" a little less picky. It's still there, but it should no longer trigger if the autogenerated number change. This means ModCheck should not need to be updated if the compiler in the future decides to use f__am$cache1 or some other number.

Interestingly only the detection code was buggy. The unstable branch would not have affected ModCheck if I didn't add the protection layer. However I will still argue that being 100% sure ModCheck can't break vanilla xml patching is the right thing to do.

I found the issue. The compiler has come up with a variable name and named it f__am$cache0. The new version the same variable is f__am$cache2. My code detects this as modified source code and responds accordingly.

The fix is easy (I already got it). However I want to come up with something, which won't break if the compiler in the future decides on say f__am$cache1. Protecting against harming vanilla patching is good, but this is perhaps a bit too much protection.

Hey, yeah this is actually the only mod we can find that's not working with the unstable build.

I'm hoping to set the current unstable build as the default build ASAP. Will ModCheck work with it when that happens? I don't want to break a bunch of peoples' games with a forced update.

I just tested and it seems to work. So I feel good about it.