Messages

Quick question...Is it better to use /Defs/whateverDef than */whateverDef now?  I've seen a lot of this since the update and wasn't sure which is better.

Good question. I have seen multiple different versions in use as well and assuming they all work as intended, the difference would presumably be speed. In other words the answer would come from benchmarking each one, so that's what I did.

Def/	baseline
/Def/	+1.4%
*/Def/	+6.4%
//	+749%

I ran 500 of each and measured several times. The results are fairly consistent and as such trustworthy and I used time for patching core only. I think the numbers speak for themselves.

Maybe it was a quick question, but providing the answer wasn't 

To have a low server load, it could be beneficially to generate an xml with just ID and newest version of that mod. This will allow the game to request the file rather than making a database lookup, which would greatly reduce CPU load. It would likely also reduce lag, which would otherwise occur when mods are requested one at a time.

It would also be nice to have a list of required mods. This will allow a mod update to add the requirement of another mod and then games, which downloads the update will realize this and download the requirement as well.

If the database gets a frontend where you can browse mods (ingame or web based) and filter based on tags, then it would totally beat steam. Right now you can filter on steam to get mods for 0.18 and that's it. They all show up. If you can filter based on useful tags like animal, power, weapon, furniture and so on, then we might actually be able to search for a feature we want rather than just random browsing. This is in no way needed for auto updating, but it would be quite useful to have thought of from the start if it is added and is successful and becomes widely used.

There is no need for any chat or posting system. Just add a field for a forum link.

• mod_id - unique for each mod, maybe using the steam id for steam mods and a function to create an id for non-steam users
• version - version or the game this supports

I propose using those two as a pair. This mean you can have the same id for both 0.18 and 0.19, yet they link to different mods. This will solve the current issue on steam about should you update the mod to a new version and break the games, which haven't updated or should you create a new mod and make everybody subscribe to a new one. If people use the 0.18 version and update to 0.19, then the game should be able to figure out that it should download the 0.19 version of the mod with the same id.

Not sure if we should use the steam ID. It might be better to just assign new ones in the order the mods are added.

PatchOperationAdd: adds a new child to the element found in xpath
PatchOperationInsert: adds a new sibling to the element found in xpath

You picked the wrong one and now it tries to read <spawnThingOnRemoved> as a Def.

Code Select Expand

<xpath>/Defs/BodyPartDef[defName = "Brain"]/specialDesignatorClasses</xpath>

You only mentioned specialDesignatorClasses here, not in the original or the wanted codes. I think you need to remove it and insert directly into BodyPartDef.

I'm a freaking idiot. Thank you! you are amazing.

But I thought you were the world's smartest orc 

There are more factors to add in. For instance plants stop growing at night. However there is a mod, which allows 24h plant growth, which obviously requires artificial lighting. How would you even calculate this? Check for light source, but what if the player is using automatic switches and it only turns on if it's dark and there is at least 50% battery power?

I think the goal should be some baseline to give an indication. If the player is using power to allow plant growth at night, then the player should be aware that he will be able to produce more. Likewise players should be able to figure out that blight, fires and similar aren't included in the calculations.

I suspect this will easily end up being CPU hungry, which is ok if it's only calculated when you open a certain window. It's not ok to make such calculations in the background because the player might see it in a popup or whatever.

I really like the idea. While I seem to do ok with food, I always misjudge haygrass to a level where I either run out or I produce like 3 times the amount I need.

Huh, pushers stopped working with freezers? 
I used them in A17 and it worked fine. Are you sure you are using rollers correctly? You need a puller to get from the stockpile onto a roller and then a pusher to take from the roller to the freezer. Rollers can't take directly from stockpile to freezer, though several people have mentioned it as a feature request.

2- I can't use the name of the file "plant_base" because I want to be able to modify any mod with its own name. With the code I used, the game will look for "<ThingDef ParentName="PlantBase" Name="TreeBase" Abstract="True"> in all the files in the "ThingDef_Plants" folder or I didn't understant something ?

Each patch is applied to all files and there is nothing you can do to prevent that. I wrote about a new ModCheck feature to allow a patch file to work on just one file in one mod, but that idea is still on the idea stage and I haven't written even a single line of code for it yet.

The only way to pick the right file with the currently available tools would be to use an xpath, which only triggers on the file you want to patch.

3-I try to reduce as much as possible the number of operation for my xpath to operate. Should I always start the path setting from the begining (so the general Defs folder) and so on, or must I only start the path setting from the subfolder there there is the files I want to change ?

The path you need in xpath is the one inside the xml files and it has nothing to do with where the actual file is located. If you want to know how to make your patching use as little time as possible, read this.

Ludeon actually offers a system like that 
where Modders can create an Account and Link to their mod.

http://rimworldwiki.com/wiki/List_of_up-to-date_mods

Isn't that just manual wiki editing, hence a time consuming extra? Besides that list looks really incomplete, like it's easy to get 10 times that amount on steam, if not more.

I had heard about modSync when it was first proposed never heard anything after that...

It was up and running. It worked great and after around a month it added a new feature where it would automatically detect new releases on GitHub and use those. Around a week after that it was suddenly stopped without warning with the explanation that not enough modders had added their mods. Now most posts in the thread have vanished as well. Based on my experience with ModCheck, it will likely take a few months before mods start to use a new system and it's not enough to have it in the tools subforum because most people will not notice.

Yeah i'm talking about reading the assembly version. targetVersion is based off the game's version as opposed to an individual mod's version like frenchiveruti was asking for.

I use the build in targetVersion (last number) as mod version due to lack of an actual mod version tag. I can't find anything in vanilla, which actually use the build number for anything and so far it has worked just fine using 0.18.4.

I looked at the assembly loading code and it looks like it keeps a reference to all the loaded assemblies in memory for easy access later on. Apparently a reference should be enough to read all the attributes. Another approach would be to add another xml file in About and load data from that one. I think I can implement both options with my current knowledge of how the game load mods at startup.

Writing this gave me an idea. Just add that xml file and include version and two urls. When checking version, one url is for the very same file in master on a git repository (like GitHub). If the version tags differs, a popup should appear and it should display the other url as a clickable link and the second link opens the browser window at the download page for the latest release. The user will then have to update manually, but it's far better than the current situation. Apart from downloading an xml from an URL, I think I pretty much know how to do all of it or know where to look it up. I suddenly think improving ModCheck can wait 

Oh and if a user loads a mod with this new xml file without having the mod to support it, then it will just be ignored. There is no vanilla code to open it. Also while it's not the fine centralized system with search functions you mentioned, it will help people keeping their mods up to date. Also without a centralized server, there is no one server, which can go offline and take everything with it.

This is just 5 minutes of brain storming though, there's probably a hole or two and I don't want to completely diverge this thread 

Too late 

A18 is the same thing as B18.

The unstable "beta" on steam is still A18, but it has the same build number as B18, meaning it's 100% the same thing apart from the A/B name. Personally I'm not sure it was a good decision to change into B18 because it has confused so many people.

Speaking of B18, I can't wait for B19 to come around because on this forum the B and the 8 look really similar.

When this baby hits B8, you are going to see some serious s... well some users will be in medieval times, some in industrial times and some in space age   

If the game could read and print the dll's version number that'd make this much easier.

ModCheck can read targetVersion and writing a number already in the code is an easy addition. If you are talking about [assembly: AssemblyVersion("1.0.0.0")] inside the actual DLL, then that would most likely be doable, though it would require more work. What precisely do you want?

Sorry this turned into a whine fest

You should whine with the rest of us about the loss of ModSync Ninja 

Following the v1.2 incident, I have been looking into patching and performance. It turns out that patching is actually quite slow and as the number of mods increase, so does both the number of patches and how much time each patch will spend patching. Poorly written patches can easily take up most of the startup time, though good written patches can't be considered fast either, just faster than horribly slow. Interestingly the majority of the time spend on a patch is for that patch to look through def xml files and go "no, nothing in this one to patch".

I have come up with a concept where you can write something like:

Code Select Expand

<li Class="ModCheck.something">
<modName>A Dog Said...</modName>
<file>Defs/RecipeDefs/Recipes_Surgery.xml</file>
</li>
This will then be a test, which is only passed when the two strings match the strings for the current file. This comparison is a lot faster than xpath searching to locate the correct file and as such should improve performance. Since the vast majority of patches are written to patch one specific file, this approach should be something, which can be used for more or less all patches.

An added bonus for this is that it exposes data, which can be used to profile each PatchOperation. Right now xml loading and patching is heavily profiled with results written to the log if verbose logging is on. However it is based on files/mods and figuring out if your newly added patch file is slow is almost impossible. I have an idea on how to get combined time spend on each PatchOperation, which should be reported with owner modname. That way everybody can identify poorly written patches and we can hopefully locate and optimize all of them. I estimate that for people with lots of mods, this can likely save at least 30 seconds for every minute spend on xml loading, though going as high as 45-50 seconds can't be completely ruled out.

There is one big problem though. This will require Harmony. This will clash with the current distribution system where people add a single dll file to their own mods. Instead it will become like HugsLib or similar where the user has to add it. I can probably do something like HugsLibChecker, but the user still has to add it. The number of steam subscribers is 672 and that's before any mod has it as requirement.

I thought about splitting ModCheck into two or somehow make a minor version of it, but I think it's a bad idea. Ideally everybody should use the fastest approach and having a version with isModLoaded only or similar will encourage not using the new and faster checks.

Do any of you have anything to say about this before I make up my mind on what to do?

So it should be safe to update to 1.4 now, right?

Yeah, it was safe the moment it was released. If people subscribed on steam they already upgraded because the standalone mod takes priority if people load it first, which the description tells them to do 

Oops, I should have paid more attention to the actual path and not skip the middle section 

It's actually a decent example of how xpath works because there is basically 3 building blocks.

/Defs/ThingDef[defName="HiTechResearchBench"]/comps/li[@Class="CompProperties_AffectedByFacilities"]/linkableFacilities

• Defs is used unconditionally and will match all paths with the chosen search pattern
• ThingDef[defName="HiTechResearchBench"] is used when it looks up the content of a child element of a specific name, in this case defName
• li[@Class="CompProperties_AffectedByFacilities"] is used when the keyword you search for is a property for the item you search for, that is they are written in the same line

2+3 are used in lists where multiple children have the same tag name and you want specific ones.

You should be able to match every single path you want using a combo of those 3.