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.

If you find it and you don't mind sharing, that would be fantastic!

Just want to share this with the community. As presented, the top node is impassible with CLS. That makes sense, as the real Gemini, IIRC, had parachutes in the top part of the capsule; thus, it would have indeed been impassable. However, since this one doesn't have main and/or drogue chutes in its snout, I decided my head canon allows a departure from reality. If you want to slap a clamp-o-tron jr (or similarly sized) docking port on the top node, and you want your Kerbals to be able to crawl on through without an EVA, then I recommend the following change to the MM_ConnectedLivingSpace.cfg file in the "GameData\JFJohnny5\MM_Patches" directory: You can also make this a separate MM patch without touching the original config, of course, but then (AFAIK) you need to add ":FINAL" or ":AFTER[JFJOHNNY5]". (If I am wrong about that, please someone correct me.) As always, thanks to the Maintainer of Many Mods, LGG, for making KSP even better.

Hi @tremonthedgehog! I see you've been around the forums for only a relatively short time. There are *a lot* of people here that are willing to help you, and the community is pretty amazing overall. But if you're having problems, you need to make it possible for others to help you find and fix them. You've actually made a good start by specifically mentioning the behavior you are seeing (i.e., you are unable to find a part). But to figure out what's going on, we need logs. Follow this link: and then upload your logs to a hosting service (like dropbox, onedrive, or google drive). Post the link to the log, not the log itself. And don't just take a snippet of the log, as that doesn't help as much as you might think. There really are only four categories of possible reasons for what's happening in your game: A bug in the mod A bug in KSP Another mod is actually causing the issue (for example, by moving items in the tech tree) User error (looking for the item in the wrong place, failing to install dependencies, etc) In my experience, #4 is the most likely reason, followed by #3. While some mods *do* have bugs, big ones (like major parts missing in popular mods) are usually reported and verified pretty quickly after a mod update. As far as I know, you are the only person that is experiencing this, which makes #3 and #4 even more likely, especially because I saw that you've posted that parts from other mods are also not showing up in your game. But if you post a link to your logs, it's *very* likely that someone knowledgeable will try to help...... However, one thing to always keep in mind. Mod authors owe us, the KSP community, nothing. They don't have to share their labor with us, they don't have to fix things we think are wrong, and they don't have to respond to us on the forums. Most of the mod devs here do all those things, but they don't *have* to. When you post in a forum making claims about a mod without any proof, you aren't really helping. So, my advice is, again, follow the link I included, post a link to your logs, and don't forget to thank Nertea and any other mod author you come across for helping make KSP the fantastic game it is.

Hi @linuxgurugamer and everyone else! I wanted to share this. I use both the Aviation Lights mod and Crew Light. I like having all my lights have the motion detector functionality, but the option wasn't in the PAW for the new Aviation Lights part. So, I changed ModuleMotionDetector.cfg in Crew Light to add: It seems to work just fine, although I haven't tested it much. Just wanted to share this in case it helps anyone. LGG, thanks for keeping so many mods going!

@Snark I don't know if it helps at all, but logs here: https://1drv.ms/u/s!AoyHZiRU1jT-z5F1TM6AWgE2L5oynw?e=4uejTG I just started the game up and let it run for a few minutes with a couple of scene changes. Obviously, I am running more than a few mods but my logs are pretty clean. I can also set up a test run if it helps. The one thing I can't do is code, so I am useless for that, but let me know if there's anything else I can do to help. Thank you!

Hey @Snark! First, thank you. Second, what does it look like when it calculates max elevation? Every 2-4 minutes, I get this in my log: I've noticed some minor stuttering when this is happening (I am literally playing as I type this). I am *not* trying to force recalculation or do anything other than play. If this is normal, then let me know and I will disregard. If not, I will provide a clean log and also try rolling back to 1.3 to see if there's any difference. Thanks!

No, that's not what I am saying. If I set the thrust to zero or individually disable the RCS in the PAW, then Mechjeb doesn't change it. However, means I also can't use them when I need to use the RCS without turning them all back on individually (in the case of disabling them) or touch the thrust slider for at least one thruster in a symmetry group. As far as having RCS that only point forward and backwards, yes, Mechjeb will enable them and use them for rotation control, but pitch and yaw only though (obviously, roll is not a factor). So that doesn't help me and takes away the main thing I use RCS for, fine translation control. My problem is exactly what sarbian said: I guess one fix for me would be if I could disable the SmartRCS module itself, but I don't see a way to do that in the config files that I can touch. I am fine disabling rotation on RCS through an MM patch myself. I mean, that's what I already have done, but Mechjeb wants it to be on. One also possible fix might be (if I understood what sarbian said) to set the default so that SmartRCS (when set to disable rotation) defaults to toggling rotation off, instead of defaults to toggling it back on. I don't know. In the end, Mechjeb is very useful and still worth it even if keeps turning my RCS rotation back on.

That's a good idea, but it doesn't work. The single direction RCS has the same toggles and suffers from the same issue. Here's another video that shows what I am talking about, and I apologize for getting your name wrong (I called you ColdP instead of ColdJ!). Notice that in this case, I was yawing, not pitching or rolling. Any rotation seems to reactivate the disabled settings. https://1drv.ms/u/s!AoyHZiRU1jT-z5F036PL2GuwB1B3Uw?e=A6Cq4P

Hi! I appreciate your response, but I think you may have misunderstood my issue. I am not trying to use RCS for rotation. I am trying *not* to use RCS for rotation. RCS rotation (roll/pitch/yaw) is disabled (by me, intentionally), both in the actuator settings and in the Mechjeb settings. However, Mechjeb appears to be rapidly toggling it on and off, and then leaving it on.

For what it's worth, here's a short video clip so what I am describing is clear. You can see on the left that SmartRCS has "Use RCS for rotation" unchecked. On the right you can see that Yaw, Pitch, and Roll are all set to "Off" on my RCS Thruster Block. When I roll the ship, everything is fine until I stop rolling (with SAS on) and the reaction wheels kick in. Then RCS toggles rapidly between on and off until the ship stops rolling, and then stays on. Same with a pitching movement. Video clip: https://1drv.ms/v/s!AoyHZiRU1jT-z5Fwsq8fCkZdBpqGwA?e=zFmOBF I threw the logs in the same folder, just for fun, but I captured this during a play session, not in my (clean) test environment: https://1drv.ms/u/s!AoyHZiRU1jT-z5FvLjmi4BIhDEw8eA?e=ycPw5k I'd appreciate any suggestions anyone might have.