Jacke

So KSP is supposed to be modding friendly, which means when it does that checkpoint it later reloads for the Undo, it should provide a hook to mods to allow them to save their state. And then when it does the Undo, provide another hook to signal to mods to revert their own state. But if it doesn't offer these hooks correctly.... Wow, best of luck with that, Diazo. As a stopgap, what about AGExt controls in the editor to manually reload its state from the AGExtEditor.cfg file? Won't be perfect and will still likely need some manual action corrections, but at least it'll allow the Undo function to be used with AGExt with only a little overhead.

Considering what happens if you set the part down and hit Undo (you have the part you pulled off and a duplicate where it was), that's reasonable. The actions associated with the part would have to be fixed manually. Unless it was a stock group (gear, lights) that get parts automatically. In my demo, it was a landing leg that wasn't a part of any AGExt action group but just the stock gear action group. All AGExt actions were being cleared. Somehow the Undo actions leads to something that ends up with AGExt not thinking it has any defined actions. Don't know if the outcome would be affected by what groups, AGExt or stock, the part being moved is a part of.

Tested it out and indeed BTSM actions now saved. Thanks, Diazo. At least with the Undo bug, if people are aware of it they may not suffer a gotcha from it.

I discovered another bug (couldn't find it in a search of the thread). The VAB editor Undo function (Ctrl-Z on PC) wipes all AGExt actions. Also, more BTSM "AGX Load Action ambiguous. Count: 0 Module: BTSMModuleScienceExperiment BTSMDeployExperimentAction" and inability to save BTSM Goo experiment actions to slots 11 and higher (some of these may be duplicates you already know about, Diazo). Output_log.txt is here. Steps I did during this log: 1. Starte KSP, load BTSM sandbox game, enter VAB. 2. Load small .craft with AGExt actions. Got "AGX Load Action ambiguous. Count: 0 Module: BTSMModuleScienceExperiment BTSMDeployExperimentAction" 3. Note that AGExt slots 12, 13, and 14 have labels but no actions. Correct each of them to Expose 1 of the 3 Goo experiments. Save the file. 4. Reload same small .craft file. Again got "AGX Load Action ambiguous. Count: 0 Module: BTSMModuleScienceExperiment BTSMDeployExperimentAction" 5. Note that AGExt slots 12, 13, and 14 still have labels but no actions. 6. Note that AGExt slots 1, 2, 3, 10, and 11 have labels and actions. 7. Make a "mistake" and accidentally pick off a landing leg. "Realise my mistake", discard the landing leg I'm holding, and type Ctrl-Z for Undo. Landing leg is back. 8. Note that all previously assigned AGExt slots, 1, 2, 3, 10, and 11, now only have labels, no actions. 9. Typing Ctrl-Y Redo removes the landing leg but those AGExt slots still only have labels, no actions. 10. Reload same small .craft file. Was distracted and didn't note if there was an "AGX Load Action ambiguous" message. 11. Reload same small .craft file. Again got "AGX Load Action ambiguous. Count: 0 Module: BTSMModuleScienceExperiment BTSMDeployExperimentAction" 12. Changed mode to Action Group. Type Ctrl-Y and then Ctrl-Z. No apparent change. 13. Changed mode to Parts. Type Ctrl-Y and then Ctrl-Z. No apparent change in AGExt information. 14. Removed bottom LV-420 engine and then replaced it. Type Ctrl-Y. No apparent change in AGExt information. 15. Type Ctrl-Z. AGExt information all blanked except labels. 16. Exit VAB, game, and KSP.

Appreciate your quick patch releases, Diazo.

D'oh! I'd changed the name of a .craft outside of KSP, to the filename and the internal 'ship' parameter, from "1-A-W1 Kerbin AW" to "1-A-W1 Kerbin W". I will have to do that inside the game to get it right.

Diazo, thanks for all your attention. I agree with Pecan that you may want to rest up prior to KSP v0.25 becoming live. (I've already backed up KSP v0.24.2.559 from Steam to a separate directory and am running on it so I don't get hit with an unwelcome change before major mods are migrated. It's wonderful you can do that with KSP. ) However, I though I should let you know I've found that the method you suggested for transferring AGExt info for copied .craft files between savegames doesn't quite work, at least for moving between a sandbox game and a full-career game. I don't know if this is related to the Action ambiguous report I PM'ed to you earlier. From monitoring the AGExtEditor.cfg file, after copying the stanza for a rocket from the sandbox game to the full-career game while neither are loaded, going back into the full-career game and loading the copied rocket leads to the AGExt stanza being deleted for it, leaving the action names being blanked but the actions being present (at least the 2 I'd set in the first 2 slots). Fairly easy to fix this manually with just a few actions for now. As far as I can tell, for the same design with the same AGExt settings, the only difference in the AGExtEditor.cfg file stanza is the VAB# and the value groupVisibility, which differs between the sandbox game and the full-career game. VAB494565458749327510111498105110326587 { name = 1-A-W1 Kerbin W currentKeyset = 1 groupNames = ‣001Temperature‣002Pressure groupVisibility = 1011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111 groupVisibilityNames = Group1‣Group2‣Group3‣Group4‣Group5 PART { name = sensorThermometer vesselID = 0 relLocX = -1.889666E-08 relLocY = 0.5908403 relLocZ = -0.2161526 ACTION { group = 1 activated = 0 partModule = BTSMModuleScienceExperiment actionGuiName = Log Temperature actionName = BTSMDeployExperimentAction custom1 = Log Temperature } } PART { name = sensorBarometer vesselID = 0 relLocX = -0.4441701 relLocY = 0 relLocZ = 2.64746E-08 ACTION { group = 2 activated = 0 partModule = BTSMModuleScienceExperiment actionGuiName = Log Pressure Data actionName = BTSMDeployExperimentAction custom1 = Log Pressure Data } } } VAB4945654587493275101114981051103287 { name = 1-A-W1 Kerbin W currentKeyset = 1 groupNames = ‣001Temperature‣002Pressure groupVisibility = 1011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111 groupVisibilityNames = Group1‣Group2‣Group3‣Group4‣Group5 PART { name = sensorThermometer vesselID = 0 relLocX = -1.889666E-08 relLocY = 0.5908403 relLocZ = -0.2161526 ACTION { group = 1 activated = 0 partModule = BTSMModuleScienceExperiment actionGuiName = Log Temperature actionName = BTSMDeployExperimentAction custom1 = Log Temperature } } PART { name = sensorBarometer vesselID = 0 relLocX = -0.4441701 relLocY = 0 relLocZ = 2.64746E-08 ACTION { group = 2 activated = 0 partModule = BTSMModuleScienceExperiment actionGuiName = Log Pressure Data actionName = BTSMDeployExperimentAction custom1 = Log Pressure Data } } }

I'm still getting this bug, but further investigation has discovered new information. It still exists under AGExt v1.16b. But it's not just a save issue. I loaded that craft and recreated the actions groups 1 and 11 through 13, 1 being Mk1-2 Crew Report, 11 being Aviation Lights nav lights' toggles, 12 and 13 being for the RW for the Mk1-2 command pod, Activate RW and Deactivate RW respectively. All 4 show as green on the list of action groups. I go Launch and (because of KCT) select Simulate. Only groups 1 and 11 show on the AGExt list. I exit out and see this on the screen. Names for groups 12 and 13 show but no actions. But here is the AGExtEditor.cfg stanza for the rocket while the game is still running. See that ACTION code for those actions 12 and 13 still appear, even though they appear to only have a name in the editor interface. And here is the AGExtEditor.cfg stanza after the game exits. Note those ACTION codes are now gone. Here is the output_log.txt for this run (also contains copies of the screenshots and the 2 .cfg stanzas).

The source of KCT would have to be checked, but from watching KCT off-world simulations, I see them momentarily spawns on the pad, then the craft is shifted to either the target surface or orbit, sort of like HyperEdit, which also starts on the pad but gives you tools to shift your spacecraft.

Diazo, I download and installe the AGExt.dll in this post's original form at 10h00. That .dll fixed the wiping-KeySet1 bug. I suggest you put a patch number on these .dll's, Diazo, either in the name or in the internal metadata (Windows says they're all version 1.0.0.0). Right now I'm going by the modify time of your post that I use the download link from. Right now it's last modified time is 13h01, but to tell if that .dll was different from the one at 10h00, I'd have to do a binary compare. When copying a ship .craft from one save to another, I noticed something that can cause a bug. When a ship design is deleted, the section in AGExtEditor.cfg isn't deleted. If a .craft file with the same internal name ("ship = NAME") is copied into the VAB, but the section in AGExtEditor.cfg isn't adjusted, when the .craft file is loaded, the resulting AGExt action groups get their names from the AGExtEditor.cfg file but their actions become the union of the AGExtEditor.cfg file and what's in the .craft file (likely the default first 1 Action Groups, or maybe your other AGExt .cfg files in Ships). I suggest if possible, you find a way to delete the AGExtEditor.cfg sections when a .craft file is deleted (assuming Squad gives you a hook to do so ).

Went to Settings, saw Custom Action 1 through 10 were assigned to Alpha1 to Alpha0. Exited KSP, restarted. In Settings still assigned. Load game, go into VAB and load last rocket, KeySet1 now has correct Alpha1 to Alpha0 assigned. Exit game, check AGExt.cfg, KeySet1 string is correct. Exit KSP, restart KSP. Check AGExt.cfg, KeySet1 is blank again. Don't change it. Load game and then rocket, in game KeySet1 is empty, in AGExt.cfg KeySet1 is blank. Exit VAB and game, check Settings, Custom Action 1 through 10 are unassigned. Exit KSP. Output_log.txt is here. Okay, colour me confused.

Thanks for working on this, Diazo. Have another couple of issues. First, all 5 keysets are labeled "KeySet1key1" and that is apparently from the GameData/Diazo/AGExt/AGExt.cfg in your current download. Second, whenever KSP starts up, it blanks the value of "KeySet1" in that same AGExt.cfg file in the KSP directory tree. Currently I'm fixing it externally by copying the value from KeySet2 after KSP starts up (faster than setting the 10 default values individually) as AGExt appears to reread that file when going into the Editor.

With EditorExtensions, the TAB key allows you to design in the VAB yet have your design launched on the runway, and similarly design in the SPH and launch on the pad.

Thanks, Diazo! And good luck with sub-assemblies, because I've been stung in the past by them and I wasn't even going near doing the no-no: symmetry of a sub-assembly with symmetry. So I now use SelectRoot and EditorExtensions and just rebuild craft.

And toadicus already has a fix out. That development VOID.dll version 0.14.1.36692 fixed the bug; no more duplicate VOID stock toolbar icons. Thanks for the quick response, toadicus!

That development VOID.dll version 0.14.1.36692 fixed the bug; no more duplicate VOID stock toolbar icons. Thanks for the quick response, toadicus!

Diazo, if we're trying to transfer a design from one saved game to another, as edited in the Editor, do we have to transfer the AGExtEditor.cfg file as well? Or more exactly, the stanza from that file for the design being moved, ie. the text "VAB...{ name = <ship in question>...}"? Or is everything in the .craft file when the game is exited?

I've discovered a bug that affects the VOID stock toolbar icon in the VAB when also using Kerbal Construction Time (KCT). Posting to both mods' threads. After first entering KCT launch simulation, exiting back to the VAB reveals an extra VOID icon in the stock toolbar. Only the leftmost one works, the others doesn't. After going to simulation at least once, every time the VAB is exited and then re-entered, whether to the Space Centre or to another simulation, there will be another extra dummy VOID icon in the stock tool bar. I've had as many as eight or nine. If I exit KSP, remove the KCT mod, and restart KSP, the bug is gone. Exit KSP, reinstall KCT, and restart KSP and the bug will appear again. Output_log.txt here.

I've discovered a bug that affects the VOID stock toolbar icon in the VAB when also using Kerbal Construction Time (KCT). Posting to both mods' threads. After first entering KCT launch simulation, exiting back to the VAB reveals an extra VOID icon in the stock toolbar. Only the leftmost one works, the others doesn't. After going to simulation at least once, every time the VAB is exited and then re-entered, whether to the Space Centre or to another simulation, there will be another extra dummy VOID icon in the stock tool bar. I've had as many as eight or nine. If I exit KSP, remove the KCT mod, and restart KSP, the bug is gone. Exit KSP, reinstall KCT, and restart KSP and the bug will appear again. Output_log.txt here.

I'm getting a similar bug in the VAB. Actions for the command pod are only save if they are in slots #1 to #10. In #11 and higher, the name is saved, non-command pod actions are saved, but not actions for the command pod. This is both when saving to a file and when exiting the VAB either to the Space Centre or to Launch. Output_log.txt is here. EDIT: I first noticed this under AGExt v1.14. Upgraded to v1.15a and it still exists.

Download link in that post is for v1.13e.

It's very nice and helpful, but I can't find documentation for HAS blocks.

Launch clamps and towers are always recovered and 100% refunded, if not manually before, automatically when you load another rocket onto the launch pad. They don't have a cost to the player like non-recovered parts of a rocket. All it matters is that the player has enough cash above the cost of the rest of the rocket to pay to put out the launch clamps and towers, as those clamp and tower costs are 100% refunded when the clamps and towers are either recovered manually at the Tracking Station or automatically when the next rocket is put on the pad to launch. It's like a cash register float in a retail business, needed but doesn't directly affect the cash flow. The reason I want their costs to be zero is make it easier to compare cash amounts at different times to measure the cash flow between rockets. Without caring whether there's clamps and towers on the pad that represent a 100% refundable temporary sunk cost. I included the Module Manager .cfg file to change the cost of the FASA launch clamps and towers to zero in the spoiler in my original post.

Really love using your launch clamps and towers, frizzank. However, could you possibly change the cost of the parts to zero? The stock TT18-A launch clamps are cost zero. And since they get recovered right at KSC, in contracts career you get all the cost back once you manually recover them (or during the auto-recover when you put the next rocket on the pad), so that cost only represents a temporary overhead. However, if you're tracking your money launch to launch to see how things are trending, you have to manually recover every clamp and tower one by one in the Tracking Station to get good numbers. Which is a pain when you have a lot of first stage engines. Thanks! Put it in your GameData/FASA/ directory to change the cost of the launch clamps and towers to zero. // MM-FASA-launch-clamps-and-towers.cfg // // Change cost of FASA launch clamps and towers to zero // same as stock TT18-A launch clamps // As they pay back everything when they're recovered // they just represent a temporary overhead // but makes it a pain to recover them to track cash flow // instead of using the auto recover on the next launch // // Include this file with mod FASA or FASA launch clamps // // 2014 Aug 24 Sun MM coding by Jacke // // what FASA launch clamps and towers // files 4 clamps and 2 towers, one per part under // GameData/FASA/Misc/FASA_Launch_Clamp_125 // GameData/FASA/Misc/FASA_Launch_Tower // parts 4 clamps and 2 towers // @PART[FASAlaunchClamp125]:Final { @cost = 0 } @PART[FASAlaunchClamp25]:Final { @cost = 0 } @PART[FASAlaunchClampAtlas]:Final { @cost = 0 } @PART[FASAlaunchClampApollo]:Final { @cost = 0 } @PART[FASAUmbilicalTower]:Final { @cost = 0 } @PART[FASAlaunchTower]:Final { @cost = 0 } // // END OF MM-FASA-launch-clamps-and-towers.cfg

If you'd just like the docking cam alone, like I do, you can look on Romfarer's list of projects on Curse to find the standalone Lazor Docking Camera.