Messages

Over on the Steam comments, Omega13 wrote:

...turning neutroglycerin into neutroamine seems incredibly slow. It takes forever to make just one neutroamine, and with the amount that I go through neutroamine, I'd need to have one or two people solely working drug labs full time just to convert enough to keep my meds in stock. A bulk recipe for neutro conversion would be grand.

I'd like to see this, myself. As an experiment, I've added the following two recipes to see how it works and feels. The "batch" or x5 recipe requires an Intellectual skill of 5 and is 33.3% (a third) faster than the default recipe done 5 times. The "bulk" or x10 recipe requires an Intellectual skill of 8 and is 50% faster (half the time) as the default recipe times 10.

Code Select Expand

<Defs>

  <RecipeDef>
    <defName>RefineNeutroglycerin5x</defName>
    <label>make neutroamine batch (x5)</label>
    <description>Make neutroamine as a batch of 5.</description>
    <jobString>Making neutroamine as a batch.</jobString>
    <workSpeedStat>DrugProductionSpeed</workSpeedStat>
    <effectWorking>Cook</effectWorking>
    <soundWorking>Recipe_Brewing</soundWorking>
    <allowMixingIngredients>true</allowMixingIngredients>
    <workAmount>5000</workAmount>
    <targetCountAdjustment>1</targetCountAdjustment>
    <ingredients>
      <li>
        <filter>
          <thingDefs>
            <li>Neutroglycerin</li>
          </thingDefs>
        </filter>
        <count>10</count>
      </li>
    </ingredients>
    <fixedIngredientFilter>
      <thingDefs>
        <li>Neutroglycerin</li>
      </thingDefs>
    </fixedIngredientFilter>
    <products>
      <Neutroamine>5</Neutroamine>
    </products>
<skillRequirements>
<li>
<skill>Intellectual</skill>
<minLevel>5</minLevel>
</li>
</skillRequirements>
    <workSkill>Intellectual</workSkill>
<researchPrerequisite>DrugProduction</researchPrerequisite>
    <recipeUsers>
      <li>DrugLab</li>
    </recipeUsers>
  </RecipeDef>

  <RecipeDef>
    <defName>RefineNeutroglycerin10x</defName>
    <label>make neutroamine in bulk (x10)</label>
    <description>Make neutroamine as a batch of 10.</description>
    <jobString>Making neutroamine in bulk.</jobString>
    <workSpeedStat>DrugProductionSpeed</workSpeedStat>
    <effectWorking>Cook</effectWorking>
    <soundWorking>Recipe_Brewing</soundWorking>
    <allowMixingIngredients>true</allowMixingIngredients>
    <workAmount>7500</workAmount>
    <targetCountAdjustment>1</targetCountAdjustment>
    <ingredients>
      <li>
        <filter>
          <thingDefs>
            <li>Neutroglycerin</li>
          </thingDefs>
        </filter>
        <count>20</count>
      </li>
    </ingredients>
    <fixedIngredientFilter>
      <thingDefs>
        <li>Neutroglycerin</li>
      </thingDefs>
    </fixedIngredientFilter>
    <products>
      <Neutroamine>10</Neutroamine>
    </products>
<skillRequirements>
<li>
<skill>Intellectual</skill>
<minLevel>8</minLevel>
</li>
</skillRequirements>
    <workSkill>Intellectual</workSkill>
<researchPrerequisite>DrugProduction</researchPrerequisite>
    <recipeUsers>
      <li>DrugLab</li>
    </recipeUsers>
  </RecipeDef>

</Defs>

I've tested it and it seems to work and, so far, feels about right. I'm not sure about the Intellectual skill requirement, though. If anyone else wants to test this, they can put the code in a recipe XML (such as the attachment below) and place it in the "RecipeDefs" folder of the mod.

If ShadowTani wants to include or modify it for inclusion, feel free. If not, perhaps I could release it as an add-on?

[attachment deleted by admin due to age]

Hi! Can you do a patch for combat extended? 

So, then, this is not compatible with Combat Extended? In what way?

I think that if you ask the author to look into fixing a compatibility issue or work on a compatibility patch, the least you could do is try to explain the problem to some degree. That said, knowing that this is not compatible with something is better than not knowing.

[Fingers crossed for an A17 version.] 

[Known Incompatible Mods:]

I think the timescale you've currently got works fine. Unless I've got it wrong, pregnancy is 3 seasons. Babyhood is 2 seasons. Toddlerhood is 3 years. And childhood lasts until 13. Perhaps toddlers could become children at 3 instead of 3.5, but any shorter would seem odd.

I agree that the Toddler stage should be reduced from 3.5, down to 3, maybe even 2.5. Babyhood and Toddlerhood are probably the least fun and least interesting stages, at least in terms of this mod. There's a reason that children in Dwarf Fortress go from newly born to adult in only 13 years. It's too long, otherwise.

I noticed you've got the art for the growth vat now, so it's only a matter of time until we can create vatgrown colonists anyway.

Nice! Once growth vats are a thing, I suspect this mod will get a lot more users and popularity.

Known Incompatible Mods:
...Combat Realism

Ouch. That may be a deal breaker for me as I usually want to use it. Combat Realism (now called "Combat Extended") is one of the more popular mods, with thousands of users. That said, CR/CE is also one of the biggest mods out there, with many hundreds of lines of code. So it's not surprising that it is incompatible with various mods - and not just weapon mods.

A17 update? Coolness! 

The file name is ApparelloA17? Damnit Shinzy    I thought we talked about this. You can't name the file like this cause if you update then with new stuff we will have to either have the game telling us were missing files or we manually have to rename it back to what it was.

But you shouldn't have any other ApparelloA17 in any of your A17 mod folders to begin with!

I believe Dragoon is correct. If you append the folder name with a version number, then when the game updates down the road and you release a new version with a new folder name (e.g., "ApparelloA18"), players that install the new version will probably just unzip in their /mods/ folder. That will create a new, separate folder and the game will see two versions of the mod.

Even if they delete the old "ApparelloA17" folder, this will likely confuse the game and generate error messages.

Regardless, I consider that a poor modding practice. Keeping the folder name consistent between mod versions is less likely to cause problems. You can have the .zip archive named "Apparello_A17.zip" or whatever, without issue. But I think it's better to rename the .zip to do that, instead of renaming the folder.

Taking note of the license mentioned in the OP, I've updated Ship Engine Size Adjustment so it will work with A17. See attachments below.

I desired to also upload it to Steam Workshop, since there seems to be a number of Steam RimWorld players who never bother to look on the official forums for mods (or who may feel daunted at the prospect of manually installing to the /mods/ folder). But, I did not.

However, I did make a derivative that is basically a complete rewrite to work with notFood's "MFO" or Mod Friendly Overrides. Again, see the attachments below. Also, I released this one on Steam (with credit to True Destroyer). This method is more mod-friendly and is both easy to update and (probably) future-proofed for future RimWorld releases. However, this MFO version absolutely requires MFO to work. Also, unfortunately, it currently only works for A16... at least until MFO gets updated to A17.

[attachment deleted by admin due to age]

Aw... shucks.

Well, what's the "Prototype Pack" for, anyway?

[Is there any way to obtain downloads for older versions?]

I'm sure that I'm not the first player to ask this, but:

Is there any way to obtain downloads for older versions?

I still have my email which provides a link to the "DRM-free personal download link(s)". However, all this does is provide four different links to the latest (A17) version, one each for Windows, Linux, Mac and a "Prototype Pack"... whatever that is.

I just want to know if there is a way to legitimately obtain older DRM-free versions. The reason I ask is because I'm trying to update some old A15 mods and this is much easier to do when I can use a file comparison tool with the original A15 Core files.

[was]

Things that would make modding easier: A built-in system to do xml patches and overrides.

Though, I feel such are more important to ensure better mod compatibility and less headaches for modders, such as making mods easier to maintain. I talked about this in the Proposal: .patch system for better mod compatibility thread.

Granted, there is notfood's MFO (Mod Friendly Overrides) and AlcoholV's Ac-Override Injector. I've used both and both have their strengths. But both systems also have their limitations. And these rely on a modder maintaining them for each update. If not, mods that rely on them could be left up a creek without a paddle.

... I was going to also mention the need for a better way to do code injections. But, I just read that HugsLib now uses Harmony library, which is supposed to be a much better practice. So... never mind.

Edit:

Never mind... I just found out about the new PatchOperation system. That's pretty much what I was asking for.

[Ac-Override Injector]

Just an FYI: Your Ac-Override Injector seems to work fine with A17. At least, myself and another player haven't found any issues with this and my Mid-Rage Drop Pods: MF. It is injecting. There's no error reports in the log, either. The only thing missing seems to be an update to the target version so RimWorld could recognize it as current.

Done, here you go. The chance is 25%, for both people and animals. I hope that's fine.

Yes! Thank you.

I also made this mod, but I have not released it because of yours. I bent the knee.

I am probably going to mix it up and add a mechanic or something. If you were thinking of doing that as well, PM me and we could work together if the Gods will it.

What exactly do you have in mind? I feel like the more complex this mod would be, the fewer people will use it. Do let me know, if you have a nice idea, I'm willing to help you or give feedback/bugtesting/whatever.

Perhaps he's thinking of implementing something like what faltonico suggested, subtracting extra hitpoints from the torso, like a critical hit or something? Or, maybe he's thinking of increasing the bleedout rate so they die faster?

Instead of reducing the randomness (sorta), why don't you try reducing the hitpoints of the torso? It would increase the chances of dying without the need of a random dice toss.
Any percentage of reduction might be translated directly onto more chances of dying.

Q: In A17, does mechanoid surgery still use the Medicine skill instead of Construction? Or has that been fixed?

AFAIK, that was the way it worked in A15. And I used to use a mod to fix this issue.

There are several comments on the Steam page for No Death Randomness who are asking for a version that reduces death randomness from 67% down to something like 20% or 30%.

Several of us would appreciate it, myself included. Reducing the death randomness is less OP than removing it entirely. (And there are at least one or two non-lethal weapon mods now which are truly non-lethal even without this mod.)

[new]

I'd say the solution would be to bump up charge lance's range up to 45, it's basically a sniper rifle anyway.

The charge lance is already quite OP. The wiki explains that it's a, "dangerous weapon due to its low initial warm-up, high accuracy, and high damage." They already have a range of 37 tiles. And you want to bump up the range so it's as good as a sniper rifle? Why not give scythers unlimited doomsday rockets or a dark-matter cannon while you're at it? Imagine what that's going to do for raids with raiders who are lucky enough to carry charge lances.

In any case, that would at least be more challenging than "wait for them to enter killbox, then go deal with the centipedes".

I suppose this strategy can feel too predictable or boring for players who have already logged a lot of RimWorld hours. I have no issue with forcing players to use a different strategy. However, heaping on more and more unfair advantages onto mechanoids is just going to make their unfair advantages and their weak AI all the more obvious. But part of the problem is that game AI just can't match human player ingenuity.

Perhaps what you're looking for is the MoreLesserMechnoids mod? It adds three new types of mechnoids and changes the behavior of vanilla mechnoids slightly. This should change your strategy in how to effectively deal with them in trying to minimize casualties. And it shows that this can be done without heaping more and more advantages onto them.

You can just hide in your killbox and lure scythers in range of your guns.

Can't the same be said for most enemies in the game?

Q: With the ability to deconstruct unwanted apparel into cloth, does the amount of cloth returned reflect the skill of the colonist and/or the hit points left on the apparel? (This is the way the ReclaimFabric mod works...)