TiktaalikDreaming Posted July 17, 2017 Share Posted July 17, 2017 4 hours ago, Nittany Tiger said: The Challenger MEM actually does two solid retroburns in the book. I guess this might be a departure point in this simulation unless I could edit the part config file for the retropack to give it two SRB tanks and allow for two ignitions. Could do it in the future. I think for now, it's OK to do one burn to the target, especially with the aid of the Trajectories mod. Before you burn time looking at that, "not in KSP". A single part can only have one staging action. And solids have no cut-off. You could stack them though. Quote Link to comment Share on other sites More sharing options...
Nittany Tiger Posted July 18, 2017 Author Share Posted July 18, 2017 7 hours ago, TiktaalikDreaming said: Before you burn time looking at that, "not in KSP". A single part can only have one staging action. And solids have no cut-off. You could stack them though. The one staging action is going to be an issue. However, the no cut-off issue wasn't because I was going to see if I could edit the config file to create two separate solid fuel-powered rocket modules that could be fired independently. That would allow for the two burns to happen with one retro pack. The model for the SRB has multiple nozzles anyway, but I'd have to edit the particle effects and whatnot, which is not something I'm skilled with at this time. It's not a pressing issue to split the retro pack into two separate engines as a single burn of the pack still provides enough thrust to de-orbit from the highly-eccentric initial orbit and land safely. I think there's enough ascent dV to get back in that orbit as well. Quote Link to comment Share on other sites More sharing options...
TiktaalikDreaming Posted July 19, 2017 Share Posted July 19, 2017 Or I could split the de-orbit engines to a frame and 7 identical mini SRBs. Once Unity finishes re-importing the MEM project. I've killed my machine since I last opened it, and the third digit of the unity version changed, so it's off thinking things through a lot. zzzzzzzzzzzzzzzz. The whole de-orbit bundle was a single mesh in blender, so there's no way of splitting it without going back into blender, splitting it there, then redoing the pass through Unity, etc etc. On the plus side I converted it to Cycles while waiting for Unity; Quote Link to comment Share on other sites More sharing options...
Nittany Tiger Posted July 19, 2017 Author Share Posted July 19, 2017 Nice. I can definitely test it out for you. Meanwhile, I'm debugging my launch script. Seems like the heading guidance doesn't work properly for all initial headings/final inclinations, mainly if the initial heading is > 90. I think there's just something wonky with the way directions are tracked, so I can put a sign convention in the code and hopefully fix it. And then it's time to finally attempt this mission. Quote Link to comment Share on other sites More sharing options...
TiktaalikDreaming Posted July 19, 2017 Share Posted July 19, 2017 (edited) 11 hours ago, Nittany Tiger said: Nice. I can definitely test it out for you. Meanwhile, I'm debugging my launch script. Seems like the heading guidance doesn't work properly for all initial headings/final inclinations, mainly if the initial heading is > 90. I think there's just something wonky with the way directions are tracked, so I can put a sign convention in the code and hopefully fix it. And then it's time to finally attempt this mission. Mini part patch, https://www.dropbox.com/s/sizxnuhz9svjekv/MEM-DeOrbitSplit.zip?dl=0 (downloads prior to 23:51 GMT 19/07/2017 are missing the thrust vector) The more I mess with this, the more I like it. I'll keep the old one in the mod, it keeps part count down. But separating out the SRBs means a lot more control over how much dV you use for de-orbiting. The full stack probably was designed for a de-orbit from the periapsis of a highly eccentric orbit. That's the lowest energy way of getting a planetary capture after all. Using the full deorbit capability from a low circular orbit tends to lead to much too shallow a descent. And when I've done missions, I've usually got to Mars/Duna using NTRs with lots of spare dV, and circularized first. I left the gimbal on. You can, now these are separate, angle each nozzle to the CoM, but I for one don't have the VAB mouse skillz for that. Individual gimbals means rotation control as well. Symmetric Arrangements Album 7KPZJ will appear when post is submitted Edited July 19, 2017 by TiktaalikDreaming added album Quote Link to comment Share on other sites More sharing options...
Nittany Tiger Posted July 23, 2017 Author Share Posted July 23, 2017 (edited) Found bugs in the heading part of my code. Days spend trying to debug that. Then I randomly decided to get a very nasty stomach bug. Ugh. I did spot a math error in the code with the heading formula, and that was fixed. I also have a flight plan thanks to KSP TOT. Flyby Finder isn't seeing any fly-bys past March 1st, 1985 in-game, but I might be using it incorrectly. Quote Hyperbolic Departure Orbit from Earth --------------------------------------------- Semi-major Axis = -33966.122 km Eccentricity = 1.2023 Inclination = 50.341 deg Right Ascension of AN = 297.637 deg Argument of Periapse = 0.000 deg --------------------------------------------- Inbound Hyperbolic Flyby Orbit to Venus --------------------------------------------- Semi-major Axis = -6164.799 km Eccentricity = 3.0998 Inclination = 13.673 deg Right Ascension of AN = 290.919 deg Argument of Periapse = 82.205 deg Periapse Radius = 12944.908 km --------------------------------------------- Outbound Hyperbolic Flyby Orbit from Venus --------------------------------------------- Semi-major Axis = -5320.994 km Eccentricity = 3.4328 Inclination = 13.673 deg Right Ascension of AN = 290.919 deg Argument of Periapse = 82.205 deg Periapse Radius = 12944.908 km --------------------------------------------- Inbound Hyperbolic Orbit to Mars --------------------------------------------- Hyperbolic Excess Vel. = 5.042 km/s Quote Phase 1 Transfer Orbit (Earth -> Venus) --------------------------------------------- Semi-major Axis = 122848311.034 km Eccentricity = 0.21393 Inclination = 23.198 deg Right Ascension of AN = 359.983 deg Argument of Periapse = 6.347 deg Period = 23484350.6501 sec Departure True Anomaly = 174.847 deg Arrival True Anomaly = 65.945 deg --------------------------------------------- Phase 2 Transfer Orbit (Venus -> Mars) --------------------------------------------- Semi-major Axis = 168030852.440 km Eccentricity = 0.37235 Inclination = 22.874 deg Right Ascension of AN = 357.176 deg Argument of Periapse = 51.705 deg Period = 37567155.907 sec Departure True Anomaly = 23.170 deg Arrival True Anomaly = 185.007 deg --------------------------------------------- Earth Departure Date = Year 35, Day 77 02:14:39.906 (1078798479.906 sec UT) Venus Arrival Date = Year 35, Day 252 21:30:24.476 (1093987824.476 sec UT) Mars Arrival Date = Year 36, Day 105 11:53:24.145 (1112788404.145 sec UT) --------------------------------------------- Total Mission Duration = 1 Year, 28 Days 09:38:44.239 Quote Burn Information to Depart Earth --------------------------------------------- Total Delta-V = 8.711 km/s Prograde Delta-V = -402.697 m/s Orbit Normal Delta-V = 8701.690 m/s Radial Delta-V = -0.000 m/s --------------------- Burn True Anomaly = 297.637 deg --------------------------------------------- Burn Information to Depart Venus --------------------------------------------- Total Delta-V = 0.404 km/s Prograde Delta-V = 403.881 m/s Orbit Normal Delta-V = 0.000 m/s Radial Delta-V = -0.000 m/s --------------------- Burn True Anomaly = 0.000 deg --------------------------------------------- Total Mission Delta-V = 9.115 km/s Departure date here is March 9th, 1985. Venus arrival is August 31st, 1985. Mars arrival is April 6th, 1986. They're close to the book dates. I think the initial orbit I used for TOT is making the dates a bit off. Could recalculate with the TOT's suggested exit inclination of 13.673 degrees. I really want to check this with Flyby Finder first. EDIT: Flyby Finder gave this as I think the best option if leaving at a 500 km orbit from Earth. Venus fly-by date is spot-on. Mars arrival is late, though. 32.7 degree inclination for the ejection. Now to plot that in TOT. Quote Start Planet: Earth Orbit Departure Time: 1079913600 seconds UT 12500 days UT 22 Mar 1985 Y35 D90 H0 Start Orbit Inclination: 32.7 degrees Start Boost from that incl.: 3715 m/s Start Equatorial Z velocity: 6126 m/s Start Equat. Prograde velocity: 1916 m/s Start Boost from Equat. Orbit: 6419 m/s V Infinity Leaving Start Planet: 3640 m/s 1st Encounter Planet: Venus Time from Start to 1st Encounter: 171 days 23.2 hours Vinf in: 7850 m/s Brake to Orbit?: 5616 m/s 1st Encounter Periapsis: 12671.97 days UT 09 Sep 1985 Y35 D261 H23.2 882 km altitude Vinf out: 7851 m/s 2nd Encounter Planet: Mars Time from 1st to 2nd Encounter: 278 days 22 hours Vinf in: 6637 m/s Brake to Orbit?: 4777 m/s 2nd Encounter Periapsis: 12950.89 days UT 15 Jun 1986 Y36 D175 H21.3 Total delta V expended: 8492 m/s Total Travel Time: 450.8 days Edited July 23, 2017 by Nittany Tiger Quote Link to comment Share on other sites More sharing options...
Nittany Tiger Posted August 1, 2017 Author Share Posted August 1, 2017 So I've been spending days fighting precision issues in KSP's maneuver node system in Real Solar System. It means planning an accurate intercept of Mars via Venus might be impossible. I can get a maneuver node that gets me close, though, and correct it along the way. I do wonder if there's a way to increase the precision of KSP's orbital equation solvers so I don't have planetary intercepts that are chaotic or inconsistent. It's frustrating for my Mars SOI intercepts to jump wildly and randomly from tiny changes in velocities in my maneuver nodes (talking 0.001 m/s changes using MechJeb's maneuver node editor). So, yeah, I may have to just create a manuever node that gets as close as possible to a Mars intercept via Venus swingby and correct it with the LMDEs. Might mean increasing the LMDE fuel or even modifying them to run off of the hydrolox of the propulsion stage if that's realistic. The book did mention they were modified engines. Maybe they were modified to use hydrolox fuel and not hypergolic fuel. Another thing, and this is something I caught a long time ago. How does a Venus swingby get one to Mars if they fly by the dark side of the planet? The maneuver node system implies that a flyby on the bright side is needed as that gives you the radial velocity change to push one's orbit out towards Mars. Any maneuver that has the flyby going along the dark side as in the book pulls any heliocentric orbit closer to the sun, not farther. Should get the velocity boost either way, but dark-side flybys seem to lead to lower orbits, not higher ones. Quote Link to comment Share on other sites More sharing options...
Nittany Tiger Posted August 2, 2017 Author Share Posted August 2, 2017 (edited) So I think I stumbled upon the cause of the resolution issue, which is just that maneuver nodes set far in the future (as in days) seem to have less precision. Therefore, I'll just have to set the maneuver node for the flight after ACM/APM docking. So ~3600 m/s to depart and ~3300 m/s to get in the elliptical orbit in the book. Hopefully my propulsion stack has the dV for that. That's what's this first test run is for though. My Ares Propulsion Module has more fuel for mid-course corrections if it needs it, though the middle tank covers up the red UNITED STATES lettering. I can always fix that later. Prime Ares crew is ready for launch. Should they be in orange suits? Final test launch to work out script bugs and to test a change to the script. So my next post or two will be the start of the first attempt at the full mission. Didn't think it would take me almost a year of on and off work to get to, but the launch script development took some time, and I did take breaks from this to move on to other things. Also, added a table of contents to the first post. Edited August 2, 2017 by Nittany Tiger Quote Link to comment Share on other sites More sharing options...
Nittany Tiger Posted August 5, 2017 Author Share Posted August 5, 2017 (edited) Attempts 1 and 2: Not so good. Attempt 1 ended when the upper three umbilicals failed to decouple due to a staging error. OOPS! Attempt 2 went well until SRB sep, and then floppy rocket syndrome hit. I decided to do a Mode II abort to see if I could bring them back safely after LES jettison. Despite 20 Gs on re-entry, everyone made it back safe. Installed KerbCam and played with it a bit. Got a pic of the F-1A ignition and launch. Might use this for a future cinematic. Also, Kerbal Phil Stone enjoying the ride, but Kerbal Natalie York a little less thrilled with her first trip to space. Edited August 5, 2017 by Nittany Tiger Quote Link to comment Share on other sites More sharing options...
Nittany Tiger Posted August 20, 2017 Author Share Posted August 20, 2017 (edited) So I figured out what was causing the rocket to flop. Unfortunately, it appears to be the new MEM part. I'm currently not sure how to add it without my rockets flopping all around on launch, so I'm having to go with the older part for now. Another couple of launch attempts, and we're finally in orbit. Final orbit. 199km x 184km. Relative inclination of 1.3 degrees though. I'll have to edit the autopilot to seek to zero out relative inclination. Jettison of the MS-II. It vents remaining fuel to help it de-orbit. Now to burn for the propulsion stack. Actually had to transfer fuel from the CSM to the OMM due to the expensive plane change needed to get to the propulsion module. Feels like cheating, but this is a test run. Soon, though I reach the propulsion module. Next will be docking and then setting up the burn to Mars. MET is 11h 40m give or take a few minutes at the last image. In my next run, I'll be comparing book times to my own METs. Edited August 21, 2017 by Nittany Tiger Quote Link to comment Share on other sites More sharing options...
TiktaalikDreaming Posted August 20, 2017 Share Posted August 20, 2017 5 hours ago, Nittany Tiger said: So I figured out what was causing the rocket to flop. Unfortunately, it appears to be the new MEM part. I'm currently not sure how to add it without my rockets flopping all around on launch, so I'm having to go with the older part for now. The de-orbit rockets? That's weird as .... I'll recheck (possibly for the first time) the masses. Do you have anything linked to the bottom of the de-orbit motors? It has a bottom stack node, but it wouldn't normally be used. Quote Link to comment Share on other sites More sharing options...
Nittany Tiger Posted August 21, 2017 Author Share Posted August 21, 2017 (edited) 3 hours ago, TiktaalikDreaming said: The de-orbit rockets? That's weird as .... I'll recheck (possibly for the first time) the masses. Do you have anything linked to the bottom of the de-orbit motors? It has a bottom stack node, but it wouldn't normally be used. Yeah. There's a procedural decoupler that attaches to a procedural fairing that makes up the MEM fairing. That sits atop a docking port, which sits atop the OMM, and all of that sits atop the MS-II of the Saturn VB. It's no different from the previous design with the old retro pack. There's still a very slight amount of wobble with the old design, but it's not nearly as severe some of the time. It seems like at some times, after SRB sep, the part joints lose rigidity in either design. With the new retro pack in the rocket, though, it'll start to flop and flex shortly after launch as well. I'm just guessing it's a Kraken somewhere. I could rebuild the entire rocket with the new retro pack and see if it flops after launch, but I'm hoping maybe it can be corrected with some struts or something else. I'm also still using KSP 1.1.3 here. I haven't upgraded my RSS install to 1.2 or 1.3. Edited August 21, 2017 by Nittany Tiger Quote Link to comment Share on other sites More sharing options...
TiktaalikDreaming Posted August 21, 2017 Share Posted August 21, 2017 1 hour ago, Nittany Tiger said: Yeah. There's a procedural decoupler that attaches to a procedural fairing that makes up the MEM fairing. That sits atop a docking port, which sits atop the OMM, and all of that sits atop the MS-II of the Saturn VB. It's no different from the previous design with the old retro pack. There's still a very slight amount of wobble with the old design, but it's not nearly as severe some of the time. It seems like at some times, after SRB sep, the part joints lose rigidity in either design. With the new retro pack in the rocket, though, it'll start to flop and flex shortly after launch as well. I'm just guessing it's a Kraken somewhere. I could rebuild the entire rocket with the new retro pack and see if it flops after launch, but I'm hoping maybe it can be corrected with some struts or something else. I'm also still using KSP 1.1.3 here. I haven't upgraded my RSS install to 1.2 or 1.3. There could be differences in the stack nodes. I'll check. And double check the booster units don't have bottom nodes. They're a size 0 node. I'll check if there's any other differences too. It's possibly related to the mass change of the part the nodes are on. Quote Link to comment Share on other sites More sharing options...
Nittany Tiger Posted August 21, 2017 Author Share Posted August 21, 2017 I can throw you my craft file if you want. Then you can test my rocket and see if you get the same problems in your RSS install. I'm just not sure if it's a particular bug in my install or indeed something wrong with the model. Quote Link to comment Share on other sites More sharing options...
TiktaalikDreaming Posted August 21, 2017 Share Posted August 21, 2017 (edited) 8 hours ago, Nittany Tiger said: I can throw you my craft file if you want. Then you can test my rocket and see if you get the same problems in your RSS install. I'm just not sure if it's a particular bug in my install or indeed something wrong with the model. Yeah? I'd have to scrounge a bit for all the mods you're using, but a fair chunk are just part of what I already have on the old 1.1.RO I did go through testing what does and doesn't affect joint stiffness, and I've completely forgotten. I do remember colliders make a fair sized difference, so i'll check that. Can't check that at work though. Need Unity. It'll be hours before I can look again. But if you can find the bit of config for the deorbit engine frame and adjust the mass for RO/RSS, that would eliminate (or implicate) part mass; @PART[MEMDeOrbiterFrame]:NEEDS[RealismOverhaul] { @manufacturer = North American Rockwell Space Division @rescaleFactor = 1.0 //325 * 9.81 * ln(49,437/46.357) = 205 m/s (200 m/s was the real thing) @mass = 0.065 } change to @PART[MEMDeOrbiterFrame]:NEEDS[RealismOverhaul] { @manufacturer = North American Rockwell Space Division @rescaleFactor = 1.0 //325 * 9.81 * ln(49,437/46.357) = 205 m/s (200 m/s was the real thing) @mass = 0.276689484 (Mass of the monolithic edition) } UPDATE Well, the stack nodes and colliders are exactly the same. So my guess is on the mass. Presumably the mass of a part adjusts the stiffness KSP assigns to the nodes. Edited August 21, 2017 by TiktaalikDreaming checked colliders etc Quote Link to comment Share on other sites More sharing options...
Nittany Tiger Posted August 21, 2017 Author Share Posted August 21, 2017 (edited) Will that drive the mass of the frame plus the engines higher than the old monolithic engine though? Might be a compromise for stability, though. I'm more concerned about accuracy between the parts because the higher mass isn't enough to affect dV much at all. I'll give the new numbers a whirl after my practice run is done. Edited August 21, 2017 by Nittany Tiger Quote Link to comment Share on other sites More sharing options...
TiktaalikDreaming Posted August 21, 2017 Share Posted August 21, 2017 (edited) 7 hours ago, Nittany Tiger said: Will that drive the mass of the frame plus the engines higher than the old monolithic engine though? Might be a compromise for stability, though. I'm more concerned about accuracy between the parts because the higher mass isn't enough to affect dV much at all. I'll give the new numbers a whirl after my practice run is done. Yeah, thinking you could raise the de-orbit engine frame to it's old mass, and drop the actual mini SRB pieces to a small number (plus the propellant). Total mass should stay about the same. I'm assuming with RO, RSS, and the size of that thing you're running with KJR. Which means I can go take a squiz at how the stiffness is actually calculated. Or at least adjusted. There may be ways I can improve the stiffness, like with the parachute bases, adding spurious non-colliding colliders. oooo... MaximumPossiblePartMass Time to add a max 9999999999, default 0 ablator resource to EVERYTHING! Or, change the frame RO MM patch section to read @PART[MEMDeOrbiterFrame]:NEEDS[RealismOverhaul] { @manufacturer = North American Rockwell Space Division @rescaleFactor = 1.0 @mass = 0.065 RESOURCE { name = Ablator amount = 0 maxAmount = 1000 } } Edited August 21, 2017 by TiktaalikDreaming Reading KJR Quote Link to comment Share on other sites More sharing options...
Nittany Tiger Posted August 21, 2017 Author Share Posted August 21, 2017 51 minutes ago, TiktaalikDreaming said: Yeah, thinking you could raise the de-orbit engine frame to it's old mass, and drop the actual mini SRB pieces to a small number (plus the propellant). Total mass should stay about the same. I'm assuming with RO, RSS, and the size of that thing you're running with KJR. Which means I can go take a squiz at how the stiffness is actually calculated. Or at least adjusted. There may be ways I can improve the stiffness, like with the parachute bases, adding spurious non-colliding colliders. I believe KJR is a requirement for RSS/RO installs, if not a highly-recommended mod. I can confirm I am running KJR though. Quote Link to comment Share on other sites More sharing options...
TiktaalikDreaming Posted August 21, 2017 Share Posted August 21, 2017 36 minutes ago, Nittany Tiger said: I believe KJR is a requirement for RSS/RO installs, if not a highly-recommended mod. I can confirm I am running KJR though. I knew this github thing would be useful... https://github.com/TiktaalikDreaming/NAR_MEM/blob/master/Parts/DeOrbitFrame/DeOrbitUnit.cfg Quote Link to comment Share on other sites More sharing options...
Nittany Tiger Posted August 24, 2017 Author Share Posted August 24, 2017 (edited) So time to dock. Means discarding of the OMM. Next the slow process of docking. We get docked, though, and the Ares is assembled in orbit! A few hours later, and we get ready for the trans-Cytherian injection. Some of the RCS ports on the APM didn't seem to want to work, especially the ones on the MS-II. I forget how hard the Ares is to turn as well. Either way, plot the maneuver and burn for Venus. ETs run dry during the burn, so I jettison them. This is actually canon to the book since they are jettison mid-burn. I end up with about 60% fuel remaining in the MS-II, which is worrisome, but I'll have to see if that's enough for the Mars orbital insertion and return burn. Final maneuver is CSM transpose and docking so the crew can occupy the AMM and settle in for the long coast to Venus. <image delayed due to Steam error> After docking, the solar array and long-range dish is deployed, and Ares is ready for coasting. Edited August 24, 2017 by Nittany Tiger Quote Link to comment Share on other sites More sharing options...
Nittany Tiger Posted August 28, 2017 Author Share Posted August 28, 2017 So made an interesting discovery about KSP's patched conic system, and it's probably something some people might know in here. KSP's patched conic system doesn't do proper velocity addition when a craft flies by a planet. This affects how flybys work in KSP versus how they work in real life. This is why a dark-side Venus flyby was done in the book and not a light-side flyby because in reality, Ares would gain velocity from Venus' motion around the sun along with the directional change in velocity. I put a maneuver node right after Ares leaves Venus's SOI and another manuever node that put Ares on a dark-side fly-by, and I messed with the former maneuver node until I got a Mars encounter. The resulting speed of that maneuver node was 6,537 m/s, which is close to the velocity difference between Earth and Venus (~5,409.3 m/s). Therefore, to properly do this mission, I need to fix KSP's patched conic system to properly model flybys. I do think the Principia mod might correctly model flybys, so I'm going to give that a shot. I'm currently creating a 1.2.2 install of RSS/RO, and I'll see if I can port my craft file to that and install Principia. I could also create my own mod that preserves the patched conic approximation but does the proper momentum transfer between planets and craft (assuming real life flybys are planets imparting momentum onto a craft via the gravity of the moving body dragging the craft along as if it were attached by a string). It would require me to do the math, but I can do the math, though the math for flybys is probably out there already. The Ares mission I think is still possible without these mods, but the Venus flyby has to be a light-side flyby, and the Mars arrival date is later than in the book as a result. When I did the maneuver node experiment, the Mars arrival date was actually within a day of the book's arrival date, which is further evidence of the dark-side flyby being correct. Quote Link to comment Share on other sites More sharing options...
Nittany Tiger Posted August 29, 2017 Author Share Posted August 29, 2017 1.2.2 install of RSS/RO is ready. Should I port my Ares run to that, or finish this one run on 1.1.3 first? Quote Link to comment Share on other sites More sharing options...
TiktaalikDreaming Posted August 29, 2017 Share Posted August 29, 2017 5 hours ago, Nittany Tiger said: 1.2.2 install of RSS/RO is ready. Should I port my Ares run to that, or finish this one run on 1.1.3 first? I'm inclined to think a lot of things will need tweaking when switching to 1.2.2 I know I never tested the ro patching in 1.2 for the MEM, due to RO taking so long to finalise that I may have well just worked on 1.3. Quote Link to comment Share on other sites More sharing options...
Nittany Tiger Posted August 30, 2017 Author Share Posted August 30, 2017 (edited) I'm not switching quite yet. I might still run on 1.1.3, and I might install Principia or create my custom mod on 1.1.3. I think 1.2.2 is mostly stable. It runs, but I haven't played much of it. I agree with what you're doing, though. Just get ahead of the curve for RO 1.3 when it's stable. Edited August 30, 2017 by Nittany Tiger Quote Link to comment Share on other sites More sharing options...
Nittany Tiger Posted September 14, 2017 Author Share Posted September 14, 2017 On 8/29/2017 at 5:44 PM, TiktaalikDreaming said: I'm inclined to think a lot of things will need tweaking when switching to 1.2.2 I know I never tested the ro patching in 1.2 for the MEM, due to RO taking so long to finalise that I may have well just worked on 1.3. I could just patch your MEM to 1.2.2 myself so you can focus on 1.3. If it's a MM config, I can do it myself. I've been learning to use MM more with a custom tech tree mod I've been making, so I can update the DEM RO patch to 1.2.2 if needed so you can focus on the 1.3 patch. I don't know what's different between RO for 1.1.3 and RO for 1.2.2., but I'm confident that either the MEM patch will work find as-is, or it'll just need some tweaks. Also, some of the KSP modders tell me the Saturn VB was supposed to only have 128" SRBs, and they were more akin to the RSRMs than the Titan UA series. I need to thumb through the book myself to verify this, but if this is true, it's going to require new launch tests followed by potential changes to part weights and the kOS script. Fun. I might just make different versions of the Saturn VB with different SRB configs to see if they all can fly with the Ares command stack. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.