Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Just made an account to say this has been happening to me ever since I reinstalled the game a week or two ago.  (Version 1.1.2654)

I don't have the Royal DLC or any Mods installed. Anyway, here is my debug log to hopefully shed more light on the issue.

Code: [Select]

Trying to get default parms for null incident category.
Verse.Log:Warning(String, Boolean)
RimWorld.StorytellerUtility:DefaultParmsNow(IncidentCategoryDef, IIncidentTarget)
RimWorld.StorytellerComp:GenerateParms(IncidentCategoryDef, IIncidentTarget)
RimWorld.StorytellerComp_OnOffCycle:GenerateIncident(IIncidentTarget)
RimWorld.<MakeIntervalIncidents>d__2:MoveNext()
RimWorld.<MakeIncidentsForInterval>d__19:MoveNext()
RimWorld.<MakeIncidentsForInterval>d__18:MoveNext()
RimWorld.Storyteller:StorytellerTick()
Verse.TickManager:DoSingleTick()
Verse.TickManager:TickManagerUpdate()
Verse.Game:UpdatePlay()
Verse.Root_Play:Update()

System.NullReferenceException: Object reference not set to an instance of an object
  at RimWorld.StorytellerUtility.DefaultParmsNow (RimWorld.IncidentCategoryDef incCat, RimWorld.IIncidentTarget target) [0x0001b] in <0ee2c524c4be441e9b7f8bfcb20aca6f>:0
  at RimWorld.StorytellerComp.GenerateParms (RimWorld.IncidentCategoryDef incCat, RimWorld.IIncidentTarget target) [0x00000] in <0ee2c524c4be441e9b7f8bfcb20aca6f>:0
  at RimWorld.StorytellerComp_OnOffCycle.GenerateIncident (RimWorld.IIncidentTarget target) [0x0000c] in <0ee2c524c4be441e9b7f8bfcb20aca6f>:0
  at RimWorld.StorytellerComp_OnOffCycle+<MakeIntervalIncidents>d__2.MoveNext () [0x00119] in <0ee2c524c4be441e9b7f8bfcb20aca6f>:0
  at RimWorld.Storyteller+<MakeIncidentsForInterval>d__19.MoveNext () [0x00171] in <0ee2c524c4be441e9b7f8bfcb20aca6f>:0
  at RimWorld.Storyteller+<MakeIncidentsForInterval>d__18.MoveNext () [0x000a1] in <0ee2c524c4be441e9b7f8bfcb20aca6f>:0
  at RimWorld.Storyteller.StorytellerTick () [0x00042] in <0ee2c524c4be441e9b7f8bfcb20aca6f>:0
  at Verse.TickManager.DoSingleTick () [0x00109] in <0ee2c524c4be441e9b7f8bfcb20aca6f>:0
Verse.Log:Error(String, Boolean)
Verse.TickManager:DoSingleTick()
Verse.TickManager:TickManagerUpdate()
Verse.Game:UpdatePlay()
Verse.Root_Play:Update()


As of yet I can't see any correlation between this error and anything occuring on my map, I think it's releated to the random events as I haven't received any pop up at all in this play through.

I get raids just fine though, go figure haha.

Please pardon my continued neglect... But this time I have good news! R++ now has a new lead contributor/maintainer (Hultis) and an official github project

Hultis has also begun to implement C# harmony patches for bug fixes and feature expansion. Some of these bugs have been around forever, so I'm sure quite a few people will be happy to see them getting fixed and this mod getting the attention, love, and care it's users deserve.

Feel free to contribute to the project or open issues for bug reports & suggestions.

I'm still holding out hope for the game moving away from infinite raider scaling and reward-nerfing.

Uninspired and demotivating gameplay features like "biocoding" or "acidifiers" to a lesser degree should never have been introduced. Added to the walls/turrets nerf, they've nearly killed all the fun I had going into a battle prior to v1.1.

I'm surprised that Tynan let himself walk into this trap. It should have been possible for him to foresee that the bloat of wealth would never be compensated by the pressure of infinite raiders, for two simple reasons. First the game AI and second the hardware of the player, both of them being limited by necessity (and thus leading to "killboxes").

With v1.1, it seems the gameplay operates a 180 turn, going against its core design principle of exponential wealth increase, attempting to reduce it somewhat here and there, by minor adjustments. This equates to fighting a self-inflicted tide with a wooden spoon, a bit of a schizophrenic endeavour if you asked me. It also has the strange side-effect of taunting the player : "See this fine gear sitting right under your nose? Well you can't have it".

A more elegant solution would have been to make enemies flee when their survival is compromised. This already exists at a macro level (50+% of raiders killed), but not at the micro level of an individual raider. Fleeing enemies would have the advantage of taking their wealth with them, so the player can't just sit behind the safety of a "killbox" if they also want the best gear. EDIT: since this would make the game easier overall, it could be balanced by other factors, such as increased cover protection or armour quality.

This could also be coupled with other traditional features like "morale" or "leadership". Raiders would hold out better and fight more efficiently under the supervision of a competent leader, making it a priority for the player to identify and eliminate them. Easier said than done in the mayhem of some battles, but this could again be coupled with other gameplay features like "snipers" or "stealth operatives", sent behind enemy lines for a quick assassination!

Of course this could be applied to the player's side as well, where a leader would boost the morale and efficiency, while their elimination would disorient colonists for a while, making them unable to move and just defend themselves instead of cooperating with each other.

So yeah, I can agree that introducing more and more wealth (with ever increasing numbers of raids) has never been a healthy concept to start with. I would much prefer to have less frequent but really challenging battles, involving only a couple of enemies (thus limiting wealth distribution) but demanding tactics and skills of the player, rather than the repeated swarms of raiders operating like mindless "zerglings".

As I've said before, I would also like to see expanded the need for real faction interactions, like diplomacy or trades (because resources would not be infinite or easy to come by) and for colonists to migrate (because of soil fertility exhaustion over time, a lack of materials needed for research purposes or just because the location of the colonist base would be known to more and more hostile factions over time). They could be the real money sinks, keeping the player alert and making the game organically more balanced, diverse, rewarding and ultimately fun.

Is anyone else still getting pink box errors when kids wear adult clothes or is it just me? I thought I was running the latest version

This will always occur when a child wears an article of clothing that cannot be resized. The way we handle resizing at the moment is to take the "thin" graphics of the adult clothing and scale them down to fit. If a clothing item doesnt have a thin graphic, it will fail to resolve. I suppose there might be a way to detect and prevent these items from being equipped in the first place. From a gameplay perspective, allowing kids to wear adult clothing and assume it magically resizes is easier for both players and developers. From an RP perspective, perhaps adding in "small" versions of clothing would be preferable. This ofcourse would reduce base compatibility with mods that add clothing. I'll have to think on it.

Hello can I have some help with this error during playing with a newborn child?. I stripped all mods except HugsLib and CnP. this is the error from the debug menu.

Exception in JobDriver tick for pawn Sarah driver=JobDriver_PlayWithBaby (toilIndex=3) driver.job=(error)
System.NullReferenceException: Object reference not set to an instance of an object
  at RimWorldChildren.JobDriver_PlayWithBaby.<MakeNewToils>b__7_1 () [0x000c3] in <9a38165400d44f088bd0ced2104c60e8>:0
  at Verse.AI.JobDriver.DriverTick () [0x001a2] in <0ee2c524c4be441e9b7f8bfcb20aca6f>:0
Verse.Log:Error(String, Boolean)
Verse.AI.JobUtility:TryStartErrorRecoverJob(Pawn, String, Exception, JobDriver)
Verse.AI.JobDriver:DriverTick()
Verse.AI.Pawn_JobTracker:JobTrackerTick()
Verse.Pawn:Tick()
Verse.TickList:Tick()
Verse.TickManager:DoSingleTick()
Verse.TickManager:TickManagerUpdate()
Verse.Game:UpdatePlay()
Verse.Root_Play:Update()

Thanks in advance :3

Based on the code, I think the only way for this error to occur if the baby is null, the pawn is null, or the job instance is null. I haven't taken an extensive look, but none of those three scenarios ought to be possible. Stripping mods in an active save file is not advised, as it contaminates your environment with undefined factors - I can never reproduce the environment that occurs from a save with mods removed, even if that save were loaded in my environment. If I can replicate, I'll patch it in the next release.

Ah, 3.0.4 is the last version on the Steam Workshop, 3.0.5 hasn't been pushed there yet.

I've downloaded 3.0.5, and I'm not having the issue anymore. Cheers! Probably should be pushed to Steam

Perhaps I should not have authorized the upload to steam workshop. This will no doubt make bug reports less viable if the versions do not match up. To be clear, I do not and will not maintain the steam release. Glad the latest version worked, however. Thank Hilvon for suggesting the changes.

can never version u pput in support for milkable colonisst or a way to input hedriffs to use for breastfeeding?

I have not revisited lactation or breast feeding yet, but it's on the ever growing list. As babies can be fed by any food item and colonist, there isn't much incentive to "store" breast milk for future feedings or anything like that. Were I to implement a feature like this, I believe the player justification for doing so would either need to be efficiency (lactation is basically free baby food, vs eating from colony stockpiles) or RP reasons. I'll consider this when it comes time to revisit breast feeding.
I'll also need to make sure that non-mammalian races have some support as well, so the code that handles lactation will need to account for races that do not lactate.
Right now custom races will need to provide a custom class for their pregnancy rules, but this could be handled by a def defining how a race's pregnancy should be handled.

In other news: I have narrowed down the memory leak in version 2.x.x and 3.x.x and am working to identify the specific cause. Memory leaks in a garbage collected system are new territory for me, so the actual fix may take a while longer - especially since Sunday is already drawing to a close. Hooray.

I'm greatly in favor of reward-nerfing. No matter which biome or scenario I play I seem to find a way to get rich quite fast. Just grow something, craft something then trade. You have silver you have all the materials you need. I don't see a reason why looting should be a great deal in the game.

Some requests ...

1. Simosuchus (aka "Pug Croc")

2. Beelzebufo (aka "Devil Toad")

3. Cygnus falconeri (aka "Giant Swan")

4. Mystacina (aka "Walking Bat")

5. Pontolis (aka "Giant Walrus")

Thanks in advance!

What were the circumstances?

I refunded the royalty DLC on Steam due to personal reasons.

What happened?

I still had the DLC on the machine and could use it to the full extend. When an update arrived it broke as steam updatred the game but not the DLC though.

What did I expect?

I would loose access to the DLC the moment I got my refund approval from steam and had my money back.

What machine am I using?

Windows 10

:thumbsup:

What I ended up doing is writing a mod (Restricted Storage) that allows me to automatically forbid anything in a storage building (shelf, etc) and then put all my packaged survival meals there.  When the caravan is forming, colonists will still gather forbidden items, so they can take all the packaged survival meals, and will happily eat them on caravan.

Forbidding stacks of meals on the ground also works, but it was also annoying for me.

I really like the priorities idea, tho.

The line from the tutorial `cookiecutter gh:n-fisher/cookiecutter-rimworld-mod-development` is a command-line command. You may have to install the cookiecutter tool if your system doesn't have it already. If you use the command line to create the frame for your mod, you should be able to open it in VS/VSCode/whatever.

There are a few open issues you should be aware of - you can see them on the github page.

Ahh I get it now. Thanks for the clarification both of y'all!
The pregnant example was pretty hilarious