Aelfhe1m

A couple of bugs crept into the last release that came to light when I began implementing the next feature so: Version 1.2.4.12 released Add settings window option to Auto Hide UI when taking screen shot. (Caution do not use this with other mods that also auto-hide the UI) Extend maximum configurable setting for Time to remember action to 10s following additional play testing. Fix issue #5 - Action text persists longer than configured Fix issue #6 - TEXT_LIST generating ArgumentOutOfRange exceptions just after lift-off The auto hide UI is in response to @tg626's message earlier this month and original mod's planned features list (next up layout inheritance).

Version 1.2.4 released Add new elements: ACTION_TEXT: conditional message when abort, stage or action group pressed TEXT_LIST: random or sequential list of messages to display based on situation Added `EvaOnly` property toggle to `SITUATION_TEXT` and `TEXT_LIST` Added `Clambering`, `OnLadder` and `RagDolled` situations to `SITUATION_TEXT` and `TEXT_LIST`. Add settings window fields to customise Kerbal day and month names. Add settings window slider for `Time to remember action` See README for full details.

That's a setting in Filter Extensions. In the main space centre view click the "black square" icon on the toolbar and unselect "Hide unpurchased parts"

Haven't tried it but I did come across ShipConstruction.RecoverVesselFromFlight() the other day while I was poking around looking for something completely different.

Thanks that was the missing piece of the puzzle: var kerbal = FlightGlobals.ActiveVessel.evaController; if (kerbal.fsm.currentStateName.StartsWith("Clamber")) { // something }

Did you put them in GameData/FASA/Misc or directly in GameData? The former works for me.

I'm trying to find a way to detect if a Kerbal is in the act of clambering/climbing over/up something at a particular instant. I found the KerbalEVA module easily enough and that lets me detect if they are holding on to a ladder or rag-dolling. It also has a number of methods and properties related grabbing and clambering but I can't seem to find a way to use any of them to detect an in-progress clamber. Does anyone know how this can be done or point me in the direction of other classes/properties that could be useful?

Not quite ready for release yet, but I modified TEXT_LIST to allow lists to be specified for each situation. If no matching list is found it uses the "Default" list (and if that's blank then no message is displayed). I also extended both TEXT_LIST and SITUATION_TEXT to have and EvaOnly option (values: true, false, either (default)) and special EVA situations of "RagDolled" and "Climbing". Example: For the moment climbing only works with ladders but I'm trying to find how to detect clambering as well.

After some experimenting, I've added a <StageNumber> parameter and two new top level elements to my dev build. 1) ACTION_TEXT: The message would be displayed on every screenshot after the action key was pressed until a configurable time-out elapsed. Pressing the key would not take a screenshot itself (that's more Automated Screenshots and Saves' territory) just queue up the appropriate message to be displayed. Like SITUATION_TEXT each message would be richtext and support all the parameters of a standard text entry. 2) TEXT_LIST: An arbitrary long list of messages (same format as TEXT again) that will display in sequence or randomly. Optional parameter to reset to start of list for each new vessel launched. Example: I'm not sure about the timed message list. It would certainly be do-able with a list of MET, message pairs but even with some sort of fudge factor around the time it would likely take several practice flights to pin down the correct timing of the messages. Perhaps instead a variant of TEXT_LIST where the message advances when a given key is pressed?

You need to reference the appropriate KSP DLLs from <KSP>/KSP_DATA/Managed (Assembly-CSharp.dll and UnityEngine.dll at a minimum - other DLLs may be needed depending on project type). See the /reference documentation on the page you linked. But it's much easier to use an IDE as @Snark says. If you don't want to use Visual Studio for whatever reason then Xamarin Studio is also available in a free version.

Version 1.2.3.1 released: Revert persistence model to config file format and set save path to GameData\KSEA\Historian\Plugins\PluginData Fix: BUG - multiple layouts overlaying each other Fix: BUG - semi-transparent rectangle elements becoming increasingly opaque over multiple screenshots Fix: potential problem with configuration window id clashing with window ids from other mods. Thanks to @Enceos for pointing me to the correct path to get Module Manager to ignore config files (I'd done some failed testing with PluginsData but that extra 's' was falsifying my results.) Thanks to @ZobrAA and @rasta013 for the bug reports. The leftover scenario module in persistent.sfs will cause a few extra debug messages to appear in the log file but these are harmless as far as I can tell. If you wish to "clean" your save file to remove this look for and carefully remove the section:

Warning, I'm not an expert in this but below is based on some of my findings from experimenting with KSP mods. Simple example of an editor window using "old" immediate mode UI (omits the code you'd need to add to wire it up to an app launcher button in the editor): public class Editor { Data data; int windowId = 12345555789; // some random unique number public void Draw(Data myData) { data = myData; var position = new Rect(0.5f * Screen.width - 200.0f, 0.5f * Screen.height - 250.0f, 400.0f, 500.0f); // location and size of editor window position = GUI.Window(windowId, position, OnWindowGUI, "Window title", HighLogic.Skin.window); } void OnWindowGUI(int id) { GUILayout.BeginVertical(); // main text box row GUILayout.BeginHorizontal(); GUILayout.Label("Main title"); // label for row GUILayout.Space(20); data.MainText = GUILayout.TextField(data.MainText, GUILayout.Width(200); // show current value in text box and store it back into data when changed. GUILayout.EndHorizontal(); GUILayout.Space(10); // padding between rows // create other rows in loop if (GUILayout.Button("Save", GUILayout.Width(100.0f))) { // save values of data to permanent locations. } GUILayout.EndVertical(); } } If you've created a custom part module and used a Module Manager config to add it to all crewed parts then you can get a list something like: var parts = EditorLogic.fetch.ship.parts.Where(p => p.CrewCapacity > ); foreach (var p in parts) { var myMod = p.FindModuleImplementing<MyModule>(); if (myMod != null) { data.ModuleParts.Add(myMod); } } Provided your module has a persistent field for the value(s) you want to set then any value you save to that field will be saved to the craft file when it is created. I believe you can access the ship name and description through: EditorLogic.fetch.shipDescriptionField.text = "Some description"; EditorLogic.fetch.shipNameField.text = "Some name";

Just a quick note that Historian has now been updated to persist config settings to the main save file rather than a .cfg. On first run it will delete the old Historian.cfg if present then should not affect Module Manager cache on subsequent loads.

Version 1.2.2.11 released: Change persistence model for configuration settings to use game save files rather than a config file in GameData. NOTE: Starting a new save will set configuration to default values. Reverting a flight or quickloading may load an older version of the configuration if you've made recent changes. Apparently putting settings file into "Plugins" folder did not prevent it from interfering with Module Manager config caching. I've rewritten the settings code to save directly into the save game file instead. Thanks @Lewtz for pointing out it wasn't working as intended. There will be a one off impact on Module Manager as it deletes the old configuration on first launch but subsequent launches should not affect Module Manager's cache.

You need to compile the code to get a new BurnTogether.dll. Then extract Burn_Together-alpha_7.0.zip (if you don't have it Google for it) and replace the DLL it provides with the new one. If @BahamutoD doesn't mind I could post a recompiled DLL (or even the full zip). NOTE: I have only done the minimum of testing with this so far and have no idea how you would go about fixing the issue with rovers. PS: forgot to enable RCS on my test space probes before. With it enabled station keeping became effectively perfect even after warping for many days with various random course correction manoeuvres.

Thanks for spotting that @ZobrAA This is the same issue that affected crew trait colouring in 1.1 pre-release. Bug fix version 1.2.1.14 now released Regression fix for `DateFormat` Added fixed(?) AVC version file

It was only partially working so I've pulled it until I can get around to doing it properly - probably next release.

Version 1.2.1.9 released: Add text node parameters: <VesselType> - the type of vessel e.g. probe, debris, lander etc. <RealDate> - the real world date and time formatted using the block level DateFormat setting Support for Kerbal Konstructs and Kerbin Side <LaunchSite> modified to detect most recently set KK launch site <KK-SpaceCenter> - the closest detected "space center" <KK-Distance> - the straight line distance from the closest detected "space center" Setting added to main configuration dialog for "Default space center name". Will replace "KSC" in `LaunchSite` or `KK-SpaceCenter` parameter results. (suggested by @ZobrAA) NOTE: only replaces the value if "KSC" is the full return value. "KSC Launch pad", "Kerbal Space Center" or similar results will NOT be affected `TEXT` and `SITUATION_TEXT` elements can now specify a `Font` property for the name of the OS font to use to display the element. NOTE: font name must EXACTLY match OS font name. A utility parameter `ListFonts` is supplied to list the names of all installed fonts. "Historian.cfg" moved to `<KSP>/GameData/KSEA/Historian/Plugins` folder to avoid interfering with Module Manager caching. Current version number displayed in settings window title bar General code clean-up and refactoring

@Aurelius Try: @PART[probeStackSmall]:HAS[!MODULE[MechJebCore]]:Final { ... } The Advanced Inline Stabilizer (advSasModule) does not have a ModuleCommand module so the second patch will never be applied. Since you can't control a craft without at least one ModuleCommand part (AFAIK) does it even make sense to add MechJeb to it?

The code on GitHub can be recompiled against 1.1.2 with just one tiny edit to line 99 of utils.cs (and referencing the 1.1.2 DLLs in KSP): var angularVelocity = Quaternion.Inverse(vessel.ReferenceTransform.rotation) * vessel.rootPart.rb.angularVelocity; Limited testing shows rovers are very flaky (probably because of changes to the wheel physics) but two spacecraft in orbit moved in (relative) synchronicity over a series of manoeuvres (total delta-V expended 842 m/s, change in relative velocity 0.58 m/s, slight ignition timing differences mostly to blame). No exceptions from BT in output_log.txt.

Another thought. Contract Configurator already has code for tracking vessels used in contracts. If you were willing to take a dependency on it then maybe Nightingale would be willing to add launch location tracking as well?

It doesn't seem to be recorded in the persistent.sfs file so probably not. However a small module could hook up an event handler and detect a change out of prelaunch and then save the launch location and ship id off to some custom storage (either a config file or into a scenario block in the save).

As a quick test I edited one of the Kerbals in the roster section of the persistent.sfs to have "trait = MissionSpecialist" and added the following block to the end of traits.cfg: EXPERIENCE_TRAIT { name = MissionSpecialist title = Mission Specialist desc = Does specialised duties on missions. EFFECT { name= RepairSkill } } When viewed in the astronaut complex after loading the game that crew member showed up as "Mission Specia". The space in the portrait in flight was even more limited displaying just "Mission". So it can be customised but there's a hard limit on the length of name that will display.

@tg626 Initial testing for Kerbal Konstructs and Kerbin Side. Album here: http://imgur.com/a/EIw4v Initial finding: my laptop hates the current version of Kerbin Side. The lag is awful. I don't remember it being this bad last time I used Kerbin Side in a career game back in 1.0.4. More seriously. There are various different values that I've been able to extract from the Kerbal Konstructs mod relating to location. The three main "useful" ones I narrowed down to: Launch Site - the last launch site set via the KK button in the SPH or VAB prior to launching a vehicle Nearest Space Center - detects the closest "marker" denoting a launch/landing location (usually a helipad or runway. Launchpads don't seem to be marked for some reason) Distance - the straight line distance to the closest "marker" Note: the "markers" are point locations which means that one end of a runway may be at the marker but the other end may be closer to another marker (e.g. helipad). Note 2: switching vessels using [ and ] may give unexpected results (see images). Barring any huge problems found on additional testing I'll roll this into an official release in the next few days. Edit: if this does get rolled into the next release then KK-LaunchSite (shown in the test images) will be merged with the existing LaunchSite parameter but KK-SpaceCenter and KK-Distance will be kept (although I'm open to suggestions for better parameter names)

Good suggestion and easily added. It will be in the next update. As far as I know Historian has never auto-hidden the UI (it's in the original mod's OP as a "future enhancement"). However since I know it's done by Automated Screenshots & Saves it should be easy to find out how to do it and add it as an option. Maybe not for the next update though. The LaunchSite parameter is currently only for KSC Switcher launch sites (I added it to support my Realistic Progression Zero play through). I can look at Kerbal Konstructs and see if/how it exposes the site information. Based on your screenshots it seems to be modifying the Vessel.LandedAt property. I'll look into this further and if it's consistent then I'll update LaunchSite to use that info when KK is installed. Edit: based on the way that Historian evaluates LandingZone it might also be a custom biome so I'll check for that as well.