Messages

I keep getting errors like the following, and I'm unable to narrow down which mod(s) are causing it:

Code Select Expand


System.MissingMethodException: string Verse.Translator.Translate(string)
  at (wrapper dynamic-method) RimWorld.IncidentWorker.DMD<DMD<TryExecute_Patch1>?1297989120::TryExecute_Patch1>(RimWorld.IncidentWorker,RimWorld.IncidentParms)
  at RimWorld.Storyteller.TryFire (RimWorld.FiringIncident fi) [0x00024] in <dbe95457a23e489a865066e846c07c16>:0
  at RimWorld.Storyteller.StorytellerTick () [0x0003a] in <dbe95457a23e489a865066e846c07c16>:0
  at (wrapper dynamic-method) Verse.TickManager.DMD<DMD<DoSingleTick_Patch1>?-384763776::DoSingleTick_Patch1>(Verse.TickManager)
Verse.Log:Error(String, Boolean)
Verse.TickManager:DMD<DMD<DoSingleTick_Patch1>?-384763776::DoSingleTick_Patch1>(TickManager)
Verse.TickManager:TickManagerUpdate()
Verse.Game:UpdatePlay()
Verse.Root_Play:DMD<DMD<Update_Patch1>?-1156012032::Update_Patch1>(Root_Play)


I can see that it's likely an issue with a missing translation for an even that's trying to fire, but how can I tell which mod is the culprit?

Another quick update: after several dozen hours of playing with a few hundred mods, I feel confident in saying that this issue has been resolved, at least for me.

Any lag issues I have now, I can attribute to various mods + using the unstable branch.

Oddly enough 1.1 works on my girlfriend's PC, so I'm inclined to think it's something with my PC.

I'm going to try it on my laptop later and see if it works.

Currently, I'm able to use moonlight as a workaround on my Android tablet, though ultimately I would like to get it work on my Steam Link device as well. 

I've been debugging this issue since 1.1 came out and I started playing again (on Steam) with the new DLC, but now I've kind of figured out something and in some ways because of it I'm more stuck than I was before.

Whenever I try to use Steam's remote play feature (client = android phone & tablet, steam link hardware), Rimworld gives me a black screen (or sometimes white).  I can see the cursor and hear the music, but there's no video.  In windowed mode, I can click on another window and Rimworld will show up on the streaming client, but then it will go back to a black/white screen when it regains focus.  It used to work fine last year when I played.  EDIT: I should note that Rimworld is the only game that has this issue for me.

I tried everything in Tynan's black screen troubleshooting thread: reinstalling, removing registry entries, unsubbing from all mods, etc. to start with a clean slate, but no dice.

Reading up on black/white screens and steam remote play, most people say it's a resolution and/or windowed/fullscreen issue, but I've tried messing around with my resolution and ran Rimworld in fullscreen, windowed, borderless windowed ("-popupwindow" argument) and yet it persists.

I just happened to be testing a mod that I updated to 1.1 and wanted to make sure it still worked on 1.0, so I rolled back and thought "why don't I give it a go..."  And lo and behold it worked.  Steam remote play works in 1.0.

But not 1.1 

Is anyone else having this issue?

Edit: Probably not, because I just got it to work on my gf's PC.  So it must be something specific to my configuration.  Both PCs are pretty similar, running 1070GTX cards and Windows 10 Pro N x64 1909, 32GB RAM, Samsung SSDs, Asus ROG mobos... The main difference is that the one that works is an i7-6700K@4GHz and the one that doesn't is an [email protected].

Other things I've tried:
- Verifying NVidia graphics drivers are up to date
- Setting up both PCs to use the same single monitor over HDMI (system with the issue has 2 monitors)
- Checking Rimworld settings are set to the defaults in NVidia control panel
- Rebooting (of course)
- Pulling my hair out
- Comparing all files in Rimworld game folder, Ludeon appdata folder and registry entries between PCs for differences (there were none)
- All the various Steam streaming settings on both host and client (hardware, software, etc)

Initial tests are very positive for me as well!

I haven't noticed any appreciable amount of lag or spikes since trying a "quick" new game today with the new dlc and 30 or so mods.  By "quick", I mean that naked brutality handed my ass to me after only a couple of hours: while suffering from malaria and heat stroke, my lone dude rescued someone from an angry duck and had his base set on fire by raiders, only to be kidnapped just before he died in another raid. 

So I've done a little bit of testing at 60Hz, 3x speed.  I noticed the lag spike for <1s every 55-60 seconds or so (approx 57 seconds usually), though there is also always a spike within 10 seconds of starting a new game.

I then added Apparello2 because it's a pretty big content mod with zero code, and while the memory usage was higher, the time to lag remained the same, as did the duration of the lag.

Then I tried running with just HugsLib, and it was basically the same as vanilla.

Then I tried running with HugsLib + JecsTools and it would lag every 19 seconds instead of every ~57 seconds.  The memory usage goes up very quickly with JecsTools, and I'd wager that it's exacerbating things quite a bit.  Has anyone mentioned this to Jecrell?

In these tests, I only ran the game for a several minutes each time, as I don't have a ton of spare time today.  Anecdotally, my past experience has been that the lag will become more pronounced (longer spikes) over time, though I don't have the data to back that up yet.

Also if anyone knows a good memory profiler that will work with Rimworld, please let me know.  RenderDoc was the one I saw recommended to use with Unity games, but I haven't had much luck with it so far.

Thanks Tynan.

I just wanted to clarify that my instructions in my previous response were the steps required to reproduce the issue immediately on my primary PC.

The issue still occurs at 60hz and 1/2/3x speed without mods, but it takes longer to become noticeable, at least on this PC. (It's been a while since I tested it... I'll run some tests this week.) While I agree that optimizing for 4x speed and 144hz isn't necessarily a good use of resources for the team, the issue is still happening within the 3x and 60fps target.

One other thing that I found interesting was that the lag doesn't occur in the Beta 18 build. Using the GC mod, I noticed that the memory footprint was a lot smaller in B18 and the GC didn't appear to build up as much before cleaning up.

Hopefully others will be able to chime in soon with their experiences and provide more data.

Thanks Tynan! I should have tweeted you sooner 

On my main PC (specs above, no other apps running), I can see it most obviously without any mods installed when I select a temperate biome with a river, all other settings default, including the scenario. Without mods, it isn't always immediately noticeable for me unless I centre the screen over the river and go to 4x speed (w/dev mode) active.  It's also more noticeable (for me at least) when my refresh rate is set to 144hz.  Others may have more extreme experiences without mods than I do.  IIRC, I usually notice the spike within 10 seconds.

If I add the GC mod, then I can set up so that it indicates the memory usage in the bottom toolbar. The lag coincides with the memory usage getting reset.

It becomes super noticeable once I've added a dozen or so mods, usually including HugsLib and JecsTools since so many mods require them.

attention pawns
check this

same fo 960 gtx i belive

https://www.nvidia.com/en-us/geforce/forums/geforce-graphics-cards/5/239928/gtx-1060-freezes-stutters/

I have tested it on two PCs with 1070s, a laptop with a 765, and a PC with a 560 Ti, and there's no stuttering in any game except Rimworld.  All 4 systems stutter when the GC process kicks in.

Rolling Rimworld back to B18 fixes the stutter. 

So while we might be able to do something using a new GC mod, I don't think it's a good solution. It doesn't really address the underlying problem - that something is creating lots of objects under the hood that need to be destroyed. Altering the GC would be a band-aid at best, and cause new issues at worst.

I have a hypothesis about what is happening.

When Rimworld moved from 32 bit to 64 bit, the unity engine was upgraded to 5.6.5f1.  My hypothesis is that there's a problem with that version of unity.

In the changelog for 5.6.6 of unity, I found 3 mentions of fixes to memory leaks. In managed code, a memory leak will be cleaned up by the GC, but can cause a performance issue, like we are seeing.

For reference -
https://unity3d.com/unity/whats-new/unity-5.6.6

There are likely more in further versions as well, though I haven't read past 5.6.6 yet. I'll do that if my hypothesis is proven.

So, to test this hypothesis, I propose the following experiment:

Install Rimworld B18 and the RunTimeGC mod for B18. Alter the settings of RunTimeGC as per my previous comment, and then observe the memory usage and FPS within the options screen in the main menu.  Note the version of unity in the output_log.txt file.

If the memory is stable, then we try B19.

IIRC B19 was when the 64bit switch was made, so B18 should be 32bit and on the old version of unity.

If it doesn't happen in B18, then we can make a couple of videos/gifs and send them to the powers that be showing them the difference, and request a unity version update to at least 5.6.6.

If it still happens in B18, then I'm going back to the drawing board...


EDIT: 

Ok, so first of all the B18 version of RuntimeGC doesn't have the memory bar in the options menu.  So I had to recompile the 1.0 version against the B18 unity & c# dlls to get that back.  You can find it here if you want to try it:

https://www.dropbox.com/s/idjk3p6cogn315l/RuntimeGC%201.0%20to%20B18.zip?dl=0

Note that it probably won't work in the game itself, as I had to comment out a whole bunch of features that aren't supported in B18, like battle logs and a bunch of the corpse removal stuff.

The memory usage in B18 _does_ still increase in the main menu, though there are differences.  For one, the memory goes from 22MB to 28MB before the GC kicks in.  Another difference is that on my 144Hz monitor, the game starts running at 137 FPS, not 144, and when the reset happens, it drops to 131 FPS.  So it's a 6 FPS difference, not 20.

While interesting, this doesn't really prove my hypothesis, as the memory still goes up in the menu in B18 too.

Unity version for B18 is 5.6.3p1.

I'm not sure what to try next...

What I'd love to try is recompiling Rimworld against Unity 5.6.6 or 5.6.7 and see if the issue persists, but that's not gonna happen.

EDIT 2:

So I've been playing around with things a bit more.  I discovered that I can swap out the UnityEngine dlls for the ones in Cities Skylines (5.6.6f2) and it still works.  No clue why, but it does, lol.  It should need a recompile or something.

Anyway, it didn't matter.  The stutter still happens.

After reverting back to 1.0 from B18, I somehow broke the steam FPS counter for Rimworld (and only Rimworld), so I started using Fraps, which indicates the FPS drop at 6-7 instead of the 20 or so I was seeing with the Steam counter.

I also starting playing with a mod called FrameRateControl.  This mod lets you force the framerate to 60 or whatever.  This reminded me of something that I forgot to note yesterday - on a 144Hz monitor, the memory usage increase will be much, much faster than on a 60Hz monitor.  For instance, at 144Hz, it goes up from 72-98 in 16 seconds (1MB/s).  At 60Hz, it's more like 0.1MB/s, so the GC starts its process nearly 10x later theoretically.  I say theoretically because I noticed the memory usage cycle is not linear.  It gets faster as it gets closer to the upper limit.

So I tried 300 FPS using FrameRateControl.  It's about 50% faster than 144 FPS.  In game is where it gets interesting...  It's about as noticeable as 144 FPS, but the speed of memory increase is the same regardless of game speed.

Conversely, if you force the FPS to 60 in game, the stutter happens less often, is linked to game speed and appears to be less noticeable, as it only happens every 40-60 seconds or so... though I haven't tried it yet with mods.

EDIT 3:

I added a dozen or so mods and tried it out again.  With this setup it's a noticeable ~1 second stutter at 60 FPS (drops to 54 in Fraps), and a ~1 second stutter at 309 FPS (drops to ~280 in Fraps; I don't know why the 300 FPS setting in FrameRateControl runs at 309).  However, the stutter occurs every 3-4 minutes at 60 FPS and every 1 minute at 300 FPS.

I just noticed that there's a "No Limit" option in FrameRateControl which makes it go up to ~1450 FPS, and then drop to 1200 FPS when the GC cleans up. 

I'm going to mess around with it some more.  30 FPS might be a workaround as the GC would probably only run every 10 mins or so... Nevermind it's not.  The memory builds up super fast anyway when you increase the speed of the game.  The stutter is noticeable regardless and the FPS doesn't have much of an impact on how long it takes for it to occur in-game. 

Btw, for reference my main PC:
Intel i7 4770k @ 3.5GHz
32GB RAM
1070 GTX
Samsung 850 Evo SSD
Win 10 Pro, recently installed from scratch a few months ago

This has been an interesting experiment, but I'm not really sure what to try next.  I can't prove one way or another that it's a unity problem or a game problem.  I can see that it happens on multiple PCs, but it's more pronounced for those with more mods and/or faster monitors, and it's definitely related to GC process.

Any ideas, folks?

So I've tried a bunch of things, but nothing has really had any effect on it.

It's much more pronounced and faster to reproduce with mods running, so I've been running a dozen or so to make things easier for myself.  RuntimeGC is key though.

You can set up RuntimeGC to display the current .Net VM memory usage in the toolbar (and in the main menu).  In my case, it caps out around 560MB and then the garbage collection kicks in and it drops to 442MB. 

What's interesting is that this VM memory usage keeps going up, even in the menu or while the game is paused.  It goes up faster for each speed setting in-game, which is why the stutter happens more quickly at 3x than 1x.  What's unusual is that it is going up at all when things are paused and nothing is happening.  Even more so that it does it in the main menu.  This signals to me that there is some kind of leak happening somewhere -- some objects are getting constantly created and destroyed.

It would be interesting to see what other people see in the memory display in the RuntimeGC mod setting screen off the main menu. (Check 'Replace "RuntimeGC" with memory usage data' and set the update frequency to 'Realtime'.  Also uncheck "Replace/enhance vanilla GC" to view vanilla behaviour instead of the optimized collector in RuntimeGC.)   Is your memory usage also steadily increasing?

Edit: With no mods but RuntimeGC running with the settings changes from above, I can see the GC correlated stutter at 98MB before it drops back to 72MB in the main menu. 

I also tried unsubscribing from everything on steam and removing all manual mods, as I noticed they were still being referenced in output_log.txt, but it didn't make a difference.

I'm going to try it on a few other PCs and see what I get.

Edit 2:  3 other PCs exhibit the same behaviour.  The memory goes up continuously in the main menu from 72MB to 98MB before being reset.  When the reset occurs, the FPS counter drops 1-2 FPS on 60Hz monitors or between 10-20 FPS on 144Hz monitors.  This might be why only some people are noticing it.  It's much more noticeable at 144Hz than 60Hz.

I'm now poking through the source code for the RuntimeGC mod.  Since he was able to replace the GC with a more efficient one, I'm wondering if I can slightly modify it so that the upper limit / time before the reset can be increased to reduce the stutter, and/or what else I can do.

Edit 3: There doesn't appear to be anything obvious in there to control the timing of the GC unfortunately.  It looks like the setting to replace the vanilla GC just prevents the vanilla GC from doing any pawn cleanup, as it's already handled by the mod, but it still fires at the same time.

The good news is that it looks like we can just use the old System.GC object, since RunTimeGC is able to call System.GC.Collect().  I thought we were looking at some unity methods for GC, but since we can use the .Net object, we should (in theory) be able to reconfigure the GC settings via a mod.

Nothing else running, Rimworld's on an SSD and I have 32GB of DDR4 RAM.

I'm going to keep experimenting.

Since only a few people encounter these thing's even on plain vanila gameplay. I am pretty sure it isn't a game thing.
Or alot more people whould have these problems.

I reinstalled my OS entirely over the summer (finally upgraded from Win7 to Win10)

upgrade isn't a newinstall, i am pretty sure you keep most installed app's too.
It would interesting to know if you encounter the problem's on a fresh installed window's with nothing else installed too.
But that is something we can't await

It was a fresh install, not an upgrade.

I've also been having this problem; it started around the 1.0 release last year.  I never could trace it down, but it becomes more obvious the more mods you add.  All I need to do to test it is start a new game and speed up time and watch a river freeze up and the FPS drop briefly every X seconds.  It happens in vanilla too, and it doesn't take many mods for it to become much more noticeable.  I reinstalled my OS entirely over the summer (finally upgraded from Win7 to Win10), have none of the same hardware as you (also a 1070GTX like the guy on reddit though) so I'm pretty sure it's a game thing.  From the descriptions in this thread, it sounds like an issue with the unity garbage collection mechanism. 

Edit: It's definitely the GC in game.  The RuntimeGC mod lets you watch it and the spikes correlate exactly with when the memory is automatically reclaimed.  I had a similar experience to RayZoar-Z with it.

The solution is likely a coding change to the base game.  One idea would be to prevent the GC from running automatically / as frequently and force it to run when a dialog is displayed instead.  I don't know if this kind of base level code change is possible via modding.

Alternatively, the issue could be caused by a memory leak, causing the GC to run frequently in an effort to try to keep up with the leak.  Again, a base game fix though.

Unfortunately, this issue makes the game super frustrating to play.  I haven't played it in months because of it, and was hoping to find that this had been figured out by now.

My best guess is that unity was updated to a newer version when Rimworld moved to 64bit (since that's when I first noticed the issue and started seeing other people post about it) and that this newer version somehow altered the way garbage collection works, or introduced a memory leak, though I could be incorrect.

Was wondering if you ever managed to figure something out? I seem to be having the same issue, I noticed the frametime spikes to something like 300ms when the stutters occur.

Same thing as you, no stutter with vanilla. Though I start noticing it after enabling about 15 mods or so and any after that just makes them more frequent.

Did either of you ever figure this out?

I've been having this same problem since the 1.0 release last year.  I never could trace it down.  It becomes more obvious the more mods you add.  All I need to do to test it is start a new game and speed up time and watch a river freeze up briefly every X seconds.  It happens in vanilla too, and it doesn't take many mods for it to become much more noticeable.  Currently I've only got 13 mods enabled and it's super obvious.  Once there are 50+ mods, the stutter lasts longer and happens more often.  I reinstalled my OS entirely over the summer (finally upgraded from Win7 to Win10), so I'm pretty sure it's a game thing.