[1.6.x] Duty Roster

[cyberKerb]

Duty Roster adds a time-on / time-off period for all Kerbals based on the 6 hour UT day within KSP. When they are on duty, they are regular Kerbals doing their regular job. When off-duty, they become tourists and use this time to look for any hidden stash of snacks that the ground crew may of left on board during the construction of the vessel. All times are based on UT game clock - not the MET.

Configurable:

• duration of on-duty time
• additional on-duty time for my experienced Kerbals
• Start time Duty Roster to ensure you have on-duty Kerbals / Skills at appropriate times.
• Jet-lag adjustment time

Much like how jet-lag takes time to adjust - usually 1 day / time zone crossed. When shifting a Kerbals start time, they will only change their start time by a certain amount per 6 hour day (default 20mins).  So it might take a bit of prepping / planning to ensure your required Kerbals are available at the correct time. 

Warning! Kerbals will not care what you as the player are doing. If their duty roster says clock-off at 4:20 UT, even if it's half way through a launch in progress, Jeb will indeed stop piloting your craft taking all the fancy SAS functionality that pilots have with him. Gliding to a safe landing and Ando Kerman has <1 minute before going off-duty? Get that plane on the ground pronto! Ando needs to find those snacks and he's not afraid to leave the controls to get them.   Realistic? NOPE! Fun? For me, yep, but I understand it's very subjective...

Note: Duty Roster is an idea of a mod that I'm not sure it people will want to use. *I* like the idea, so I've tried my hand at OOP again and this is the result. Figured I'd share for feedback and general improvements through the usual iterative process.
In my own career game, I've found it's kinda restricting, but in a good way. I've had to shuffle Kerbals around to ensure that I had duplicate crew types to cover the off hours for longer missions, or as a bare minimum, know my pilot will be on-duty before executing my landing phase of the mission.

  

Development Notes

[27-Mar] Still in early development, but some kind forum users that said they'd like to test this out and give feedback once I uploaded it.
I would ask people to backup any career saves before using mod (or better yet, use a new save) as there are probably bugs I haven't thought of.
First mod I've written that's made it through to "Release" phase - so, yay!

 

Requirements

• Module Manager

Feedback & Bug Reports

Appreciate all feedback! Let me know your thoughts on the mod. If you have a bug report, please provide an output log while in Debug Mode (use in-game settings to enable) or at least give exact instructions how to reproduce it.

License: MIT

Download: Latest release for KSP 1.6.1

Source: Github Repo

Credits:

*Huge* THANK YOU to @garwel for letting me use a bunch of his code to get this mod off the ground. Also for advice on OOP coding in general, where I so obviously am lacking.

Edited March 26, 2019 by wile1411

[CobaltWolf]

Oooooh, sounds awesome!

[Damon]

This is an interesting approach. Will try this out!

[Freshmeat]

First of all, I am going to use this. I've just started a career, but if it blows up 5 launches lost is not a problem.

If I may suggest a small change in layout, I would add occupation after the name instead of after "on duty". Maybe snatch the icons (with permission) from the portrait stats mod I seem to remember- wings for pilot, wrench for engineer, Erhlenmeyer flask for scientist - so we have an idea whether Aldny is qualified to take the controls when Jeb steps down. Also, you might want to be able to sort by craft instead of by off duty time, if that is not included already (not clear). Looking forward to get home tonight and try it out.

[theonegalen]

Sounds interesting! I wonder how this would work with the other mods I have that modify Kerbals.

Edited March 26, 2019 by theonegalen

[Hotdiggitydog]

Its interesting but I could see it getting pretty infuriating if your kerbals stop functioning in the middle of some important maneuver. Maybe consider adding something that would l allow the kerbal to finish what ever action they were doing before sleeping.

[komodo]

This is neat! I haven't had a chance to check, but does it support other day lengths than 6 hours? If it is something you want to support, it's easy to do so in the code. (I have some examples, just... not on my phone  )

[linuxgurugamer]

This is very interesting, but I would like to make a suggestion (not sure how easy/difficult it is):

If in the middle of maneuvers it shouldn't matter what the roster is, the kerbal should stay awake until the maneuvers are completed.  One way to check would be to see if any engines are currently active and firing.  When the maneuver is completed, the roster should take affect, and some penalty should be assessed against the kerbal, as well as shifting his/her on/off time by the amount of the overage.  Maybe an extra period of rest?

I'll be following this with interest

[cyberKerb]

Wow - one post and I've already got a list of ideas.  Thanks all for the feedback! 

17 hours ago, Freshmeat said:

If I may suggest a small change in layout, I would add occupation after the name instead of after "on duty". Maybe snatch the icons (with permission) from the portrait stats mod I seem to remember- wings for pilot, wrench for engineer, Erhlenmeyer flask for scientist - so we have an idea whether Aldny is qualified to take the controls when Jeb steps down. Also, you might want to be able to sort by craft instead of by off duty time, if that is not included already (not clear). Looking forward to get home tonight and try it out.

Thanks @Freshmeat This seems straight forward and would need the CTI mod that was create especially for adding icons to other mods. I'll have a look into adding it. The catch is I think I'll need to redo how the display window is generated and I'll need to do a bit more of a deeper dive to work this out. I'll have a bit of fun learn this though and I'll certainly use the knowledge in other mods. Thanks for the sorting suggestion. This will probably go hand in hand with the gui change. I kind of wanted each column to be sortable, so this kind of confirm that suggestion. The column headings will be changed to buttons that execute a process so that column is the sorted key.

17 hours ago, theonegalen said:

Sounds interesting! I wonder how this would work with the other mods I have that modify Kerbals.

Thanks @theonegalen I've only tested this on a limited list of mods so far and haven't done much testing against those other mods. (It is planned though) The main one I personally want to test it with is Crew RNR that @linuxgurugamer has revived as I want it to work with that. If I can get it working nicely with RNR, there's a good change the rest might be OK. In fact, there might be a seed of a idea there. It would be good if somehow there could be a community mod that allows a way for a group of mods to affect that trait without conflicting. (Crew RNR, USI LF, Snacks, Kerbal Health are mods I can think of that all collectively change the Kerbal trait value) This would be an ideal rather than have mods set it independently. Kind of similar to why the Community Resource Pack was created - ie to avoid conflicts.

12 hours ago, komodo said:

This is neat! I haven't had a chance to check, but does it support other day lengths than 6 hours? If it is something you want to support, it's easy to do so in the code. (I have some examples, just... not on my phone  )

Hi @komodo I've not play with any mod with this - would that be RSS? I'm sure it'll easy to have it as a game setting, but I'm sure there's a fair be or rearranging I'd need to do to allow the logic to work with the longer period. I'm currently using the const value of KSPUtil.dateTimeFormatter.Day as my max day and the logic is simplified to only compare against the hour/min that only appears once per day. (hours 1-6 in KSP). I'd need to change how I've coded it and that would be a little lower in priority at the moment. Just trying to get the basics done first.

12 hours ago, Hotdiggitydog said:

Its interesting but I could see it getting pretty infuriating if your kerbals stop functioning in the middle of some important maneuver. Maybe consider adding something that would l allow the kerbal to finish what ever action they were doing before sleeping.

 

11 hours ago, linuxgurugamer said:

This is very interesting, but I would like to make a suggestion (not sure how easy/difficult it is):

If in the middle of maneuvers it shouldn't matter what the roster is, the kerbal should stay awake until the maneuvers are completed.  One way to check would be to see if any engines are currently active and firing.  When the maneuver is completed, the roster should take affect, and some penalty should be assessed against the kerbal, as well as shifting his/her on/off time by the amount of the overage.  Maybe an extra period of rest?

I'll be following this with interest

Regarding the comments from @Hotdiggitydog & @linuxgurugamer. That is the same concern I have while still developing the mod. I've learnt to plan around it, but I'm still thinking of ways around it to allow other play styles for those inclined to use this mod.

The current front running idea is to have an "overtime" button that adds an extra xxxx (configurable) time to the current shift. Each press of 'overtime' would mean that Kerbal then goes off-duty for zzzz(configurable) time * overtime presses. This essentially means you can keep a on station indefinitely if desired. Personally I like the added stress of having the manage that and like that it forces me to land a plan and when doing solo long haul flights. What I DO need and is the first change I want to make is add an alert option that pops in the science alert message box when a Kerbal is about to go off duty in 5mins. Also maybe only have the alert pop when the current vessel has an active engine running so as to not spam the message box after a high warp period.

 

 

[Superfluous J]

Very cool idea. Not sure if I'll use it, but I really like it

One semirandom idea: Each time a Kerbal enters "Overtime" they lose a star (because they're tired). If they have no stars, they can't go on overtime anymore. When overtime is done, they get their stars back, and become tourists for 6*(1+ot duration). hours. So if you've configured overtime to be 1 hour (likely all most people would need, as you would probably only do it when you had to sneak in a quick maneuver at the end of a shift) then they'd be off for 6*2 or 12 hours. If you set OT to 6 hours and press it 3 times, then they get 6*19=114 hours (19 days) off.

[komodo]

1 hour ago, wile1411 said:

I'm currently using the const value of KSPUtil.dateTimeFormatter.Day as my max day and the logic is simplified to only compare against the hour/min that only appears once per day. (hours 1-6 in KSP)

Sounds like you’re most of the way there already. Something to be aware of is that value isn’t exactly “constant” constant, it will return values for 24 hour days if such is set in the game preferences. Mods that change the datetime (via khronometer) do so “transparently “, by adjusting the values of dateTimeFormatter properties behind the scene. 

[linuxgurugamer]

1 hour ago, wile1411 said:

The current front running idea is to have an "overtime" button that adds an extra xxxx (configurable) time to the current shift. Each press of 'overtime' would mean that Kerbal then goes off-duty for zzzz(configurable) time * overtime presses. This essentially means you can keep a on station indefinitely if desired. Personally I like the added stress of having the manage that and like that it forces me to land a plan and when doing solo long haul flights. What I DO need and is the first change I want to make is add an alert option that pops in the science alert message box when a Kerbal is about to go off duty in 5mins. Also maybe only have the alert pop when the current vessel has an active engine running so as to not spam the message box after a high warp period.

Not a bad idea, it could go along with an automatic detection of engines being active.  In fact, you could have both configurable, so the player could choose either, both or none to play with

Best place to put that would be in a stock settings page IMHO

[cakepie]

This is pretty cool, but there's a bit of a problem I foresee:

Changing the kerbal class to Tourist is an easy and convenient way to render them unable to do anything useful while off duty, but there are a couple of issues that arise from that.

Only Duty Roster is aware that the kerbal is not actually a tourist, and knows what their original class is. This can lead to various unintended consequences.

 

1. Loss of information / contradictory information from player POV

Basically, you can lose track of what class a kerbal is when they are off duty, i.e:

23 hours ago, Freshmeat said:

so we have an idea whether Aldny is qualified to take the controls when Jeb steps down.

Duty Roster knows their original class, and can add this to its GUI (so that it states the class e.g. "Off Duty (Pilot)" rather than just "Off Duty").

However, this is going to be contradicted by KSP itself, and any other mod that displays the kerbal's class

e.g.: KSP Tracking station / map view

Portrait stats, and other mods:

Obviously, we all know Jeb is a pilot, but it can be much harder to keep track of other kerbals in a large roster.

 

2. Unintended stats (ExperienceEffect) changes

Okay, so while Jeb is on break he's not going to apply any AutopilotSkill or FullVesselControlSkill, no problem there.

But should it really mean that his GeeForceTolerance suddenly gets downgraded from 2.0 to 0.75? Or affect his EVAChuteSkill?

 

3. Unintended consequences

Ability to EVA: tourists cannot go on EVA.

If you have an off-duty "tourist" occupying a seat that is intended for someone else, that could be an unwelcome delay.

e.g. You have a permanent facility on the Mun and a craft visits to effect a crew change, but the incoming crew just happens to be on break and refuse to get out. Or you accidentally pick the wrong kerbal (who went EVA while on-duty but is now on break) to board the craft, and now he won't get out until break time is over.

 

---



To be constructive, here are some possible ways to tackle this:

1. Off-duty classes

 

Here is a MM patch I cooked up:

Localization
{
    en-us
    {
        #LOC_DUTY_ROSTER_0001 = (Off-Duty)
    }
    ja
    {
        #LOC_DUTY_ROSTER_0001 = (休憩中)
    }
}

DUTY_ROSTER
{
    title_offduty_suffix = #LOC_DUTY_ROSTER_0001
}

$EXPERIENCE_TRAIT:HAS[~name[Tourist]]:FINAL
{
    @name = #offduty_$name$
    @title = #$title$ $@DUTY_ROSTER/title_offduty_suffix$

    @EFFECT[GeeForceTolerance]
    {
        passive = true
    }
    @EFFECT[EVAChuteSkill]
    {
        passive = true
    }

    !EFFECT:HAS[~passive[true]],* {}

}

This patch creates "off duty" versions of all kerbal classes (except Tourist), so in terms of name (internal ID) "Pilot" has the counterpart "offduty_Pilot", etc. This includes modded classes (e.g. those from MKS).

The trait title (display text) is modified by suffix, and is fully localizable, so title = #autoLOC_500101 //#autoLOC_500101 = Pilot becomes Pilot (Off-Duty)

Certain EFFECTs are marked as passive, all others are deleted.

So this gives the ability to switch out any class  for the "off-duty" version.

There's one minor quibble I have where this doesn't quite work, which is that all these "off duty" classes are also eligible to be generated as applicants in the Astronaut Center. Which is kind of weird and could maybe lead to strange behavior?

 

Other possible avenues to investigate:

 

2. inactivation?

ProtoCrewMember.inactive <-- perhaps this can be used?

You can apparently inactivate a PCM for a set duration using ProtoCrewMember.SetInactive ( double time, bool additive ).

ProtoCrewMember.outDueToG suggests that this is used for high-G blackouts, among other things.

 

3a. Programmatic editing of ExperienceTraits

It is possible to fetch ProtoCrewMember.experienceTrait and then obtain the list of Effects from that. Not sure if tampering with that list (to remove/disable certain effects while off-duty) will work, but could be worth a shot, since this:

static ExperienceTrait 	Create (System.Type type, ExperienceTraitConfig config, ProtoCrewMember pcm)

appears to suggest that there is a distinct ExperienceTrait for each kerbal, rather than shared between all kerbals of the same class.

Even if this works, the changes will likely not be persisted in the save file, because rather than a config node for all of this for each kerbal, the save file just contains the trait as a string. Presumably that is used to lookup the ExperienceTraitConfig and re-instantiate ExperienceTrait as needed upon loading. So some OnLoad machinery will be needed to check if the kerbal is off-duty, and then re-do the edits to the effects list as needed.

Downside of this is that while we might be able to deactivate the ExperienceEffects, it doesn't look like we can modify the ExperienceTrait's typeName, title (display string) or description.

Unless...

3b. Programmatic creation of ExperienceTraits

Completely replace ProtoCrewMember.experienceTrait with one that is crafted programmatically, from scratch, via ExperienceTraitConfig.Create() and then ExperienceTrait.Create(). This would basically be equivalent to enacting all the changes from the MM patch (approach 1). However, by doing this in code, the modified "off duty" version won't be in GameDatabase.Instance.ExperienceConfigs and can't be generated as applicants.

This is the most involved option, by far, but probably the "correct" way to do it.

 

---



Re: shift / overtime mechanics, you could also consider taking inspiration from automobile endurance racing. For instance, the rules for the 24 Hours Nurburgring limit drivers to a maximum stint of 150 mins of continuous driving, and enforces at least 2 hours of rest between stints in the car. So, when changing the on/off-duty timings, you'd be allowed to push back the on-duty time or bring forward the off-duty time, but not the other way round.

Maximum on-duty duration and minimum off-duty duration could vary according to kerbal experience level (number of stars)

To encourage careful planning ahead and strongly discourage flippant use of "overtime", it should come at a steep cost, and perhaps even carry some risk:

- "fatigue" ticks up when on duty and ticks back down when resting
- grows faster than linearly, probably exponential. decreases slower (linear should be ok)
- fatigue doesn't normally need to be tracked as a variable when not doing overtime, just treat the max on-duty time as "generally allowable 100% fatigue" and the min off-duty time as sufficient to recover fully from that; extrapolate accordingly
- when overtime commences by prematurely ending rest time, initialize with 0% < fatigue < 100%
- when overtime commences by going over max working duration, initialize at 100% fatigue
- once overtime has ended, kerbal will be forced to rest for a much longer duration according to fatigue value, with overtime strictly disabled (think sleep debt)
- when fatigue exceeds a certain value, say, 200%, introduce a chance of the kerbal passing out; risk grows with fatigue level. (probably make this an option that can be turned off)

 

 

 

 

 

 

 

[Eugene Moreau]

Next, they're gonna unionize and want overtime pay.  Could work that into the costs in the budgeting mod.  

[Freshmeat]

Chiming in on the overtime, it would be sweet if it had a spillover to Kerbal Health, taxing the overtime in HP (1/30 mins would be a real danger quickly). Actually, if you really wanted to make me happy, make it so you manage the crew rotation on active ships not in timewarp: I can choose to relieve Jeb, or make him bit the bullet and suffer through, until he can get a long R&R.

[cyberKerb]

Thanks so much for all the feedback. I'll be digging into some of these over the weekend to see if I can't get a few improvements to the mod. Big thanks to @cakepie for all the UI considerations and code suggestions. That's probably what will have most of my attention.  

[cakepie]

On 3/28/2019 at 12:23 AM, cakepie said:

you'd be allowed to push back the on-duty time or bring forward the off-duty time, but not the other way round

Upon further consideration, this isn't completely correct. If you've already pushed back the on-duty time, you should be able to bring it back forward again as long as you don't go under the minimum rest time. Likewise for off-duty times.

 

[DStaal]

What might be realistic - if you wanted to get this complex - is something like the CDL 4-clock system, or at least parts of it.  For those who've never used it it, it has the following:

 * Amount of time driving today.   Can be started/stopped, resets daily.

 * Amount of time on duty today.  (You're on duty doing things like checking the status of the truck, or monitoring loading/unloading, or filling out paperwork.  This clock is longer than the previous.)   Can be started/stopped, resets daily.

 * Amount of time since you went on duty today.  Resets daily, *can't* be stopped.  (So if you drive an hour to the yard, and then sit all day they can't make you then drive 8 hours.)

 * Amount of time on duty this week.  Can be reset or rolls off.

 

The resets are the interesting part of this: The 'resets daily' means it resets with 8-hours continuous off.  Those can be at any time, but have to be solid blocks.  The duty this week can be reset by a continuous amount of hours off (basically two days) - however it only counts how many hours in the past 7 days.  If you don't do full days, you can keep the total hours in the last seven days low, and keep working every day.  If you do do full days, you'll have to take the weekend off.

Anyway, it might be another way to deal with overtime: Have a bank of hours that they'll assume to have depleted to a certain level, and if you go overtime you deplete further.   Give your Kerbals shorter normal shifts, and they'll be more willing to work overtime - but you can't pull overtime all the time either, or they'll go off for longer periods.  Maybe allow shift length on a per-Kerbal or per-ship basis?

[BlackHat]

Quick questions & suggestions , I dont know if its possible.

If I launch a mission with tourists on it, Say 6 Kerbals (2 P, 2 E, 2 S) and 4 tourists, Will Tourists be shown on the Duty Roster? (Think they should be, but maybe without the time controls to adjust their start time.)

Also, when Kerbals are off duty, their Classification becomes Tourist. Which might be confusing if your mission has actual Tourists on it. Can they be labeled in the Off Duty as opposed to Tourist in the portrait window?

[cyberKerb]

Wasn't able to get to it last weekend. Hoping this weekend is better.

5 hours ago, BlackHat said:

Also, when Kerbals are off duty, their Classification becomes Tourist. Which might be confusing if your mission has actual Tourists on it. Can they be labeled in the Off Duty as opposed to Tourist in the portrait window?

This is on the list of this that came from earlier suggestions. Will do.

[smotheredrun]

This looks very cool

[vardicd]

I will be watching this mod with an eager eye. Very promising.

[The_Arcitect]

Looks promising, can't wait to use.

[cyberKerb]

Yikes! I've been reviewed. Thanks @Kottabos! I really need to get onto some of those issues this weekend - including changing the labeling on the the "Change to" column to "Change to (Mins)"  

 

Edited April 5, 2019 by wile1411

[cyberKerb]

Just letting all know that I did get some time to work on the mod over last weekend. Just ran out of time for the last bit of testing I wanted to do.

•  rebuilt and rearranged how the list of Kerbals is displayed
•  added the CTI profession icons next the names - Kerbal profession trait stays regardless of On/Off Duty status
•  broke the paging process when there are too many kerbals to display at once (should be an easy fix)
•  added tourist support. They won't have any duty to maintain and any change buttons wont appear for tourists
  •  I intend on addressing the trait being tourist at all issue that Cakepie raised, but it won't be done in this update.
•  got most of the way into adding the Overtime process, but need a bit more testing before releasing an update.
  • WIP process is a press of button gives you an (default) 20 mins extra and is configurable. The "cost" for overtime is that they'll take a full extra day off duty (per button press - again configurable) before coming back for their next shift.