Rodhern

Splendid idea! The problem with OnGameSettingsApplied was that it wasn't always triggered, but if onGameUnpause is (and it sounds plausible that it is) then that is a very good work-around. In my particular case I don't think it is important to know if the difficulty settings panel was actually opened, so even if it fires onGameUnpause a bit often that is fine by me.

If you accept the contract usually there is a long time to expiry after that, At least that used to be the case (I haven't played much KSP lately). How short of a deadline do you see?

Hmm. I just tried overriding the OnSave method. It seems to me, if for instance I am in the Space Center scene and change the custom settings, OnSave is not called when I click 'Apply'. Does it work for you?

Ahh, thanks. I hadn't even considered using the OnSave of the CustomParameterNode. Sounds like a good idea.

It is possible to accept in-game changes to custom difficulty settings, and not have OnGameSettingsApplied fired. @Gotmachine already reported it here issue 13591. It can, IMO, be a major gotcha. How do you solve this catch? Do you build in a mechanism in your custom parameters to 'broadcast' when the settings are changed? Do you ignore that particular case (the 'close' button option)? Or something third?

The exact thing is that I was debugging like this sprintf "%A" game where "sprintf "%A"" is F# compiler magic for formatting all of the field values of the object to a string. You can think of it as an enhanced version of .ToString(). I think I have been able to recreate the crash with this (simpler) C# code: [KSPAddon(KSPAddon.Startup.SpaceCentre, true)] public class Class1 : MonoBehaviour { void GameStateSaved (Game game) { Debug.Log ("Call .ToString():"); Debug.Log (game.ToString()); } void Start () { GameEvents.onGameStateSaved.Add(GameStateSaved); } } At least I think that is the offending code bit.

When using the GameEvents.onGameStateSaved my callback gets passed a Game object. I think that if I inspect the Game object too thoroughly I trigger an additional call to .onGameStateSaved, potentially leading to an infinite loop. Has this caught you off guard too? Do you happen to know which part of the Game object it is that I should keep my palms off?

Always trust your instruments

First the caveat: Like @JeffreyCor I don't know either if it is simple or difficult to make. That said, I think your idea of tracking tech node bonuses could be fun in-game; possibly even more fun than the per part experience bonus we are used to.

When is GameEvents.onGameStatePostLoad called? I don't see my callback being called. Edit: Maybe the solution is mentioned between the lines here, that the callback is (only) for reverted flights?

Perfect? In every way? Even the nav lights? (just teasing of course)

Thank you, @IncongruousGoat, for the detailed explanation. Heh-heh, turn off heat-effects ('cheat') and use a service bay with nosecone and fins. Sounds fun even if I am not able to myself. It does have kind of a Jules Verne ring to it, I think. P.S. If you get apoapsis high enough the jet-pack should easily raise the periapsis. Maybe we will see some kind of crazy vertical cannon shot.

I don't know about a Kerbal as is, but let us assume some kind of non-symmetric aerodynamic shape (say a fin on the backpack) and the ability to control the Kerbal's attitude (mono-propellant). Wouldn't it then be theoretically possible to trade vertical velocity for horizontal velocity (in some possibly weak proportion)? My instincts tell me, that would make it (theoretically) possible to achieve a periapsis strictly higher than the cannon elevation. So I guess I have two (and a half) questions: Is there, theoretically speaking, a flaw in my above 'logic' / hunch ? Can a (solo) Kerbal change his or hers trajectory in free atmospheric flight. I imagine the 'thruster' pack should do the trick, but maybe the Kerbal won't be able to leave 'tumble mode' ? Is the Kerbal shape such that it is possible to get an aerodynamic force (lift / drag) in any other direction than exactly opposite of the movement ?

KAPOIN A mod to track the progress of your career game. Kapoin is an unusual mod in the sense that the mod does very little in itself. Kapoin uses other mods to check which milestones you have reached in your career game. The milestones can be a certain number of ribbons awarded in Final Frontier; a number of Kerbal Construction Time points accumulated; to survey given celestial targets by performing SCANsat scans; to bring a Planetary Dome to a surveyed location for further analysis; to ship a particularly important sample from A to B in a Module Manager modified command pod; and stuff like that. So far I imagine maybe six milestones. Once the milestones are reached you know you conquered early KSP career game. The intention is that after the last milestone is reached the career game is so far advanced you are able to play scenarios like the DERP challenge (which was one of the challenges that made me think Kapoin thoughts). The mod does not really do anything you could not have done yourself by role playing through a mission challenge. On the other hand, maybe a mod can improve the immersion and mission challenge fun. MOD STATE (pre-alpha) Kapoin is work in progress. In its current state it is not much more than an idea. The license conditions for Kapoin are all rights reserved with some exceptions. Downloads of Kapoin pre-experimental versions will possibly, at some point, become available on Spacedock and/or Github. The Kapoin source code repository is hosted on Github. I plan to use the Github ticket system as well. Contributions are welcome. If you want to contribute, post a message below or send a PM. The Kapoin project needs milestone definitions, icons, custom flags, mission design, mod code, play testing, documents and much more. Happy new year Rodhern

When/how to proper call: Game.AddProtoScenarioModule (MyScenarioModule, SomeGameScenes) . This is approximately the life of a custom scenario module (as far as I can tell): When I call Game.AddProtoScenarioModule I can add, say, "MyScenarioModule". The module is added to the game right away, so far so good. When the scene is changed (exited) the module will be included in the .sfs file. When the next scene is loaded OnLoad is called to take care of what ever I need to take care of. When the scene is then changed again (exited) OnSave is called. At this point the .sfs file is all up to date. The idea that I just have to call AddProtoScenarioModule in-game once and in the future KSP sees from the .sfs file that it should load up "MyScenarioModule" is nice. The issue I ponder, is the 'delay' from you first add the scenario module (some time after the game is first spawned) and until the .sfs is updated with all saved values (after two scene changes) . How do you prefer to handle that?

If you are able to use mods I think Kerbal Alarm Clock might show the date and time.

@Gordon Fecyk: Good to see that you got your game installation fixed. Nice video, I like that you left in failed attempts too - particular the first one, racing along the Kerbin sea at tremendous speed, horizontal at 4 km. I couldn't help think where is this rocket going? Good fun. This challenge got a teeny bit harder in version 1.2.1 so your score is 37.66 %. You are currently in second place - well done. B.t.w. This challenge does not have one of those 'max one entry per player' type conditions. Feel free to try out new ideas and come back later and improve on old scores. (I will filter the results so that the same player is only listed with his or hers best result in the vanilla leader board though).

Hello, I have updated the scoring to fit KSP version 1.2.1. The changes turn out to be pretty insignificant. The Kerbal 1-5 have lost some engine performance (compared to KSP ver. 1.1.3) but is considered more aerodynamically streamlined now. As a result, the straight vertical ascent is a few seconds faster, which almost cancels out the degraded engine performance. @Eidahlil: Maybe the structural parts and the engines on this relatively basic level orbiter cannot handle a higher thrust setting. I imagine that even the 100 % setting on an RT-10 signifies the point just before breaking the thing. @JAFO: Is GravityTurn up and running for KSP ver. 1.2.1? In that case maybe you want to fly a ver. 1.2.1 entry (at least once without the launch clamps).

Steam just downloaded version 1.2.1 today. Seems you are right about the gravity. The Kerbin sea level gravity acceleration is back to exactly 9.81 m/s2.

So, we arrived at “Kerbin G 121”. Note: Data valid for KSP version 1.2.1. Let us run through which of our parameters have changed from version 1.2 to version 1.2.1. Radius of all bodies unchanged. Periapsis, apoapsis and inclination of orbits unchanged. Gravity changed (increased by a factor of 9.81/9.80665 for all bodies). Rotation period was changed for Kerbin and all moons except Gilly and Minmus. First lesson The g0-value, representing the surface gravity at Kerbin, is (again) exactly 9.81 m/s2. Second lesson The new Kerbinational standard unit for gravitational acceleration is one Gee, which is 9.80665 m/s2. This means that the (sea level) surface gravity on Kerbin is more than one Gee. Further lessons I haven't added any tables this time. If anyone misses the course material tables, leave a comment, and I might just add a table or two.

KSP version 1.2.1 is here. The Kerbin gravity changed (again). I will at some point update the OP. Future entries are supposed to be flown in version 1.2.1.

Thanks.

I think I remember that it was possible to award KCT build points from other mods. I have forgotten were I saw that, and a few forum searches didn't help me. If one of you remember how, could you post a link, tell how it is done or quote a code example. Thanks.

@Gordon Fecyk: Is it a GOaP entry or a vanilla one? If it is a vanilla one I think something have gone wrong; the Kerbal 1-5 is supposed to have an initial TWR below 1 [edit: when the main engine is off] until at least some booster fuel is burned. @tg626: Thank you. I am willing to call that a stable 80x80 orbit. I am not trying to pick on you, but to me it is a little bit disappointing to see a few meters of periapsis missing. The scoring method allows periapsis between 80 km and 100 km. The idea was to avoid forcing a bang on circularization. I realize that there is some advantage to do an exact 80x80 orbit; that is intentional on my part. Feel free to submit new entries - maybe you can even improve on your current score. P.S. I am not updating the OP leader boards at the moment, I plan to get to that at some point, maybe next week, but possibly even later.

I think you might have confused oxidizer and liquid fuel. 42.23 units of LF Is still a lot though