Messages

Yep, there was a bad version uploaded for all of 10 minutes before fixed. But the real problem here is that steam failed to update people's mods when 2 uploads happen within a short period of time. If anyone knows a fix for this, do share.

Made another CE patch some of y'all may find of some usefulness. It optimizes the ammo defs to improve game load time: https://steamcommunity.com/sharedfiles/filedetails/?id=1721900020

So, there's a middleware mod called UniversalFermenter, except it has a lil' bug that I posted about here. I decided to just take that project on myself in the end, and I got it all fixed up and now and working. Only problem is I can't seem to get rimworld to recognize the dll as being different from the old version. Thereby, if you use a mod that has an older version of UniversalFermenter, and it's higher in the load order, my new version just seems to get ignored, and never loads.

I been trying for the past hour now changing everything I could think of. GUIDs, versions of all manner, assembly meta information, the names. Nothing seems to be working. I was trying to study how Harmony does it since I know rimworld will load multiple versions of that dll, but I couldn't quite crack how they were pulling that off.

EDIT: After stepping back and thinking about it for awhile, I believe what is happening is that it is loading both versions... however the old version, having loaded first, seems to be taking first dibs on any class calls coming from in-game Things, making the new version appear absent.

I made something called the Universal CE Patch: Races mod today. Could be helpful for some folk.

I feel it's worth noting the annoyance of overwhelming load time. What I have come to learn is that mods which add new functionality to the game aren't much of a culprit for adding load time, but mods that add new definitions to the game could be (new items/buildings, new recipes, hediffs, etc). There's some sort of compounding effect the more you add since everything is trying to validate their cross references between one another.

For example, say you added a mod which only added 10 seconds load time to starting up the game. Later on you add a whole mess of other mods to your game. If you remove that first mod again, you might expect to regain 10 seconds of load time if it were a linear effect, but you'd probably find it to be much more than that, even upwards to 10x the difference. Personally, for me, I got one such example of a mod that adds 4 seconds with a vanilla loadout. But if I remove it with all my other mods installed, it shaved 35 seconds off load time.

Are you by any chance using Common Sense? If you are, then it's probably an ignoreable error.

EDIT: just realized that could sound insulting, lol. I mean Common Sense, the mod!

That AnimalCollabProj CE patch is outdated and buggy. I made an updated one.

Also the Vulpine patch is already included in CE now.

What would you propose the difference are between stone block walls and brick walls? Or would it be mostly a matter of graphical variety?

Yes, load order can help with optimizing load times. This guide has served me well: https://www.reddit.com/r/RimWorld/comments/a2ttf6/help_with_mod_load_order_please/eb19liq/

"Resolve references" is basically just where the game checks every reference mentioned in a definition against your ever-growing library of definitions from all the mods your using. It will exponentially compound and get worse and worse when you use mods that add a lot of content to the game (tangible items and recipes for instance).

To give an example of this, take Apparello 2 for instance. Now I got 80-something mods installed, but apparello probably is the most definition-heavy mod I got. Startup Impact claims it loads in 2.44 seconds, but no no. Using a stopwatch, I compared... 3 minutes 28 seconds to load with Apparello 2, and 2 minutes 50 seconds without it. So, moral is, scrutinize any mod that adds a lot of definitions to the game.

Also check your disabled mods if you got any. I have found that those are still poked at by the game when you start up to some capacity, and removing some of them shaved a few seconds off my load times.

UPDATE: nevermind, did it myself. If anyone is finding this via google/search or care to know what happened, the updated dll can be found in my lumber or leather mod (link in sig).

The Universal Fermenter was made back in 2017 by Kubouch. At some point, it became outdated and was taken over by Syrchalis for their blueberry mod, and this variant of UF circulates around the workshop now-a-days.

I am one mod developer using UF, but I have run into a bug with it. I brought it up with Syrchalis, but was told they are no longer developing for Rimworld at the moment.

The bug in question is this: UF allows a building to show a "full" version of its graphic using a <graphSuffix> node element. For example you could have an empty bucket and a full bucket graphic and it'll switch over when a pawn fills it up. The problem is that if you save the game and reload while a building is in a full state, the graphic reverts back to the empty version again. It's just a cosmetic bug and the full version will show up again next batch the pawns load into it, but a bug is a bug and a graphical one may be confusing to some users.

Anyway I figure it wouldn't hurt to put a call on here and see if C# gurus are willing to take it on. If you'd like to see this bug in action, you can see it on my lumber mod. I also downloaded a bunch of other workshop mods that used UF to see if they were having the same problem as I was, and it seemed they were, just to rule out if I may have been doing something wrong.

Hello - I been writing up some patches for mods using PatchOperations. The only thing I can't seem to figure out is how to change the DefInjections. In my scenario, it's a japanese mod and some of the labels are a bit not-quite-right. I wanted to rewrite them, but their in-game text is coming from the DefInjections instead of directly from the def label/description. Any help would be appreciated!

- Fuel smithy, the unfinished object get put in the middle at the smithy, since the object is impassable the crafter can't reach it anymore.
Seting it to passthrough solve the problem, but changing the drop/workspot would be better.

- engl. translation for "anybody" at the crafter selection is wrong/corrupt.
- engl. translation for "paused" at crafting bill is wrong/corrupt.

- sawmill "chop wood kindling" -> chop firewood

Fueled smithy problem is obsolete as it was replaced with the blacksmith in the latest patch.

Translation problems I been looking at for some time now. It's elusive because it doesn't always show up incorrectly. Sometimes it looks fine, sometimes it doesn't.

Kindling -> Firewood fixed in next patch, thanks.

Thanks again. I am translating the MOD Pack into Spanish. That is why my doubt.

Eventually, we would need to have a new Spanish-SK language set, like Russian has.

Who knows why errors come out like these?

The language I have default is Spanish

Code Select Expand

Def-linked translation error: Found no Verse.ThingDef named Cassowary_Leather to match Cassowary_Leather.description
Verse.Log:Warning(String)
Verse.DefInjectionPackage:InjectIntoDefs()
Verse.LoadedLanguage:InjectIntoData()
Verse.PlayDataLoader:<DoPlayLoad>m__6F7()
Verse.LongEventHandler:ExecuteToExecuteWhenFinished()
Verse.LongEventHandler:UpdateCurrentAsynchronousEvent()
Verse.LongEventHandler:LongEventsUpdate(Boolean&)
Verse.Root:Update()
Verse.Root_Entry:Update()

These can be ignored. They're just warnings, not full blown errors. It's on the to-do list to fix.

Thx.
But could you tell me what that mistake is?

Those leathers that it's trying to specify a language translation for don't exist in HCSK.

Who knows why errors come out like these?

The language I have default is Spanish

Code Select Expand

Def-linked translation error: Found no Verse.ThingDef named Cassowary_Leather to match Cassowary_Leather.description
Verse.Log:Warning(String)
Verse.DefInjectionPackage:InjectIntoDefs()
Verse.LoadedLanguage:InjectIntoData()
Verse.PlayDataLoader:<DoPlayLoad>m__6F7()
Verse.LongEventHandler:ExecuteToExecuteWhenFinished()
Verse.LongEventHandler:UpdateCurrentAsynchronousEvent()
Verse.LongEventHandler:LongEventsUpdate(Boolean&)
Verse.Root:Update()
Verse.Root_Entry:Update()

These can be ignored. They're just warnings, not full blown errors. It's on the to-do list to fix.