eightiesboi

I disagree with one thing you said: Thanks for helping keep up KSP. I rarely comment anymore, but this was worth crawling out from my cave. :)

Visuals aside, I don't see anything in the description that there is an integrated heatshield or that ablative material is used on any of those command pods / landers. There is no ablator resource included in the configs for those vehicles, which suggests that that Nertea (the mod author for NF) didn't intend for these pods to have integrated heatshields. It's your game, of course, and you can do whatever you want with it! In that spirit, if you want to add ablative shielding to the NF pods, you might want to either look at how DRE added it (check out the DeadlyReentry.cfg and look at the line for "@PART[mk1pod|mk1podNew|mk1pod_v2]:FOR[DeadlyReentry]" for an example), or you could look at what Squad does on their pods (an example can be found in the KV1Pod.cfg, and either add an MM patch [the best practices method] or copy/paste the ModuleAblator and Resource blocks right into your command pod of choice [not generally a good idea]). Remember to backup any files you start playing around with!

@DeliriumTriggerraises some great points (and extra kudos for being respectful, clear, and comprehensive). I am a bit opposite from DT (hope you don't mind the abbreviation) in that I always install RealChutes in every career playthrough. However, I also go into the config files outside the game and change the presets there, as well as a couple of actions to make my life a bit easier. What this says to me, is that although I have a workaround, the fact that I do this every time means that the default configuration doesn't work well for me (emphasis on "for me"; YMMV). I agree that the User Experience could be made better in RC2, assuming that it is technically feasible and that @stupid_chrisso chooses. This is a great mod that has made my game qualitatively better. I appreciate all of the work SC has done and generously shared with the community. And I also think that DT has made some great suggestions worthy of consideration.

Hi @Zulkonit! Welcome to the Forums! Are you having specific problems with NF Construction? There are many people (myself included) that use the various Near Future mods in their games without problem. If you aren't having any problems, then don't worry about the version number. It's like the song says, "Age is just a number, and so are KSP versions" (or something like that!). If you haven't tried using any of the NF mods, it's usually a good idea to read some of the forum posts. At minimum, the Original Post and at least a few pages back from current. That will tell you if anyone has been reporting significant problems. In this case, on the previous page, on March 4th @Grem helpfully reported that all of the mods are currently working with KSP 1.12.3. If you are trying to install using CKAN and having issues, note that you can override the version in CKAN. And, if you have already installed an NF mod and you are having problems, we need information to help you. Follow the instructions in this post. Again, welcome!

I am going to add my thanks to @zer0Kerbalfor reviving another languishing mod. Between ZK and @linuxgurugamer, the number of mods that have been updated and maintained long after their authors have taken a break from the community is inspiring (and let's not forget the number of original mods ZK and LGG have authored). Not only that, but the cooperation and coordination between the two of them is much appreciated. I can't speak for anyone else, but I find myself constantly revisiting old mods, comparing them to new ones, and feeling quite fortunate that I have different feature sets to choose from. I can Play My Way (tm), and that's not a bad thing. Just waiting for ZK to release his take on Office 365 for KSP.

Hi @Artyom, I see you've been around the forums for about a year, so a belated "welcome!" My apologies if you have already seen this, but in order for someone to really be able to help you, we need information. Check out this post here, which explains everything.

Hey ZK, I am getting this in my logs: And then I found this on the forums: What do you think? What did I screw up... again? Logs here: https://1drv.ms/u/s!AoyHZiRU1jT-z5MCm0GZJg5PFxNW5g?e=fpOlNj

As @darthgentlyand others have mentioned, I was sloppy in my little experiment. I performed it again this morning, making two changes: first, I flew to 66km and made sure I had an AP close to 200km and a PE below 20km (specifically, 198 and 14). Then I quicksaved the game. I then ran multiple tests, decoupling each 1000m (starting at 67,000) up to 74km, checking the SR recovery process each time. And, each time I ran the test, the lifter was successfully recovered. And so, the "oddity" I noted was due to failure to control for a variable on my part. My cats are ashamed of me, and they've stated it will take many bribes of treats to ever publish in their journal again. Everything else I said, however, matches. If you want to use SR to recover a vessel, you must make sure that the PE for the vessel to be recovered is below the point at which KSP deletes it (just under 25km on Kerbin in stock solar system). One other thing: I tried one other little experiment. After getting the payload in stable orbit, but before the lifter was recovered, I switched back to the Space Center, then went to the Tracking Station. I watched the lifter make several orbits, going all the way down to 14km and back up to 198km. Then I switched back to the payload. If the lifter was below the 25km line and thus deleted by KSP, SR *did* process the vessel correctly. So it would seem that you don't have to stay with the vessel after a decoupling event; if you leave Flight, it will be immune from deletion while it proceeds on rails, but when you return to Flight, it correctly gets deleted and SR does work. @linuxgurugamerand @magico13make great code. But I think we all know that.

As long as my cats count as peer reviewers.

Well, to be fair to by rigidly controlled and fully scientific experiment, my AP was rarely at 200km at the time of decoupling. I was mostly testing for PE, not AP, so the AP varied from a low of 84 to a high of 180 (after decoupling, I targeted the lifter and noted the AP/PE after it left physics range). 200 was the final AP for the payload. However, AP didn't seem to matter at all. The only difference I experienced (again, in my peer-reviewed and journal-ready) experiment was as reported: decoupling events below 70km resulted in success, above resulted in failure with orbital speeds reported in the dialog. I am *not* suggesting that anything is wrong with SR, nor that my observations should be taken without a ton of salt. The only thing I *did* do (without being sarcastic) is run the test multiple times, so I am relatively sure that what I observed, on my rig with my modified install, was an accurate representation of how SR works (again though--on my rig with my modded install).

Ladies and gentlemen, the results of my experiment: AP/PE (km) Decouple below 70km? Result 200/50 Y #3 200/50 N #3 200/20 Y #1 (pass) 200/20 N #1(?) (fail) Parameters of experiment: Lifter with probe core, engine, fuel, and parachutes was decoupled from payload either above or below 70km, as noted above. @DeadJohnwas 100% correct; if the lifter's PE was below 25km, when KSP deleted it as it passed through 25km, Stage Recovery processed it. If the lifter's PE was above 50km, it stayed on rails regardless of the parameters of its "orbit". One oddity: when I decoupled the lifter from the payload below 70km, SR recovered the lifter without problem and indicated a propulsive recovery. However, when decoupled above 70km, SR did process the lifter when it was deleted from the game but invariably noted it was destroyed due to excessive speed, as shown here: NB: This was later determined to be due to difference in altitude during the decoupling event. The only difference between successful recovery and failure that I was able to note was that in each incidence where the lifter was decoupled below 70km, recovery was successful. Likewise, in each incidence where decoupling occurred above 70km recovery failed. In my totally inexpert opinion, I would like to note that the velocity indicated (2276 m/s) looks like the orbital velocity at the time the lifter was decoupled. I would speculate that once you've crossed the border from "flying high" to "in space low", the velocity that SR uses to decide if the recovery was successful changes. However, I may be *totally* wrong about this. NB: I was. @linuxgurugamer, I hope you find my little experiment interesting. If nothing else, it seems to show that if one wants to use Stage Recovery, one must make certain that any craft to be recovered has a PE (on Kerbin, at least) below 25km. It also may help with successful recovery if the decouple event occurs before crossing the border between flying high and in space low.

I apologize in advance for not responding directly to the OP. However, this thread has been sleeping for over a year and a half and has turned into a discussion of the merits of Tweakscale instead of being about the mod. Please note that I hold both modders and moderators in high regard and that absolutely nothing that I am about to say is meant to be a disrespect to either of those groups. Without modders who continue to create and maintain the dazzling array of mods available, KSP would not be the fantastic game that it is. And without moderators to keep the forum well-organized, we might have long descended into toxic anarchy. First, I am familiar with @Lisias and with Tweakscale (both the mod and the forum post). I haven't seen Lisias state a "strong dislike" or being "very unhappy" with ModuleManager, other than discussing some of the things that MM does or does not do well. I've also not seen Lisias try to convince anyone, much less "everyone" to switch to any version of MM other than the official one. And it is certainly not true--at least for me--that Tweakscale displays the aforementioned message on loading (in fact, I have never seen that message in my own, moderately modded install). Unless you have evidence to the contrary, everything stated here is unsupported allegation at best, demonstrably false at worst. To my knowledge, I have not been forced to use another version of MM. The only version I have loaded, per my log, is the official 4.2.1 version. Therefore, unless you have evidence otherwise, this statement is false. [snip]

I will try it and report back. My inclination was to decouple just before transition at 70km, but I could try something else if you'd like me to do so. I am going to predict that "#3 - Nothing happens, because there's no ground intersect and the vessel is on rails" will be the winner. I'm not willing to bet money on it though! I'm doing my taxes ATM, so I won't get to play around with this until tonight. But I'll post my results this evening. Thank you!

Hey @linuxgurugamer! I have a question regarding expectations. I am not reporting a bug. A lifter body with an active probe core and sufficient parachutes (per SR in the VAB) is decoupled with an AP of 200,000m and a PE of 50,000m. There is still fuel in the tanks at the time of recovery, although probably not enough to recover completely without the use of the attached chutes. What should I expect to see when the payload gets out of physics range of the lifter? An attempted powered recovery? (likely unsuccessful, as insufficient fuel remains) An attempted unpowered recovery? (likely successful, as sufficient parachutes exist) Nothing? (No ground intersect, so once out of range, it remains on rails) Something else? Follow-up question: does SR continue to process for vessels that have been unloaded from prior launches? That is, if I have a lifter that's drifting on rails from a launch of a different (not the current) vessel, will SR process that vessel or is it effectively a ghost ship? If the latter, can I call it and its brethren "The Flying Kutchmen"? Thank you so much for the work you do! PS - I know that FMRS exists and I've benefitted from it many many many times, but I am only curious about SR in this scenario.

First, I am definitely not a coder, but I don't see why that little snippet of code exists. It does seem like the likely culprit. I don't have the tools installed to compile the code right now, but maybe I will download them this weekend, comment out that section, and then see if it kills my problem without causing any new ones. Thanks, Starwaster.