magico13

In honor of the release of the ARM pack, aka 23.5, here is an updated release! This version includes the fix that JeffreyCor helped me find for booster recovery not always working properly (with some help from CatastrophicFailure as well), so thank you both for your assistance. Also included is the removal of time jump as you can now warp in the Space Center and Tracking Station. Warp works properly in both situations in my limited testing. I think those are the only changes. The link is in the OP (if you don't see it yet, give me a minute to actually add it) Edit: Annnnnd done! Link is in OP. I'm going to go finish writing my thesis now.

I almost never use Sandbox mode, but I totally agree that the messages on the science equipment are annoying when I do. I also agree that the tracking things should be open as well. I might be tempted to play in sandbox again if they did that, simply because it would be way more fun. Why shouldn't I be allowed to send a totally awesome ship made from 3.75 meter parts to Duna for a year with all of the science equipment and actually roleplay getting science? Why would the R&D center not care, even though the tech tree isn't a thing. Also being able to see my expansion outward. To me, sandbox isn't "you suddenly can do everything" its "you still have to learn the ropes, but we're going to give you all the tools".

There's also these cool rock formations on the Mun that you can look for. They look more natural than the monoliths, but still stand out pretty well against the typical ground. You'll know them when you see them! There's all sorts of cool stuff scattered around the planets. Even on Kerbin! (If you want to spoil yourself, many of them are on the wiki or in certain threads on the forums. There's maps to each of them around as well. Finding them by chance is more exciting though, imo)

I looked through the KSP.log but couldn't find any instance where anything was being recovered. Did you cancel a vessel that uses parts from the inventory? Because that would give you back those parts. If you notice it happening again, let me know and send me the logs. Recovery of things that shouldn't be recovered is a serious bug if it's occurring. Thanks for testing this

Well, that's certainly weird. I didn't change the actual recover requirements, only the initial check for if a vessel is possibly recoverable. I'm going to ask you to do the thing you're so good at doing now: can you get me the logs? I'm curious as to if the stock drag is really high or something. It would have to be in the hundreds, and is usually 0.2 for something without parachutes.

If you aren't opposed to using another mod, there has been one around for a while that does just that: http://forum.kerbalspaceprogram.com/threads/43208-0-22-Oct17-SelectRoot-Set-a-new-root-part-0-22-fixes Seeing that sort of functionality as stock would be nice. I have yet to use that mod, but there are times where it would be extremely handy instead of awkwardly rebuilding half of my craft just to have a new root part.

I would like to point you to this set of output from the KSP.log file: [LOG 11:51:39.249] [KCT] Vessel being destroyed, listing information: [LOG 11:51:39.250] radialDecoupler [LOG 11:51:39.251] Shuttle Debris [LOG 11:51:39.252] Shuttle Debris [LOG 11:51:39.253] Kerbin [LOG 11:51:39.254] 16167.6203737071 [LOG 11:51:39.255] -1 [LOG 11:51:39.256] False [LOG 11:51:39.256] True [LOG 11:51:39.257] True [LOG 11:51:39.258] flying [LOG 11:51:39.259] [KCT] Found realchute module on parachuteLarge [LOG 11:51:39.260] chute area: 3525.652 [LOG 11:51:39.261] dragC: 1 [LOG 11:51:39.262] [KCT] Using RealChute Module! Drag/Mass ratio: 56.3295452308007 [LOG 11:51:39.264] [KCT] Recovered parts from Shuttle Debris Which means it is working properly now! The last debug version should be fine to play with, but perhaps later tonight I will get an official update out. Assuming everything doesn't suddenly break. Also, your chute area is huge! I only require a drag to mass ratio of like 8 or 9 to recover, which in my testing has been appropriate for a less than 10 m/s landing. When configuring the chutes were you using just the mass of the boosters? It certainly doesn't hurt to have larger chutes, but it's just something I noticed If CatastrophicFailure could perhaps test the latest debug version and let me know if his issue has been fixed, it would be greatly appreciated! I'm assuming he is having the same issue as you are, JeffreyCor.

This would be an awesome addition! With RemoteTech installed (and a fairly small satellite network) it already takes up an annoying amount of space in the TS. Being able to shove those all into a folder would be wonderful. Flags too. I almost want to never place flags because they take up room too.

For whatever reason it looks like they aren't being unloaded before being destroyed, even though the action of them being unloaded is what destroys them. I'll have to do some sort of workaround I guess. The one I'm thinking might work is checking (in addition to the other checks) that the altitude above the surface is greater than a buffer of 10 meters while also not being landed and is also below 35km. I fear that will "recover" boosters that collide with each other and are destroyed, which wouldn't make sense. Before trying that though, let me try seeing if the vessel is "packed". That may work better and I just thought of it while typing this. This hopefully will be the last one... http://www./download/1wsw8l5bvc5o7g5/KCTDebug3.zip Once again, thank you for your help. If I weren't busy with school right now I could do more of the testing myself. I did test that this one will recover boosters that normally are recovered, so this method might work. If the vessels aren't being packed before destruction though, it's going to be more difficult.

Well, darn. The different names I can apparently get are these: [LOG 18:48:14.425] radialDecoupler [LOG 18:48:14.426] Shuttle Debris [LOG 18:48:14.427] Shuttle Debris Which none of them are formatted correctly and only the first one ever gets the (unloaded) part added to their name. I think I'm going to have to come up with a different set of conditions. Instead of checking the name, I'm going to try to check if vessel.loaded is false. Another debug version for you, when you get time. http://www./download/k887iawvok4sqvl/KCTDebug2.zip

That having the same problem it seems. For some reason it's saying the vessel name is "radialDecoupler" instead of "[ship Name] Debris (Unloaded)" which is throwing it off. Would you kindly try this version and repeat the same procedure? (btw, you can just simulate the launch. It does the recovery then too, but when you revert it "forgets"). The only difference is what name I reference in the vessel (I also am printing each name I can access, there are 3 total, so hopefully one of them will be right). http://www./download/fseste9fd933tsu/KCTDebug1.zip This issue is really frustrating, but at least it seems like we know what the issue is, just not yet how to solve it. (the issue is just the name the debris is being given after decouple)

I'm not seeing anything happening at all with that part, same as for JeffreyCor. One thing that I'm noticing about both of them is that it looks like they're being staged automatically using Smart Parts. I am starting to suspect it as the culprit, but am not yet sure. Were the fairings staged with smart parts, or was it the booster (or both)? Wait, you didn't switch to it and follow it down that way did you? It won't be recovered if it's the active vessel. I can't tell if that's what got destroyed by deadly reentry or if that was something else. I'm not entirely sure what's going on. It could be smart parts staging things differently and the boosters somehow not getting "(unloaded)" in their name, thereby not passing that check. I need that check to make sure they're being destroyed by being unloaded and not from crashing into each other (both use the same function). If you are using smart parts (JeffreyCor or CatastrophicFailure), could you try without it and just stage manually and see if that helps? If so, then I can focus my efforts on getting compatibility with it. Could you also use the debug build I mentioned earlier, if it's not too much trouble, the extra bit of information it outputs will possibly help diagnose the issues. It's just the .dll file, if you extract it like you would normally and overwrite the old one it will be fine. Don't delete the old folder first. Thanks for your assistance. I wish I had more time to test things, since I don't really have a chance to try this out myself.

Ok, so this time you launched something called "Shuttle" right? What was attached to this one? I see some radial decouplers getting destroyed that for some reason are not unloaded when they get destroyed. These ones are not getting recovered because they aren't unloaded (their names don't include "(unloaded)"). Later on you stage again and there are at least two different pieces of debris. These both are being processed correctly (but don't appear to have any parachutes as their terminal velocity is 78 m/s) which means that the mod itself is still functioning correctly at that point (sometimes there's an issue and the mod just totally stops functioning afterward). So the issue with this one seems to be that they aren't unloaded, but they were at something like 15km. Very strange. I'm going to try not using v.name and instead using v.vesselName. I'm not sure if that will change anything though. Can you get me the craft file? Maybe I can reproduce it on my end and then I can see if I can fix it, instead of continuously asking you to try things and then send me the logs Hmm, I'm not sure what would be causing that. I'm going to do the same thing I ask of everyone and ask you for your logs. Perhaps there's (somehow) an issue with how I place Kerbals in the ship after the ship is on the pad, or with having to load the ship in the space center scene. If it's just a visual bug though, I'm not going to have it too high on my priority list (no offense, but right now I don't have the time to fix every little bug when this is still under heavy development. The game breaking bugs are my main priority atm) Also, a reminder for everyone. I'm currently taking a small break from development as I am quite swamped with school. Please see this post for more information: http://forum.kerbalspaceprogram.com/showthread.php?p=1031205#post1031205 Also, 0.23.5 adds timewarp to KSC and the Tracking Station, so the jump to complete will be gone and I can just timewarp to complete! I am very happy about that addition

So here is the 25 subscriber special, where I send everyone crashing into the sun at several tens of thousands of meters per second! No videos for the week, as I'm super busy, but they will hopefully resume soon!

I think it might have to do with another mod changing something. Looking at the logs, KCT doesn't even attempt to recover them (which is weird, even without parachutes it should display something as long as certain conditions are met.) I see that at least one of the boosters was set as the active vessel after separation, but am not sure if that's related. I also am only seeing two boosters actually being destroyed from the ship "Data Currier" due to being in atmosphere (and also some debris from a minmus satellite crashing into minmus, which entertained me for some reason). I'm going to list the requirements for it to attempt to recover the boosters, which may help somehow: v is the vessel that is destroyed (the booster) if (v != null && v.mainBody.bodyName == "Kerbin" && v.name.Contains("(Unloaded)") && v.altitude < 35000 && (v.situation == Vessel.Situations.FLYING || v.situation == Vessel.Situations.SUB_ORBITAL) && !v.isEVA && !v.isActiveVessel) In pseudocode: The vessel must not be null (it must exist) It must be in Kerbin's SOI It must be unloaded (not active/on rails, this happens when it gets outside of 2.5km) It must be below 35km It must be flying in atmosphere or at least on a suborbital trajectory (it has to crash) It has to not be an EVA'd kerbal It has to not be the active vessel One issue could be restricting it to suborbital, as a booster with an AP of >70km and a PE of >0 is probably not considered suborbital, however your main vessel isn't even switched to sub orbital (from flying) until after the boosters are destroyed (so likely not the cause in this instance). Could anyone experiencing issues with booster recovery please try this version and then get me their KSP.log and output_log.txt files after the boosters should be recovered? It adds some extra debug info that will possibly help me diagnose the issues (and also changes the height up to 70km instead of 35). http://www./download/j7oc199q7th7v1t/KCT_Debug.zip Thank you all for your help! Sorry about the issues :/

The floating rockets over the R&D center is a known issue (discussed a few pages back) that I don't currently know how to fix. It's a side effect of having to load the ships to get to their parts, which I do only in the Space Center in order to avoid them being loaded (and causing real issues) in the flight scene. In the future I may write my own method for loading ships into parts, or I may find a better one. Until then the mini ships will appear, but should be harmless, just possibly annoying. You'll notice that every single ship in a build list or in storage will be piled on top of each other, as a result of the loading. What do you mean by "the things with launch effects don't have launch effects"? Can you clarify that some more, perhaps with screenshots if it would help? Is this an issue on the launchpad, or is it with the floating ships? If it's the floating ghost ships, then I'm not going to worry about it, for the above mentioned reasons.

The ksp.log is less important than the output_log.txt. I should be ok with just the output_log. That range is weird that it wouldn't work. Is it just a solid booster with a chute? I've had that setup work alright for me in my gameplay :/

I'm not a huge fan of the claw being able to transfer fuel either. It makes it too OP imo. Station Science adds a docking port that disallows any fuel transfer through it, even with the right-click menus. It shouldn't be too hard for Squad to implement something similar, though it is unlikely they will. I'll probably just use the claw for grabbing debris and stranded ships, but not for fuel transfer. That's the nice things about this game, you can play it however you want

In the ksp folder there is a log file titled ksp.log and in the subfolder KSP_DATA there is another log called output_log.txt. If you can get me both of those (or at least the second one) after launching the craft and the escape tower being destroyed then I can try to figure out what's happening. There's some debug text that I output that will hopefully give me a better indication of what's happening. Edit: I have a feeling it's because there is a 35km limit on booster recovery and if it gets destroyed above that then it isn't recovered. The purpose of that was partly because things were assumed to burn up on reentry (you can't drop something uncontrolled from orbit and expect it to survive intact), but KSP doesn't actually have reentry heating. I'll remove the restriction (up to 70km for safety) and perhaps later on add in a lower restriction if Deadly Reentry is installed. Though I'd like to see the logs to be sure that's the cause first. There's a chance that it isn't, since the limit at which KSP will delete things in atmosphere is around that height (though it might be 36km). Above that, things on rails won't be deleted (which is why things can be in a "stable" orbit at less than 70km when unfocused)

There shouldn't be any conflicts since this only recovers the booster when the booster is unloaded by the game. If neverunload makes it not unload, then only the manual recovery will have any effect. If you try it out and see a conflict, please let me know!

Weird. Can either of you get me your logs? I wonder if there's an error in the calculation. I tried to use the same formulas as realchutes, but may have messed it up somewhat.

Just saw your edit. That's very strange. 4a is built specifically against RC v1.0.3 and 4b shouldn't be dependent on any specific one. The only time that kicks in is when the booster should be destroyed by KSP in atmosphere (aka, when the 2.5 km limit is reached and they haven't touched down) Are the boosters being dropped at fairly low altitude but without the parachutes being deployed? If so, they may be hitting the ground and being destroyed. I can take a look at your logs if you've got them from after the issue happens to try to find out what's happening, if you want. Has anyone else had issues with real chutes not working properly?

I can't think of any way that would be happening as this never affects staging at all and nothing much actually happens during the flight scene in this, but if you can get me the output_log.txt and KSP.log files from a session after this issue happens I can take a look and let you know if I see anything. It could be a compatibility issue with another mod, or some unexpected bug. Or, hopefully for me, another mod entirely

I have seen an issue similar to this (likely the same issue in fact) when you add a ship to the build list, then load a different one, then try to add that one to the build list without exiting the VAB first. I'm not sure what the cause is exactly, so it probably won't get fixed right away. It throws an error when trying to save the second time. Hmm, looks like when you load a ship the persistence isn't saved but there is a scene change. Could be the cause. I'll look into it some more, but for now it should be circumvented by exiting and reentering the VAB/SPH when wanting to add a ship that you load or when you press "new". It should still occur in 4a since nothing really changed between them other than the realchutes stuff.

Just an update, it's probably going to be a while until the next release since I'm quite busy IRL right now. After April 12th or so I should start to have more free time, but until then I'm pretty sure my free time is just going to get less and less (I've got a senior thesis to finish and classes are starting to go into "project" mode). Please post your bug reports if you've got them and I might be able to scrounge up some bug fixes, but it seems as if this version is relatively stable. Should 0.24 release before the middle of April then I will try to do a quick update, but do not expect full functionality before then. 0.23 mods shouldn't be assumed to work in 0.24 (hopefully it will be an easy initial transition. I am afraid of what contracts are going to do, this could make career mode unplayable in 0.24). Basically, this isn't dead but I need to take a short break due to school. Post your bug reports and I'll try to make sure things stay stable. But don't expect any new features for a little while Thank you all for your patience I'll still be around here in the mean time, so don't hesitate to ask questions!