WIP, feedback wanted: Reassign seats to lowest-fitness Kerbals

[wisq]

DON'T MERGE THIS, I'm just posting this to ask your thoughts. :)

In my Kerbal game, I run an OKS base with a science lab and an ExtraPlanetaryLaunchpads shipyard. With the giant OKS habitat rings, I have 20 "EXERCISING" slots, and only about 11 crew.

The problem is, they're all incredibly unfit because the scientists spend most of their time in the science labs, and the engineers spend most of their time in the workshops. I've taken to trying to move them to their jobs only when I need them and move them back afterwards, but a) it's tedious micromangement, and b) surely we can assume that they don't spend 24-7 at their posts and can put in some exercise and relaxation time each day.

What I've got here is a prototype of some seat upgrade code. I've never touched C# before today, and my closest known language is Java (which I also haven't done in years), so this is probably extremely gross code. Plus, it only works for loaded ships, and should really work for both loaded and unloaded. And finally, the upgrade thing should probably be configurable.

Anyway, here's my thoughts:

• global "Kerbals can move around ship" option
  • if this isn't set, we can just skip the entire upgrade code
• per-Kerbal "wants better seat" option
  • if this is set, they'll be assigned better seats when available
  • if not set, then their current seat is the best they'll ever get
• per-Kerbal "will give up seat to less fit crewmate" option
  • if this is set, and there aren't enough comfy seats, and a crewmate is less fit than them, then they'll give up their seat
  • if not set, then their current seat is the worst they'll ever get
• if neither of the per-Kerbal options are set, then the Kerbal is locked in their current seat

The algorithm works like this:

• while iterating through the ships, we count up the number of available seats at each activity level
• while iterating through all the Kerbals in a part,
  • we track the crew at a particular activity level in shipCrew
  • anyone who wants an upgrade gets added to seatUpgradePool
• we then go through the activity levels, descending
  • freeSeats is initially the same as total seats at that level
  • anyone who is not willing to give up their seat, takes their seat (deducts 1 from freeSeats)
  • anyone who is willing to give up their seat, gets added to the seatUpgradePool (effectively vacating their seat immediately, but they might get it back)
  • to fill the remaining freeSeats, we go through the seatUpgradePool, from least fit to most fit

(It doesn't actually move them around the ship, it just treats them as being in a better seat than they are. The idea is, so long as your ship isn't overcrowded, Kerbals can spend their off-duty time in a comfier environment, saving their fitness.)

If every Kerbal is set to "want upgrade" and "give up seat", then the algorithm effectively just assigns them all to the best seats in descending order — it'll maintain the same overall fitness level amongst the entire crew, because they'll all be rotated in/out based on fitness. So as long as your station/ship isn't overcrowded, you can have people in labs, or you can have a pilot in the capsule and assume that he'll retire to the hitchhiker module when he's not actively piloting (which is most of the time, probably).

Any other settings can be used to prioritise the crew. For example, you might have a pilot who always needs to be as healthy as possible, so you put him in an EXERCISING seat and set him to refuse to give up his seat.

I'm thinking the next steps are:

• figure out a way to adapt this code to unloaded ships
  • I'm thinking we just store the seat counts, the original activity level of each crew, and run this?
  • it should probably be split into a separate method that can operate on both loaded and unloaded using the above data only
• add some UI elements to configure this
• Connected Living Spaces mod integration
  • if CLS is installed, then treat each CLS section as a separate ship for seat upgrading purposes
  • it adds a lot of value to that mod, since now there's a real reason to design ships with highly connected spaces, beyond just "I don't have to EVA to move crew around"

Thoughts? Is this something you'd want?

[timmersuk]

Sorry I never even noticed this until now - I'm not an enormous githubber so the unobtrusivim they use make notifications out of went unnoticed!

I've incorporated support for CLS and autodetection of best seat either in CLS 'space' (with CLS) or in whole vessel (without CLS) already, but will take a look at your proposal in more detail probably tomorrow - it matches with something I've been thinking of, and which has been suggested on the forums, of actively moving kerbals around to let everyone balance fitness without handwaving it all away (though I'd probably still do that for unloaded vessels as in that case we don't have access to as much detail (and also the processing cost)).

[wisq]

Yeah, the ideal approach would be to actually move them around. My approach just sorta assumes they'll all spend enough time in the most comfortable places to maintain their fitness, so yeah, it's very very hand-wavey.

In terms of a more comprehensive solution — the hardest part to automate is whether Kerbals need to be on-duty or off-duty, i.e. whether their services are needed right now. It's tricky because module behaviour is mod-specific, and sometimes player-action-specific too. For example,

• in ExtraPlanetaryLaunchpads, you want engineers in your workshops, but only when ships are building (and maybe when converting metal to rocketparts or whatnot)
• in MKS, there may be workshops that need to be manned (I forget)
• in MKS and stock, the science bay needs to be manned if you want to refine science results
• in StationScience, there's a zoology bay (nice place to stick your scientists, but only when there's Kibbal available) and various labs (I forget if they need to be manned)
• You need a pilot to do anything, but except insofar as loaded/unloaded status, the game can't predict when the player is going to want to pilot the ship and when it's okay to just coast with no pilot.

Offhand, there are a few ways that come to mind to deal with this:

One, a system whereby each manned compartment has an "on duty" / "off duty" toggle, and a desired number of Kerbals, and (optionally) a filter to limit who can work there (e.g. Pilots / Scientists / Engineers). Optionally, there could also be a third setting, "global", and then a ship-wide "on duty" / "off duty" that controls all the "global" rooms. And there could also maybe be an "auto" setting which mans the station when the ship is loaded and unmans it when it's unloaded.

Two, a system whereby each Kerbal has an "on duty" / "off duty" toggle, and an assigned station. When on duty, they move to their assigned station. If multiple on-duty Kerbals have the same assigned station, they rotate out, either based on time or based on fitness. (There could also be "global" and/or "auto" settings like above.)

Both of the above assume that when a compartment is "on duty", Kerbals will be manning it 100% of the time. An alternative option (possibly as a per-Kerbal or per-compartment extra setting in tandem with either of the above) would be a "strict duty cycle" mode, whereby Kerbals are strictly limited to a certain number of duty hours per day (or a minimum fitness level) and will always swap out when they hit that limit, possibly leaving the compartment unmanned. The user could override that, of course, but it would ensure that they could maintain ship fitness even in an undermanned situation, at the cost of reduced efficiency / limited hours of operation.

All of these approaches have their advantages and drawbacks, and might vary quite a bit in ease of implementation. But yeah, the main thing I want to avoid is having to move lots of Kerbals around, one by one, every time I want to use a particular component.

[wisq]

I should add that even in my current hand-wavey "assume they live in the comfyest compartments when you don't need them" solution, it at least still forces you to bring along enough comfy living space to support all your Kerbals, even if you nominally keep them in more cramped compartments. Adding CLS support would also force you to ensure they're all connected.

If that's enough of a constraint, that might be all you need, and you can avoid all the complicated duty-cycle stuff.

[timmersuk]

offtopic - please don't put science and zoology on adjacent lines of text - I was skimming and thought I saw scientology mentioned - we need to have scientologist Kerbals now ??!?!?

[timmersuk]

I'll have to think more on this, and would probably only do it once I've re-done the current UI for the fitness/Gee levels part of KeepFit, but it certainly represents an interesting (and more worked through than much I've seen from designers) approach.

One thing that bothered me with doing a simple Kerbal HotSeat style thing was the danger of Jeb/Val wandering away from the wheel halfway through a maneouvre node burn, so something where you get to mark duty stations and set/inherent requirements (e.g. Must always have at least 1 pilot in the mk1-2 capsule) might be the way to go.

We'd also almost certainly need with this to go with an overallocation of seats approach, as AFAIK there's no 'swap' crew locations API in KSP, so you'd have to have more seats available than Kerbals. I'd probably want to keep it simple though and avoid having to play shuffle-a-kerbal to get people where you want them - moving kerbals is sllooowwww in KSP for ... err... I'm not sure - reasons, I expect.

[timmersuk]

Oh ... I also suspect, but haven't checked for sure, that you can't really move around Kerbals except for those on the current vessel - maybe it works, maybe it doesn't, but for certain CLS only provides mobility information on the current vessel, so even if moving Kerbals around works, it'd probably be limited to current vessel, and unfocused vessels would adhere to the (current) handwaving away of the actual part in which a Kerbals sits, and say for KeepFit purposes they get to use 'some time' in the best part available to them (IIRC in current code KeepFit caches the Kerbal's available activity level, so it 'remembers' well enough for unfocused vessels).

[wisq]

Yeah, it's slow both in the UI — find the EVA port (ugh!) for the component you want to take them from, select the Kerbal, select the component you want to send them to, click many many times if your framerate is low enough (some sort of bug there) — and also just slow in that there's some sort of artificial delay to simulate them walking around I guess, during which you also can't move any other Kerbals. Repeat a dozen times to cycle a duty roster.

That's why, in my first draft (which I used for a bit in my own KSP games), I went with my own auto-reallocate hand-wavium solution. It turned the fitness aspect into a construction / mission-roster consideration — ships either needed enough spaces to comfortably house their crew, or the crew would need to go on short-duration missions and spend time recovering inbetween — rather than a micromanagement issue.

[timmersuk]

Let me know how you are with the current CLS powered handwavium - IIRC its enabled by default if you have the latest KeepFit, plus CLS on your install, and does implement the CLS limitation - my current career save is using it and I think its showing in that my long-duration crews are looking less ragged nowadays,