blipadouzi wrote:You know, I don't really have a big problem with the food teleportation system. It's not that different from say having your kitchen in the basement and then sending things up to the canteen via dumbwaiter.
This is exactly it. The food is being transported from one canteen to another where the need is. It's not ideal because it's magic, and I'd love to see cooks or whomever actually cart the food between canteens, but it's a dirty patch to the capacity fluctuations that were causing starvation prior.
That being said, if you know the algorithm mechanic you can exploit it like the min/maxing examples in the first post (note they also have showers and a fleet of TVs as well, which is further min/maxing, yet we're not complaining about how un-realistic
that bit is) but I'd wager if you didn't know how the serving stations worked you'd set up your canteens as any normal person would.
rlgjiojgboirtjnb wrote:And if you having to assign cooks to canteens(as an idea) like guards to patrols or prisoners to jobs is too much micromanagement, why arent those things an issue? (i personally hate to manually assign 400 prisoners to work rooms 1 by 1, ruins my mouse!). Or why is linking canteens to kitchens an issue, but having to manually connect every damn door and every door camera to a control station not? The current implementations of all the utility systems are way more micromanagment than any kitchen solution ive read so far.
What you're missing with the kitchen-canteen linking and cook deployment is that canteens don't currently take a running average of expected attendance individually, and they don't know in advance how many inmates they're expected to get, only how many Eat next prison-wide, instead of a by-canteen sub-total. It was fluctuations in canteen attendance and lop-sided kitchen efficiencies that made for lopsided food production across multiple canteens.
So if you have two canteens, and 100 prisoners, and all cooks know to make 100 food for the next shift. They make it as they're able, and cap out at 100, irrespective of which canteen or their or expected individual attendances.
Due to being delayed, one kitchen may've got a head start on production and made 75 meals, and the other because there was a delay in production made 25 meals.
So lunch comes and 50 inmates go to the kitchen that made 75 meals, and 50 go to the kitchen that made 25 meals. One canteen now has too much food, and the other has too little. And I know what you're going to say, if you could assign more cooks to the slower kitchen there'd be balance, but it may've been a momentary delay, and so next shift you may just have the imbalance in reverse. Again, all canteen needs are considered in total, not individual.
This can be resolved by a
three sigma rule for each canteen, and having the cooks make only as many meals as that canteen likely needs within 3 sigma, but presently PA doesn't take a running mean of individual canteen attendance, and treats each canteen as all canteens, and each attendances as all attendance, does that make sense?
Teleporting food to keep multiple canteens from messing up the food balance for each isn't perfect, but it's a quick shortcut. Your min/max example doesn't even approach the problem the fix was trying to resolve, in that multiple canteens aren't handled properly, not how efficiently a single canteen is.
