magico13

I don't typically like adding extra GUIs, but I can see about adding a general "Are you sure you want to do this?" for scrapping/resetting upgrades/etc. I haven't gotten a chance to do much work on the update recently unfortunately, so no promises on that being any time soon. At least the rebuild should only take a day or two for that ship!

I personally am hoping for deformable terrain, but I don't think destructible buildings is a direct precursor to that, so unfortunately that probably isn't it I want my crashed Mun lander to make a crater darn it! Upgrading/repairing buildings makes sense from a functionality point of view and from a playability point of view. And that would likely be a large art project like they've been saying.

So I saw that it was mentioned a page or two back about trying to figure out how Squad's recovery code worked. In short, it just finds the distance between the KSC and the ship by doing the Great Circle Distance between them using their latitude and longitude, dividing by the Max Distance (pi * kerbin radius), then does a linear regression between 0.98 and 0.1 (so 98% and 10%) to give the recovery percentage. The ONLY way to get 100% is to be landed at the LaunchPad or Runway (it specifically checks the "LandedtAt" string of the vessel). Even at KSC you only get 98% recovered (which I personally think is lame). Easiest way to support multiple recovery "zones" would be to check the Great Circle Distance from each and take the smallest one and put it into that calculation instead.

Awesome! I think with that and KCT's reconditioning disabled, KCT and Kerbal Konstructs should be functionally compatible. Could you upload that file to a site like dropbox so I can take a look at the whole thing. That snippet appears to indicate issues with Tarsier Space Tech (only way to know for sure would be to try removing that and seeing if the KCT functions work properly) but I would like to see the whole log just to be sure there isn't something else going on somewhere else too. Thanks in advance

Two things we can do. First, I can try to fix it on my end, which will require you to enable Debug Messages in the Settings, enter the VAB/SPH, build something and launch it, then exit the game (you can revert the flight). Then send me the output_log (check the bottom of the first post for details) and I can see if I can figure out why it isn't working. It could be a mod conflict or some other issue. Do make sure you're using the latest version, since earlier versions had a similar issue with 64 bit KSP. Second, which you should do after doing the above stuff, is that you can disable the launch button override in the Settings. Doing so will completely disable the launch button but you'll have two buttons on the KCT Editor GUI, one for building the vessel and one for simulating it. This should function as a workaround for the time being or if I can't figure out the issue.

Not entirely true. Activating non-physical timewarp puts EVERYTHING on rails. Every single vessel. That's the purpose of non-physical warp. If it's on-rails and in atmosphere (above 0.01 pressure, about 22km), it gets destroyed by KSP. Solution: Don't use non-physical timewarp. You can use the Alt key to activate physical timewarp even when it would otherwise use non-physical, meaning your unfocused vessel won't be deleted (as long as it stays within about 2.2 km). I don't believe you actually went to 2x warp, you likely actually went to 5x (one press of the . key, which if you've never noticed is also the > key, which is awesome since the reduce warp key is <).

Every mod is required to also post the source code, the actual contents of the .DLL, which is what you can make changes to. You can decompile the .DLLs directly, but that is generally frowned upon and is actually illegal in some cases (pretty sure, definitely against the license of certain mods/against the KSP EULA). So, you should really only be looking at the source code that is publicly available.

Just thought of something. For the actual mod pack .zip file, you could host it on Kerbal Stuff, that way users could be notified of updates automatically and authors could see detailed download statistics. All Kerbal Stuff needs is a zip file, so it should be agnostic to the fact that the pack isn't itself a mod. I'm not positive how the hosts would feel (Majiir and SirCmpwn), but they'd likely be more ok with a modpack on the site than Curse would, especially if you've got permission for each mod. It may be worth asking on the Kerbal Stuff thread before doing so, though.

In short, the way textures are handled in KSP right now is totally terrible. Everything gets loaded into RAM at startup, meaning you run out of it quickly and loading takes forever. I use LoadOnDemand to avoid those issues. My load times are much faster as a result and I don't hit the memory limit pretty much ever. Occasionally there's a bit of a "slowdown" when tabbing quickly through pages in the editor, but not enough that it's annoying. It does take a moment for the full textures to load, but until then there's lower res textures in place and I don't mind waiting a second for everything to be "pretty" when I can still fully interact with the parts. If a mod can do it without access to the actual source, I see no reason why Squad couldn't do it in the future. I'm sure they will, but for now we're stuck with a stupid but simple method of loading textures. Edit: I'd also like to point out that there's no additional delay when loading ships. Physics and parts get loaded as normal, the textures load as quickly as they can and apply, but everything is functional even without fully loaded textures.

I'm a mod author that is generally OK with mod packs. Whether that's because my mods don't have such massive popularity that I don't worry too much about the time required for support, or if that's because I played minecraft with friends and modpacks were essential (even if they were made by me just for our server). I agree that once multiplayer becomes "normal" in KSP mod packs will be needed to make everyone's lives easier. With that said, I give early permission to the use of my mods in this pack. Though I doubt KCT will be of any use to the pack, StageRecovery may work well with these other mods. I haven't tested it with DMP though. Like others, I'd prefer that support goes through you first, then to me but the occasional person who goes straight to me won't bother me that much. If you decide not to include any of my mods in this pack, that's fine as well

That's likely because KCT checks what the vessel's launch location is to determine which queue it is supposed to go into. Specifically it checks to see if it will launch at "LaunchPad" to go into the VAB and anything else goes to the SPH. If Kerbal Konstructs has different names like that that actually control where to launch, then I hopefully will be able to easily allow the user to pick a launch location later, but I'll have to do a bit of rework to determine which list to put the vessel in. Also, Sarbian recently committed a fix for the mechjeb issues presented earlier. So that will likely be in the next mechjeb release he does.

That's what that linked comment sounded like it was saying. That's actually substantially better than what I expected would happen, so I'm surprised it's even slightly compatible. I've not yet looked into seeing how easy it would be for me to view the available launch sites and present them, but it may be worth asking in the Kerbal Konstructs thread for something (like a toolbar button) that lets you choose the launch site while in the Space Center. At the very least that would reduce annoyance by quite a bit.

What is the issue exactly? You haven't actually said anything useful if you were trying to do a bug report. I don't use Kerbal Konstructs so I don't know anything about compatibility between them other than that one comment I linked from July. And, as I've previously mentioned in this thread about this topic, it's on my TODO list but toward the very end. You will definitely have to turn off Reconditioning and there's a chance that using KCT's Launch button from storages will only place you on the normal launchpad. But I have no idea and I have much more pressing concerns at the moment than trying to add Kerbal Konstruct support. Right now I'd like to just have a working version of KCT in dev since it's currently completely non-functional.

One. Have fun your way, don't try to make other people have fun that same way (aka, if a thread isn't something you think is fun, cool, don't participate in the thread) Two. You will need a plugin, ModuleManager likely won't help. Three. Totally doable with C# (what plugins are written in). Probably wouldn't even be hard. Four. Magico13 is amused, even though I likely won't use anything produced from this thread. Silliness is why I like KSP. Reminds me vaguely of the mods that iChun makes for Minecraft. Stupid but really, really well done.

Well they do very different things Supposedly KCT works (somewhat) with KerbinSide, which uses Kerbal Konstructs. I plan on adding support for Kerbal Konstructs at a later point (since it seems like it's replacing KerbTown). The only thing regarding current compatibility that I could find is this, which is in the KerbinSide thread and is a few months old

Awesome! Others had reported similar issues in the past now that I think of it, and I was always suspicious that mechjeb was possibly at fault since everyone who reported it was using mechjeb. Until now no one had figured it out. I'll report this on the mechjeb thread if you haven't already, since it's up to the mechjeb developers to fix, but it should be a quick fix.

I think a lot more mod developers will start using the Stock Toolbar if it had some improvements. I still prefer Blizzy's (being able to hide buttons, create folders, not take up half the screen) but my mods can use either. They use Blizzy's if that's installed or the stock one if it isn't. Wasn't hard to support, so I'm not sure why more modders don't use it as a back up. Even better is letting users choose which they prefer.

OP stands for Original Post (or Original Poster, if talking about the poster). If you've got an output_log.txt file from after that happening (note that the log gets overwritten every time you start KSP) I can take a look and see if there's a lock active or something. Alternatively if you open up the debug menu there's a button that says "Show Input Locks" (or similar). There shouldn't be any active, but that does look like there is. Are you playing with reverting disabled? When you pressed "Escape" the options for reverting weren't presented, which would be weird if you didn't have those disabled.

Thank you for including the log file! I have seen this before and have meant to bring it up in the VOID thread since I'm not entirely sure what exactly KCT is doing that causes VOID to do that. I think the fix is likely within VOID and should be simple: just check if there is already a toolbar icon for VOID before adding a new one. Unfortunately I can't do that on my end but it should be simple for the VOID developer to fix. Until then, using Blizzy's toolbar and telling VOID to use that (in the settings) should hopefully get around that issue. For the first suggestion: I am planning on adding something like that in a future update since I've had so many people request it. You'll be able to recover and refuel, but likely won't be able to add any parts to the vessel (so no new payloads). I haven't finalized anything on it though, so I may be able to come up with something that allows you to add parts as well. I had originally planned on making the EXACT vessel (plus fuel) be put out immediately, but I might be able to force you into the SPH/VAB to make any changes and forbid editing afterward. Speaking of funds, with the next update there will be a radical change to how funds work (as a result of integration into the Scrapyard API/developing a common base with Kerbal 4X). You no longer will receive funds for recovering vessels but only pay once for a part. Once it's in the inventory you never have to pay for it again. You'll also be able to sell parts. Oh, this also includes Fuel and other resources. So basically we (SiriusSam and I) are rewriting how Stock does recovery. As for the second suggestion: Just prebuild your subassemblies, then Scrap them or edit them to add the payload/launcher. I do this all the time. Just build your payload (you can load subassemblies in the editor), scrap it so the parts are in the inventory, and then add that subassembly to whatever rocket/plane you want. Especially now that editing supports using inventory parts (until the 1.0 release you had to use exclusively brand new parts). People always ask for this because they don't realize that the inventory system was designed around doing this Just remember that it's always more efficient to build everything at once (because of the square root in the BP calculation), so you shouldn't build the plane and the payload separately (exception: if you have two build rates and aren't using them for anything else, then building them separately is actually faster). If your plane is out doing other missions though, building the payload is worth it if it's gonna be a while before it's back (or if you need to use the plane for something else while the payload builds, like a "Rescue a Kerbal" contract or another payload that's finished).

All I would need or want is to tell the API to compute a single trajectory for the vessel after it is staged, and from that I take the lat/lon predicted for determining the distance from KSC, which affects recovery return rates. Honestly, it doesn't make too much of a difference since it takes many kilometers to reduce the rate by 1% but if I can get more accurate results by tying into another mod then I'd like to do that. The trajectory doesn't need to be drawn, but it should be assumed to use the orientation with the least drag, if possible (since the landing zone is all I want access to, not just that it landed). I don't even need the full trajectory, just the latitude and longitude, which would keep memory footprint low. Parachutes wouldn't matter too much unless they're already deployed since they deploy so low that it might make the difference of a few kilometers at most. If they're deployed really high up then you'd expect them to fall faster than they would, but otherwise they'd fall straight down. Probably only a few kilometers different there as well, the error being from Kerbin rotating less than it should(so it'd "land" East of where it would if it was followed) Conceivably it would be possible to do that (override the KSP behavior), but it wouldn't be easy. It would be simpler to draw the trajectory and some symbol on it even after the vessel is destroyed, but keep the vessel in memory to then spawn on the surface. You'd have to stop drawing the vessel as soon as it hits atmosphere though (it's not destroyed until about 22km) since the trajectory provided by KSP doesn't account for air resistance (obviously). That'd be too much for me, personally, as semi-realistic landing zones are more of a novelty for a stage recovery mod than a requirement. If you really wanted to tackle that and add stage recovery features into this, that would be an awesome way of doing it though.

My comment was meant to be in the specific case of dropped stages, which are generally uncontrolled and are not going to remain in the point of unstable equilibrium you propose for long. If you care very much about your unattended stages which are aerodynamically unfavorable, you should probably land them manually (and most cases you won't need a heat shield for sub-orbital trajectories where you wouldn't be able to manually land).

I'm the author of the StageRecovery addon and this looks awesome! I have considered adding similar features to StageRecovery but it's always been too much work to do for me at the moment. If you ever decide to open up any of this as an API for other mods to use, I would love to be able to get the predicted lat/lon for landing and maybe the maximum velocity of a piece of debris/dropped stage. The lat/lon would be for determining the proper recovery value and the max velocity/speed would be for estimations of whether a vessel would be destroyed by Deadly Reentry (StageRecovery currently does this but since the atmosphere isn't actually changing the velocity, just gravity, the velocity at destruction is far too high). Would it be possible to assume the orientation is the one with the least drag? I'd also love to see this, or an extension of this, do aerobraking while on time warp. Even if you can't do any of that, this is still awesome!

I also play with final frontier and have noticed that the mission counter isn't increasing (for rescued kerbals at least) but haven't had my ribbons reset before. Could be related since KCT uses a super-hack to revert from simulations (it copies the backed up save file over the persistence right before the game reads the persistence file). It's likely safer to use the revert buttons (stock or KCT) than exiting to Space Center since then FF will know to revert. As for SR and per-stage info. I'd love to do that, but it's not super easy to determine what exactly is a stage. I may be able to figure out the total mass and parachute info for each stage in the staging info, but no promises. StageRecovery is currently on the back burner as I work on the shared inventory back end with SiriusSam and the next KCT update. I might have a beta up in the next few days, if I can get the back end how I need it for KCT. RealChute really helps with that, BTW. As long as you know the dry mass and set the parachutes to work with that then you're golden. With Stock it's harder.

I also am biased but Kerbal Construction Time plus TAC Life Support can make for some really interesting rescue missions.

Already got it implemented into the next version. You can't launch or do anything in the little side window (through the * button) but you can rearrange and view vessel names/times. Speaking of things I'm working on, can you all figure out the significance of this?