Messages

I see that the loom allows our colonists to turn unwanted apparel into cloth. However, I wanted to know:

Q: 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...)

[must]

...Do you think miniaturization mod would cause this problem?

Have you tried moving it to the bottom of the list. THEN building a new electric stove?

The miniaturization mod must be at or near the bottom of our mod load order in order to work right. I learned this the hard way. Any mod with buildings (etc.) located after miniaturization in your mod load order will not be recognized as having miniaturization support.

However, I believe a lack of the ability to minify certain furniture or buildings should be the only consequence of miniaturisation being in the wrong order.

Make is so that scythers stay with the centepedes, they waste their tactical advantage by coming in two waves.

Doesn't that depend on the weapons their enemy (your colonists) are equipped with?

Okay... I'll just have my colonists snipe the scythers with guns while they hold back next to their slow-as-snails centepedes.

[may]

It's probably been suggested before, but crops ought to have different temperature tolerances. As it is now, every crop can be grown as long as it's growing season and the soil has a sufficient fertility rating.

I think the crop system is pretty good the way it is. Having a limited growing season is almost like dealing with temperature tolerances. Granted, some plants just won't grow in certain climates. However, growing something in the wrong climate may mean it will still yield food, just not viable seed. Even in cold northern climates like in Alaska and Canada they can grow carrots and many other vegetables we are familiar with. It's just that the window for growing is shorter.

And soil fertility does have a big impact on growing speed and which crop is best. Gravel only has a fert. of 70% and players often recommend that only crop worth growing in that are potatoes. See this video for details: Quick Tips for Farming, Food and Drug Crops, and Hydroponics

Mushroom and fungus plants should grow year around and require very little light and low fertility...

That depends on the type of mushroom or fungus. Some require rich soil or lots of moisture, some don't. Some need a near absence of light, others are more tolerant.

...flowers and smokeleaf should be extremely temperature sensitive and would require a temperature controlled hydroponic room to be grown in some climates...

Again, that depends heavily on the species or variety. There are some species of flowers that thrive in the desert. And there are some flowers that grow in some bitter cold tundra areas where little else will grow.

I think it's too easy to farm cash crops like psychoid plants too. A single harvest can yield hundreds of doses of flake. Nerfing psychoid plants to require a narrow temperature range (around 35-45) would also give incentive to settle in rainforest and desert biomes.

I think you should read this reddit: Some quick numbers for the drug farmers [RimWorld]

To summarize: The math shows that drug farming is hardly worth it. I've read similar conclusions elsewhere, too. Believe it or not, growing hops and brewing beer seems more profitable than any form of drugs. And utilizing regular crops is not that far behind drugs. Cooking lots of fine meals with a decent cook is a decent way of making money in RimWorld. Don't believe me? Then check out this video: How To Make Money in Rimworld

Not sure if this is already ingame, but fertility ought to decrease slightly around mountains/rocky areas. would nerf mountain bases by making them a bit further away from their food source and force early investment in hydroponics.

In a vanilla game, an "early investment in hydroponics" seems rather difficult. Aside from the research to unlock, you have to build sufficient power and/or batteries. A single sun lamp requires 1600 W, not to mention the 70 W per hydroponics bay.

I've read several complaints about the power requirements of hydroponics. And several in RimWorld chat wrote that hydroponics isn't worth it unless you've settled in tundra or ice sheet where there isn't much other choice for food. That may explain why mods which lower the power requirements for hydroponics seem so popular...

As for the fertility of mountain areas: Actually, such areas are covered in a lot of mine-able rock, leaving comparatively little for grass, trees or soil. And, in my experience, they also seem to have more gravel and overall less soil fertility than usual.

[directly]

I just discovered AlcoholV's Ac-Override Injector. In some ways, this is similar to notfood's MFO. However, MFO can do a lot of things that Override Injector can't.

Override Injector only has one use. But that makes it a lot easier to use. It's perfect for changing the values of specific tags without having to copy or replace a whole def or a whole set of data.

For example, I used Override Injector to directly change the <fuelCapacity> of the PodLauncher. One line of code is all it took:

Code Select Expand

<LanguageData>

<PodLauncher.comps.0.fuelCapacity>300</PodLauncher.comps.0.fuelCapacity>

</LanguageData>

To accomplish the same thing with MFO required replacing the whole <comps> section (with less potential mod compatibility):

Code Select Expand

<Defs>

<Override.Def Target="PodLauncher">

    <comps Mode="Replace">
      <li Class="CompProperties_Refuelable">
        <fuelCapacity>300.0</fuelCapacity>
        <targetFuelLevelConfigurable>true</targetFuelLevelConfigurable>
        <initialConfigurableTargetFuelLevel>75</initialConfigurableTargetFuelLevel>
        <fuelFilter>
          <thingDefs>
            <li>Chemfuel</li>
          </thingDefs>
        </fuelFilter>
        <consumeFuelOnlyWhenUsed>true</consumeFuelOnlyWhenUsed>
        <autoRefuelPercent>1</autoRefuelPercent>
        <showFuelGizmo>true</showFuelGizmo>
        <drawOutOfFuelOverlay>false</drawOutOfFuelOverlay>
<drawFuelGaugeInMap>true</drawFuelGaugeInMap>
      </li>
    </comps>

</Override.Def>

</Defs>

xml patches/overrides/injections would be a nice thing to have, but those incompatibilities are generally more or less trivial to begin with, they just require a bit more busywork replacing whole defs instead of just patching a value or two.

I think you're missing the point. XML patches, overrides, and injections are not really about making it easier for modders to mod. Rather, it's more important that mod users can use a lot of mods together without error messages, lost functionality, or worse.

The common practice of "replacing whole defs instead of just patching a value or two" is a major culprit of mod conflicts. Different mods may try to change different aspects of the same defs. But there would be no reason for them to not work alongside each other if mods could freely change or insert whatever XML code they needed to without throwing out the baby with the bath water.

For instance, one mod may add "Neutroglycerin" to Boomalopes and Boomrats as a milkable item to make drugs or explosives. Another mod may change Boomalope leather. Still another may make Boomalopes trainable so they can haul like dogs. And yet another (Combat Realism) may add FSX to Boomalopes and Boomrats as a shear-able material.

Have you tried to get Combat Realism to work with mods? It replaces so many vanilla files and vanilla defs that it seems incompatible with a good chunk of the mods out there. Aside from everything guns and combat related, it also changes:

• humans
  
• mechanoids
  
• boomalopes
  
• boomrats
  
• oribital/outlander/caravan traders
  
• food (all raw food ingredients and all cooked meals)
  
• stone chunks
  
• all resources like wood, silver, gold, steel, plasteel, etc., etc.
  
• medicines (all of them)
  
• factions (pirate, tribe and outlander)
  
• and much, much more

What does stuff like food and stone chunks have to do with combat, you might ask? Well, a lot CR's changes are done solely to add <Bulk> tags to everything.

With something like MFO, though, <Bulk> tags could have been inserted without replacing everything outright and without affecting mod compatibility.

The real problematic incompatibilities are in .dll conflicts, where only better coordination between modder(s) involved is going to make any real difference.

Those may be more problematic. And, unlike XML conflicts, it does sound like the only solution is better cooperation between modders. But while I may not be as knowledgeable in .dll modding, in my experience XML conflicts seem a lot more commonplace.

Perhaps if more modders took advantage of XML tools like MFO or Override Injector, then the importance of XML conflicts would give way to .dll conflicts. But such tools remain largely unused and unheard of. I'm not aware of a single mod that takes advantage of MFO. And the only mods that use Override Injector (that I could find) are the author's own Quiet Weather and my Mid-Range Drop Pods: MF.

[at all]

Use glitterworld medicine and you will have a 120 % multiplicator operation success chance.
Linked with a level 16 doctor with 100% consciousness, manipulation anv view, it gives 119 % chance of success.
What do you need more ?

Not all colonies have access to glitterworld medicine or a doctor with a l33t medicine skill. And even those that do could suffer a setback, like having your best doctor die from an attack or disease or a loss of your stock of glitterworld medicine and no traders in sight to get more.

Besides, a 3% bonus isn't asking for much. That's the same pitiful bonus for having sterile tiles for the hospital floor.

It just feels a bit immersion breaking that having hospital equipment like hospital beds and vitals monitors does not improve operation success chance at all. Players tend to assume it does, until they find out otherwise.

[nothing]

A hospital bed has a higher healPerDay than the average bed and has both a ImmunityGainSpeedFactor and a MedicalTendQualityOffset. That's fine and dandy for tending to the sick or wounded. However...

Is it too much to ask that the use of a hospital bed should add... I don't know... at least 3% to the success chance of medical operations?

But, AFAIK, the use of a hospital bed does nothing for operation success. That does not sound right.

[nice]

I typed this spreadsheet up a while ago for personal use, as I wanted a way to keep track of the skill levels of each of my colonists and which skills they have an interest or burning desire in. (See attachments below.) And I wanted to do this on paper. I print several pages out and then use a pencil scribble the numbers, as well as {i} for interest or {b} for burning.



In case you're wondering, the "Management" skill is for the Colony Manager mod and the "Fishing" skill is for the FishIndustry mod.

Yes, I could simply click on the colonist in question to get a list of their skills. And I frequently do just that.

But, say, I get the option to recruit a new colonist, rescue a downed raider, or I get a refugee chased event? I wanted a chart of my colonists to compare them with to make it easy to decide whether I want them or whether it would be worth the effort. (I'm also using the Refugee Stats mod to get more details about refugees.)

Also, with both Colony Manager and FishIndustry mods, the Management and Fishing skills are not always visible. (They can get cut off, depending on my screen resolution.)

BTW: It would be nice if RimWorld had a Colonists screen that would allow us to look at the stats of all of our colonists at a glance.

[attachment deleted by admin due to age]

I just discovered notfood's documentation for MFO (Mod Friendly Overrides). From reading it... that sounds a lot like what I was talking about. I had no idea it could do stuff like that.

(BTW: notfood's Mod Friendly Overrides original post and discussion is buried inside the Miniaturisation Overloaded topic, so it seems easy to miss.)

It sounds like if more modders used MFO (or overrides) to make changes to vanilla stuff, then mod conflicts would be much less common.

[not]

No wonder he call himself "Der Failer" he failed to add a proper work to the RTGs ! :-)))
Both just need 1 work to made, i suggest 100 and 150 for the adv. one.

If you looked at the code before making this accusation, you'd see that it still says <WorkToMake>2500</WorkToMake>, which is the same as it was in the A15 version. The problem is that in A16 Tynan changed <WorkToMake> for buildings to require <WorkToBuild> tags, instead. RimWorld does not trigger an error message over this and, instead, just defaults it to 1 work.

As modders usually just look for error messages and corrects them, many modders overlooked this A16 change. (See this post or this post.) I spotted at least half a dozen mods in my /Mods/ folder with this issue and I've read about several others, so this is a fairly common problem.

It's not like Tynan posts a modding announcement with each version, with details of all XML and code changes, to help modders to know what to do. And the game itself is often rather cryptic or silent on problems. If anyone is to blame, I suppose it might be Tynan for not making it easier to update mods or debug them.

We should be grateful to Der Failer for even attempting to update Itchy's mods to A16 as he isn't even the creator. I can tell from experience that updating mods can be a major time sink and not terribly fun, esp. when it comes to updating someone else's mods.

On the subject of making the advanced RTG require more work to build, I agree. 2500 work may sound like a lot, but it's not. That's the same work as building a solar array, while building a geothermal generator requires 6000 work. So, I suggest that the simple RTG require 3000 work and the advanced version require 6000 work. (That would be like changing the current 30 seconds to build into 36 seconds for the simple RTG and 72 seconds for the advanced.)

[Circumstances:]

1. Circumstances: Playing in 0.16.1393, stone tiles do not respect the work that should be required to build them.

2. What happened: Stone tiles are built very rapidly, despite how the description says, "Pretty to look at, but they take a long time to lay." This is regardless of how much construction skill the colonist has (or lacks).

3. What is expected: Playing in A15, I can confirm that building stone tiles takes a long time.

4. Steps to reproduce: Order multiple stone tiles be place, making sure you have enough stone blocks. Have a colonist with low construction try to complete this bill, noting how rapidly this is completed. Now repeat this procedure in an A15 game, noting the marked difference in speed.

5. The solution: skullywag reported in this thread how <worktomake> tags are no longer respected for buildings in A16 and how we are supposed to replace them with <WorkToBuild> tags, saying that failing to do so means that the building takes no ticks to build. (In other words, they're built instantly.)

Comparing A16 with A15, almost all <worktomake> tags for buildings have been replaced with <WorkToBuild> tags... with the exception of stone tiles. (This can be seen in the "TileStoneBase" abstract in Terrain_FloorsStoneTile.xml.)

The logical conclusion is that how <worktomake> tags were left in "TileStoneBase" (instead of being updated to <WorkToBuild> tags) was an oversight.

[Tinkerer.XML]

The "substitute version" you mention has a tiny flaw:

In Tinkerer.XML, the Tinkering bench and the Pattern designer both still have <WorkToMake> tags.

Thing is, as of A16, <WorkToMake> tags no longer work properly for buildings (and only buildings). This does not generate an error. However, not fixing this means that the building will not require any work to build. (You just rename the <WorkToMake> tags to <WorkToBuild> tags to fix.) Just an FYI...

Thanks, skullywag! Those <worktomake> tags are definitely easy to miss if they don't even generate an error. (BTW: This must be a name change only as the values for <WorkToBuild> are exactly the same as for <worktomake>.)

Another discovery: In trying to update a mod with a bed, I learned that <Bed_HealTickInterval> tags are no longer valid. Instead, mods must use <bed_healPerDay> tags if they want their beds to heal colonists while sleeping. The values do not translate, either. But the vanilla bed has a value of "7", which is a good reference point, I guess.

Oh, and most furniture seems to have this:

Code Select Expand

<comps>
<li Class="CompProperties_RoomIdentifier">
<roomStat>Impressiveness</roomStat>
</li>
</comps>

I believe that all this does is tell the game that this building affects room impressiveness.

When trying to update a mod with a mortar, I found these issues:

• The <turretBurstWarmupTicks> tags are no longer valid. Mods must use <turretBurstwarmupTime> tags, instead. And this value is measured in seconds instead of ticks.
• Similarly, the <turretBurstCooldownTicks> tags are no longer valid and mods must use <turretBurstCooldownTime>, instead. This is also measured in seconds instead of ticks.

Only 41 views an no replies? 

Isn't there a desire for better mod compatibility? With their new .patch system, mod conflicts are quite rare in Starbound. Just imagine if RimWorld players were able to use huge mods like Combat Realism without worrying about compatibility with other mods.