Topics

I could have sworn that, some time ago, I read a topic on Ludeon's forums explaining a weird way in which certain combinations of mods will, by chance, result in completely unpredictable and sometimes very bizarre game behavior. The topic explained that this issue sometimes makes solving or even tracking down the bugs and mod conflicts that users report even more difficult for mod authors.

I seem to recall that  it had to do with game memory and/or the way mods are loaded.

I really thought I had bookmarked this topic. I've searched and searched through my bookmarks and game notes, but I can't seem to find it now.

Is my memory failing me? Was this a thing? If so, perhaps someone can point me to the topic or give me a hint for the title or subject matter? Please?

Looking on the Steam store, I noticed that all games currently have a section under the heading that says,
"Nominate this game for the Steam Awards." (Yes, Steam has had something like this in previous years.) Anyway, there's a selection of several awards that a game can be nominated for. And I was curious what others think would be the most appropriate category for RimWorld. The awards:

• The "Game of the Year" Award
• The "VR Game of the Year" Award
• The "Labor of Love" Award
• The "Best Environment" Award
• The "Better with Friends" Award
• The "Best Alternate History" Award
• The "Most Fun with a Machine" Award

Obviously, several of these are inappropriate, such as "Best with Friends," "VR Game of the Year" and "Best Alternate History." And I suspect "Most Fun with a Machine" is intended for games that revolve around machines, such as where you pilot a starship, tank, car or mecha.

Myself, I'm leaning towards nominating RimWorld for the "Labor of Love" award.
Thoughts?

[Apparently, not even two of the best bionic eyes in the world can push shooting accuracy beyond 100%.]

I was just watching this video:
RimWorld Science Alpha 17: Cover and Accuracy — RimWorld Alpha 17 Weapons and Cover SCIENCE!!!

Around 1:48, Bjorn explains how manipulation and eyesight affects shooting accuracy. He explains that there is a hard limit on how much good eyesight can benefit shooting accuracy. Apparently, not even two of the best bionic eyes in the world can push shooting accuracy beyond 100%.

Consider that the closer a colonist's shooting skill gets to 20, the closer their base accuracy gets to 100%. So, if I'm understanding correctly: At some point, a colonist's shooting skill becomes high enough that bionic eyes no longer provide any benefit.

Really? Does that sound right to you? If we had telescopic bionic eyes comparable to that of Ghost in the Shell, Shadowrunner, Cyberpunk 2020, etc, I would think that they would always enhance eyesight above baseline humans - unless, perhaps, you got the cheap, substandard stuff. If cyber eyes do enhance eyesight, then shouldn't it be a given that having such would increase shooting accuracy, even if the person in question was already a world-class sniper?

I don't see how having a shooting skill of 18 or 20 or whatever should be a hard limit - a wall beyond which bionic eyes can't help you. That's very counter-intuitive, anyway, if not illogical.

On the subject of brightness and darkness as it affects accuracy:

While it used to be easier to hit targets in a brightly lit area and it used to be more difficult to hit targets enveloped in darkness, this is no longer the case as of A16. But... why? What purpose did this change serve?

Obviously, it was much more realistic when brightness level affected accuracy. Was it a game balance issue? If so, couldn't this affect have been nerfed somewhat instead of removed entirely? Again, this is counter-intuitive and illogical.

Further, having to deal with light levels added a more depth to game strategy. Sure, players often illuminated the area inside their kill-boxes and outside their walls. But this took a degree of thinking, planning and effort. It's not entirely free, either, if the lights require electricity.

Please, consider re-introducing the illumination impact on shooting accuracy.

Also, please give players a reason to have bionic eyes on their uber-skilled shooters. Bionic eyes are expensive. And surgery success is not always guaranteed. There's a certain risk involved. Why go through the expense and risks for no benefit?

[same]

As a modder, I've taken a close look at various /Core/ XML files. Recently, I've taken a look at animals and pets like dogs, mostly to compare them to modded animals to see how certain tags are supposed to work.

Well, I was surprised to discover that not only do animals lack any sort of <weight> tag, but that <baseBodySize> tags are not very precise. I don't care about fictional animals like the Thrumbo. And I could imagine some variance, since this is set on an alien world some centuries or millennia in the future. But, sometimes, it's quite an inaccurate representation of their relative sizes. Examples:

• Human : baseBodySize = 1.0
• Elephant : baseBodySize = 4.0
• Gazelle : baseBodySize = 0.7
• Iguana : baseBodySize = 0.2
• Dromedary : baseBodySize = 2.0
• Yorkshire Terrier : baseBodySize = 0.3
• Husky : baseBodySize = 1.0
• Labrador Retriever : baseBodySize = 1.0
• Wolf : baseBodySize = 0.85
• Cow : baseBodySize = 2.0

Some of this breaks my suspension of disbelief. Why give the Husky and Labrador Retriever the same baseBodySize as humans? Is this an alternate reality where those are suppose to be very large breeds, on the same scale as the St. Bernard or Marmaduke? And why make the Wolf smaller than the Husky and Labrador Retriever, yet significantly more dangerous than them in combat?

According to Wikipedia (and other sources), here's the average weight:

• Human : average (worldwide) = 62.0 kg (136.7 lb)
• Elephant, African : average weight = 5897 kg (13000 lbs)
• Elephant, Asian : average weight = 5443 kg (12000 lbs)
• Gazelle, Dama (largest) : average weight = 57.5 kg (126.5 lbs)
• Gazelle, Red-fronted (medium) : average weight = 29.7 kg (65 lbs)
• Gazelle, Thomson's (medium) : average weight = 23.7 kg (52 lbs)
• Iguana, Blue : average weight = 14 kg (31 lbs)
• Iguana, Green : average weight = 4 kg (8.8)
• Dromedary : average weight = 459 kg (1012.5 lbs)
• Yorkshire Terrier : average weight = 3.2 kg (7 lbs)
• Husky : average weight = 21.5 kg (47.5 lbs)
• Labrador Retriever : average weight = 30.5 kg (67.2 lbs)
• Wolf (Gray or Timber) : average weight = 40.6 kg (89.5 lbs)
• Cattle ("Cow") : average weight = 907.2 kg (2000 lbs)

Granted, baseBodySize is certainly not meant to be the same thing as weight. However, there is a size relationship with weight and I can't imagine a better animal statistic to use.

If we were to use the human average weight as a baseline, then we could perhaps get a better idea of appropriate sizes by way of ratios and multiplication. For the purpose of this discussion, let's assume a baseBodySize of 1.0 equivalent to the Avg. Human Weight of 136.7 lb and call it "AHW". So...

• Human : average (worldwide) = 62.0 kg (136.7 lb) = 1.0 AHW
• Elephant, African : average weight = 5897 kg (13000 lbs) = 95.1 AHW
• Elephant, Asian : average weight = 5443 kg (12000 lbs) = 87.8 AHW
• Gazelle, Dama (largest) : average weight = 57.5 kg (126.5 lbs) = 0.93 AHW
• Gazelle, Red-fronted (medium) : average weight = 29.7 kg (65 lbs) = 0.46 AHW
• Gazelle, Thomson's (medium) : average weight = 23.7 kg (52 lbs) = 0.38 AHW
• Iguana, Blue : average weight = 14 kg (31 lbs) = 0.23 AHW
• Iguana, Green : average weight = 4 kg (8.8) = 0.06 AHW
• Dromedary : average weight = 459 kg (1012.5 lbs) = 7.4 AHW
• Yorkshire Terrier : average weight = 3.2 kg (7 lbs) = 0.05 AHW
• Husky : average weight = 21.5 kg (47.5 lbs) = 0.35 AHW
• Labrador Retriever : average weight = 30.5 kg (67.2 lbs) = 0.49 AHW
• Wolf (Gray or Timber) : average weight = 40.6 kg (89.5 lbs) = 0.65 AHW
• Cattle ("Cow") : average weight = 907.2 kg (2000 lbs) = 14.63 AHW

Some are close to baseBodySize - the Blue Iguana, for example, at 0.23. The Gazelle is okay, too. And I could forgive the large animals like the Elephant and Cow because: game balance. Also, I would imagine that the baseBodySize scale becomes exponential for anything larger than human. But, even being generous, there are large discrepancies with some of these (mostly the canines and other predators).

[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.

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.

[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]

[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.

Thundercraft's Mods

I decided to start this thread as a central location for my A16 mods. Please, don't hesitate to give feedback.

Mod index:

• Less Default Hair [A16]
• Rage and Zonk [A16]
• Antimatter Power Boost [A16]
• Mid-Range Drop Pods [A16]
• Right Tool Rebalanced (A fork of RTFTJ) [A16]
• More Population [A16]

[sometimes]

Often, we can use several mods together without much issue. However, sometimes, mod conflicts can cause players a lot of grief, especially if they are trying to use a lot of mods together. Just tracking down the culprit can be a frustrating task. And I have to wonder if this may be discouraging some players from using mods altogether.

When I was learning how to mod for Starbound (a sandbox akin to Terraria in space), I read the following announcement. It struck me as an innovative approach to maximizing mod compatibility and reducing the likelihood of issues:
August 19 – The day when all your mods died.

This .patch system allows modders to easily change a single line (or even part of a line) in their JSON files, without having to replace entire files or entire sets of data. The "op" operator can take "test", "add", "replace", "move", and "copy" commands, to change, remove, or shuffle data around.

Granted, the situation with RimWorld mods is different. Instead of using JSON, it involves .XML files and/or maybe compiling a .DLL. And modders can opt to change just one item in a file, rather than replace the whole thing. However, with lots of mods, it is inevitable that several of them will try to change some of the same vanilla items.

Wouldn't it be nice if we could "add" new tags to a vanilla item (say, the stonecutter's table) or perhaps "replace" something (say, the <SharpDamageMultiplier> of steel) and do this in a way that would not automatically cause a conflict or other issues with other mods?

Often, we can deal with mod conflicts by making sure that the mod we arbitrarily place more importance on is later in our load order, to make sure those changes take priority. But this does not always work. Sometimes, the only solution is to either disable an offending mod or manually combine the two.

For example, Combat Realism has nearly 600 files and many of these make changes to vanilla items! It's no wonder, then, that it conflicts or causes issues with so many other mods. I'm no expert, but it seems like large mods such as CR depend heavily on the changes it makes to vanilla files, such that any changes other mods make to the same files are likely going to cause problems.

[reserve]

With the introduction of the research tree, there are now <researchViewX> and <researchViewY> tags for <ResearchProjectDef>. (See the ResearchProjects_Tier?_Misc.xml files.)

In the Alpha 16 unstable branch feedback topic, this post grabbed my attention:

Discussing with people in a Rimworld Discord channel #a16-discussion channel we came to the conclusion that the current way the Research tree is setup makes it extremely troublesome for mods that add their own research to play nice with both the Core mod and other mods.

Our proposed solution for this perceived problem is to make each mod add their own research either up or down from the Core research. It would only have to take up as much space as it needs in order to work well...

As someone who has created a few mods and is working on more, this concerns me.

Q1: What happens to a mod in A16 if it adds new research, yet it lacks <researchViewX> and <researchViewY> tags?

Q2: How would modders make sure that they don't - figuratively speaking - step on the toes of other modders when deciding where to place their mods' research in the research tree?

Should we start a thread and reserve specific <researchViewX> and <researchViewY> values? Should each modder reserve their own <researchViewY> for all of their mods? (This concept is not entirely new to me. In modding process for certain other games it is sometimes necessary to publicly reserve a certain range of limited game resources.)

[replaced]

I just thought that I would start a topic as a place to share observations about significant changes to XML with A16 and to discuss what is or isn't necessary to update a mod. Disclaimer: I'll freely admit that I'm no expert at modding. But I'll start:

• With the introduction of the research tree, there are now <researchViewX> and <researchViewY> tags for <ResearchProjectDef>. (See the ResearchProjects_Tier?_Misc.xml files.) I have not yet tested how the game reacts if a mod lacks those.
• For Hediffs, I've noticed that <bleeding> tags have been replaced with <bleedRate> tags.
• Also, the way HediffComp classes are handled is different. It's now "HediffCompProperties", instead. For example, what used to be <comp><li><compClass>HediffComp_Disappears</compClass> is now done with
  <li Class="HediffCompProperties_Disappears">.
• Items have <Mass> tags now, to indicate weight. Are these mandatory? Will the game throw an error or warning if an item lacks these?
• For guns, <warmupTicks> tags have been replaced with <warmupTime>. (See Weapons_Guns.xml.) I'm not sure what the exchange rate is, but it seems warmupTime is typically around 1 or 2.
• I've noticed <smeltable> tags on guns now.
• I've noticed <Beauty> tags on guns. (A negative value, that is.)
• I noticed that the <RangedWeapon_Cooldown> for several guns was increased. (I thought that might be noteworthy for efforts to balance mod weapons with vanilla.)

Also, it should be worth noting that the market value for several materials has been changed:

Code Select Expand

       gold = 10 (was 15)
   plasteel = 14 (was 27)
    uranium = 6 (was 5)
      cloth = 2.8 (was 1.5)
  synthread = 7 (was 11)
devilstrand = 10 (was 12)
hyperweave = 16 (was 45)
       wool = 3 (was 4)

I think any changes to the market value of materials should be important to modders because the ingredient costs and market values of modded items should probably reflect such changes.

Feedback? Have other observations on code changes or advice on updating for A16?
BTW: I just noticed that the XML Auto-Documentation Test Build topic has been updated for A16.

Edit (Only somewhat related):
Notable changes between A13 and A15 (useful for updating old mods):

• "BuildingTall" is no longer valid for use with <altitudeLayer> tags. Must use "Building", instead.

[before]

I've seen several modders release their mods on GitHub. I've never really bothered with GitHub before, but I thought I would try to use it to release a mod. I followed the tutorial and managed to figure most of it out. However, there is one issue I'm having that I can't figure out.

I finally managed to create a Release. However, it did not do it the way I wanted. The .ZIP for the Release contained the README.md file and everything else in my project's root directory. But I wanted it to only include a sub-directory of my project. I know that this is possible to do this as I've seen Releases for other mods which do that. I just can't figure out how.

And a minor quibble: The filename of the .ZIP for the Release download is automatically generated as the name of my project, plus the version number tag. I wanted to either choose the filename or have it reflect the sub-directory I wanted to select (above). Again, I've seen other mod Releases where it seems this was somehow done...

[Rage gun]

Adds two safely non-lethal weapons:

• Rage gun: Smithing requires 4 Medikits, among other resources. Darted targets will go berserk. Enraged, they will charge in as fast as their legs will carry them. They will take the shortest path to pummel the shooter, even if it means bashing down the nearest door. It inflicts a lot of pain. A few shots should be enough put the enemy into shock.


• Zonk gun: Smithing requires 3 Yayo and 2 Neutroamine, among other resources. Darted targets will be doped into a drugged daze. They will become sluggish, barely able to shoot, and soon wander around aimlessly. Before long, they may start casting off their clothes or gear.

For the sake of balance, these guns have a rather poor accuracy and slow fire rate.
Maximum range is a bit less than the survival rifle (32 vs 37).

From my testing, these seem to have an extremely low mortality rate - less that 5%, I believe. In other words, they seem to bypass the game's random death mechanic.

Download for A16:

• Subscribe to the A16 version via Steam
• Dropbox download for offline / nonDRM use

Download for A15:

• Subscribe to the A15 version via Steam
• Download A15 version via Mediafire

To Clarify What These Weapons Can and Can't Do:

These weapons are intended to either (a) strategically make raids a bit more manageable or (b) make a target easier to capture. And I think they're fun to use.

Instead of sensibly standing behind cover and shooting, targets hit with Rage will often blindly run after whoever shot them. Berserked, they will charge via the shortest path, running through your gauntlet of defenses. However, they will try to bash through the nearest door to get to the shooter instead of taking the long path (where you've probably placed traps). More importantly, they will usually (most of the time, but not always) try to melee instead of shoot.

The Zonk gun will make a target mostly harmless. But, it does not make them capturable as such. Also, keep this in mind: Even after the target starts wandering aimlessly, if a colonist stands next to them, the Zonked are still likely to melee an enemy.

If your goal is capture, then I'd recommend the Rage Gun. It's designed not to kill, but it inflicts a lot of pain. About 3 to 4 hits should push their pain to "Extreme" and have them drop. Though, I find that if I shoot a target with Rage a couple times first, before they wander into my traps, the added pain from the traps will make them drop - assuming the traps don't hit a vital organ (which is quite possible).

Or, after being Zonked, you could down them with the Stun Gun mod (or the Blowgun mod). Though, the Stun Gun is melee range. And the Blowgun requires 2 solid hits to down someone and has such awful accuracy (and range) that it will probably take at least 7 or 8 shots. But, if they're Zonked first, they'd be sitting ducks!

Do note: After either the Berserked or Zonked wears off, the victim will experience "Catharsis", which gives a significant buff to mood that lasts for over a day. If the victim is captured before it wears off, the resulting positive mood may make recruitment a bit easier.

If that's still not easy enough or non-lethal enough for you, perhaps you'd be interested in the No random death mod?

Saved Games & Precautions:

This mod should work with saved games. I've done extensive testing with my saves. Though, it's always wise to keep a backup save before trying new mods. Also, I suggest quitting and restarting after activating or deactivating any mods.

Known Issues and Compatibility:

NOTE: Sadly, it is not effective to hit a target with Zonk, first, and then down them with the Rage gun. In my tests, once they've been subjected to Zonk, shots from the Rage gun will no longer bypass the random death mechanic. Another words: After being Zonked, each Rage shot will have a strong chance of killing.

This should be compatible with nearly everything. I have many dozens of mods installed and I've not encountered a mod conflict. And I was careful in how I coded it. But please report any you may find.

A Request of Users:

Please, do report any issues or balance concerns. I've spent many hours testing it. But I could not test for every mod compatibility or contingency. Don't hesitate to make a suggestion. I am willing to adjust the performance of each if I get reports that they seem over or under-powered.

Credits:

Special thanks to:

• Sahothron for the inspiration that the Tranq Gun mod provided me. (All my files are my own or modified from the core game.)
• johnhain, DasWortgewand, and pixabay for the cool background images used for the logo.

[coded]

I've been trying to get 'non-lethal' modded weapons like the tranq gun, stun gun, and baton to be less lethal. I wanted at least one of them to always incapacitate. But it seems that the game is coded to make all weapon attacks inherently lethal to a certain degree, regardless of how little damage they inflict (even zero) and regardless of how they are coded.

When I posted about this issue, schizmo informed me:

...As for kill over incapacitation, the game is coded specifically to make incapacitation events happen less and less frequently the more colonists you have, it's done as a form of population control.

Question: Is there an .XML file somewhere that I could tweak to adjust the 'kill vs. incapacitation' ratio? Or is it hard coded such that it would require a .dll-mod or using CCL to change?

I have considered adjusting the 'Desired minimum', 'Desired maximum' and 'Critical' population limits in my Storytellers (e.g., the Double Population mod) as a sort of workaround. But I'd rather not adjust lethality that way. And I'm sure that no matter how high I set the population limits, that won't entirely remove my lethality problem.

[drastically]

My biggest gripe with combat has to be how highly likely it is for a pawn to die from a single shot or blow. Aside from how unrealistic this seems and how difficult this makes it to capture raiders, this also makes it impossible for modders to create any sort of truly non-lethal weapons (such as tranquilizer darts or a taser, stun gun, or baton).

From this recent post in the Your Cheapest Ideas thread:

- Reduce the chance of raiders of insta dying.

I've read that projectiles are lethal about 50% of the time. Why should it be so high? I'm not the only one to think that the insta-death per shot should be drastically reduced. The only time a shot should mean instant death is in the unlikely event that it hits one of the two vital organs: the heart or brain. If given medical treatment, even a hit to the lung is survivable - unless the victim can't breathe or bleeds out (both of which the combat mechanics already simulates separately from insta-death shot lethality, anyway). If any other organ was hit, death would come more slowly. And perhaps an organ transplant (or artificial organ) could save them.

Make all body parts of the body less likely to be destroyed, it seems that they are made of paper... The torso (and internal organs) should be able to get hit more often while small parts like nose, ears, eyes, etc should have less chance to get hit.

I agree. Parts like nose, ears, and eyes are quite small. At range, a shooter would be hard pressed to hit them even if it was carefully aimed at. Them being shot off unintentionally during combat should be rare.

Also, limbs like arms, legs, hands and feet should not be so easily destroyed by a single gun shot.

I like the way these things are fixed in Combat Realism:

• Generally, limbs are tougher while organs are squishier and bleed much more. A rifle shot to an unprotected heart is lethal, but it does not send an arm flying. Only repeated hits or a high power round (.50cal, Lasgun, etc.) can destroy limbs.
• Internal body parts are significantly more likely to be hit. The human body is chock-full of vital organs and you are much more likely to hit one of them rather than this generic "torso" area that 80% of vanilla bullets would hit.
• Battle wounds cause more pain, more bleeding and more penalties overall.

That last part brings me to another big problem I have with the vanilla combat system:

Currently, the only way a pawn can fall unconscious is if their Consciousness stat falls extremely low. And about the only time a pawn goes into shock is if their pain reaches "extreme". (Or, perhaps, from extreme blood loss?) But these things seem to only occur if they're very close to death, if at all.

This makes it very unlikely to capture a particular raider as they will almost certainly die before falling unconscious or even go into shock.

In fact, it seems that the game is currently coded such that if the Consciousness stat falls to zero or below, that automatically means death. This seems silly: Loss of consciousness literally means that the victim has fainted or otherwise slipped into an unconscious state. It should not mean instant death.

In real life, melee punches have a good chance of knocking someone unconscious. And, unless a gun shot hits a vital organ or they bleed out, there's a good chance that the victim will go into shock before they die.

Also, it seems unrealistic that all raiders have the macabre grit of a fanatic or cultist. They seem 100% driven to fight until death rather than fail their raid or face capture.

Is there even a game mechanic that would allow them to flee in the face of overwhelming losses or debilitating injuries? Wouldn't at least some of them prefer to run away? Wouldn't some eventually surrender, throwing themselves at the mercy of the enemy in the hope that they might get medical treatment to live another day, perhaps in the hope to get sold back to their faction? Even slavery might be better than facing certain death.

Also, I want to point out the following from the Frequent Suggestions Topic:

Tactical combat - Tactical options from tactical games, such as prone, crawl, suppression, and automatic behaviors: aggressive, cautious, defensive.

Some of those would be useful, I think. It might make combat more interesting / varied. I could see how crawling should increase cover, even when there are no trees or walls to hide behind.

Finally, I want to suggest that RimWorld's combat mechanics include an option to make a called shot or otherwise target a specific limb or area. Why not allow pawns to target the head, at the cost of reduced accuracy? In theory, it might put the enemy (or beast) down faster. Or, in the case of weaponless melee, a hit to the head of targets should have a good chance of knocking them unconscious.

Alternatively, perhaps the goal is to shoot off a limb? Perhaps our colony recently developed prosthetic limbs/parts and the player is itching to try them out? Or, perhaps the doctor is begging for a chance to practice their seldom-used medical skills? Maybe we want to (literally) disarm them without killing? Maybe we want to harvest their organs?

Even with such improvements and even with the ability to make called shots, I'm not expecting RimWorld's combat mechanics to evolve into something like Kisat Dur (Dwarven martial arts). RimWorld is real-time and not turn-based, after all. But, with a bit of effort, combat could be so much more interesting.

Some may argue that such suggestions would require a lot of time and effort which could be spent on other parts of the game. However, a lot of these changes have already been implemented as part of Combat Realism, which I nominated to be included in the base game. It includes several other commonly-suggested changes, too, such as the need to use ammo.

[hours]

Early this morning, I lost my internet due to maintenance. It was out for hours.

I thought that I could play RimWorld, anyway. After all, it's not a multiplayer game.

Granted, I only had the Steam version installed. However, Steam does have an Offline Mode, which I tried to use. Thing is, I had a bunch of Workshop mods installed... 

Okay... I'll admit: That's my fault. If I wanted to play without the risk of loosing access to my Workshop mods, then I should have either installed the DRM-free version or at least stuck to installing only offline (folder) mods.

That said: I see no logical reason why it has to be this way. All Workshop mods are located in {Steam Location}\Steam\steamapps\workshop\content\294100\. And they remain there even if the player's PC looses internet access. So, why prevent RimWorld from using Workshop mods while offline? What possible purpose can this serve?

But what irritated me was what happened after I got my internet back. I tried to play RimWorld and... I still couldn't load my save. It seems that when I attempted to play in Offline Mode, it permanently unchecked all my Workshop mods. 

Essentially, it forgot which Workshop mods I had enabled. Now I have to manually, painstakingly, re-enable all my Workshop mods. (Which is a pain, because I was using many, many dozens.)

I could (barely) understand not being able to use Workshop mods while I was offline. But why permanently disable my Workshop mods for even trying to play offline?

I'm pretty sure that if I had not even tried to play RimWorld offline, all my Workshop mods would still be enabled and I wouldn't have to fix this issue. And without that inconvenience to bother me, I probably would not have bothered posting just to point out how we can't use Workshop mods while offline.

Edit: On further thought, one way to resolve this issue could be by implementing one of the ideas in the Easier mod load suggestion topic: Namely, if we had some way to save a mod load order and/or link it to our saves.

[might]

I realize that version changes usually necessitate updating a mod in order for it to work correctly (or at all). One can sometimes get a mod from a previous version to work, but that seems unusual.

There are a lot of 0.14 scenarios on the Steam Workshop that did not get updated. And some of them seem tempting. I just thought that scenarios might be more likely to work. Am I wrong? Can anyone verify?

There are a few scenarios which have dependencies on other mods. Obviously, those are less likely to work.

I suppose I could just copy/past the scenario conditions (which are are always spelled out in the description) into the game and create my own updated version for my own use. That seems simple enough. However, at least some scenarios also have a page of text (for flavor) that appears after landing/starting. That part is not as easy to copy.

[any]

For personal use, I tried to mod Right Tool For The Job so that the toolbelts required leather as an ingredient.

I do realize that the game has a variety of hides, furs, skins and leathers. But I was under the impression that there may be some way to define a recipe to use any type of leather (or a generic definition of leather). Am I wrong?

I found "Leathers" defined as an <ingredient> in Recipes_loom.xml in the Vegetable Garden mod. And I found "Leathery" referenced several times in the vanilla files, such as between the <stuffCategories> tags for Apparel_Hats.xml.

In RTFTJ-ToolRecipes.xml, I added the following in between the <ingredients> tags:

Code Select Expand

<li>
<filter>
<thingDefs>
<li>Leathers</li>
</thingDefs>
</filter>
<count>40</count>
</li>

As soon as I enabled the modified RTFTJ mod, it spat out errors:
"Could not resolve cross-reference to Verse.ThingDef named Leathers"

I also tried it with "Leathery", but it gave a very similar result.

[This is real.]

Diseases are a serious threat. Open wounds will get infected. Flu and plague can appear anywhere, and tropical rainforest areas are rife with malaria and sleeping sickness.

I'd like to suggest that the game provide some way to either obtain or research a method of wiping out malaria on a given planet or colony location. Perhaps your colony could trade for a rare device or breed of malaria-resistant mosquitoes? For game balance, perhaps it only appears late in a game? Or maybe it should be prohibitively expensive?

I suggest this because, in some cases, science fact is beginning to overlap with science fiction. Indeed, if researchers are correct and things go as planned, malaria may be practically wiped out in a few short years.

Check out this topic over on the Dwarf Fortress community. It's not just theory or conjecture. This is real.

A new genetically engineered breed of Mosquitoes has the potential to wipe out the genes of the existing mosquitoes, and as designed, end the spread of Malaria through Mosquitoes.

It took twenty years to engineer a mosquito that doesn't transmit Malaria. It then took only four years to engineer a Mosquito with this gene drive.