Topics

So, over several versions, the save and configuration folders for RimWorld have seemingly moved several times for some people, switched back and forth for others, and sometimes remain elusive for a while.

I recently upgraded to a new computer, and have only used A17B on this system.
I was moving a saved game to my flash drive, when I noticed that my saved game wasn't in the save folder I had navigated to.
So, I did a bit of digging, and I found the following weirdness.

%userprofile%\AppData\LocalLow\RimWorld by Ludeon Studios\Saves
%userprofile%\AppData\LocalLow\Ludeon Studios\Saves
%userprofile%\AppData\LocalLow\Ludeon Studios\RimWorld by Ludeon Studios\Saves

The folder that RimWorld was actually using for the most recent saves was: "\LocalLow\RimWorld by Ludeon Studios\Saves"
That being said, the other two folders contained a mixture of autosaves, new and old, and a few manual saves from when I was just testing out A17B on this system.

I kind of have no idea what to make of this.
It doesn't seem to have affected RimWorld in any way, and I was always able to load the newest saved colony.

So, anybody have any thoughts, or perhaps weird locations of their own?

So, I've been playing for several versions now on my toaster of a computer, and it only just occurred to me to ask this question.

How long should a RimWorld day be in real seconds at "3" speed?

Now, admittedly, my system is a dinosaur.
An AMD Phenom x3 running at about 2.01GHz at full power draw.
An aging GTX 650 Ti BOOST, under-clocked because my power supply can't keep up with the system demands.
Only 8GB of RAM on the high-latency mainboard.
But, it has been a good computer, and it still runs RimWorld, albeit at a deficit.

This system is probably near the lowest possible point end of "just viable" to run RimWorld.

7 hours in, mostly at "3" speed, my colony has been on the RimWorld for 40 game days.
Doing the math, this comes out to about 10 minutes 30 seconds per game day.

So, my question is, how does this compare to the real-time length of a RimWorld day for others?

Tiny graphical issue I saw while playing yesterday.
No gameplay impact, just a little annoying to look at.
Unsure as to reproduction since, well, AFAIK tree graphics are randomly set (or seeded pseudo-randomly) when the tree becomes fully grown?
Will upload a copy of the saved game if necessary.
Edit: Mainly because I forgot to copy it to my netbook for the report. Oops.

Moving the camera results in "shimmering" of the area, likely resulting from one graphic taking the foreground slightly more quickly than the other as frames load.

Link if hot-linking is broken.


Link if hot-linking is broken.

Glitterworld-tech devices that can hydrate and condition soil to be useful (or more useful) for crop growing.
The effects of these devices are intertwined.

New soil types, arid soil and wet sand.
Arid soil has 50% fertility, wet sand has 12% fertility.
Arid soil would replace some gravel on arid shrubland maps, and almost all gravel on desert and extreme desert maps.
Wet sand does not appear naturally as part of map generation.
(Unless someone can think of a map type where it would fit in.)

The soil conditioner uses a supply of plant matter (and possibly trade-only goods like Neutroamine) to slowly increase the fertility of the surrounding ground by creating nutrients and cultivating micro-organisms in the surrounding ground.
The device can turn sand into arid soil, or wet sand into soil.
It takes a full season, and conditions a circle with a radius of ~3.5 tiles.

The moisture condenser must be built on top of a steam geyser.
(The device is 4x4.)
This device captures steam from the geyser, condenses the steam into water, and uses the water to slowly irrigate surrounding soil or sand.
This device turns arid soil into normal soil, or sand into wet sand.
Taking a full year, the device irrigates a circle with a ~9.5 tile radius.

Just an idea I thought of while playing my 2-year arid shrubland colony.

Might even be relatively easy to implement considering the effect of the moisture pump.

Additional issue related to an earlier post by another regarding similar pawns standing to drop gear.

If a pawn that is unable to stand (leg shot off for example) has a condition leading to vomiting (food poisoning for example) they will stand up in order to vomit.

Since these pawns still need to be able to vomit, this is more annoying to fix than the gear dropping, yes?

Suggestion for a related addition; possibility of choking on vomit if a pawn is unable to stand up to vomit.

If you make a one-cell-wide hallway, make sure it is roofed, and then place three doors in a row in this hallway, once all the doors are completed, the center door will appear "lit" by sunlight, even though it is roofed.

This also appears to happen to doors placed this way under "overhead mountain" roofs.

Reproduction
Create a hallway.

XXXXXXX
_______
XXXXXXX

Place three doors in the hallway.

XXXXXXX
__DDD__
XXXXXXX

The cell of the door in the middle will appear to be lit by sunlight, even though it is roofed.

Edit: I apologize I could not upload an image of this glitch.
I hope this is enough information to reliably reproduce the issue.
I, unfortunately, will likely be unable to check the forums for several days, or perhaps weeks, due to financial and geographical constraints.

Randomizing colonists.
I randomized a pawn with a "extreme carcinoma, untreated, stable" on his nose.
I figured "Eh, it's stable, and he has some good skills. Let's just roll with it."
I started the game, and checked the status of all the pawns.
The man's nose (and carcinoma) were simply "lost" to the void.
(That is to say; they were nowhere to be found. Nose was labelled as "lost" and nothing more.)

I expected the man to spawn with a nose, and a carcinoma on it.

Honestly, short of randomizing colonists until you receive a similar starting pawn, I have no clue how to reproduce the bug.

Perhaps this would happen if you force-spawned an (already) extreme carcinoma onto the nose of a pawn?
Would creating such a carcinoma on the nose of a pawn by directly editing the XML cause this to happen upon the game being loaded?
Or, maybe this only happens while newly-generating a colony?
Will be testing these things tomorrow if I have time.

I will be providing my output_log file, a game saved shortly after I discovered this problem, and any other information I can come up with when I am able to; hopefully by 5:00 PM PDT, 10/25/2016.

So, after testing for a long time, I have found the following:
-Loading a game with a carcinoma (as described) edited into the XML on a pawn's nose will not remove the pawn's nose. (Even with 0.999 severity.)
-Randomizing pawns in an attempt to recreate this will take forever, and is really annoying.

So, here's the video (cut down to the relevant section) of the pawn before I started the game.
https://www.youtube.com/watch?v=XZPRyk9vazE

Saved game (just after starting the game) attached.

Generate pawns; carcinoma.
Start colony; no carcinoma, no nose.

[attachment deleted by admin due to age]

[Important Note]

Important Note
Updated to PVT02, reflecting changes suggested.
When updating from PTV01: Make sure all Electric Stoves, Fueled Stoves, and Campfires have the "Grind Soybeans" bill removed in your saved game before you update to this new version.
If you do remove all the bills, your saved games using this mod will load properly.
All soy mash will rot away immediately (if not frozen) when loading this new version of the mod.
This is intended, as this will remove soy mash from all future saved games, allowing future versions of the mod to not include the soy mash data.

Preface
This is just a little mod I threw together in a couple days after a friend asked why there were no vegan alternatives in RimWorld.
(One day for research, one for coding, testing, and graphics.)
I had intended to create a new food category for "vegan alternatives" but didn't have the time, (or skill,) so it is under "animal products" instead.
I may change that in the future, but for now I'm going to drop this mod here for public testing and use.
This is a soy beverage production chain, simplified down into a couple of "steps" and balanced for early-to-mid-game play.

Mod Components
Soy Plants - Grow soy plants outside, or using hydroponics.
Raw Soybeans - Raw soybeans harvested from soy plants. Must be properly processed before human consumption.
Dried Soybeans - Hulled, dried soybeans. Must be cooked properly before consumption.
Soy Beverage - A soy beverage resembling milk. Does not last long without proper storage.

Mod Notes
Adds recipes for cooking soy beverage, or drying soybeans.
Drying soybeans allows for long-term storage without a freezer, but is not necessary for producing soy beverage.
All steps can be completed at the electric stove, fueled stove, or campfire.
Soy beverage becomes very dangerous if not properly cooked or stored, and rots very quickly to compensate for this.

Mod Compatibility
This mod should be compatible with all other def mods as it does not modify or inherit from any core files. (To my knowledge.)

Mod Download
PTV 01 for RimWorld A15C - Direct Download Links
Simplified Soy Production PTV02-A15C (RAR Compression)
Simplified Soy Production PTV02-A15C (ZIP Compression)

Questions
So, please let me know if you decide to use my mod and there are any issues you come across.
I would also like some feedback as to the balancing of the mod in terms of how quickly the plants grow, and how quickly they can be processed, as well as whether I should reduce the requirements for the growing and processing of soybeans.

Usage
Use parts of this mod as you see fit, and include it in modpacks if you wish.

I noticed a while ago that whenever one of my pawns had an alcohol or smokeleaf binge, they would always consume a malari-block pill before actually starting the binge.
Recently though, when one of the pawns had an alcohol binge, they consumed malari-block, and then proceeded to not consume alcohol for the rest of the binge, almost as if they had "satisfied" their binge with the malari-block.

Reproduction:
Have a supply of binge-able drugs and malariblock.
Cause a "mental break - binge" (major or extreme) on a pawn.
Pawns consume one of nearest malariblock before any actual binge drugs.

Tested with following drug supplies: Alcohol, Psychite (Yayo), Psychite (Flake), Smokeleaf.
Tested with both "Chemical Interest" and "Normal" pawns.

A set-up quick testing save is included as an attachment.

[attachment deleted by admin - too old]

So, while diagnosing another bug (which I will post if I cannot find it on Mantis or the forum) I attempted to start RimWorld using the "-quicktest" parameter. 
Even though the quicktest map loaded, I received the following dev log error messages:



The final error (with 35 instances as-of the screenshot) continues to build in number until, I assume, an exception occurs.
(I didn't actually wait for an exception as I wanted to get back to testing another bug.)

There were no errors recorded in the output_log file.

To reproduce, start RimWorld (with dev mode enabled) from a shortcut with the "-quicktest" parameter.

I was defending against a raid while a trade caravan was in my defense area.
The trade caravan became hostile, and I had to wipe out both the trade caravan, and the pirates.
I could not rescue the trade caravan animals, so I decided to attack the trader animals to death.

I discovered that pawn Malone (incapable of none) was incapable of melee attacking the trader animals.

Some testing revealed the following:
Malone unable to melee attack with ranged weapon equipped.
Malone unable to melee attack with no weapon equipped.
Malone able to melee attack with melee weapon equipped.
Other pawns able to melee attack with ranged weapon equipped.
Pawn Malone is unable to melee attack any animal.

(Did not try on raiders. Decided to just keep playing after making this save file.)

Compressed Save Game Attached; .zip format
Truncated output_log.txt attached; following repeated and removed:

Code Select Expand


(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 37)

BestAttackTarget with Oliver who has no attack verb.




[attachment deleted by admin - too old]

A "Dry Thunderstorm" weather system started.

Lightning struck an unexplored section of the map, (which was behind a mountain range in the upper-right of the map,) starting a fire.  This resulted in a notification that an unexplored area had been discovered.

I expected not to be notified of an area unexplored being discovered when fire started in it.

Likely impossible to reproduce without pure chance. (Or a "lightning strike at XY" dev tool, and the map seed/coordinates.)
I will provide the seed and coordinates for the region tomorrow, if necessary. (On my main computer; unavailable right now.)

Save file unavailable; I didn't have a save from just before this happened, and I didn't keep one after this as, well, I wasn't really thinking about reporting it at the time.

No log available.

First, some system info...
Windows 7, 64 bit.
Non-Steam Version of Rimworld, Alpha 15B.
(rev1280, I think?)

In A15B, I had paused the game and I was looking around the map for boar to tame.

I came across a small issue with some deer.



After resuming the game, they remain clumped together, one fulfilling their hunger need, and the rest remaining together to repeat the process.

I did not expect this. I was not prepared!

Unfortunately, I do not know how to reproduce the problem, and I did not have an earlier save game to provide.

Perhaps this is how something like issue ID 0002523 often begins?
(I'm guessing that the deer are either not properly reading a "reserved" tag, or not properly creating one. Thus, they all attempt to eat the same grass, though only one of them actually fulfills their hunger need.)

Anyways, attached is the save file, saved just before I took the screenshot.
(The save file was compressed to "Best Compression" ZIP format using WinRAR.)

No log data available. (Not pertinent either? Not available at this time, anyways. Let me know if you do need it, and I will see if I can go find it.)

Not a high priority issue, obviously.
Good day to you all.

[attachment deleted by admin - too old]

Mod Edit (Calahan) - Doing some housekeeping, so closing this bug report as a known (partially) resolved issue. Here is the Mantis report on it. And I'm editing the OP rather than posting a reply because I don't want to bump the thread for no good reason.
https://ludeon.com/mantis/view.php?id=2314