Messages

Bloody hell forgive me, I have misunderstood you!

The problem is, you can only inherit things via ParentName="...", if said "..." has been defined with Name="..." in the <ThingDef>.

So if you add Name="Campfire" in the <Thingdef> of the campfire in the Building_Temperature.xml, so it ends up like:

Code Select Expand

<ThingDef ParentName="BuildingBase" Name="Campfire">

you should be able to define your firepit by using ParentName="Campfire". Which of course brings us to the point dburgdorf has raised. The reason that your game has no idea what you mean if you put "ParentName="Campfire"" is that "ParentName" doesn't take whatever <defName> has been given to an object, but it looks for the "Name" that has been given to an object in its <ThingDef>.

As far as I can tell, this is defined under the Verse.XmlInheritance in the Assembly-CSharp.dll. However I have no idea how you would be able to change that behaviour in order to also take a <defName> into account in terms of inheritance.

[Steam\steamapps\common\RimWorld\Mods]

Nonono, this is exactly what you've asked!

For example:

Have you ever thought to yourself "Man, It'd be great to have a pistol with 150 range and the option to attack the ground with it! I want it to otherwise function exactly like a pistol and I don't care that I can't draw for ****!".

Fear not, download the zip I have attached and put the folder it contains under your path "Steam\steamapps\common\RimWorld\Mods".

The moment you have smacked together a mod similarily to this ^and you have "created" a gun / building / whatever with your own <defName> for it, it will be there as another gun / building / whatever. (This is also how you "install" mods manually)

[attachment deleted by admin due to age]

[Steam\steamapps\common\RimWorld\Mods]

Sooo, you already have your <Defs> in a xml, or did I misunderstand something?

You can add whatever mod you want by putting its folder under the path "Steam\steamapps\common\RimWorld\Mods".

Just be sure to maintain a proper folder structure, especially whatever <texPath> you've given to your texture.

For example, I have added a gun by putting its About.xml in the folder "About", its Defs.xml in the folder "Def", its texure in the folder "Textures" and the three said folders were put in the folder "TestTest".

The folder "TestTest" was then put in the path I have posted above and I can activate the mod under the register "Mods" on the main menu.

[NEW]

Have you actually tested this in a NEW game? Just enable dev mode and test stuff that way. Existing games aren't a good way.

The problem isn't the old game itself, but using an already existing drug policy because they aren't automatically updated.

For example, the "No drugs" policy still allows addicts to use a drug in order to avoid withdrawal. However, if you add a drug via a mod, said drug will not be part of "No drugs".

You just have to create a new policy and all enabled drugs will be part of that new policy.

[Steam\steamapps\common\RimWorld\Mods\Core\Defs\ThingDefs_Buildings]

The easiest way to change that would be to go to the "Buildings_Security.xml" file under the path "Steam\steamapps\common\RimWorld\Mods\Core\Defs\ThingDefs_Buildings" and directly change the <turretBurstCooldownTime> in row 221.



On a sidenote, someone on the forum has advised against directly changing things in the core because that can lead to incompatibilities with other mods. I'd guess that directly changing the cooldown of a mortar isn't exactly that gamebreaking, but how would you implement this change otherwise?

I mean, the <turretBurstCooldownTime> is defined in the <ThingDef Name="BaseArtilleryBuilding" ...>, so I can't just smack a file in a mod that says

Code Select Expand

<?xml version="1.0" encoding="utf-8" ?>
<Defs>
   <ThingDef Name="BaseArtilleryBuilding" ParentName="BuildingBase" Abstract="True">
     <turretBurstCooldownTime>3.5</turretBurstCooldownTime>
   </ThingDef>
</Defs>

because there ALREADY IS a <ThingDef Name"BaseArtilleryBuilding" ...>.

Sooo, how do you add a file that changes a value by editing only this value for an existing def?

You'll find the brain in BodyParts_General, row38.

I'd guess if you want to split an organ into several parts / add some, you'll need to add a <BodyPartGroupDef> similarily to how the groups are defined in BodyPartsGroups. Then you'll have to assign these groups to the specific organ.

From how I understand the Bodies_Humanlike.xml, the corePart of the human body is the Torso. One part of the torso is the left shoulder, which belongs to the group "Shoulders". The left shoulder is only made of one part, the left arm - which is part of the group "Arms". The left arm however is made from several parts, one of which is the left hand, which belongs to the group "Hands" and is made up of five parts - the left fingers - all of which belong to the groups "Hands" and "Left Hands".

Things get quite confusing at first glance, but I guess in order to split the torso into several pieces, you'll have to make these pieces <parts> of the torso. So for example you don't put the clavicles as "direct parts" of the torso like this:

Code Select Expand

  <BodyDef>
    <defName>Human</defName>
    <label>human</label>
    <corePart>
      <def>Torso</def>
      <height>Middle</height>
      <depth>Outside</depth>
      <groups>
        <li>Torso</li>
      </groups>
      <parts>
        <li>
          <def>LeftClavicle</def>
          <coverage>0.005</coverage>
          <height>Top</height>
          <depth>Inside</depth>
          <groups>
            <li>Torso</li>
          </groups>
        </li>
        <li>
          <def>RightClavicle</def>
          <coverage>0.005</coverage>
          <height>Top</height>
          <depth>Inside</depth>
          <groups>
            <li>Torso</li>
          </groups>
        </li>

but instead add the bodypart ... I dunno ... "Clavicles" or whatever and put "Clavicles" as direct part of the torso, with the clavicles themselfes as parts of "Clavicles", belonging to the groups "Clavicles" and "Torso".

Code Select Expand

  <BodyDef>
    <defName>Human</defName>
    <label>human</label>
    <corePart>
      <def>Torso</def>
      <height>Middle</height>
      <depth>Outside</depth>
      <groups>
        <li>Torso</li>
      </groups>
      <parts>
        <li>
          <def>Clavicles</def>
  <coverage>????</coverage>
  <height>Top</height>
  <depth>Inside</depth>
  <groups>
      <li>Torso</li>
  </groups>
  <parts>
    <li>
      <def>LeftClavicle</def>
      <coverage>0.005</coverage>
      <groups>
        <li>Torso</li>
        <li>Clavicles</li>
      </groups>
    </li>
    <li>
      <def>RightClavicle</def>
      <coverage>0.005</coverage>
      <groups>
        <li>Torso</li>
        <li>Clavicles</li>
      </groups>
    </li>
  </parts>
        </li>

As for the impact on performance with the <chairSearchRadius>, think about it this way:

As far as I've understood the code so far, your pawn's hunger-meter gets to a certain threshold so your pawn gets the job "JobGiver_GetFood". Your pawn then looks for the "most preferable" food, so he would of course love lavish meals the most while some meals only get touched when your pawn is so malnourished that he looks for "desperate_only"-level of food. Once the pawn has gotten his hands on the most preferable food available, he looks for a chair - by default in a radius of 25 tiles - and then walks over there to eat; the chair is reserved by your pawn for this time.

With a <chairSearchRadius> of 999, literally everything in this behaviour except for the <chairSearchRadius> is the same as it would be with the vanilla <chairSearchRadius>.

I don't see how this would have any effect on performance at all.

Does it means that with <chairSearchRadius>999</chairSearchRadius> each pawn will look for a table/chair in that huge radius? I don't know if that's going to have a negative impact on performance, the more pawns you have.
Why not to assign a table for your pawns to go to, before they start looking for any food? In that case you just have to make sure your stockpile is next to said table. They will have to ignore the one they are carrying for it to work.
It would have to change vanilla behavior => when hungry do not look for food, go to your table (or just go to the kitchen, i think it might be easier); when there, look for food; when you get the food then look for a table; if you have food problems and the pawn gets to the designated table (or the kitchen) and you have no food it will go find food wherever it is, and then eat it on the floor if it was too far from a table. If there is no designated table (or kitchen) it will look for food wherever he is at the moment.

Well, it isn't exactly a "delicate" solution, but yes it forces your pawn to simply look for a chair within a radius of 999 tiles. Considering that the max size for a map is 400x400, this search radius will cover the entire map.

I don't think this would cause performance issues in terms of how well your game runs since every crafting station has a default search radius for materials of 999. However, if your designated eating room only contains like eight chairs but you have 20 pawns and all of them get hungry at the same time, they are going to look for other chairs all over the map, since you can't forbid chairs in the vanilla game. But chairs aren't really a problem in my colonies because every room gets outfitted with a short table and a chair when I get around to it, so they don't have to walk far.

I have just destroyed all chairs in my newest colony except for the seven at the dining table and when I told all of my 13 colonists to eat, the first seven ate sitting on a chair while the others just ate standing a few tiles from where they picked up their food. Since this behaviour wouldn't be any different if you assinged a "proper dining table" to your colonists and more people want to eat at once than there is room at the table, I'd say that the <chairSearchRadius> is by far the most simple solution for this problem.

OrganicProductBase is right at the top of Mods/Core/Defs/ThingDefs_Items/Items_Resource_RawPlant.xml.

Thanks! I had misread "Name" as "ParentName" ...

Anyways, if you want this to work for raw food such as milk and vegetables, too and you're too lazy to add the <chairSearchRadius> for every raw plant - and animal foodstuff, you'll have to add the following lines to the "OrganicProductBase" found under the path that BlueWinds has posted above:

Code Select Expand

    <ingestible>
    <chairSearchRadius>999</chairSearchRadius>
    </ingestible>

Before you do something to your main reproductive organ that you're (probably) going to regret, open the "Items_Food.xml" found under "\Steam\steamapps\common\RimWorld\Mods\Core\Defs\ThingDefs_Items".

Now go to the <ThingDef Name="MealBase" Abstract="True"> and add the line "<chairSearchRadius>999</chairSearchRadius>" under <ingestible>.

I can't find the "OrganicProductBase" for the life of me, so if you want this to work for raw animal products like milk and insect jelly, you'll have to add that line under <ingestible> for every animal product in the "Items_Resource_AnimalProduct.xml" (unless you'd find the "OrganicProductBase", of course).

Hello there!

First of all forgive me if this question has already been asked, but after looking through the forum for a bit, I didn't quite see an existing thread that seemed to be about this topic.

Speaking of topic, I'm screwing around with a bunch of things in my free time, one of which is a drug (in Rimworld, of course!). It's supposed to be a highly potent stimulant which boosts all aspects of the mortal body for prolonged periods of time. The downsides for this are supposed to be a rather long and resource expensive production process and irreparable chemical damage to the body.

Said damage is supposed to start out small and pretty much negligible, but once you've managed to get addicted to the drug or even go into withdrawal, you're really in for it!

I have thought about implementing this damage similarily to how the vanilla drugs of Rimworld can cause chemical damage to the brains or kidneys. Yayo for example goes about the punishment for kidneys this way:

Code Select Expand

<HediffDef ParentName="DrugToleranceBase">
  <defName>PsychiteTolerance</defName>
...
    <hediffGivers>
<li Class="HediffGiver_RandomDrugEffect">
<hediff>ChemicalDamageKidney</hediff>
<minSeverity>0.50</minSeverity>
<baseMtbDays>120</baseMtbDays>
<partsToAffect>
<li>LeftKidney</li>
<li>RightKidney</li>
</partsToAffect>
</li>
    </hediffGivers>
</HediffDef>

So basically, once a person's tolerance to psychite reaches 50%, their kidneys are going to catch chemical damage in a time span of up to two years.

Additionally, a pistol's bullet is dealing the <damageDef>Bullet, with a <damageAmountBase> of 9. The <damageDef>Bullet on the other hand, is designated to the <hediff>Gunshot. Thus, the bullet of a pistol deals 9 points of "bullet damage", of which the effects in terms of tending, bleeding, pain etc. are written down in the <hediff>Gunshot.

Since I would like to implement the chemical damage of my drug by giving the drug a chance to deal 1 point of permanent damage to any living part, with the chance rising in account to how high the tolerance is and whether or not the user is addicted / in withdrawal, my best guess is:

1.) I have to add an <HedfiffDef>, which contains the info that the damage instantly scars + labels and values for damaged parts

2.) I have to add a <DamageDef>, which contains the info that the damage is supposed to ignore armor, isn't a battle wound, has no impact sound and contains the message that pops up when someone succumbs to the damage

Now the problem is that the vanilla drugs cause their chemical damage to organs via <hediffGivers>. However, in order to properly limit the chemical damage to a single point at a time, I obviously wanted to implement it with a <damageAmountBase> of 1. But since hell would freeze over long before I could add a <damageDef> + a <DamageAmountBase> under <hediffGivers>, I'm kind of lost here.

So far, I have resorted to adding an <Hediff> with stages in steps of 0.05 severity, where every next stage lowers the efficiency of the body part and causes more severe pain. Moreover, I gave the drug's tolerance an <HediffGiver_RandomDrugEffect> to cause said <Hediff>, with <canAffectAnyLivePart> enabled.
It kinda works and properly affects every body part but obviously, it would be stuck on the first stage because without a function in place that raises the severity. I've added this via <comps> with <HediffCompProperties_Immunizable> + a certain value for <severityPerDayNotImmune> in combination with <severityPerDayNotImmuneRandomFactor>, so it truly works in terms of a progressing illness.

Code Select Expand



  <!----HediffGiver that causes the illness in the definition of the drug's tolerance---->

<hediffGivers>
<li Class="HediffGiver_RandomDrugEffect">
<hediff>ChemDamDiffCPEDII</hediff>
<minSeverity>0.001</minSeverity>
<baseMtbDays>0.01</baseMtbDays>
<canAffectAnyLivePart>true</canAffectAnyLivePart>
</li>
</hediffGivers>


  <!----Hediff that acts as the illness---->

  <HediffDef Name="CPEDIIDiseaseBase" Abstract="True">
    <hediffClass>HediffWithComps</hediffClass>
    <defaultLabelColor>(190,180,20)</defaultLabelColor>
    <initialSeverity>0.001</initialSeverity>
  </HediffDef>
 
  <HediffDef ParentName="CPEDIIDiseaseBase">
<defName>ChemDamDiffCPEDII</defName>
<hediffClass>HediffWithComps</hediffClass>
<label>Chemical damage</label>
<tendable>false</tendable>
<stages>
<li>
<label>negligible</label>
</li>
<li>
<minSeverity>0.05</minSeverity>
<label>negligible</label>
<partEfficiencyFactor>0.98</partEfficiencyFactor>
<painOffset>0.01</painOffset>
</li>
<li>
<minSeverity>0.1</minSeverity>
<label>negligible</label>
<partEfficiencyFactor>0.96</partEfficiencyFactor>
<painOffset>0.0133</painOffset>
</li>
<li>
<minSeverity>0.15</minSeverity>
<label>minor</label>
<partEfficiencyFactor>0.94</partEfficiencyFactor>
<painOffset>0.0166</painOffset>
</li>
<li>
<minSeverity>0.2</minSeverity>
<label>minor</label>
<partEfficiencyFactor>0.91</partEfficiencyFactor>
<painOffset>0.02</painOffset>
</li>
<li>
<minSeverity>0.25</minSeverity>
<label>minor</label>
<partEfficiencyFactor>0.88</partEfficiencyFactor>
<painOffset>0.025</painOffset>
</li>
<li>
<minSeverity>0.3</minSeverity>
<label>medium</label>
<partEfficiencyFactor>0.85</partEfficiencyFactor>
<painOffset>0.03</painOffset>
</li>
<li>
<minSeverity>0.35</minSeverity>
<label>medium</label>
<partEfficiencyFactor>0.81</partEfficiencyFactor>
<painOffset>0.0366</painOffset>
</li>
<li>
<minSeverity>0.4</minSeverity>
<label>medium</label>
<partEfficiencyFactor>0.77</partEfficiencyFactor>
<painOffset>0.0433</painOffset>
</li>
<li>
<minSeverity>0.45</minSeverity>
<label>medium</label>
<partEfficiencyFactor>0.73</partEfficiencyFactor>
<painOffset>0.05</painOffset>
</li>
<li>
<minSeverity>0.5</minSeverity>
<label>medium</label>
<partEfficiencyFactor>0.666</partEfficiencyFactor>
<painOffset>0.0575</painOffset>
</li>
<li>
<minSeverity>0.55</minSeverity>
<label>major</label>
<partEfficiencyFactor>0.6</partEfficiencyFactor>
<painOffset>0.065</painOffset>
</li>
<li>
<minSeverity>0.6</minSeverity>
<label>major</label>
<partEfficiencyFactor>0.533</partEfficiencyFactor>
<painOffset>0.075</painOffset>
</li>
<li>
<minSeverity>0.65</minSeverity>
<label>major</label>
<partEfficiencyFactor>0.466</partEfficiencyFactor>
<painOffset>0.0875</painOffset>
</li>
<li>
<minSeverity>0.7</minSeverity>
<label>major</label>
<partEfficiencyFactor>0.4</partEfficiencyFactor>
<painOffset>0.10</painOffset>
</li>
<li>
<minSeverity>0.75</minSeverity>
<label>extreme</label>
<partEfficiencyFactor>0.325</partEfficiencyFactor>
<painOffset>0.1125</painOffset>
</li>
<li>
<minSeverity>0.8</minSeverity>
<label>extreme</label>
<partEfficiencyFactor>0.25</partEfficiencyFactor>
<painOffset>0.125</painOffset>
</li>
<li>
<minSeverity>0.85</minSeverity>
<label>extreme</label>
<partEfficiencyFactor>0.17</partEfficiencyFactor>
<painOffset>0.14</painOffset>
</li>
<li>
<minSeverity>0.9</minSeverity>
<label>threatening</label>
<partEfficiencyFactor>0.1</partEfficiencyFactor>
<painOffset>0.155</painOffset>
</li>
<li>
<minSeverity>0.95</minSeverity>
<label>threatening</label>
<partEfficiencyFactor>0.02</partEfficiencyFactor>
<painOffset>0.175</painOffset>
</li>
<li>
<minSeverity>1</minSeverity>
<label>threatening</label>
<partEfficiencyFactor>0</partEfficiencyFactor>
<painOffset>0.2</painOffset>
<destroyPart>true</destroyPart>
</li>
    </stages>
<comps>
<li Class="HediffCompProperties_Immunizable">
<severityPerDayNotImmune>20</severityPerDayNotImmune>
<severityPerDayNotImmuneRandomFactor>
<min>0.5</min>
<max>3</max>
        </severityPerDayNotImmuneRandomFactor>
</li>
</comps>

  </HediffDef>



However, I would prefer the way of implementing the chemical damage via a <DamageDef>, so the chemical damage stops mounting up once you've managed to get rid of addiction and tolerance to the drug. But as I've said before, I have no clue how that's supposed to work, so help would be appreciated!