Messages

If I was stuck on an unfamiliar planet, I'd probably want to never venture out alone.  So, why not have the option for pawns to partner up?  They can go and mine together, or one can "stand watch" for raiders while the other mines, etc.

I think you're looking for a city-building game with contracts, missions and droids, not an isolated getusoutofhere colony simulator :L

Granted, a lot of people have widely varied expectations for what they're looking for in the game.

It's probably the global pathfinding that is the problem, it's not just about rocks...

The topic or board you are looking for appears to be either missing or off limits to you.

I was just playing a Chill Cassie game.  The first two raids consisted of one raider each, once with a pistol and once with some molotovs.  Manageable.  Then the third raid consisted of *ten* raiders, armed with a variety of weapons.  Now, mind you, my base isn't quite armed to the teeth.  Four colonists, four turrets, and some sandbags.  That's about it.  I haven't even researched carpets!  Seems to me like Cassie is ramping up even quicker than Cassandra!

FWIW, someone mentioned almost the exact problem in the comments for the Kickstarter Update notification of 254.


TEN raiders having just appeared and killed my poor miner

I am seeing this behavior as well.  Even with a straight path not on rocks, the pawns seem to want to go *out of their way* to go over the rocks.

Confirmed fixed in 0.0.254b

So even once bugs like this one are fixed, it'd still be nice to be able to go through and make sure your base has ceilings where you want them, without being forced to look for sunlight or rain.

Why not a simple "View Ceilings" button that would draw the roofs / rock ceilings wherever they are?  Note that this shouldn't necessitate any sort of Z-level implementation.  Ceilings already exist (and they're even drawn for a couple seconds when first constructed) so I'm proposing a simple toggle to be able to view them.

Is this the same bug causing this? http://ludeon.com/forums/index.php?topic=803.0

It appears that ceilings aren't always automatically constructed, even when it's a small enough room.  See example (world here (the one attached won't work because it was too big apparently)):


This dispenser keeps short circuiting in the rain...why isn't it covered?

Perhaps there should be some way to "force" ceiling construction to get rid of this type of problem.

[attachment deleted by admin: too old]

Example:
1. Place dumping zone
2. Place blueprint near dumping zone
3. Place another blueprint over some debris that has to be moved a distance away
4. Prioritize construction of the second blueprint

What happens:
1. Construction worker starts construction on the prioritized blueprint, then has to sub-task moving the debris
2. As soon as the debris is moved, the construction worker will start work on the blueprint closest to the dumping zone
3. To get the worker to re-prioritize the desired blueprint, one must re-order its prioritization
4. This keeps happening until there are no more sub-tasks.

What I'd expect:
1. Construction worker starts construction on the prioritized blueprint, then has to sub-task moving the debris
2. As soon as the debris is moved, the construction worker remembers the prioritized blueprint and goes back to work on it

Since a lot of people utilize dumping areas as a "free barrier" of sorts, it makes sense to allow arbitrarily-sized dumping areas.

Just set someone to have hauling at priority 1.

The problem is that sometimes I only want them to haul some metal, then get back to work mining more.  Instead, they pick up whatever's closest -- rock, metal, food, dead squirrels, etc.  Sure, I could micro-manage and force them to handle each piece of metal, then manually change their priorities back.  It would be preferable to have a "prioritize this area" tool.

Awesome!      Looking forward to it.

The main goal is to create interesting, dramatic events, which may sometimes include combinations of very destructive or near-unbeatable events.

That's a good point, and I do really appreciate that goal.  That being said, at the moment it seems less "sometimes" combinations of unbeatable events and more "almost-always" combinations of unbeatable events.  Perhaps I'm just "lucky" with the spice!

I'd go so far to say that if you're playing RimWorld to win, you're playing it with the wrong mindset. nja's story is tragic, but in a certain light it's also hilarious. This is the "losing is fun" mindset from Dwarf Fortress.

Heh, I hadn't thought of looking at it in that way.  I imagine I'll move more in that direction once the dialog and art style is updated.  Looking forward to it!  Emergent narratives bordering on the amusing are a good thing.

My first response to these kinds of situations actually isn't to try to make Cassie smarter, it'll be to create events that are less terminal. Raiders that leave before killing everyone, or who can be paid off if you can't handle them. In the terminology I use in my game design book, I'd like to create more elastic failure conditions so the colony can take more hits before the game ends, thus dragging out the drama.

That sounds like a very reasonable thing to do, and I appreciate your work on it.  Please don't take my comments as any sort of hatred of the game --- it's a pre-alpha and it is amazing for what it is!  That being said, more "elastic failure conditions" will likely lessen the frustration and allow for more enjoyment, to the benefit of all!

during a raid some crew will go:  "Oh, I need to stand in the middle of the desert and work on my tan for a moment - I'll just ignore all those gunman I need to run by."   I can actually see the target trace line - it just runs out to nowhere.  If he survives, he normally turns around and runs back from whence he came - again past the raiders.  Seldom do they survive two such passes.

I have seen the same behavior as well.