Redoing the Hauling System

[Thyme]

A problem fixed by a mod is a solved problem. *needs to be in vanilla anyway

Not if the Cook delivers the Meals to a 2-tile Gather stockpile adjacent to him. They would have priority due to the spoiling, but the Gather stockpile's hauling delay would prevent a Hauler from moving it until there's a full stack of Meals.

On second thought, this would require a decent amount of AI rewriting. Not only that, more complex systems require more player thought which quickly gets confusing. New players will likely see the following as bug instead of a feature:

Supply stockpiles as an endpoint for Hauling: anything that's supposed to be on it is never moved to other stockpiles

[Britnoth]

A problem fixed by a mod is a solved problem.

A gameplay problem fixed by a mod is a poorer game.

[MikeLemmer]

Currently, haulers can easily get occupied hauling just 5-10 berries across the base every time someone cooks a single meal

Stopped reading right here.

If pawns work inefficiently, it is your fault. Not the game.

It is a part of the game to learn to use the tools provided to help your pawns work more efficiently.

If you add a huge pile of AI checks to make it more efficient, you both lag the game considerably, and remove an important element in player choice and skill.

So what's your alternate solution using the tools provided? Manual hauling micromanagement? Tricks involving zone placement? You don't get to make an uncontested blanket statement about how inefficient pawns are the players' fault without providing a counter-example of how the players can fix it.

[Thyme]

A gameplay problem fixed by a mod is a poorer game

Hauling Hysteresis is a vanilla friendly mod which needs to be in vanilla. Imagine that it will happen two alphas from now:
"A gameplay problem fixed by an update is a poorer game."

[RolanDecoy]

Stopped reading right here.

If pawns work inefficiently, it is your fault. Not the game.

It is a part of the game to learn to use the tools provided to help your pawns work more efficiently.

If you add a huge pile of AI checks to make it more efficient, you both lag the game considerably, and remove an important element in player choice and skill.

Didn't want to say anything, being new at the game and all, but I was thinking this last night when I was fighting the tendancy to reply...

I would like to see a copy / paste option for bill details similar to the work schedule copy / paste thingy, that stuff is neat. Maybe an invert button, disallow everything that is currently allowed and vice versa. Makes it a lot quicker to configure 2 different stockpiles. Brainfart...

But as it stands, I just don't recognize any of these problems. Sure, workers get pre-occupied in my games as well, but that's mainly because I have more tasks than I have people, and even that requires little to no effort to correct.

"A gameplay problem fixed by an update is a poorer game."

Agreed, players get spoiled, stop solving problems when there is an update or mod out there that can solve them for you...might as well watch a movie then...

A good way of measuring this is how much do you run the game at full time compression, and how long does it take you to resolve an issue before you can return to that compression after something happened that required your attention? That time that you didn't spend at full is the actual game time you've spent, the time you enjoyed the game, the entertainment value of the game (with the exception of seeing your colony function as a well oiled machine, but that's only fun for an hour or so). Of course, imho...

[Thyme]

"A gameplay problem fixed by an update is a poorer game."

Agreed, players get spoiled, stop solving problems when there is an update or mod out there that can solve them for you...might as well watch a movie then...

You are essentially saying that RimWorld got worse with every update. I guess you're still playing the first release?

Enough OT. I'd like to suggest a minor change to Mikes OP:
+Spoiling items outside the kitchen should get higher priority (maybe weighted with distance), to get all the food inside. Deteriorating stuff is a smaller issue, I have no problem micro'ing it.

[Swat_Raptor]

Agreed, players get spoiled, stop solving problems when there is an update or mod out there that can solve them for you...might as well watch a movie then...

you know hearing this makes me remember when my dad taught me to do maintenance on my Car, I asked him where the wrench and other tools were and he told me that I was lazy and spoiled and shouldn't be asking for TOOLS to take away my problems. (sarcasm)

those tools where just a crutch which didn't give me the ability to solve problems that I otherwise couldn't. I just needed ingenuity, effort, and two hands to solve ALL of my problems.(more sarcasm)

I'm not sure who here is asking for a mod or update to take problems away from us. I would like to see some tools and features to help us deal with problems we currently can't deal with and to give us the ability operate at a level of efficiency that we currently cannot reach.

oh and here is a quote

(It's best to have your tools with you. If you don't, you're apt to find something you didn't expect and get discouraged.)  --Steven King, On Writing: A Memoir of the Craft

[MikeLemmer]

A problem fixed by a mod is a solved problem. *needs to be in vanilla anyway

A poorly-solved problem, I would say. Not only is there the risk of it becoming unusable later because the mod's author quit updating it along with the patches, but there's always the issue of it conflicting with other mods, or accidentally introducing bugs. It still works, but it's basically duct tape and spit with no guarantee how long it'll last.

A good way of measuring this is how much do you run the game at full time compression, and how long does it take you to resolve an issue before you can return to that compression after something happened that required your attention? That time that you didn't spend at full is the actual game time you've spent, the time you enjoyed the game, the entertainment value of the game (with the exception of seeing your colony function as a well oiled machine, but that's only fun for an hour or so). Of course, imho...

There is a difference between pausing the game to plan out an expansion, figure out what to craft next, or tweak work priorities... and pausing the game to micromanage colonists into hauling spoiling meat from a drop-pod or making sure they aren't shooting your own colonists in the back. The former is enjoyable, the latter is actively driving me away from playing further.

And while I suspect there may be some fancy way to max out hauler efficiency through a combination of allowed zones and work schedules/priorities, it shouldn't be necessary to jump through that many hoops to solve the fundamental problem of "ONLY REFILL THIS STOCKPILE WHEN IT DROPS BELOW HALF STOCK". I got into RimWorld because I want to figure out how to build a good base, not because I want to (figuratively) figure out how to remove a nail without a hammer.

[Thyme]

Resource flow is managed with intelligent zone configuration. This is a core feature of RimWorld and one of the major reasons why I like this game. Hauling Hysteresis and your suggested zones add even more complexity to that system (aka more tools to choose from).

[MikeLemmer]

Resource flow is managed with intelligent zone configuration. This is a core feature of RimWorld and one of the major reasons why I like this game. Hauling Hysteresis and your suggested zones add even more complexity to that system (aka more tools to choose from).

As I asked Britnoth, care to provide an example? Because while I've considered the idea, the finickiness of making allowed zones that let certain haulers go everywhere but the kitchen, or barring a hauler from most of the inner fort just so he focuses on grabbing stuff outside the fort, feels as awkward as using a crowbar to pound a nail in. Allowed zones are meant to keep vulnerable colonists inside your walls and your pets from eating your colonists' meals, not wrangle job priorities so your haulers can function halfway efficiently.

[b0rsuk]

If Supply Stockpile is implemented, it should be the default setting for Hoppers, though.

Watching my colonists haul things inefficiently (especially leaving items on the ground when they go home) drives me nuts. I prefer a little complexity to create a special stockpile to ordering them around manually (prioritize this, prioritize that). It's one of reasons I rarely use 2x and faster speeds. I just can't stand colonist stupidity.

[tyriaelsoban]

Something else that should also be taken into account is; the haulers tendency to go and grab those 6 blocks of sandstone from way in the middle of bum-fuck-nowhere ('scuse the euphemism) when 5 tiles away there are also 35 blocks of sandstone, but instead of condensing the stacks into 41 and hauling them home, the current system calls for a second hauler to pick up those 35 blocks from the other side of the map ... WHY GOD, WHY WOULD YOU MAKE IT DO THAT?!
It drives me up the wall, because pawn A could haul all 41 units even with a dicky manipulation score and pawn B could go and do something fucking productive, instead of driving me bloody mental!
I mean, i cant even shift click order haul, so if the game does not recognize that pawn A can haul all of it ... ive got to spend 5 mins screwing around with this guy hauling the 6 units while the ai keeps dicking around and sending extra pawns to grab the 35...

[MikeLemmer]

Something else that should also be taken into account is; the haulers tendency to go and grab those 6 blocks of sandstone from way in the middle of bum-fuck-nowhere ('scuse the euphemism) when 5 tiles away there are also 35 blocks of sandstone, but instead of condensing the stacks into 41 and hauling them home, the current system calls for a second hauler to pick up those 35 blocks from the other side of the map... WHY GOD, WHY WOULD YOU MAKE IT DO THAT?!

Because programming is hard. No, seriously; I recall spending several days banging my head against the problem of diagonal sprite collision. Hence I'm willing to give Tynan the benefit of the doubt concerning getting the colonist AI to override its own jobs.

Human brains are amazing at grouping things together, quickly hashing out a mostly optimal solution to it, and saying "good enough". Getting AIs to do that is... trickier.

My guess is the pawns only check for similar stacks nearby once they reach their destination, rather than when they start heading to the job. You see similar "stupidity" with pawns traveling towards a mining mode halfway across the map... only to turn around right before they reach it because they're hungry/tired. (Although I suppose that could be mitigated by estimating the time it'll take to reach there and measuring it against how soon they'll need to eat/sleep, but then factor in average walk speed over that terrain... Hrm...)

[Listen1]

I only see a problem with gathering stockpiles, even following the new system, or making something like "They will only take the itens from the gathering stockpile to the main stockpile after the first one is full" is that your pawns will start gathering, stop, go smoke a joint, than go back to the gathering stockpile, haul to it, stop, go to sleep. and etc.

Depending on how you do it, I can see some problem specially the fact that it would be faster for them to take the gathering suplies directly to the main stockpile than to divide it into two tasks. Even though, this both option must be in the game for we to achive a better "Automatization" of the colony.

The suply stockpile though, that will work perfectly.

[Thyme]

Resource flow is managed with intelligent zone configuration. [...]

As I asked Britnoth, care to provide an example? Because while I've considered the idea, the finickiness of making allowed zones that let certain haulers go everywhere but the kitchen, [...]

I haven't even thought about allowed zones, just stockpile zones. Gosh, so many possibilities.

I'm not sure where your point is. You're defending the limited AI in one post and lamenting about stupid pawns in the next one.