ShakeNBake

Signed, but I’m already pretty much gone. Indie developers I can convince myself that they are decent and I can bring myself to support them. Large corporations, I simply cannot. That’s just my own bizarre ethics and I don’t expect anyone to agree with me, just explaining myself. As far as what may be “legal” in business practices; everything is legal if the laws aren’t enforced. I’ve worked for 4 large corporations in 4 very different industries and all of them exploited their employees to the max. I worked overtime at 3 and never got paid for it. I got fired from 2 because of my seizures. Sure, those things might be technically illegal, but if you don’t have the resources to, not just lawyer up, but out-lawyer the corporation, you’re SOL.

Because toxic capitalism makes me sick to my stomach. I don’t pretend to think that anything I do will affect any of those studios at all. They already have my money and ten thousand hours. I just get extremely frustrated with myself for participating in the system.

I’m strongly anti-capitalist to begin with and shenanigans like this turn me off significantly. Honestly, I might now be done with KSP1.

Any tips for fine-tuning the inputs to get good trajectories out of the MFMS? Solar System's Edge only mentions the waypoint flight time bounds. Do I need to limit the Hyp. Excess Vs? I've been trying to find a EVEEJ but it keeps finding ridiculous 15+km/sec departures. Am I missing something? Setup: I tried to just brute force it by setting the number of runs to 100 and letting it run overnight, but no dice. This looks like it will be an absolutely amazeballs tool, I just have to figure out how to make it work. Edit: Also, is there a way to specify that I do *not* want to do powered fly-bys? I would much much rather dump a bit more Hydrolox on the departure than have to use up my hypergolics in deep space.

Random question; How are engine ignitions handled in the game? Is it something that a patch could be written to allow Engineers to refill Ignitions?

8GB is totally inadequate for a mod list of that size. Bone stock KSP runs fine at 2-3GB. I only have 20 more mods than you and my install would overwhelm most machines.

This isn't exactly a request for support as much as it's an inquiry into where I should head next. I don't expect exact support since my mod list is ludicrous and I write quite a few patches on my own. Starting another attempt at my giant space station to Jupiter project, this time I opted for MKS and USI-LS. However, RO nerd that I am, I wanted to have more realistic heat loads for things. So, I've been making a bunch of ModuleManager patches but things aren't turning out how I wanted. I was hoping to add the MKS 'governor' feature to my main nuclear reactor so that I can opt to run it at partial capacity most of the time. Unfortunately, it doesn't actually slow down the reactor. Not that it would help though since even once all the batteries are full and the reactor has throttled itself back to 3%, the reactor still seems to need the FULL radiator capacity. Making retractable radiators for high-load situations not really a thing. From some quick reading, I started to get the feeling that the CoreHeat module does a lot of weird things and I'm wondering if writing more configs for CoreHeat might be a waste of my time. So far, my best info has been from the limited wiki and This Thread. Should I just put in whatever numbers make the game run now and worry about head-canon for how it all works later? Also, I just realized that the basic lights don't do anything. SurfaceLights and AviationLights work, but the good old Illuminators don't actually emit light when on... (FYI: I have spent zero time looking into this if it's actually an easy fix)

Do you ever get stuck in the VAB for way too long working on an epic mission? Designing, and re-designing, and re-re-designing, and adding this, and tweaking that, ad infinitum. And eventually, even though the TWRs and delta Vs and all the other details are properly engineered (mostly), the craft is completely unflyable in game due to it's excessive complexity. Well, I fell for that hard and ended up with IMHO an awesome design that unfortunately will never leave the VAB; the Zues Program's Jovian Science Station. The mission is to have a permanent space station in orbit around Jupiter (RSS) that would allow access to the surface of all 4 Galilean moons. However, from the midpoint (deltaV-wise) between Io and Callisto, the full there-and-back-again was too much for a single stage. The chosen orbit is 585Mm above Jupiter, just inside of Europa. From here, the round-trip delta V to either Io or Ganymede is just over 5km/s, workable for a single stage. Round trip to Callisto would be 9.2km/s, possible if I have a fuel tanker already in Callisto orbit (yet another ship to design, number waytoomany at this point). There will be 2 different crafts for the moons; an Orbiter fully equipped with science gear, and a stripped down Lander/Space Tug for surface access. The ships are fully reusable so these trips can be repeated by shipping more fuel, with the limitation that the Callisto tanker only contains enough fuel for 1 mission of each craft, and will have to be refilled or replaced for subsequent Callisto missions. Transfer to Jupiter will use a E-V-E-J path that will require a 5.7km/s departure burn (Flyby Finder is awesome). The Base: The Ships: The Launchers: Even after an aggressive campaign of part welding and cleaning things up, it still runs at <10% speed. A 5 minute burn will take over an hour. As awesome as it is, this design is headed to the recycle bin... What next? I've been thinking of updating to the newest RSS and trying this mission again, but WAY stripped down, or perhaps trying out Principia in the Kerbal world.

DeployableHabRestrictor doesn’t seem to do anything at all. I found it in an RO patch for PorkWorks habitat pack but I’m not sure if I have that mod. Time to fire up CKAN I suppose... Was never able to get AnimationGroup to stop the animation. Is there any better documentation on how it works? I found an example on the forum of using variables in MM during startup, but it doesn’t appear to be able to run in game. Also, as a side thought, is it possible to add abilities to engineers using MM? I would like to be able to use engineers to refill engine ignitions.

Would it be at all possible to assign high radiation levels to various orbital altitudes in order to make radiation belts?

I have been dipping my toes into ModuleManager configs for a bit, changing some masses (a small marker light should not weigh 10kg), adding Tweakscale and Avionics modules to parts, even changing Engine Configs (I wanted a RD-275 with multiple restarts), but that is all just "find examples in the existing configs" and then copy-pasta with changed variables. Now I'm trying to do a combination of things that I don't have a complete analog for, and I'm not entirely sure it is possible with just a config file. I'm trying to use the SXT Mk2 Centrifuge in a space station with somewhat different behavior. I would like to make it only be habitable and consume power while it is rotating. I think I can do them separately. It uses FSanimateGeneric for the rotation, but I think I can remove that and use the ISRU behavior of combining a ResourceConverter and AnimationGroup modules to make it consume power only while rotating (even though I'll lose the gradual spin up and down), and I found a reference to deployableHabRestrictor, which I assume does exactly what it sounds like it does. My question is: is there is a way to make the game trigger both of those together? I have been using these for reference: AnimationGroup, ResourceConverter, OtherConverter, Old Thread. Mostly those just showed me how much I don't understand about what I'm doing and how incomplete the documentation is. Given that my ungodly number of mods (RSS, RO, and a pile more, on top of 1.2.2 still (I hope that doesn't screw me)) makes restarting KSP with changes take many minutes, I don't really want to fight this pure trial-and-error. Any input is appreciated. Edit: After my first attempt at using the ISRU behavior, it starts the animation and the power usage correctly, but when I turn it off, the power usage stops but the animation continues. For some reason, even a copy-paste isn't working properly.

Another vote for N-body physics (even though it will steepen the learning curve) and multithreaded support so my 700+ part rockets don’t lag (as badly).

Having a weird ullage problem. I can achieve ullage on the RCS and fire the engines (multiple Astris on a big station) but the engines won't maintain their own ullage. As long as I hold down 'h' they will keep going but once I let go, the engines flame out 'vapor in feedlines' within a few seconds. They're pushing almost 1m/s² so I would think that's enough acceleration. I could just disable ullage for those motors entirely, but if there's a way to just decrease the ullage threshold in a MM patch, that would be ideal. I already have several of my own MM patches. Can't find documentation for the ullage keys though. Is the GitHub wiki the best place for reference? Still 1.2.2, hopefully that's still OK. Edit: Wow, creating a new engine is a lot more difficult than changing the cost of lights. Maybe I can't just do this in ModuleManager. Seems like my changes aren't actually changing.

Small bug that probably isn't worth trying to track down or you may have already fixed. Running 1.1.3.8 on KSP 1.1.3 with 100+ mods in RSS, just to make finding bugs impossible. Wide field observations have worked fine on everything out to Neptune but when I attempt to gather science from Pluto I get "Scope not zoomed in far enough" even though I'm at maximum zoom. I've already had to hack my persistent for a few other reasons and if I just have to hack my way through the contract, so be it. The question is if there is a file somewhere I can edit to allow me to collect the direct science. Whether by removing the zoom requirement or just crediting the science or whatever. I can handle anything that can be opened in NP++ but any decompiling or whatever is beyond me. Thanks

Same here. Now that I don't have that dirty RAM limit, get All The Mods! If the version number in the title is correct and 1.1.x does mean 1.1.2 (is it stable? haven't read the thread, sorry. :/ ) then CKAN has it wrong and we should probably bug them.

LOLed@FULL OF BEES This looks super nifty.

Through a sequence of links I can no longer remember, I came across something really neat: the Atlas V Launch Services User’s Guide. 400 pages of real rocket numbers. The most interesting thing so far, they have a launch configuration with a single SRB? Those engines must have a mean gimbal! Hopefully this isn't a repost. Didn't see anything in a quick search. Edit: LOLZ! In regards to the navigation system: Someone has a sense of humor.

Nifty. I would love something that would automatically deploy the solar panels and radiators when I stage the fairings.

Bookmarking this. My current KSP loads in at about 3.2gb. It can only tolerate about 5 scene changes before crashing. And I'm using aggressive ATM and have deleted a bunch of Squad parts.

Don't have EVAs yet, so it's transmit or recover. :/ This should be the last flight for that though.

"Unhinging reality" indeed. It was as though the CoM was suddenly about 10m behind the rocket... And now I feel like an idiot. I didn't bother to check for updated mods since I just put this together last week. You guys are really on top of things here. Sorry about the waste of a thread. In the final version, the panels will be offset in so they're just barely exposed. Hopefully FAR will barely even notice them. The winglets are because my REV is quite long with the Mat bay and the service bay being recovered, and I was having a hell of a time keeping it butt-first. It's only 66kg for the 3 of them, out of a 1763kg REV, so it's not a huge loss. 50% scale is still quite excessive, but 10% is insufficient. And now I have enough lift and control that I can just aim for 40km from anywhere up to SOI boundary and just glide along with a 0 vertical velocity bleeding off speed ad infinitum. Thanks a ton. Love your sig, that's my policy as well...

Can I make them physicsless again?

Does anyone know what mods might be turning on the physics for the OX-STAT panels? I thought it should be physicsless, but adding any to my rocket makes it freak out after staging the SRBs. Witness: (1:30) If I just remove the OX-STAT, the whole thing flies great. Doesn't matter where they are attached or how many, a single panel anywhere and after the second stage it flips around and insists on going backwards. I may have too many mods for this to be fixable. The main ones: Active Texture management EVE DMagic orbital science FAR KCT KJR KW Rocketry MechJeb Procedural Fairings/Parts RealCute SCAN sat TAC lifesupport Tweakable Everything Tweakscale Plus a bunch more minor things. Even worse, I have deleted a lot of parts from the mods and have deleted all of the fuel tanks from the Squad folder, so it's a molested-modded-install. So yeah, any thoughts are welcome, though I don't have high hopes...

My procedural parts are overheating and exploding on takeoff. Didn't see anything about this in the last few pages... First, I was trying to use a procedural battery 2.5m diameter, .125m thick, right under the command pod at the top. As I was about to hit mach, it would overheat and explode. I pulled that out and now the procedural decoupler a little farther down the stack is exploding a bit after I hit mach. Am I missing something?

Edit: Wow, so I apologize for the giants pics and the spoilers not working. My usual forums have full BBCode support and auto-resize Imgur pics. As it has taken me several hours to type this all out, I'm not going to go back and reformat the whole thing. Sorry. Double edit: So I guess the pics do resize... Edit x3: HAHA, made the spoiler tags work . Shayk and Baik started their space program in much the same way as other space programs began. Random Mun landers, Moar Boosters, and just plain strange orbital paths. But they had a dream. A dream that most reasonable Kerbals (and some quite unreasonable ones) called ludicrous. Their dream was to build a single(ish) ship that would make a full tour of the solar system, landing Jeb on every solid body, before returning home to Kerbin. (A mothership with multiple landers counts as a single ship) They fully understood that such a goal would take very significant effort, but they were up to the task, and they had a plan. And the first step of that plan was to establish an orbital base of operations. The name was easy as it was designed entirely to stay in space. The design however was a bit more difficult. It needed to be highly modular, but in the interest of simplicity and aesthetics, they didn't want to be slapping probe cores and RCS tanks and thrusters all over every component. So they decided to build a small fleet of what are essentially just RCS tanks on Jr. docking ports, nicknamed 'GoBots'. Using these, anything that has a few docking ports around it can be grabbed and maneuvered into place. Once properly installed, the GoBots can be removed and the installed parts are left mostly unmarred. Step 1 was a basic hab core, the first added part was a base and fuel tank for the GoBots, and the first parts to be added using the GoBots were some excessive solar arrays. Added a couple return capsules and deployed the GoBots again to install some extra hab space. The extra structural supports that were used to launch the hab modules are just stuck on the side waiting for an appropriate transfer stage to deorbit them. (Poof, the Stayshun design changes slightly here. This is because I put the first one into a polar orbit FTFOI, and after realizing how much of a pain it was to rendezvous with polar orbits, I rebuilt it in an equatorial orbit.) A couple beauty shots of the effectively finalized Stayshun. So now, after a suitable shakedown of the GoBots and a proof-of-concept of my abilities in orbital assembly, it was time to start building... stuff... But what? Well, this complete planetary tour is going to require copious quantities of fuel and lifting it all off of Kerbin is practically a non-starter. Suddenly, there is a strange flash and the planet gets covered in giant hexagons. Poof, Thar be fuel on Mun!! In order to fuel the planned interplanetary mothership, it was decided to put a large refinery on Mun. In fact, 'large' may have been quite the understatement since initial designs involved designing the refinery around a 2.5m Aegletes fission reactor. Giving all of these parts their own engines and enough fuel to land themselves wasn't going to work, so the Dropper was conceived of along the same lines as the GoBots. It would essentially be a flying scaffold that can attach to whatever with various docking ports, set it down on Mun, and return to orbit taking all of the flight parts with it. First, a couple test flights around KSC just to make sure the many docking ports were actually connecting and decently structural. Once the design seemed solid enough, it was broken down into all of its components and strapped to a bunch of lifters for assembly in orbit. The physics lag around the Space Stayshun was getting pretty bad (or so I thought), so a small service module was used as a base of operations so that I could do most of the work a few km away. Several tight fits, but overall the GoBots continued to perform excellently. Its first payload would be a simple surface base unassociated with the planned refinery. This base would be used to try and develop Mun-rally rovers. (I was never successful. Even with rockets pointed up for extra downforce, I was never able to get anything suitably agile) The Dropper and the MunBase would be mated in LKO and then the MunBase's upper stage would make the transfer to Munar orbit. My launch of the MunBase was much more efficient than expected and left me with extra fuel in the main stage to begin the transfer. The quad-engine transfer stage finished the burn perfectly. Coming in for the landing, and touched down. As you can see, there was no cross-bracing on the short axis. The wobbliness was deemed acceptable during the test flights around KSC, but in actual usage, was quite unacceptable. Thankfully, the entire thing is fully modular, so a single lifter with a couple beams was dispatched for Mun. Here you can see Munar GoBots performing the upgrade. The Mun Stayshun is similar in design to the Space Stayshun with the exception that most of the crew space has been replaced with fuel tanks. Its primary purpose is to be a fuel depot for the Dropper between drops. After some more minor tweaks, the Dropper makes its final drop at the proposed rally site. The Dropper has been thoroughly tested with 7 drops at the rally site and the Mun Stayshun continues to receive periodic fuel shipments from Kerbin. I heard you like SRBs... Do you have a better way to get 50t of fuel to Mun? The first part of the refinery to be constructed and landed is the afore-mentioned 2.5m fission reactor. (Since I care more about aesthetics than physics lag, this will have approximately 30x as many parts as it really needs..) The planned reactor core is initially divided up into 13 separate launches, though only 11 of these are actual parts of the core. 1 is the service module that will serve as the base of operations and 1 is extra parts for the dropper. Excessive procedural fairings FTW! A little heavy maybe? First, the service module is docked to the main baseplate for the entire reactor assembly. The main stack of reactor + generator is docked to the other side and structural components begin to be added. The fifth transfer stage brings in some robotic legs to support the massive structure. More parts. Yes, I continued to do construction on the dark side. All the MechJeb readouts make docking on instruments alone entirely feasible and I have lots of lights on everything anyway. Oops. At this point, the already very noticeable lag increased dramatically. After looking around a bit, I realized I hadn't been paying attention to my station-keeping and the Mun Stayshun had drifted back into physics range. Welp, this will make a good time to ferry a Kerbal over to do a little bit of KAS strutting. At this point, it is about time to bring the Dropper in. The service module needs to be disconnected and moved elsewhere so that the underside of the core can be finished. First, the Dropper needs to meet up with the Stayshun to refuel. Next, the extra structural parts to connect it to the core are brought in. And then a very slow and delicate multi-point docking is performed. ARGH! Well, during this maneuver, through a sequence of events that I can no longer remember, the reactor assembly was imparted with a significant amount of rotational momentum at a time when I had essentially zero control authority over it. So, I did something that I should have known was a bad idea and tapped the time-warp button... It did stop spinning, but all of the legs and pistons on the bottom decided to take a jump to the left... This will cause some cosmetic misalignments later, but luckily doesn't actually cause any major problems. The Dropper is successfully docked and its descent drop tanks have been added. The final component is a ridiculous comms tower that I left off for as long as possible due to its ludicrous part count. Once it is attached, it's time to start dropping. Once the extra tanks are empty and I'm suborbital, the tanks and most of the assembly decouplers + docking ports are jettisoned. OMG! I'M ON THE GROUND!1!1ONE I'll be honest, with the size of that thing, I was not at all sure that I would be able to actually land this. Landing the little rovers was a piece of cake. I could spin around and jump right up with a tap of the throttle. With this, everything had to be done very slowly and methodically. It took significant time to start turning and even more time to stop. And even at full blast, the engines were being pushed to their limits. In fact, despite my many flawless landings and re-orbits at the previous site, after this landing, I did not have even close to enough fuel to get back up into orbit. I could at least move the dropper out of the way to get the reactor fully deployed, but I will have to land a tanker or something here in pretty short order. Harberry Kerman has been 'promoted'(?) to senior site supervisor for the Mun Refinery. (So glad all those decoupler remains disappeared on the next load.) Initial design for a flying tank to ferry fuel from the surface up to the Mun Stayshun. And successfully landed at the site. Hook it up to the core, not that the reactor is even doing anything yet, and send the Dropper back up. The Dropper returns to the Mun Stayshun, a job well done. Now that there is a large nuclear reactor on Mun, it's time to make it work and make it productive! It will take 5 more drops to complete the refinery. At the moment, that big nuclear reactor is only good for looking pretty. Before it can even be activated, it needs a cooling system. Hey look, 6 more things on their way out. It's some pipes! And some radiators! And even some little RollyBots to move it into place. The Dropper clears it quite nicely and despite the ridiculous moment of inertia and slight imbalance, the total mass is pithy and the Dropper lands without incident. Why am I so far away? Well, the plan is to roll it into position and those RollyBots mounted on that stupidly long pipe have about a 7km turning radius. But, after more time than I care to admit, the cooling towers are finally moved into position ITS ALIVE! Next comes the actual stack of refinery units that will be converting the Kethane into sweet, sweet rocket fuel. 'THUNK'... Oops. And it’s in. (not shown: The refinery stack was only connected at the 2 ports at the top. This was not even close to structural enough to keep the stack from swaying so much that the Dropper was uncontrollable. So, a couple robotic 'bumpers' were brought up that would attach to the Dropper's lower docking ports and centralize and steady the refinery.) Coming in for a landing. The plan here is to also have the RollyBots move this into position. After my previous venture with rolling heavy equipment around on tiny little wheels, I decided to land much closer this time. Like much, MUCH closer... Once again, the payload was just slightly too much and the Dropper will need to top off the tanks to get back into orbit. It does so just fine, returns to the Stayshun, and picks up a little tow truck with a couple KAS winches on it.(Yes, it got relocated to the center port before I dropped it...) This will assist the RollyBots with maneuvering the refinery stack and will move the excess structural debris out of the immediate work area. With tweakable-everything, I decided to put yellow lights on the tow truck, just FTFOI. Bad idea... A standard radial decoupler with a Jr. docking port on it will go 977m if decoupled straight up on Mun. Finally, 3 semi-stand-alone drill rigs will be dropped around the refinery stack. Dealing with aligning docking ports has gotten too frustrating and these will just be connected by KAS pipes. Being docked: Success: On subsequent drops, the transfer stage for the drill rig was used for the initial burns during the landing. At some point around here, the game glitched out several of my docking ports. All of a sudden, nothing wanted to attach or detach anymore. I ended up having to do a good bit of save-game hacking to get everything back to functional. As part of this, I decided to also add colored lights to the Dropper. Blue is a much nicer color and makes a nifty effect while bringing in the first drill rig. Drills deployed, KAS pipes connected, COMMENCE PRODUCTION! Harberry continues to supervise. A random launcher for something I can no longer remember. Did I mention I like SRBs? The 2.5m tanker I had made earlier was not going to be nearly big enough to really be worth flying in to and out of the physics range of the refinery, so a larger tanker was designed around the 3.75m orange tank and sent on its way and landed at the site after the second drill rig was attached. Bringing in the final rig. And the dropper departs the refinery site for very likely the final time. As it sits: Remember how I said that the physics lag around the Space Stayshun was bad? Hue. Heh, Heh. HAHAHAHA. Due to the distant cousin of General Relativity that is Kerbal Part Relativity, the space within 2.4km of the refinery proceeds at approximately 1/15 real-time. Several more tankers will be brought in and hooked up once the interplanetary exploder explorer is ready to receive fuel. Now, with a near-infinite supply of fuel that is an easy hop into Munar orbit (while mucking around in the save file to fix my ships I also added a couple zeros to the size of the Kethane deposit I'm sitting on) it is time to begin the construction of the absolutely excessively large ship(s) that will set Jeb on every solid body in the system before returning to Kerbin. I am an actual engineer IRL, so in true engineering fashion, the first step to planning this epic venture was to make an excessively large spreadsheet. All of the values came from a nice Android app my buddy has (which does not appear to be in the fascist Apple store, not surprised ) though a lot of them look pretty suspect. The numbers going from moons to other planets are just wrong. 3 dV to get from Mun to Duna? -28 dV to get to Ike?? How would that even work? I'm hoping that the important planet->planet numbers and the landing/to-orbit numbers are correct though. The one that really made my brain hurt though was Eve to-orbit. 12.7Km/sec to orbit?!? FAR should cut that down some, but still, major ouch. Trying to design a standard style rocket with 12Km/sec on board was a bit of a challenge. In the end, I ended up with a monster. No full pics just yet as it still needs to be assembled in orbit. Initially, I was struggling to figure out how to split the rocket up in order to get it into orbit. Thankfully, I remembered that Kerbin is stupid small compared to Eve and just the boosters have a ridiculous amount of oomph. Empty out all the upper tanks to save weight. Stages? We don't need no stinkin stages... As you can (maybe) see, the primary engine is not firing because it still has a decoupler attached to it. This is where all of the deorbit and landing equipment will attach, as well as where the completed ship will attach to the mothership. IIRC, final mass in the VAB was ~530t. The only other lander that will have to have multiple stages is for Tylo. 2400m/s to get down and then again to get back up... Fun with ludicrously long rockets and the Tylo lander accelerating to orbit. Duna will also get its own purpose-designed lander, a simple small ascent vehicle with a ton of parachutes that get left behind, as will Laythe, an SSTO spaceplane so that I won't have to pray that my parachutes set me down on dry ground. Having essentially zero experience designing things to fly horizontally, my first few prototypes performed exceptionally badly. Rather than continuing to bash my head against the wall to reinvent the wheel, I decided to outsource my spaceplane design to these very forums. I found a wonderful little VTOL ship and made a couple minor tweaks to make it easier for a noob with just a keyboard to fly. All the other moons and planets can be done by one of a few different landers that are nothing special, though the 2km/s needed for Moho and Vall made for a decent size. Now, with a decent idea of how much planetary stuff I'll need to push around, it's time to get started on the mothership to carry it. The main base is a simple hexagon of ~3.75m vertices connected by 2.5m tanks. On one side are 7 docking ports of various sizes to carry the small fleet of landers. On the other side are 6 3.75m docking rings for the engine stacks and a hab module in the middle for Jeb to sleep in. Primary propulsion for the mothership will take the form of 6 clusters of 7 nuclear engines which will sit at the back of stacks of 3.75m tanks. Each cluster is fully autonomous and they, as well as all of the tanks, are connected with docking ports. As the fuel tanks are emptied, the engine clusters can be disconnected, the set of tanks can be dumped, and the engines reattached to the remaining stack. Here is one of the tanks sitting on the launchpad. I expect to need >30 of them. Ahh the joys of orbital ballet. And this is effectively where it sits right now. I just had another crash-while-loading, so I'll have to step back to the last KAC persistent file backup. Hopefully I don't lose much progress. Yes, I'm still running on .23.5. If anyone thinks that it's possible to somehow update this to be compatible with 1.0, I would be happy to provide my 13MB persistent file for you to poke at. There are also still a couple minor mission planning details I have yet to work out. And before I grab a bunch of equations from wiki and make another big spreadsheet, I’ll just ask here. Is the Oberth effect worth using if I intend to end up in a high orbit? As in; I want to end up circular around some planet or moon at 500km. Do I aim for a 500km peri and simply circularize there or should I aim down at a peri of ~10km, pull down the apo to 500km, and then raise the peri back up to 500km? I’ve tried varying a few of my Mun transfers, but the difference doesn’t seem to be very big, if it exists at all.