Messages

Some of the ThoughtDefs revolving around humans seem to have changed names at one point or another:

Code Select Expand

AteHumanIngredient -> AteHumanlikeMeatAsIngredient
KnowButcheredHuman -> KnowButcheredHumanlikeCorpse


If one of your alien race mods is still using the old names, it may cause this error.

Related to this bug about character names, Thing labels that include brackets [] break the grammar resolver when, e.g., they find their way into the battle log.

Specifically this was discovered with a modded bullet with brackets in its label. Looking at the resolver log, other possible sources of brackets include: weapon, PawnKindDef, and BodyPartDef labels, backstory titles (either abbreviated or full), or faction names. There may be others.

With the brackets removed, the log works fine. In the linked thread, disallowing brackets in pawn names was mentioned by Tynan as a solution; that would be fine here, but if that is the case, a ConfigError should be raised, similar to when a def has a defName that isn't allowed.

The other approach would be to sanitize input when loading custom rules from fields such as labels, perhaps by omitting the brackets or replacing them with parentheses or another allowed character. A label of "[test] my item" might be changed to "test my item" or "(test) my item" before handing it off to the grammar resolver.

A grammar resolution trace is attached. Note line 4, where the label "[LC] Solemn Vow Bullet LC" creates a spurious, unresolveable "LC" element.

Perhaps the Terraforming transformations could show their products in icons, instead of just a shovel when they yield something? (I routinely forget that's what the shovel means.) So a transformation that yields say 3 piles of dirt would have three dirt icons on the button. FWIW this information is in the infobox that pops up when you hover over the button, but it's hard to see "at a glance" when you're considering different options.

While we're talking about Terraforming buttons, I'd really like a blanket "transform whatever to X" designator. So you'd drag say dirt over a bunch of mixed terrain and it would figure out "these tiles are gravel, put down gravel->dirt frames; these tiles are sand, put down sand->dirt; these tiles are dirt, do nothing".

Walling in will partially work, but if the animal needs to leave (wrong temperature, or no food available in its pen) it will start digging through walls far faster than they can be repaired.

I came into this thread wondering why we at all need two pieces of furniture that more or less did the same thing but I guess not lol

My impression is that ship CS caskets have additional hardening that makes them vacuum- and acceleration-safe, whereas normal CS caskets don't need that, don't have it, and are therefore cheaper. But I don't know if they're actually cheaper in-game.

That is quite an observation! This inerstellar dust will act on spaceship as water does on submarine applying friction and reducing ship speed.

The problem isn't that it will apply drag and slow the ship down. The problem is that your ship will be gradually worn away by the impacts, and if it's hit in the wrong place, it could fail catastrophically. The faster you go, the greater the danger.

Most of these can be done by modders already, not sure what a DLC could add that the psycho-cannibal modding community couldn't It'd have to be something inaccessible to modders, what that is exactly I'm not sure.

Technically speaking, with the tools available, there's nothing that mods can't do. That doesn't mean that there aren't things DLC could do more easily and smoothly.

Is that 30 days after you buy it, or after game start, or every first of winter/summer or spring/fall or something else?

I'm fairly certain it's every 30 days although the game might stagger it (i.e., settlement A regenerates on day 15, day 45, day 75..., settlement B on day 6, day 36, day 66...).

I don't butcher people. I'll leave them to rot, but I won't butcher them. I also don't tend to take many prisoners; probably my most common outcome is just leaving them to their fates. If they recover after the battle, they leave peacefully, so it's not like I really lose out by just ignoring them, and it's loads easier. If they bleed out, I generally just leave the bodies there until something eats 'em, or drag them to a dump.

The real reason I avoid both of these is I think they make the game kind of silly. There's something deeply wrong about raids where the more you're attacked, the richer you get. But it's nice not to have to worry about separating food stockpiles or having tons of prison cells.

9) I changed the value of -15 "Failed to romance me" to +5 to simulate flattery and the principle of successful persistence.  This obviously leads to more romances, but it also tends to lead to more affairs, which IMO is way more fun than the nearly insurmountable monogamous relationship values in vanilla.

I'd never thought of tinkering with that... I might mod it to depend on the attraction/compatibility values between the pawns, so that pawns who hate each other don't magically hook up, but ones who are marginal aren't scared away.

The problem here is related to ThingClass. Classes are bundles of C# code and variables that define how particular objects in the game should act. Most things you see in the game belong to a class called, simply, Thing. Some of them have more complicated behavior, though, so they have a more specialized class. One of them is Medicine.

It so happens that the Medicine class is pretty much vestigial; most of the work it used to do is now taken up by stats, which are more flexible. However, the end step of the tending code still assumes that any medicine used will be of the Medicine class, and complains if it isn't. To fix this, add this to your Azerite XML:

Code Select Expand

<thingClass>Medicine</thingClass>

The link between XML and C# is in this line right here:

Code Select Expand

<conditionClass>GameCondition_ClimateChange</conditionClass>

What this does is looks in the namespace "RimWorld" (or Verse) for a class "GameCondition_ClimateChange" that tells it how that particular condition works. However, your code is not in the namespace "RimWorld", it's in a namespace unique to your mod (which in this case appears to be "ClimateChange".) You need to signal this by putting the namespace first, then a period, then the class name, like so:

Code Select Expand

<conditionClass>ClimateChange.GameCondition_ClimateChange</conditionClass>

With that said, this shouldn't be a blackscreen issue from what I'm aware of. Make sure you're following the tutorial's instruction precisely when it comes to compiling and organizing your files. What should end up in the Assemblies folder is not the .csproj or source files, but a compiled .dll file with a name of your choosing. (It really doesn't matter what the name is.)

Finally, the reason the class looks so sparse in the C# code is because most of it is inherited. This line:

Code Select Expand

public class GameCondition_ClimateChange : GameCondition

means, essentially, "create a new class called GameCondition_ClimateChange, take everything from the class GameCondition, and stick it in that new class". Then you selectively overwrite a few details to create the specific effect you want. If Visual Studio's dependencies are set up correctly, the "using" directives at the top of the file (like "using RimWorld;") will allow it to automatically find GameCondition in the base game code.

So it looks like I was wrong and Limdood is spot on: the death-on-down chance applies only if they're downed as a result of violence. Directly applied hediffs don't count. I didn't know this because my colonies are sad and poor and lacking in psychic shock lances. <.<

Unfortunately this can't be done in XML. The duration is set explicitly in the C# classes JobDriver_SmoothFloor and JobDriver_SmoothWall, in their respective BaseWorkAmount attributes. If you're comfortable with C# modding, it should be possible to patch the attributes that hold these values fairly seamlessly.

Another, somewhat uglier option would be to modify the SmoothingSpeed statdef, which is used by these two jobs and (as far as I can tell) no others. You can increase or decrease this stat's factors to adjust how long the jobs will actually take, though the "work remaining" value won't be affected.

As far as I'm aware, the death-on-downed chance applies to any time a (non-colonist, non-guest) pawn is downed for any reason, including the shock lance.

Do those autodoors and tables count as colony wealth from the get-go? I don't like your odds with those kinds of raids coming your way. Although you have plenty of maces to fend them off with...

I personally wish it was more of a roguelike combat log:

Code Select Expand

Alice attacks Bob with wooden mace. Misses! (11% chance)
Bob attacks Alice with left fist. Hits! (57% chance)
Alice dodges. (25% chance)
Alice attacks Bob with wooden mace. Hits! (89% chance)
  hits Bob in the brain (1% chance) for 13
Bob dies.


The problem with the procedurally-generated text is that for all but the shortest fights, you see the same phrases and constructions come up again and again, and it becomes rather robotic. And despite diligent efforts to avoid it, it still comes up with some baffling combinations at times.

Maybe it's just how my mind works, but I find it easier to "see" a coherent narrative when I'm just given the bald facts and have free reign to make up connections, rather than a not-entirely-bright algorithm doing it for me.