Messages

[EDIT: woops. not sure how PC actually handles these. ignore this comment ^]

Yep, for some reason the mod locks the rib operation behind the research. Just the ribs.

If you want to take that requirement out, look in "Recipe_BionicProsthetics" under RecipeDefs in EPOE and remove <researchPrerequisite>RibReplacements</researchPrerequisite> from the 4 ribs operations.

You'll still need the research to craft them, but you'll no longer need it to put 'em on if you want to start with them.

EDIT: woops. not sure how PC actually handles these. ignore this comment ^

Hey, for some reason I cannot install the new ribs on my colonists. In operations tab, there is no "install X rib" option. Other things (legs, ams,...) work fine. I have researched every single thing available in my save file. Any suggestions?

Just tested this out in the latest version. Ribs work just fine. The operation itself is locked behind the "rib replacements" research. Once the research is done, you'll need any rib somewhere on your map, and the operation should appear when you click.

Tested in Prepare carefully, I can´t install ribs too. :/

Prepare carefully only lets you spawn the ribs. It doesn't let you attach any of them at the start. You'll still need to research the operation.

^That just means there's no <label> for the jobs introduced by this mod. The Work Tab mod uses the <label> by default to show you the jobs when looking at the work tab in obsessive compulsive rainbow mode.

That is totally fine to ignore. Though you can add any labels you want under workgiverdefs in EPOE such as <label>make prosthesis</label>.. or just download the latest version which I assume you haven't already.. because 1.72 has the labels defined now. I checked.

Heya. Just noticed duplicate operations on version 1.72. Apparently, it was caused by defining <recipeUsers> Human </recipeUsers> on certain recipes when the same exact recipe defname already exists in Races_Humanlike.

Removing recipeUsers on operations already on Races_Humanlike should clear that right up.

Choosing either will still use the mod's recipe, so it's mainly more of a visual bug. Sample (4 install peg leg):



Man.. I really want to get into modding.. but everyone just sounds so.. demanding. :^(

Vents and coolers are still being worked on. It says "STILL WORKING ON THIS ONE FOR A14" right under the picture.

C'mon mang.. let the artist work. You'll find those inside the thoughtdefs folder. You can easily change the mood value, duration, and stacking of all thoughts in the game as they are all just numbers.. as seen here:

https://www.reddit.com/r/RimWorld/comments/4x0xwx/psa_how_to_modify_those_annoying_debuffs/

If you want to want to beg like me, make sure it's atleast for a C# mod or something complicated. Like so:

RedistHeat vents + heatpipes pls

Kidding.. but yeah. For mods that just edit numbers, let's not take up their time.

_{really want to study the A14 code for dem heatpipes though}

Spooky. Probably something environment or processor related then.

Well, this is still much better than losing a whole stack of items like the previous versions, so.. hurray? :^)

Thanks. That definitely fixed the truncation when you build them on top of tiles with items. Only time will tell if it fixed that other issue with normal use that people keep mentioning but I can't reliably reproduce.

Just a minor bit though: built a tray rack on top of 2 stacks with 10 meals each.. get 21 meals as combined output. It doesn't have to be god mode build on top of existing items.. even a regular build causes it.

Before you sledgehammered truncation, stackCount also registered 21 in the logs before it would delete one of the stacks-- so this was probably already here long before. It just wasn't showing up because it gets truncated before we get to see the 1 extra.

Everything seems reasonably stable on my end as well. Only time I got truncation on 1.09 was when I god moded a storage object into tiles which already had items. The items were compatible with the storage, but the ones on the input block just up and disappeared anyway.

I also distinctly remember a minor log warning that stated something like "pawn is already hauling to object" after manually right-click ordering (while paused) several items to be hauled. The first pawn I ordered hauled just fine, but the subsequent pawns just cancelled the job and the warning popped up. Besides the log popping up, nothing bad seemed to come out of it though.

I'll test 1.11 when I get back.

[So, I suggest restricting storage to accept only 1 type of item for now so the storage object doesn't get locked.. allowing you to reach the maxStorage value.]

Hi, Skully. The maxStorage setting in ExtendedStorage seems to be... only working rarely. It's odd, as it seems to work a little bit, but it doesn't work very well...

I can actually answer that quite a bit. Been digging through big modders' codes to try and learn a thing or two.

Each expanded storage object seems to be made up of 1 "input" block and 1 "output" block (notice how they are all 2x1 buildings)-- pawns haul allowed items into the input block, then the storage object tries to stack the items into the output block, keeping the input block free. The maxStorage parameter only dictates how much can be stacked in the output block.

Since items can only stack with themselves, once a pawn brings a different item to the input, the storage item effectively gets locked as the input block gets taken up. So, I suggest restricting storage to accept only 1 type of item for now so the storage object doesn't get locked.. allowing you to reach the maxStorage value.

I'm trying to learn some C# modding though.. maybe I can edit this to work more intuitively once I get good enough. No word on when though, am currently total scrub. :^)