Waldwolf

Thank you. And if you tell me what's wrong with the one I linked (which is the one mentioned in the "how-to-get-support" and was created specifically for this bugreport by running the vanilla test version reproducing the errors) I'll do better next time. Sorry English is not my first language. I'll try to remember and be more precise in the future.

Yea, I just tested that. Nevermind. I recently had an unplanned disassembly on the launchpad after I timewarped to a perfect Mun window and I don't know why, but I thought BPB had something to do with it. Probably just came out of timewarp too abruptly. But it's still good to know where the limits are. Never know how much I'll misuse the mod. I already got some idea to use it as an automatic abort for a space station. Just in case I'll dock too hard... again.

That's nice! Then I guess I'll set it to a year or ten when I actually get around to edit the save file just to be sure.

Well that's a shame. Thanks for the info I might do that for the timeout time as I usually don't want the panicbox to disable by time but just by altitude. Do you happen to know what the maximum value for that is? Just in case I timewarp on the launchpad again and forget about the armed panicbox.

I don't understand, please elaborate on this Well when you configure the panicbox in VAB, SPH or Flight you have those cool textboxes for all sliders except Neg-Vel-Limit, High-G-Limit and Max AoA, so you can enter any value you want. When you want to quickly get an exact value or just one not covered by the slider just use the textbox. When you set up the default values in the difficulty settings you have no textbox for any value. So you can't set the default values to a value not covered by the sliders like in the other window. Say I want to set the default timeout time to 900s or a disable at altitude higher than 100km I can't do that at the moment. So I'd like to know if it's possible to get those textboxes in that menu, too.

Sorry, I haven't played in a while because I'm currently writing my master's thesis but my problem was solved in the versions before. And I found a new bug. When you don't have the applauncher button activated and you click on the paw button in flight the window opens and only the "Activate" button is visible. The rest of the window is completely empty so you can't change anything and to exit you have to click the paw button again. This does not happen when you active the the applauncher button nor when you only activate the applauncher button. Something else that's strange in my opinion is that the default values for AoA and abort deactivation on altitude are not used when you reset the PanicBox to default values. No matter what is set when you click the "set to default button" those sliders will not be changed. Also is it perhaps possible to get the textboxes we have for the applauncher / paw button window for the default values? e.g. for the altitude, neg. vel. values, etc. Test environment used: I'm sorry but I had no time to update KSP so this is on 1.4.4. Win x64. Edit: Did the Test on 1.4.5 and it's the same there. Installed mods (from CKAN): { "name": "ClickThroughBlocker", "version": "0.1.6.7" }, { "name": "ModuleManager", "version": "3.0.7" }, { "name": "BobsPanicBox", "version": "0.0.1.8" }, { "name": "ToolbarController", "version": "1:0.1.6.10" } Log file: https://www.dropbox.com/s/hura0s73wcey0y1/output_log.txt?dl=0 Picture: https://www.dropbox.com/s/9zo9zip6nnbfh0v/180803.jpg?dl=0

Yes I am aware of that and it's a reason why I consider testing the Blizzy toolbar again. I also remember that the Blizzy toolbar needs to be configured but thanks for the help.

That's one of the things I really like about KSP and the mods. Everybody can play the way they want. The way I play, is to use the stock toolbar only and hide or disable all buttons I don't absolutely need all the time in a scene using The Janitor's Closet. I've tried the Blizzy toolbar when it was quite new but I didn't like it so I've actually never tried it again. Maybe I should. Having thought about it since I mentioned that there is no indication, I also have no better idea than flashing the buttons as of yet.

Flashing the toolbar button would be a possibility but as you gave us the option not to use the button for the PanicBox I thought you knew that some of us have so many mods in their regular modded game that the last thing they want is another button in the toolbar that they usually only use at launch. And if you haven't guessed I'm not using the toolbar button but the one on the PAW - a great option by the way - and I don't think you can make that flash? Also clicking the button to immediately terminate the abort sequence would mean that that you can not just open the menu to check what you set up. In fact I just found out that you can actually "cancel" the after-abort, just not quite so obvious. If enabled in the settings you can change the options in flight. That means you can also just open the window and set the "Trigger action after abort" to "None" even if the after-abort is armed and waiting.

Well if that is how you want it I'll live with it... or rather my kerbals when they are saved by the PanicBox. But I often enjoy playing somewhat real-time and if that capsule needs more than half an hour to touch the atmosphere I'll have two launches, one docking maneuver and a rover mission in between. Heck I could even exit the game an come back a week or month later (yes, the after-abort persists. I just tested it) or I could catch the capsule in orbit if it gets close enough to a another vessel. I know I will someday have forgotten that the after-abort still lingers in the dark waiting for it's time. I understand that aborting an automatic abort sequence should not be a thing in your mod but well I wish there was that warning light somewhere that Jeb ignores telling me that the after-abort will come eventually. I knew that would come up when I proofread my post for the 10th time after I posted it. (And yes, I proofread it 20 times before I posted it in case you are wondering) Yes. I can confirm that the abort was always triggered BEFORE I started the test. I launched the rocket. MaxAltitude at 75km, timeout at 180s. I threw a sphere into the rocket at around 70km and then waited until after the timeout. Just in case the Box would check those when I switched the vessels. Then I tested whether any of the actions I took would cancel the after-abort one by one. I don't know what you mean by that. That you write BPB into the message? In that case... there is no BPB on my test version of the game with version 0.0.1.3 of BobsPanicBox. At least not in the explosion or AoA abort messages.

That's really great! And... yea, I found another thing you might wanna look into. It's about the "Delay post-abort until safe for chutes" option. Maybe it works a little too good. The two things I'm concerned about are: When the abort triggered and the PanicBox waits for the "safe for chutes" there is no indication whatsoever that it is still active and doing something. Like a message that stays or an indicator in the menu. Once the abort is triggered there is no way to cancel the after-abort action even if you want to. It would be nice to have a flag for that in the menu. So I found out about this when I launched a rocket without control (no autopilot or SAS and hands off the keyboard except for launch and staging once). To my surprise the launch was quite successful. The rocket even tilted just the right amount for a really smooth launch. Then, after the second stage was empty and just before leaving the atmosphere the rocket suddenly turned sideway and Bobs Panic Box triggered the abort because of AoA. The LES fired and took the capsule out of danger and atmosphere. I was curious whether the after-abort would trigger so I waited. The capsule reached an apoapsis of over 1000 km it was a long trip and when it came back the after-abort triggered when it was once again safe for the chutes. So I tested this more today. When the abort is triggered after leaving the atmosphere there is nothing to stop the after-abort to trigger on reaching "safe for chutes" on reentry. So far I've tested: Doing an EVA and board again. Switching to another vessel via map, drive around for a bit and then switch back to the capsule via map. Switching to the space center then to the tracking station and time warp until the capsule is on it's way down, then switch back to the capsule. Switch the Active flag in the menu. Switch the "Delay post-abort until safe for chutes" flag in the menu. For all tests I reached an altitude higher then set for the "disable at altitude" and a time after the timeout before doing the tests.

Well I do like the message actually if they come from my active vessel. Easily spotting why the abort is triggered and knowing what exactly just went kaboom helps a lot in my opinion. My preference would be to have different messages whether it was on the active vessel or not. So my suggestion in detail would be: Leave the message for the PanicBox triggering on the active vessel as is. If the PanicBox triggers on an inactive vessel don't use red but the default green-yellow and add the name of the vessel at the beginning of the message. If that is not possible or too difficult I would prefer to have a message with the name of the vessel at the beginning so I do know exactly what just happened.

Thanks for the new version, the docking port problem seems fixed. Ok, so maybe I have not been clear enough and that one developed out of a misunderstanding so I try to be precise because there might be nothing wrong. I was testing why someone could get a message about an abort triggered because of an explosion if there was no apparent explosion witnessed. Based on this: So there were two things that I found: If a ditched stage exploded the abort was triggered on the active rest of the vessel. That's what I recreated consistently with the drop tanks and you fixed that. If a different vessel that has the PanicBox activated explodes in close proximity (within physics range) the abort is triggered on that vessel and you get the same message as if it was your vessel that's aborting so it might get confusing. I have not thought that the second case was really an issue and just wanted to mention it so you know about it and can decide whether it is a problem. But then you wrote: Ok. This is why I always need log files. These errors you are getting really sound like issues I had and dealt with during the development. Please get me a log file, and the save files if you can. This was an older bug. I just set up a scenario like this, and it never happened in 10 tests So I thought you saw that case as a problem that's why I continued testing it. I'm sorry if you spend time on that only because I've not been clear enough. What version of TACSelfDestruct? I had to release an update for that because of an incompatibility with Bob's. Yea, I've seen that just after I wrote that part on my regular modded game but then the problem with the docking port happened and I forgot about it. So as said before this might follow a case of misunderstanding and I also recreated what I was testing completely without TACSelfDestruct but just in case CKAN-history shows that I installed version "1:1.6.7" which is as far as I can tell the most recent at the time of writing. Again I'm sorry if I made something appear like a problem that is none and made you invest time because of it. And just to be crystal clear I have a small story how it might get someone confused:

I'll help as best as I can. So I added TACSelfDestruct via CKAN to the previous vanilla test installation and updated the PanicBox manually to the newest version. Then I recreated the scenario and the same happened. Here are the logs and the save: https://www.dropbox.com/sh/d0q8cp5jjn3fv56/AAALhZXnbmKX1OlVRHRc2FOwa?dl=0 The vessels in the test where a stock "Crater Crawler" and a stock "Aeris 4A" with the TACSelfDestruct added to the wing. After the Aeris exploded while the Crawler was active and the abort on the Aeris triggered, I waited till the explosions were over and then threw a sphere (ObjectThrower) into the Crawler and the abort on the Crawler triggered. Please tell me if there's anything else I can help with. P.s.: As I wrote this I had an idea to remove the mod-factor of the TACSelfDestruct. So I removed the mod, reopened the game and parked a stock "Crater Crawler" and a stock "Bug-E Buggy" next to the runway with abort and PanicBox set up. I switched between the vessels and made sure the box was active on both and then threw a sphere (ObjectThrower again) at the Buggy while the Crawler was active and the Buggy's abort triggered. After the explosions settled I threw at the Crawler and its abort triggered as well. So this does not seem to be a mod problem. Logs of this test are here: https://www.dropbox.com/sh/46npci47lj5ve91/AADwubK-EwsIaF6kqNbBpRHOa?dl=0 Edit: Oh, but on the positive side I just did the test with the droptanks again with the new version and that problem did not occur in the vanilla or the modded game anymore. Edit2: Sorry that it seems like I'm the one having all the errors but I have another one. The newest version of BobsPanicBox seems to have a mod conflict with "Stockalike Station Parts Redux" or, to be more precise it's model for the stock docking port. When I have both installed the PanicBox detects an explosion from the docking port at launch. I've tested it with the modified vanilla and the PanicBox version 0.0.1 where the problem does not occur, logs here: https://www.dropbox.com/sh/rmaha7hn4dat9xc/AAASNvJYmUtFEHqyDjko9WpAa?dl=0 and with the PanicBox version 0.0.1.1 where the problem occurred, logs here: https://www.dropbox.com/sh/xuquz29zjz78r2i/AAAAHlVDnCDi7xWlioP-52iXa?dl=0 In the version 0.0.1.1 link is also the save and a craft file I used with both versions. It happens when there is a dockingport2 with the replaced model of the SSPR mod anywhere on the craft.

I did use a Sock Aeris 4A and put a "Wrapper" Droptank underneath but I use a quite mod-heavy game so I don't know if you want to use that. So I made a pure vanilla installation with only the Panic Box and the AtmosphereAutopilot (for consistent flights) with dependencies installed and made a version of the plane with only stock parts and reproduced the problem. (On a side note: on CKAN Bobs Panic Box does not have it's dependencies properly set up so it does not work out of the box.) I drop the tanks using actiongroup 1 and the plane stays the active vessel. Here are the craft files: https://www.dropbox.com/sh/abu6hsvblelf6h2/AAAgmjSAoA693x79BRV7oUxfa?dl=0

So I tested a bit more today and the Active flag and the disableAtAltitude setting worked in my tests. On the other hand because of: I tested this specifically: And in my tests it did work... kinda? But I don't think quite as intended. In my first test I ditched a 3-part drop-tank from a plane and as it hit the ground the abort triggered on the plane because of the explosion. Then I parked two different vessels next to the runway and blew up a part of one of them using the TAC SelfDestruction device with a timer while I switched to the other. Again the abort was triggered but on the inactive (the exploding) vessel while I still got the usual message. So my conclusions are: 1. the Panic Box activates on the exploding vessel, but it does not check if the exploding part is still attached and it also activates on an inactive vessel for that vessel (which I think might be useful). 2. you get an identical message no matter if the vessel on which it actives is actually your active vessel or not.

As you asked for feedback, first of all great Idea. Helps a lot. Secondly, it seams like the main activation option does not work in flight. So you can't enable Bobs Box in flight if you disabled it by using the first option in editor and vice versa. The toggles for the separate options work in flight so to deactivate it you have to disable every option. Also, well maybe that's just me, but for those first tests I don't want to set the timeout too low and then I tend to forget that the Panic Box is still active when I move my rocket in orbit. So maybe you could add an option to trigger the timeout on exiting the atmosphere? That would be awesome.