Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Nightinggale

#16
ModCheck 1.8 has been released. The main change is B19 support and dropped support for B18.

Vanilla made a complete rewrite of xml loading from mods, meaning ModCheck had to be partially rewritten too. Now all files are read, merged into one giant xml file and then patched. This is a great move because it's much faster, even faster than ModCheck could make B18. However since there is no longer an owner of the file being patched, FindFile is dead. I did work on preserving it, but it didn't turn out well and actually slowed down patching. You will have to rewrite FindFile to either not use it at all or use the other operations to test for presence of other mods.

I added a search operation. It's used like this:
<li Class="ModCheck.Search">
<xpath>Defs/ThingDef[defName="WatermillGenerator"]</xpath>
<operations>
same code as a sequence
</operations>

What it does is whatever it finds will be moved to Defs/SearchResult/ThingDef and then back once operations are done. This mean xpaths can use "Defs/SearchResult/ThingDef" instead of "Defs/ThingDef[defName="WatermillGenerator"]". It has an overhead in setting up, which is around 2.5-2.7 xpath searches (at least if only vanilla is loaded). However if you need to do 3 modifications it will be faster because "Defs/SearchResult/ThingDef" is following a path, not a search. If you need to do 4 operations, it's still faster than 3 vanilla operations with a searching xpath. In other words it's a performance boosting tool for the cases where you need to do a bunch of operations to the same item.

I also added the Move operation.
<Operation Class="ModCheck.Move">
<xpath>Defs/ThingDef[defName="SolarGenerator"]</xpath>
<followers>
<li>Defs/ThingDef[defName="AdvancedSolarGenerator"]</li>
</followers>
</Operation>

This will make use of the fact that it's now one big xml file. What is does is that it will find xpath and then it will take whatever is in followers (it's a list of unlimited size) and move the elements to be right after the xpath element. In this specific case it will move AdvancedSolarGenerator to be next to SolarGenerator. If multiple followers are added, they will be added in the order they are written. This should allow placing the buildings in useful groupings rather than the vanilla approach, which is semi random based on load order.
#17
Tools / Re: [LIB] Harmony v1.2.0.1
September 14, 2018, 03:35:04 PM
Now it works :D

Testing with another mod was a good idea. Released mods using 1.2.0.1 works, but it didn't fix the problem with ModCheck specifically. However it started making the log complain about failing to locate Harmony 1.1.0.0. I went into Project->Add reference and tried to replace/update the harmony reference, but it didn't work for some weird reason. I then ended up deleting all references and start over adding all dll files again and that fixed the problem. Somehow I must have had a reference to 1.1 hiding somewhere, though I'm not sure how and now that it's fixed, it's a little tricky to go back to investigate.
#18
Tools / Re: [LIB] Harmony v1.2.0.1
September 14, 2018, 12:34:17 PM
Can somebody explain why I can't get v1.2.0.1 to work when v1.1 works?

More specifically, ModCheck (GitHub) currently has 1.1, but if I update to 1.2.0.1, I get the following:
ReflectionTypeLoadException getting types in assembly 0Harmony: System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.
  at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)
  at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0
  at Verse.ModAssemblyHandler.AssemblyIsUsable (System.Reflection.Assembly asm) [0x00000] in <filename unknown>:0

Loader exceptions:
   => System.TypeLoadException: Could not load type 'Harmony.Traverse' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.CodeTranspiler+<>c' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.CodeTranspiler+<ConvertToOurInstructions>d__7' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.Patches+<>c' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.HarmonyInstance+<>c' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.HarmonyMethod+<>c' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.HarmonyMethod+<>c__DisplayClass13_0' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.HarmonyMethod+<>c__DisplayClass13_1' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.HarmonyMethod+<>c__DisplayClass14_0' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.HarmonyMethodExtensions+<>c__DisplayClass0_0' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.HarmonyMethodExtensions+<>c__DisplayClass2_0' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.HarmonyMethodExtensions+<>c' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.HarmonySharedState+<>c' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.MethodPatcher+<>c' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.PatchFunctions+<>c' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.PatchProcessor+<>c' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.AccessTools+<>c' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.AccessTools+<>c__DisplayClass21_0' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.AccessTools+<>c__DisplayClass22_0' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.AccessTools+<>c__DisplayClass23_0' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.AccessTools+<>c__DisplayClass24_0' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.AccessTools+<>c__DisplayClass36_0' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.GeneralExtensions+<>c__DisplayClass0_0`1[T]' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.GeneralExtensions+<>c__0`1[T]' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.GeneralExtensions+<>c' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.PatchTools+<>c__2`1[T]' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.Tools.SelfPatching+<>c' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.ILCopying.Emitter+<>c' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type 'Harmony.ILCopying.MethodBodyReader+<>c' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type '<>c' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type '<>c__DisplayClass36_0' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type '<>c__DisplayClass37_0' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type '<>c__DisplayClass38_0' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type '<>c__DisplayClass39_0' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type '<>c__DisplayClass40_0' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.
   => System.TypeLoadException: Could not load type '<>c__DisplayClass41_0' from assembly '0Harmony, Version=1.2.0.1, Culture=neutral, PublicKeyToken=null'.

At first I thought I got hold of the wrong DLL, but even copying 0Harmony.dll from InfiniteStorage fails. Running with those errors results in the same as not including 0Harmony.dll at all (not surprising), meaning it completely breaks my mod.

Any idea on what I can do to fix this?
#19
Quote from: PleaseBro on June 29, 2018, 05:35:46 PM
I agree with all the people that say the name changes from 18B to 1.0 are not good for older players.

What was wrong with the old names for things? We all liked those. I don't think there is anyone who was upset with the old names for things.
The name goes from 0.18 to 1.0. Looks ok to me. The problem you refer to is more like people write 18B when it's actually named 0.18. Declaring a version to be version 1.0 is a common approach to declare something final, as in end of early release or pre-release state. I don't really see a problem with the version naming.
#20
Quote from: Lanilor on June 26, 2018, 01:02:14 PM
Quote from: Tynan on June 26, 2018, 08:24:39 AM
Regarding "legendary", I think when there's an issue it's because people import assumptions from other games. In every RPG you always end up decked out in all "epic", "legendary" loot etc. This isn't RimWorld. I'm going with the actual meaning of the words "masterwork" and "legendary". Specifically, if something is going to be legendary it has to be so exceptional that people tell stories about it for years and years. Most of us never experience such a thing; in a RimWorld game it's entirely reasonable to never encounter a legendary. But if you do...

The same goes for skill levels. Player complain about how it's impractical to "max out" skills on their characters. I'm just like, dude, have you ever even met a single person who you could say was "maxed out" on any skill at all? Probably not, and most of us never will. When the description says something like "system-class master" it's describing something most people will never encounter, by design.

I can fully support this. Please keep it this way!
Some people like it and some people don't. However everything mentioned by Tynan in this quote was modded in B18 and odds are that they will be in 1.0 as well (if not already without me noticing). All the "I want for my playing style" arguments are rather pointless. The real question is how it should work for new players, who haven't played enough to start looking through mods.

Another question is the part about features for modders. For instance the question about not being able to perform surgery on Mechanoids. Apparently it's disabled/removed in the code, making it extra work for modders to enable again. Why isn't it simply disabled in xml? It would have made sense considering it's something, which is modded for B18 and odds are that most B18 mods will be converted to 1.0 mods.
#21
Quote from: Roolo on June 24, 2018, 03:42:28 AM
Quote from: Tynan on June 24, 2018, 12:17:38 AM
Quote from: Nightinggale on June 23, 2018, 11:19:59 AM
Speaking of code modding, I have a question. Verse.ModContentPack.LoadDefs() has [DebuggerHidden] set. It seems to interfere with Harmony Transpiler, making it impossible to mod the method, only do stuff before/after or replace it entirely. While it turned out that this specific case doesn't prevent me from doing what I want to do, it does leave the question why it's even used? Wouldn't it make sense to search and remove all [DebuggerHidden] from the entire sourcecode to ensure the code to be as modder friendly as possible? None of us can predict which method will need to be modded a few months from now because the modder haven't gotten the idea yet. Because of this, it would make sense to unlock all of them.

Wherever [DebuggerHidden] is coming from, it's not defined in our source code. Kind of a mystery... and thoughts from anyone appreciated.

This happens for any iterator method (methods returning IEnumerable). I'm not sure why, but I can imagine the annotation is there to make clear that the method displayed has a hidden object inside it.

@Nightinggale The problem of not being able to patch the method is ...
Oops. Seems like it was an issue with my Harmony skills rather than RimWorld. Sorry about sending you searching your code for a problem, which isn't there  :-[

I have to say I'm fairly impressed with your new patching code. I tried reimplementing B18 patching and it turns out that applying an empty sequence takes 5 times as long as a 1.0 patch, which changes construction cost of a building. I assume this has to do with the loop overhead (it can't really be anything else) and I have to admit that I did not predict that to be slower than xpath searching since xpath searching is the performance killer in B18. You truly came up with the right design for patching. Good job.

I have to admit I had a moment of feeling obsolete, though that's not really the case. I can still mod to patch faster than vanilla as well as all the other features, like patching profiling. It's just not as much of a notable performance boost as it was in B18.


And I will like to repeat that it's annoying having to pick 64 bit each time the game starts from steam. It would be nice to have it pick for you without the window. Factorio managed to pick 32/64 automatically without asking, meaning it should be possible to do so. Admittedly Factorio dropped 32 bit support due to technical (memory?) issues, but it was picking automatically at some point.
#22
I pushed a new version. This time I fixed a crashing bug for empty patch folders and improved profiling.

However now I ran into an unexpected issue. I made a simple patch, which changes the construction cost of a building. This resulted in the following profiling.





B18 patching
20 ms
B18 patching with FindFile
14.5 ms
1.0 vanilla patching
0.065 ms
new operation (see below)
0.044 ms
This made me suspect something is wrong with my approach and I tried B18 style patching with an empty sequence and it turns out patching that one takes 0.3 ms or almost 5 times as long as applying the patch using the new 1.0 style patching. I honestly did not expect that or the big difference between B18 and 1.0. It would appear vanilla code itself is 300 times faster. I'm considering removing FindFile and B18 style patching, but since it works, I might as well keep it and see what happens with hundreds of patches when those are available.


I did however finally implement the last operation I have been thinking of regarding performance boosting.
<li Class="ModCheck.tmp">
<xpath>Defs/ThingDef[defName="WatermillGenerator"]</xpath>
<operation Class="PatchOperationReplace">
<xpath>Defs/tmp/ThingDef/costList/WoodLog</xpath>
<value>
<WoodLog>100</WoodLog>
</value>
</operation>
</li>

What it does is it makes the search and for each found xml node, it moves that node into Defs/tmp, calls operation and then it moves the node back. The result is that when operation is called, Defs/tmp will only contain a single node and as such xpath can use a fixed path without any searching. This simplifies the xpath search and as the table shows, this is even faster than vanilla patching. Even better, if operation is a sequence, multiple patching can be done on the same node (in this case ThingDef). I can't really tell the time difference between patching one or 3 values, meaning I can patch all 3 cost values for less than it takes to change even just one using pure vanilla operations.

This leaves one question: what should the new operation be called? And what should the temporal path be called?
Right now I can't think of a good name. Hopefully somebody else can come up with something, which doesn't seem to be disconnected from the functionality.
#23
Quote from: Ser Kitteh on June 23, 2018, 07:34:53 PM
I hope Mechanoids can be turned off/harvest for scyther blades, if only because I've been looking forward to Roolo's mechanoid mod since forever. Even if it doesn't, I hope it's in the game code somewhere so modders can use them!
I tried look into this and it looks like Defs/PawnCapacityDefs/PawnCapacity.xml holds the answer. It has Consciousness on top and it has a bool called lethalMechanoids set. I assume setting it to false will allow mechanoids to be disabled without actually killing them.

Quote from: Ser Kitteh on June 23, 2018, 07:34:53 PMAlso devaluing scyther blades to like 50 Silver a pop may be a good way so as to not make the game too easy. I don't mind Centipedes automatically dying since shutting them off was just extra work, but as some modders rely on this frame, I hope it does come back. Maybe even have a very low chance to salvage the minigun off them?
Just make other factions reject buying mechanoid technology. It's against their religion or something. Problem solved. Another issue to consider is what if you sell lots of weapons to some faction and then they turn on you? Should you be killed by an army full of people with scyther blades or miniguns or whatever you sold them? The whole concept of selling weapons to potential future enemies is a bit weird if you start to think about it. And even if the faction in question is ok, they could be raided and then the raiders have the weapons.
Realistically speaking, some weapons should be so dangerous in the wrong hands that your best option should be to take them apart if you don't want to use them yourself.
#24
Quote from: Gfurst on June 21, 2018, 03:57:13 PM

  • don't remember if already mentioned earlier, but watermills are pretty OP, being an obvious choice early on an unparalleled power source despite its wood requirements, maybe make water flow variable like wind turbines
We could add a power factor to the water as a multiplier between 1 and 0. It goes up during rain and drops without rain. We can then make it depend on all the river areas upsteam and rain there as well. RimWorld doesn't use all the CPU cores, meaning it would be possible to make rainfall simulations on a different core, hence adding the feature without slowing down the game. We can even go extreme and make those points flow, meaning there will be benefits from placing wheels at narrow locations, even throwing rocks into the water to make even more water flow through the wheel. The wheel then eats up flowpoints, meaning you will not get twice as much power from having two wheels in a row.

The question is if it's worth the coding time.

One interesting fact to add is that the industrial revolution didn't start with water wheels. Water power have existed for ages (even the Romans used it), but it has reliability issues as it depends heavily on rain. In the 18th century, all the water wheels stopped in England due to lack of rain. A factory owner named Charles Bolton happened to come in contact with an unknown and penniless man called James Watt. Watt converted the factory to steam power, Bolton made a fortune by not relying on weather and they started Bolton & Watt, a steam engine production company. Watt later invented a method of making steam engines constant rpm engines, changing steam usage automatically to match the workload, something waterwheels can't do. This allowed the cotton industry to produce way more with significantly less workers. Those workers then went out to look for new jobs and became the workforce to really start the industrial revolution. Waterwheels became niche, but never died out because they work without fuel. Some factories used until electrification and even today waterwheels are in use. Go to youtube and you can see people making their own. I saw one, which pumps water from a river to some nearby cows while a fence prevents the cows from falling into the river. Yes, it's primitive and looks somewhat crude, yet it works, is cheap/free and is used in commercial production, meaning waterwheels aren't dead.

Quote from: Elendil on June 22, 2018, 07:21:08 AMSomething that seemed a little odd was that a river affected me the same in boreal forest when it was -17°C as in arid shrubland when it was 34°C. What I think would be really interesting and made the gameplay more engaging would be if the soaking wet debuff gave a debuff to cold resistance (perhaps even negate cold resistance of clothes).
An interesting fact to add here is that Japan has summers around 40°C and plenty of rain/water. Traditionally they took a bucket of water and a big spoon like thing, walked down the street and threw water around them. This made the stones wet and the process of making the water vaporize takes up energy, meaning it actually cools down the stones, making the temperature on the streets more comfortable. Now with indoor climate control, it's not as widespread anymore, but it haven't died out completely.

Water spraying cooling could be used in RimWorld, not as a freezer, but more like lowering indoor temperature from 40°C to 30°C. Add a new job, which goes to the river, goes inside, work quickly on a tile to lower heat energy on it and repeat. It does take up colonists to do so, but it could be a way to prevent heatstrokes during early/mid game during heatwaves.


Reading this thread gives me plenty of ideas, which would be cool to have ingame. However this thread is about core, which is aimed at new players. It should be well balanced, easy to understand and not bloated with ideas and concepts. We can all add mods if we want. Because of this I see two main tasks right now:

  • Figuring out game balance.
  • Locate all issues, which can prevent mod creations.
Lot's of people talk about #1, but somehow I have the feeling I'm the only one using ILSpy and Harmony to examine the code for modability at the moment. If it turns out that 1.0 is indeed the final version, now is the time to detect and correct issues for mods where we get the idea for the mod in 2020. I consider this issue to be way more important than details, which can be modded anyway.

Quote from: Tynan on June 23, 2018, 07:30:29 AMDon't worry, every message gets read.
I had the feeling of being ignored as well. Nobody replied and page after page were added until suddenly a reply stated the issue was fixed. I'm now once again able to mod the mod loading code  :D

Speaking of code modding, I have a question. Verse.ModContentPack.LoadDefs() has [DebuggerHidden] set. It seems to interfere with Harmony Transpiler, making it impossible to mod the method, only do stuff before/after or replace it entirely. While it turned out that this specific case doesn't prevent me from doing what I want to do, it does leave the question why it's even used? Wouldn't it make sense to search and remove all [DebuggerHidden] from the entire sourcecode to ensure the code to be as modder friendly as possible? None of us can predict which method will need to be modded a few months from now because the modder haven't gotten the idea yet. Because of this, it would make sense to unlock all of them.
#25
I just committed a new version, which can be downloaded with the link from the last post. ModCheck now reads patches in ModCheckPatches and apply them to each xml file individually, just like B18. Patches are still applied by vanilla code. All PatchOperations work in both places. ModCheck.FindFile works again, though it only makes sense to use it in ModCheckPatches. Profiling adds M or P to tell which folder each patch is located in.

I haven't tested it much yet and as such it's still not ready for a real release. I have rewritten most of the harmony interface and the internal memory/cache in order to handle the new vanilla code and two locations for patches. As a result, it really should be tested well. The individual PatchOperations are however untouched.

Feel free to report back what works and what doesn't.
#26
Quote from: Madman666 on June 21, 2018, 01:51:47 PM
Quote from: Nightinggale on June 21, 2018, 01:37:51 PM
I clicked create shortcut and it starts the 32 bit version. Also anybody claiming the extra clicks at startup to be a minor issue clearly aren't making their own mods, which needs testing, adjustments, testing, etc, which results in frequent starting of the game.

You go to your Rimworld folder, find a file "RimWorldWin64.exe" and make a shortcut to that file. Then it starts 64bit version properly. I guarantee its a faster way of getting rid of your 2-extra-clicks problem than waiting for devs to fix it.
You disable all steam features by starting the game from the exe instead of through steam, which is the very reason why the question was introduced to steam in the first place.

Starting the exe directly is ok right now when people playtest vanilla, but in say two months when the workshop is full of mods, it's no longer as fun to disable all mods downloaded through the workshop. This startup issue really should be fixed.
#27
Quote from: Lanilor on June 21, 2018, 12:43:16 PM- Will there be a way to set 64 bit a default option on start so one doesn't have to extra click every time?
What is the point in asking anyway? Why would anybody pick 32 bit on a 64 bit OS? Ask the OS how many bits it's using and pick the exe based on that. Add some option in properties for those rare cases where people aren't happy with the autodetected value.

Quote from: Madman666 on June 21, 2018, 12:50:06 PMYou can just make a 64bit shortcut on your desktop its not really a huge issue with one more click.
I clicked create shortcut and it starts the 32 bit version. Also anybody claiming the extra clicks at startup to be a minor issue clearly aren't making their own mods, which needs testing, adjustments, testing, etc, which results in frequent starting of the game.
#28
I made a pre-release version for RW 1.0. It can be downloaded here. It's linked against the new Harmony 1.1.0, which I added to git here.

Do note that being a pre-release it's not intended to be released with other mods. It's purely intended to allow other mods to be tested with RimWorld 1.0 even if they use ModCheck. Testing is limited, but it passed the automated test. FindFile is broken for the time being and will always be true.

Now I will carry on to implement B18 style patching and generally optimize for the new conditions present in RW1.0.
#29
Quote from: Alenerel on June 19, 2018, 08:36:45 PM1. It was random and useless unless it was your grower. Better have a proper trait than this wasting space.
We really should have a trait/background story overhaul. We already had somebody complaining about a chef who is unable to cook.

Quote from: MarvinKosh on June 19, 2018, 08:39:45 PM@Julia: Green Thumb isn't really needed any more because colonists who have a passion for doing a particular kind of job will now get a nice mood buff when they do that job.
Good point. It would have been nice if the changelog mentioned it's replaced and not just removed.
#30
Build 1939 appears to have solved the issue. In fact everything without any exceptions related to xml loading and patching has become fully modable, which is even better than B18  :D

The situation is this. Vanilla patching approach:

B18:

  • Defs files loaded
  • Patching each file
  • Merge files

1.0:

  • Defs files loaded
  • Merge files
  • Patching the now single file

The reason for this change is that XPATH is by far the slowest part and by using it on just one file, the number of XPATH calls is reduced alot, which translates to faster patching. The problem is that this one file is huge compared to the multi file approach of B18 (and A17).

My plan:

  • Defs files loaded
  • Patching each file (ModCheckPatches)
  • Merge files
  • Patching the now single file (Patches)
My splitting patches into two folders, it will be possible to have vanilla patching and B18 style patching working side by side. This way mods using ModCheck will be able to use FindFile, which should still be significantly faster than even the new vanilla. Both approaches will then use a single XPATH search, but the performance difference lies in the fact that ModCheck will use the search a much smaller file. Mods not using ModCheck will use the new vanilla code and benefit from the improved performance.

All operations will work in both patch folders and both will be profiled. However the vanilla one will keep file and modName blank for obvious reasons, meaning features relying on those will not really work. This completely destroys the idea of FindFile, but it will technically still work. It just compares against empty strings.

Still no ETA on this, but I have a plan and I have made vanilla support the plan. That's way better than yesterday.