[Request/Idea] Kerbal Training and other time-based Kerbal mechanics

[NathanKell]

This is pointed especially at @magico13 as I feel this sort of thing is right up your alley. @nightingale might also be interested.

The idea (largely inspired by BARIS, as frankly most of RP-0 is...) is that your kerbals can go into training, which costs time and funds. This can work in two ways, in order of easiness to implement and importance.

1. You can train them up (to a certain XP level) by "sending them away for training" at a cost of x funds and y time. During that time they are unusable for missions (although they can be removed from training early, at a cost of not getting the XP gain). This might be initiated automatically on hire.

2. They can be trained for a specific spacecraft and/or mission. In order for a kerbal to actually control a vessel in a given situation they will need to be trained on it (for some time period), and that training wears off after a time period. Or, if you go the bonus instead of penalty route, they get a bonus during the period, but can still always control everything. Or some combination. This will obviously need to vary by part and by situation, ideally including speed ranges (<250m/s, <1000m/s) and flying low/high/spacelow/spacehigh per body, and that affects training time and cost. Different AC upgrade levels can affect what options are available. Tourists would come trained for their requested environments (so controls don't lock), although they would still not be a source of control themselves.

 

Reach goals:

A. Teams. Kerbals can like or dislike other kerbals, and should be teamed with those they like. Training for multi-kerbal missions is team-wide, and only that team together gets the bonus (or the control ability) per 2.

B. Kerbals can retire (faster if they're teamed with those they dislike and if they don't fly).

 

Thoughts?

[Evanitis]

Training sounds totally cool. Training for a specific mission would be nice... (mission type? How it's defined? Maybe by destination?) I can't really imagine training a kerbal for a specific craft... the exact composition of a vessel tends to change pretty quickly - a lot quicker that I imagine a training session would take. Though if that target craft is defined by... dunno, cockpit? Approximate mass? Horizontally or vertically launched? - something more general, it could be fun.

I'm somehow not really fond of the A-B goals. I'm all in for any kind of aeronautic or astronomical realism that makes it's way into stock... But physiological and mental realism? Especially animosity between kerbals? I always envisioned them as they are above such things.. or at least who doesn't take such feelings too seriously, not enough to affect their performance.

And retirement? It's still the same species that keeps grinning after they spend 40+ years alone on Eve, waiting for the rescue? Ok, grinning is one thing, but they were totally functional after such. I always loved that quality in them.

[Joshwoo70]

+1 for idea... I really want it!

[magico13]

1 is actually something I looked into doing back when the experience system was first added (actually, now that I think of it the original idea was before XP was added but after funds were), but it was made complicated because of XP's deep connection to the flight log. I know @nightingale came up with a way around that for Contract Configurator that could probably be adapted (and I don't believe it's tied into any planet/situation directly), and @RoverDude's USI Akademies get around it by copying flight data from the teacher Kerbal to the students (presumably, I haven't checked the code) which would be planet/situation specific.

I wanted to have different courses, each with different costs and time constraints that gave varying amounts of XP. Part of the cost would be a base cost for the class, then there'd be a cost per Kerbal, and a cost for the teacher. If you used your own teacher(s) you could eliminate that cost, and it was always most cost effective to put as many Kerbals into a class as possible. One of the original ideas was to have a test at the end (success based on the Kerbal's stats), if they passed they'd get the XP/a stat increase. If they failed they wouldn't get the XP but would still get a stat increase to help their odds next time. Now I'd probably just stick to the "take class -> get XP" method and not rely on (or change) stats.

1 is pretty easy. It's just adds optional benefits (maybe with a required "basic training" course before a Kerbal can fly) that can reduce grind and would be great in a Stock game and alright for an RSS game. The simple way of doing it would be to tie courses to specific planets/situations and just adjust the flight log, but keeping the experience separate from any situations is an option as well. It's a mod I'd happily add to a save without worrying about it affecting my playstyle much. 

2 is obviously tougher, both from a programming standpoint and from a playing standpoint. It sounds perfect for RSS but sounds tedious for a non-RSS game. Even if you go "benefit only" with it, it's specific enough that I don't know if I'd take the time/funds to train people. I love the idea, but I don't think I'd use it personally and I wouldn't want to take the time to work on something I won't use (someone who does use it will do a much better job at it).

I like the idea of teams. I just started watching "From the Earth to the Moon" and I can see why teams would be important. I'm less a fan of retirement personally, but it probably wouldn't be hard to add.

 

Here's the problem: I'm in my last semester of a Masters program where I'm doing research and am a teaching assistant. I have to write my thesis soon. Time isn't something I've got loads of at the moment, so I'm not sure if I can devote much to something like this. I could probably crank some proof of concept stuff out this weekend, at least for 1, but I can't make any promise of anything over the long term. If it's kept simple enough I'd be able to find the time though. I also start a new job in early July, but I think I'll actually have more free time once that starts.

If @nightingale isn't interested, and nobody else chimes in in the next few days, then maybe I'll play around with it this weekend.

[nightingale]

Some interesting ideas, I really like this kind of stuff.

2 hours ago, NathanKell said:

1. You can train them up (to a certain XP level) by "sending them away for training" at a cost of x funds and y time. During that time they are unusable for missions (although they can be removed from training early, at a cost of not getting the XP gain). This might be initiated automatically on hire.

Like the idea, although it probably shouldn't be automatic on hire (since the most common use case for hiring Kerbals is "oh crap, I need a pilot for this rocket that I'm launching in 5 seconds").

2 hours ago, NathanKell said:

2. They can be trained for a specific spacecraft and/or mission. In order for a kerbal to actually control a vessel in a given situation they will need to be trained on it (for some time period), and that training wears off after a time period. Or, if you go the bonus instead of penalty route, they get a bonus during the period, but can still always control everything. Or some combination. This will obviously need to vary by part and by situation, ideally including speed ranges (<250m/s, <1000m/s) and flying low/high/spacelow/spacehigh per body, and that affects training time and cost. Different AC upgrade levels can affect what options are available. Tourists would come trained for their requested environments (so controls don't lock), although they would still not be a source of control themselves.

I guess it depends what the bonus/penalties are.  Something like "Your Kerbal isn't trained for orbital flight, disabling controls" might just be punishing gameplay (although as long as they didn't go TOO fast, they should be coming back...).  This area has actually been my biggest struggle with Strategia - thinking up bonuses that are good from a gameplay perspective, significant enough for a player to want it, and technically feasible.

2 hours ago, NathanKell said:

A. Teams. Kerbals can like or dislike other kerbals, and should be teamed with those they like. Training for multi-kerbal missions is team-wide, and only that team together gets the bonus (or the control ability) per 2.

I remember there was a mod that did something like this - Kerbal Interactions, Kerbal Emotions or something along those lines (it was maybe 6-9 months ago?).  I think the mod really was more of a toy though, as I don't think it ever got anywhere significant.  That being said, I do like the idea.

2 hours ago, NathanKell said:

B. Kerbals can retire (faster if they're teamed with those they dislike and if they don't fly).

Absolutely necessary if you're doing all encompassing where time matters.  You'd probably also want to tack on salaries (in place of escalating hire costs), which could be dependent on experience.  I'd also rip out the stock experience system almost (ie. don't calculate it purely based on the flight log, but base it on all kinds of other stuff), and then hook back in by setting the kerbal XP at the appropriate time (much like @magico13's Field Experience mod does).

To make a cohesive "Kerbal Career" mod, I think you'd also need to add:

1. Kerbal age (really just storing a birthdate, and using that to determine likeliness of retirement).
2. Kerbal salaries (I always forget if BROKE does this or not).
3. Lots of different bonuses/penalties for high/low experience, good/bad team dynamic, etc.
4. Final Frontier style ribbons/awards/military rank might be neat
5. UI to put all of the above together

Lots of good areas that can be explored here that haven't seen much mod love.  The trick would be getting it all together in a way that is cohesive and FUN.

[nightingale]

5 minutes ago, magico13 said:

1 is actually something I looked into doing back when the experience system was first added (actually, now that I think of it the original idea was before XP was added but after funds were), but it was made complicated because of XP's deep connection to the flight log. I know @nightingale came up with a way around that for Contract Configurator that could probably be adapted (and I don't believe it's tied into any planet/situation directly), and @RoverDude's USI Akademies get around it by copying flight data from the teacher Kerbal to the students (presumably, I haven't checked the code) which would be planet/situation specific.

The Contract Configurator way is a horrendous hack.   I'd just add something that tracks experience in a scenario module and inserts it in, instead.

6 minutes ago, magico13 said:

Here's the problem: I'm in my last semester of a Masters program where I'm doing research and am a teaching assistant. I have to write my thesis soon. Time isn't something I've got loads of at the moment, so I'm not sure if I can devote much to something like this. I could probably crank some proof of concept stuff out this weekend, at least for 1, but I can't make any promise of anything over the long term. If it's kept simple enough I'd be able to find the time though. I also start a new job in early July, but I think I'll actually have more free time once that starts.

If @nightingale isn't interested, and nobody else chimes in in the next few days, then maybe I'll play around with it this weekend.

Interested, but I really don't want to take on anything new until I get Strategia out the door.  It's been in "almost done" state for a month an a half now.  Also, people need to stop raising Contract Configurator enhancement requests.

[magico13]

1 hour ago, nightingale said:

Kerbal salaries (I always forget if BROKE does this or not).

BROKE does have a salaries Funding Modifier as one of the defaults. Configuring that/writing a different one would be pretty simple to do if you all wanted one that was more RSS specific.

 

How about this: I'll mess around with some of this this weekend and I'll release whatever I come up with under MIT or Public Domain. If you guys want to refactor it into something way bigger then great. If you hate it then I will have had some fun playing around with a concept and someone else can come up with something else. And if you've just got some suggestions for tweaks or future enhancements then I can try to find some time to add them down the line. Basically I've wanted to tinker with this idea for a while (it'd go great with KCT and the downtime it encourages) and that'd be a way to maybe meet everyone's desires without any sense of obligation from any party. I just can't make any promises of a total career overhaul right now.

 

Regarding ripping out the Stock XP system, I've given some considerations to that in the past. I've got an RPG like idea based on a single ship, scavenging parts from space hulks, with a totally different XP system (pilots get XP based on time spent flying, engineers get it for scrapping things/using KAS, scientists get it for hacking probes). That's not at all related to this though and is way off topic

[NathanKell]

@magico13 those time constraints seem very reasonable. Goodness knows I feel your pain. On the plus side, RP-0 already has control-locking code, so if the 'training course' framework is extensible enough I could just query the existence of the appropriate course for each kerbal and then decide to lock or non-lock, so #2 would become fairly trivial to bolt on top of your existing framework, assuming training courses can be arbitrarily added and have expiration dates and expiration conditions (i.e. expires after x days in the complex, or y days in flight, and/or on return to the complex).

Let me explain, however, why I mention it (#2) in a stock framework. Again, it's a question of time, and therefore planning. KCT is great about actually making you have to plan ahead for missions (and have nailbiting rescue windows, especially if you didn't keep a rescue LV ready). However, so far it only deals with the hardware, not the (as it were) software. Further, right now kerbals are fairly interchangeable, separated pretty much only by XP: there's no reason to not keep reusing the same kerbal over and over, and indeed (XP gain) reasons *to* do so. If you have to plan ahead and have kerbals in training, if you fly two LKO missions within a week of each other, say, you can't just reuse the same kerbal.

 

@nightingale re: automatic: see above for why that actually plays into the idea. (Not for everyone, of course, but for those who do want the challenge of playing ahead, not being able to "buy and fly" applies as much to kerbals as to vessels.)

 

As to punishments vs. bonuses: I agree that (stock-wise) the bonus approach would be better, but I also agree that it's very hard to find good, balanced ones that don't (hi VesselValues) change physics, for example. I would certainly like to remove the current experience system and replace it with something more BARIS-like, but I am unsure how to do that in a game where the player directly controls things and where (pseudo-)random failures do not occur,--even if the player controlled things directly, low pilot skills could lead to random-ish failures, but that's not exactly fun or, speaking narrowly, realistic. I also do plan to integrate BROKE into RP-0, although perhaps more optionally than KCT (I know there are and will be people who like the current contract model for missions, so we may offer a less-than-hardcore-state-funding-only model).

 

@magico13 that sounds like a good plan! When I have time after 1.1 I can dive into it more (I mention above an easy way to achieve #2 using more or less only my own code, and querying kerbal history), and sounds like @nightingale is interested too.

[magico13]

I feel a need to point out CrewQueue as something to look into since it provides additional time constraints on crew based on their last mission, to prevent recycling Kerbals quickly. KCT itself is purposefully "hardware" only, I've made a point of not interacting with Kerbals to avoid excessive feature creep (it has enough as it is ), so the intent was always to either make a mod or integrate with a mod to handle Kerbals.

If you've got the ability to easily handle #2 given a course history, I can easily make that happen on my end. It'd be almost trivial to use Reflection to grab a list of passed courses for a given Kerbal. And I think everyone in this thread is well aware that I like configurability, so I'll make it easy to define new courses through configs.

 

Regarding how the XP should work, I think having two options is a good idea: an option for "raw XP" that's blindly added to the XP total after the career log, and a second option where flight experience is added to the log. So you might have a "Kerbin Orbit Training" course that adds "Kerbin, Orbit" to the career log and a second course "How to use a Space Wrench" restricted to Engineers that gives +1 XP. The first course wouldn't benefit Kerbals who have been to orbit, but the second one would benefit anyone who took it.

Ideally there'd be options to restrict courses to specific classes, prerequisite courses, minimum (and maximum) levels, whether it can be retaken or is a one time thing, expirations for the experience (I'm a bit wary of removing data from the career log, but StageRecovery removes things from the Flight Log so it should be similar for the career log), the amount and type of experience, base cost/per kerbal cost/teacher cost, and whether the course is required before the kerbal is allowed to fly.

I think KCT's math parsing might be handy to use to let you hire a better teacher (at a higher cost) to get more XP without having a nearly duplicate course. For #2 it might be better to define separate courses though, unless the data that gets returned when you query a Kerbal's course history also includes the finalized course config (definitely an option).

Here's a rough idea of what a course config might look like. If anyone can think of anything else you'd want/need, let me know, but I think this covers most basic needs. The REWARD node could be fairly arbitrary so you could define your own custom rewards (for #2 it could be used to define the situations the course is valid for). Like I mentioned before, I could return the REWARD node when you query the courses a Kerbal's taken or I could return the whole COURSE node, or just the course id.

 

COURSE
{
  id = ENG101
  name = How to use a Space Wrench
  classes = Engineer, Scientist
  prereq = BAS101 //basic training
  time = 18.0 //total number of hours the course takes to complete (3 Kerbin days)
  expiration = 180.0 //number of hours the class experience is valid for (30 Kerbin days)
  expireOn = IMMEDIATE //when to have the XP expire, IMMEDIATE expires as soon as the time is up, RECOVER expires when the kerbal is returned to Kerbin (so you can finish the current mission)
  required = false //whether to course is required before the kerbal can fly (ie, basic training)
  repeatable = EXPIRED //can be repeated if the granted XP is expired (ALWAYS, EXPIRED, NEVER)

  minLvl = 0
  maxLvl = 5

  costBase = 1000 //base cost of having the class
  costSeat = 100 //cost per kerbal in the class
  costTeacher = 1000 //cost of hiring a teacher for the class (can be mitigated by using a kerbal of our own)

  teachClasses = Engineer, Scientist
  teachMinLvl = 2

  REWARD
  {
    XPAmt = 1 //RAW XP added to the total, independent of situation

    FLIGHTLOG
    {
      //here you'd define a flight log that would be inserted into the career log
      //since this course doesn't use this type of experience, the node is blank
    }
  }
}

 

[NathanKell]

@magico13 yeah, makes sense. Although I think it's probably better to add cooldowns to this so the various ways of taking kerbals "offline" don't interfere, maybe? And yep, I can pull this with reflection and that'll get #2 sorted well (or, more likely, just hard-reference the plugin ).

As to the cfg format, the math parsing would be very good, yes. It would cut down on the number of custom courses. They could also be used for dates (30h, 1y, 60d Kerbal, 60d10h, etc) For additions, here's what I'd suggest:

1. Ability to set different expiration regimes and times, i.e. expire after 360 days period, or 2 days in flight, with the IMMEDIATE/RECOVER option for both cases.

2. Expiration blockers: Expiration will not occur if another course is currently on the list. Consider a Basic Orbiting course that allows flying a basic orbit, and then a Transmunar course for entering Mun's SOI. Each has an expiration of 90 days and a length of 90 days. The Basic Orbiting course blocks expiration if Transmunar is active, so if you do them back to back ordinarily Basic Orbiting would expire, but it's blocked to not expire until Transmunar does. Perhaps an easier way to do this is just as a stack, where only the 'topmost' course (with an expiration) can expire? Or, alternatively, the other way around: a course can list what other courses it blocks from expiring.

3. Required minimum number of kerbals in a course (if you don't add this many, the course doesn't go forward).

4. Prohibits as well as requires (a list of courses that, if present in the record and unexpired, prevent the taking of this course).

5. Can be removed from course (and if so, how much of the REWARD is given). I.e. it's a 2 year course (basic training) and you can remove the kerbal starting 6 months from the end, but get only 3/4 the reward if so.

6. Is auto-run on hire.

7. Meta-courses, i.e. course packages. Per 2 above, we might have a LKO course and a Transmunar course, and a Transmunar package that is presented to the player which includes both together (so you don't have to add six courses manually for a complex mission). Maybe even offer time and cost discounts for these package deals.

8. Make the use of a teacher optional (i.e. some courses can be set teacherless--they have only a base cost and seat cost, and don't have teacher requirements or costs).

 

Finally, and this is something for KCT as well as this: it'd be nice to have the option to show dates in either y/d/h/m/s format, or KAC-style calendar date using a known epoch equivalence. I.e. a course expires in 90 days or on Sep 21 1962.

[inigma]

How about a simple contract that requires you to physically fly your Kerbals to the KSC2 training center? Stick them there for a period of time, and the pick them up and return them safely to KSC for an experience reward? I can add this to GAP right now.  

Edited February 5, 2016 by inigma

[nightingale]

7 minutes ago, NathanKell said:

As to the cfg format, the math parsing would be very good, yes. It would cut down on the number of custom courses. They could also be used for dates (30h, 1y, 60d Kerbal, 60d10h, etc) For additions, here's what I'd suggest:

I've got a simple regex based date parser that I use in Contract Configurator to accept strings in pretty much that exact format:
https://github.com/jrossignol/ContractConfigurator/blob/master/source/ContractConfigurator/Util/DurationUtil.cs#L22-L42

I didn't realize that KCT had a math parser too - neat!

10 minutes ago, NathanKell said:

<a bunch of good stuff>

I like this, it's very well fleshed out.  One thing I'd suggest is a sort of tiered expiry.  If the course expires, they may need to take a refresher course that is half the duration of the regular course (and could be a self-directed course with no teacher).  If they don't take the refresher within the expiry period, they go back to completely untrained and need to take the full course.  This way players aren't penalized as hard for forgetting to top up training (and an astronaut with expired training is still valued higher than a brand new hire).

Another is to think about splitting the courses into activities (atmospheric flight, orbital flight, Munar injection, etc.) and courses (which give the ability to do an activity with a certain level/proficiency).  In a way, this just takes the idea of meta-courses one step further - the *only* kind of course is a meta-course.

[magico13]

@NathanKell Those all sound great, but a few might have to wait for a little longer down the line. KCT's got both the math parser and y/d/h/m/s support so bringing those into a new mod would be easy (I might move them into MagiCore and have both KCT and this reference that).

 

For 1 you mean that there's two separate expiration triggers: 2 days of flight (total, non-consecutive?) OR 360 days, whichever comes first? That feels like it's something that would benefit from a general solution for handling expirations rather than the mod including a bunch of specific triggers. I'll have to think of a good way to handle that, but I can definitely provide a way for other mods to manually expire a course.

For 2, if Transmunar required Basic Orbiting and both were Flight Log based, then Transmunar would include Basic Orbiting in it by default (if we're just talking about XP). Not just talking about XP, Transmunar might be FL205 while Basic Orbiting is FL151, and Basic Orbiting would be a given based on the fact that you've taken Transmunar. Basically you'd only have to look at the highest in a stack and all pre-reqs should be automatically valid. I realize now that there should be two sets of prereqs: active ones where you must have the taken the course and it has not expired, and inactive ones where you just have to have completed the course in the past (perhaps with a maximum amount of time since it expired, like transferring credits has a max number of years before they're no longer valid). Basically, the highest course should probably include all the lowers. I could maybe add an additional "provides" where a course can provide equivalent credit as another course (but that could also be handled in the REWARDS). I'll have to think about this one.

I also realize there should be a way to "test out" of a course if you have equivalent experience. So a kerbal who has orbited Kerbin and wants to take the Tranmunar course could take it even without taking Basic Orbiting. The Basic Orbiting course would define what counts as equivalent credit for prereqs. I'll have to also think about how to add this, it might be a task for later on down the line.

3, 4, and 5 are all fine. Perhaps the REWARD section can define how much you get for completing the course through the use of a variable (0 to 1 representing the percent of course finished). If that variable isn't present then you get none of that reward if you quite early or all of it if you stay. (ie "XP = 10 * [COMPLETED]" vs "XP = 10")

6 This conflicts with class sizes and such so I'm not a huge fan, and what if someone tries to set up several autorun courses? I'd rather provide a "required" flag in the course that makes the course a requirement before the Kerbal can be used in missions. Then you can hire a bunch of people at once and put them through a single basic training once you've got them all hired (rather than N individual basic training courses). You can even have multiple required courses then, so maybe there's a "basic training" everyone takes and then "Flight 101", "Engineering 101" and "Rocket Science 101" for each class that is required before they can go. It's be extra cool if you set it up so they can be used for missions after basic training but have no "specialty" until you train them in one of them (I'll add a REWARD option of defining the kerbal's specialty).

7 would be a "later on" task at this point, but I like the idea. Especially if group dynamics are added then that could provide an additional group bonus since they will have stuck together the whole time.

8 teachers would be optional. By default you either pay for a teacher to come in from somewhere else (a university, another company, etc) or devote one of your kerbals to run the course (thus taking that kerbal out of the roster as well, but saving some money, maybe providing other incentives too, like extra XP [defined by the REWARD]). If the teacher cost is zero then it'd be free to hire an outside teacher, or you could just say there isn't a teacher at all. I'm not sure I'd totally disable the teacher option then, since you could still provide benefits by having one of your kerbals teach (set the min level to 6 and then the teacher is disabled completely).

I know of KAC's calendar so I can look into that. That's something that can easily be added later so I might not worry about that this weekend.

[NathanKell]

@nightingale ooh, the refresher course/tiered thing is great! Definitely. And I think your idea re: activities and courses makes good sense in theory, although I struggle to see how it might be implemented in game:

 

@magico13 hah! No, I get it--I feel bad enough I'm not writing it myself, please don't take this as badgering or Are-we-there-yet-ing

1. I agree that a general solution would be better, say multiple EXPIRE nodes with situation, raw time, and expire state (IMMEDIATE/RECOVER), where once one reaches RECOVER all other RECOVER nodes no longer need to be checked, and once one reaches IMMEDIATE it's all over.

2. The problem here is that the stack isn't linear: LEO + Rendezvous + Translunar vs LEO+Translunar vs LEO + Rendezvous. Yes, often enough there will be guaranteed prereqs (everybody requires Basic Training), but some times it's not straightforward at all (A scientist-astronaut or, perhaps in Shuttle parlance, a Mission Specialist, who is trained for EVA but *not* LEO piloting operations, let alone rendezvous). Or consider a simple Apollo-ish Mun mission. Jeb gets the pilot training for LEO, translunar, transkerbin, and reentry; Bob and Bill get EVA and Mun-landing and Mun-ascent. As to "in the past"--I would suggest combining this and nightingale's idea: if you've done a course in the past (before some final expiration) you can take a refresher instead (or test out period). I do think the options shouldn't be only never test out or always test out.

Actually, let me back up for a sec: I envision courses beyond Basic Training as less "how do I x" and more "we're going to simulate the mission now, and cover all failure modes, so you'll be ready whatever happens"--so to my mind testing out doesn't make much sense, although testing into only a shorter ("refresher") does.

3/4/5 makes sense to me! Though you would probably need a step function there (i.e. x < 0.75, reward = 0, else reward = orig * (x * 4) for a simple 75% threshold.

6. I agree, that makes sense; withdrawn. And that last bit is perfect!

7. Makes sense, although see above for nightingale's thoughts there.

8. Ah, yes, setting minlevel to impossible would do the disabling that way.

And yeah, I believe KAC's code for date conversion is "please use me" Right @TriggerAu ?

(Although leap years would be nice... )

[nightingale]

5 minutes ago, NathanKell said:

@nightingale ooh, the refresher course/tiered thing is great! Definitely. And I think your idea re: activities and courses makes good sense in theory, although I struggle to see how it might be implemented in game:

Really more of an internal issue of avoiding having to duplicate information in multiple courses that may give the same effect, especially if that effect (effect makes more sense than activity) is not unique to a specific course.  Example, you have the courses Science 100, Piloting 100, and Engineering 100 which all give the effect "EVA" (without this, they are basically tourists and can't EVA).  Rather than having to check if the Kerbal has one of the 3 courses, you just check for the "EVA" effect.

In other words, Kerbals take courses.  Courses give effects.  Kerbals have effects.  Effects are used in checks for the ability to do things, for penalties and for bonuses.  This also gives the flexibility that down the line you could also conceivably give effects without any courses ("on the job" training).

Taking it one step further, you might even be able to implement the effects as ExperienceEffects that are added to the Kerbal on load (rather than as part of the trait definition).  I have no idea if that part is possible, or if it gives any worthwhile benefits over making up a new system - just idle speculation.

Implementation wise I may be overthinking it too - in Magico's example config the effect really may just boil down to a FLIGHTLOG item.  I think reason that I'm thinking of it as a separate "entity" is that you can then give it attributes (such as the expiry, rather than having that as part of the course).

[NathanKell]

@nightingale Ah, yes. That makes sense. Although I don't see how to do a "transmunar" effect, in that it's gameplay-wise indistinguishable from any other burn in LKO until it creates an encounter...and by then you've already done the burn. Hence my original thinking re: situation checks. I would, frankly, *love* to do it your way entirely, I just don't see how.

[nightingale]

10 minutes ago, NathanKell said:

@nightingale Ah, yes. That makes sense. Although I don't see how to do a "transmunar" effect, in that it's gameplay-wise indistinguishable from any other burn in LKO until it creates an encounter...and by then you've already done the burn. Hence my original thinking re: situation checks. I would, frankly, *love* to do it your way entirely, I just don't see how.

Ah right, was just throwing out example without thinking them through fully - I can't see a way to do that part either.  Best I can come up with is a reputation penalty for sending unskilled Kerbals out, but I'd be concerned that it would just come as a surprise to the average player (surprise, we took reputation because you went to the Moon!).

[NathanKell]

I agree. In that case we'd have to fall back on situational bonus/penalty (in Munar SOI) rather than activty-based (TMI burn, MOI burn, LMO operations).

[TriggerAu]

On 2/5/2016 at 7:52 AM, NathanKell said:

And yeah, I believe KAC's code for date conversion is "please use me" Right @TriggerAu ?

(Although leap years would be nice... )

Yep the KSPDateTime and KSPTimeSpan classes are all good to be reused.

Once @NathanKell sorts out leap years I can take his pull request into the DateTime class... see what i did there  . TBH, I dont recall how it handles (or not handles) them atm I'll note it down for when theres time

[NathanKell]

[x] Rekt

[magico13]

So I started doing some work to at least get a framework up and running for this. Still a lot of work to do before it's really usable (I literally just added persistence to the active courses) but it's a start. Rewards don't work yet, neither does the "required" flag, nor does expiration (or prereqs or conflicts, or really anything more than the bare minimum).

Here's the repo on github. There's no license mentioned on there yet, but I'll likely use MIT. I'm going to try to do some more work on it in the evenings this week. Next weekend I'll be out of town so I'm not sure I'll get much work done on it then.

 

One thing I decided to change was to put EXPIRY nodes inside the REWARD nodes. That way individual rewards can expire at different times (or one REWARD might not expire at all but the others in the course might). Each REWARD node can then have multiple EXPIRY nodes as well. To handle whether the course should be considered expired I'm thinking you can define "expired = ANY, ALL" to say whether it should be "expired" when any of the rewards expire, or only when all of the rewards expire. Maybe it makes sense to allow a list instead? So a course might have 5 rewards and is considered expired when a specific 3 of them have expired? REWARDS themselves should have similar options. I'm just thinking out loud at the moment, REWARDs don't even work at the moment so this isn't even close to an issue yet.

[NathanKell]

@magico13 good stuff!

Assuming the reward nodes have names, it seems like supporting an expireOn value in the main node with either ANY, ALL, or (comma-delimited) list of REWARDs would be the most flexible, yes.However, that raises an excellent point. I don't immediately recall if this was covered above, but it would be good if REWARDs can "provide" (in the way CKAN means provides) certain things. So a course could have the active rewards expire but leave one that 'provides' a basic proficiency that other courses can detect and require. Though that really brings us back to @nightingale 's original argument for all courses being meta-courses, with the granularity at the effect level (i.e. courses would just be a set of effects, would have prerquisite effects, effects would do the expiring, etc). I think the way you're going with rewards is 90% of the way there and you might as well just go whole-hog. 

[MatterBeam]

Throwing an idea out here:

Pilots are trained for specific command modules. All have basic one-star functionality in all command modules, but better training provides them extra-star bonuses.

For example, a pilot who has flown ten times in a MK1 Cockpit would be very proficient with it. However, he would be unfamiliar with the controls of the MK3 Cockpit.

The reasoning behind this is that rockets change much too often for pilots to be trained on a per-flight or per-mission basis. However, encouraging players to standardize at least parts of their rockets, and build specific training craft, would be a good thing.

Thoughts?

Also, @magico13, you truly are magical.

Edited February 8, 2016 by MatterBeam

[magico13]

@MatterBeam The way I'm trying to set things up is that the core plugin might only do some basic things with XP, but REWARDs can have any arbitrary data assigned to them. Other plugins can then get that data and decide what to do with it, so your idea would be pretty straightforward to add with a subsequent plugin (assuming you used "simulator" courses to train for cockpits instead of relying on actual flights). I haven't really figured out what, if anything, I'm going to do about "real" experience from flights as opposed to "course given" experience for things like prerequisites or assigning equivalent REWARDs.

So this theoretical additional plugin would provides some configs for "flight simulators" that when completed add a REWARD with "proficiency = mk1cockpit" in it. The plugin would ask FlightSchool for all the REWARDs active for a kerbal and the plugin would set the kerbal's level based on the current cockpit and whether the kerbal has proficiency with it.

I think a lot of the trickier ideas are going to require implementation in a secondary plugin like that, since I can't think of a good way for FlightSchool to handle every possible idea. @nightingale has more familiarity with really open ended things like that, so maybe later on down the line we can come up with a good way of handling that.

[Ser]

On 04.02.2016 at 11:43 PM, NathanKell said:

1. You can train them up (to a certain XP level) by "sending them away for training" at a cost of x funds and y time. During that time they are unusable for missions (although they can be removed from training early, at a cost of not getting the XP gain). This might be initiated automatically on hire.

2. They can be trained for a specific spacecraft and/or mission. In order for a kerbal to actually control a vessel in a given situation they will need to be trained on it (for some time period), and that training wears off after a time period. Or, if you go the bonus instead of penalty route, they get a bonus during the period, but can still always control everything. Or some combination. This will obviously need to vary by part and by situation, ideally including speed ranges (<250m/s, <1000m/s) and flying low/high/spacelow/spacehigh per body, and that affects training time and cost. Different AC upgrade levels can affect what options are available. Tourists would come trained for their requested environments (so controls don't lock), although they would still not be a source of control themselves.

 

I've been thinking abut that for a long time too. My suggestion is to replace Super-Mario-like disgusting XP system with the one that is closer to reality: Kerbals just have stats of practical (in-flight) hours and ground training hours which may consist of theoretical classes and G-training. In a mission a kerbal's ability to do something is determined by those hours of experience but with some random variation. You should never tell the exact amount of training. A kerbal sitting on Kerbin for too long may gradually loose his training. But I don't know how to disable the stock XP system.

EDIT: kerbal's stupidity may be given a practical purpose if used as a modifier to a kerbal's training rate.

Kerbal training for a mission:

That should encourage you to always train a spare team, like IRL. Random events might be added, like inability of a team member to go on a mission. Amount of training could depend on a mission size (e.g. number of specific parts in a vessel) But there's a trouble I'm still thinking of: how to determine that a vessel still represents the mission same as the crew has been training for? I mean, you can build a small vessel, train a crew and then add much more parts to it. After that it stops being the same vessel (mission), but the crew is still trained for it. Think that could be solved by having a "training volume" for each part and each trait (scientist amount, engineer amount, pilot amount). So if you add two large engines then you have to do much more training for a pilot on this mission, and for engineer also. If you add a ton of science experiments, you'll have to train your scientist hard. Thus we can have a number that represents ability of each kerbal to do a certain job. For example, scientist's ability to do science = personal_science_training / total_amount_of_science_training_required_for_ a_vessel.

Something like that.

 

 

Edited February 16, 2016 by Ser