NathanKell

since SolverEngines doesn't check compatibility, you have other problems.

Yes, stock now supports enabling surface-attach crossfeed for STACK_PRIORITY_SEARCH, and therefore I have not updated the mod.

@CitizenVeen use Ship Manifest to transfer science.

I know at one point we were looking at forking the FS bits and putting them in AJE, so maybe ping @blowfish ?

Uh, he means the Win x64 hack. Linux x64 is an official stable build of KSP, and AFAIK all mods are compatible with it, including this one. @TranceaddicT

@magico13 the discussion over on the other thread reminded me about this. One FM I'd love to see--and I think I may have mentioned this before on KCT's repo? Can't recall--is an upkeep cost based on the number of KCT upgrade points invested. That's because RP-0 effectively treats the point total as your space program workforce, and workers gotta be paid. That might, however, also require an ability in KCT to remove upgrade point. Same with a general facility-tier based upkeep system. Another good FM, and I'm pinging @Peppie23 here, would be Remotetech groundstation upkeep costs. Now, that would ideally require an ability in RemoteTech to purchase-unlock new groundstations, which IIRC has been planned for a while but is not, AIUI, done yet?--since otherwise it would just be a fixed cost per year for everybody. Or until that point, maybe base RT stations available on tracking station level, and the FM base on that. I am reminded of that because I love the idea discussed in the OP of simulating real life's "dish time" issues and the expense of continuing a mission based off DSN use. That said, I think that the dish time concern needs a counterpart: capcom time, as it were. Human spaceflight missions require far more in the way of communications (and other groundside support) than uncrewed missions, and that should be reflected in the mission costs.

@StarStryder I wouldn't expect a cockpit rated for only Mach 2.5 flight to survive reentry, no matter what you slap under it.

@MoeslyArmlis sure! That means it will look visually choppy, but your gametime will be closest to realitme. Moving the slider to the right means things will "look" smoother, at the cost of things happening slower (game time becomes slower than realtime). Of course, all this is assuming I understand the Unity docs right.

>.> QA format. My response just got an upvote and is now out of sequence.

@MoeslyArmlis yes, we are. Physics updates run on a fixed game-time timestep (20ms), or, if using physics warp, 2x, 3x, or 4x that value. Visual frames run on a variable timestep, based on how much has to be done. As the time between visual frames grows longer, more and more physics frames are run. That setting effectively determines the number of physics frames that can be run per visual frame before the visual frame is rendered and you go on to preparation for the next visual frame. The accuracy of the underlying physics does not change at all. What changes is how often there's a visual snapshot of the physical reality. EDIT: Example. Say each physics frame takes 5ms to run. That means, for a (visual) framerate of 50FPS, you have 15ms per frame to spend on other things (including rendering the frame). Now, for a visual framerate of 25FPS, you need to run 2 physics frames per visual frame, and let's say now (slower computer) each takes 7ms to run. That leaves you with 26ms to render the visual frame and do whatever else needs doing. With the slider all the way on the right (EDIT: Left, in modern versions of KSP), that's saying you can have a maximum of 1.5 (0.03s = 20ms x1.5) physics frames per visual frame, which means the game can no longer run in realtime; it has to slow physics (game time) down so it can maintain <= 30ms of ingame time per visual frame. necro-edit: see this excellent modern recap by @damerell

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).

@MoeslyArmlis I am saying it has literally nothing to do with the game setting. Because the game setting does not, and never will, affect physics timestep--that would be horrific.

@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.

FAR is required for RO.

@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... )

It's a longstanding CKAN bug with sometimes 'Recommended' mods not auto-installing. But we can't set RO to require RSS, because if we do then you can't install 10x Kerbol and RO at the same time with CKAN. Tagging @pjf

Uh...I'm pretty sure none of that is right. The value that is set is this one. The larger that value, the slower your visual FPS can be (but the closer to realtime physics will be); the smaller that value, the slower game time will be compared to realtime, but you'll have a higher visual FPS. Remember, physics frames aren't the same as visual frames.

@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.

@Matuchkin ServiceModule, like any other tank, can hold as many resources as you like.

@g00bd0g under what conditions?

EDIT: @g00bd0g please don't crosspost. We *do* check both threads you know.

@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.

Just posted an idea that's designed for RP-0 but relevant to stock career too. If you like RP-0 (and like BARIS), please read it and post your thoughts on that thread. http://forum.kerbalspaceprogram.com/index.php?/topic/131381-requestidea-kerbal-training-and-other-time-based-kerbal-mechanics/

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?

@Whitecat106 just a friendly poke re: RP-0--you still interested?