EpicSpaceTroll139

I'm not sure if this is a bug, limitation of matlab-generated guis, or if I'm just missing something. Is there a way to minimize or move the Launch Vehicle Designer window while the optimizer is running? Whenever I use LVD and set the optimizer running, as far as I can tell, I'm completely unable to interact with the LVD window until the optimizer window isclosed. Usually this isn't much of an issue, but it can be a nuisance if I want to click something hidden behind it on my desktop.

No worries. Got it now, thanks!

Ah nice! LVD has so many features I should have guessed there was something similar what I was describing already, just someplace I hadn't found yet. Engine listbox... Is that different than the one that pops up when you click "edit engines" in the vehicle configuration window? All I get when I right click that is "Create Copy of Selected Engine."

First off, I want to say thank you Arrowstar for being so quick to fix the bugs I found! Secondly, while using LVD, I had an idea for a (hopefully) simple feature that I think anyone using LVD regularly would find useful. No pressure on adding it (this is already an amazing tool that you're providing free of charge lol), just wanted to share the idea. Context: Using LVD, I've realized that a significant amount of my setup time for each mission is spent looking back and forth between KSP (or the wiki, or part config files), a calculator, and LVD just entering in isp and thrust profiles for engines on each stage (fortunately nothing I've done has needed the throttle modifier profile yet). At the same time, I find I'm often using the same 4-5 engines, just in different clusters* and staging orders for each mission. Idea: Import and export of (or perhaps some kind of "favorites" bar for) engines with saved specifications. A user could go through the various settings found in the "edit engine" window to create an engine to the specs of, for example, a Raptor 2.0. The user could then optionally click a button to save the engine configuration for later use outside the current mission. Later, setting up another mission, when the user is in the "edit engines" window, there would be an option (perhaps as a dropdown when hovering the mouse over the "add engine" button) to select one of the saved engines to add, and then to enter a number for how many of it to add,** what stage to put it in, and a name. Upon hitting confirm, an engine with the desired name would be added to the stage with the same throttle limit, isp profile, and throttle modifier profile settings as the saved engine, and with the same thrust profile and EC charge/drain settings, but scaled by the number the user entered. *I'm aware of the duplicate engine button, but usually I model a cluster of engines as a single big one in LVD, so I don't have to activate/deactivate them individually. **I presume nobody wants to actually deal with adding 33 individual raptors for a Superheavy and editing their corresponding events Thanks for reading, and again, no pressure on adding this. I just wanted to kind of throw it out there. Edit: I might actually be willing to try helping out with coding it if you think it's a decent idea, as I do have MATLAB installed and have experience with it. Not guarantees on timeliness or it working tho lol. I've never used the app designer before.

Thanks! LVD is working wonderfully now! Next time I if find a bug, I'll post it on the Github since I see now that was where you wanted them lol

Thanks! I felt sure there had to be a way to do it, given how flexible your program is. Not sure why I didn't think of the spherical elements set honestly. I've used them recently in classes, should have been fresh in my brain. Anyways, I wanted to work on training myself in LVD, so I read through the "Eve: The Final Frontier" tutorial. I thought it made sense, so I opened LVD and started tinkering. I thought I'd start off simple. No atmosphere. No dropping stages. Just a small, single stage vehicle with a single engine and single tank taking off from the surface of Vall and going into orbit. I was able to configure my little vehicle with the stage, engine, tank, and a battery just fine. I was also able to set up most of my initial state,* create events with specified durations/termination triggers and actions too. But for some reason I can't seem to save any changes I make to the steering or throttle models. That goes both for events using actions, and just setting their values at the initial state. At first, I assumed it was something I was doing wrong, so I spent quite some time troubleshooting, but eventually I went and looked in the ksptot.log. There's this 7 line error message that pops up every time I click the Save and Close button. The first line "Dot indexing is not supported for variables of this type" stood out to me because I have gotten smacked with that bug so many times in my own MATLAB work. I've linked the log and LVD files here in my google drive. Perhaps this is some issue that came with the new MATLAB Runtime version? My install of MATLAB Runtime and TOT are both just 2 days old, so they should have all the proper updates.

Ok, first of all, this tool is absolutely awesome. Thanks for all your work Arrowstar. I've been going through the tutorials and tinkering around with the mission architect. Is there a way to create a delta-v maneuver with a user-defined delta-v magnitude, and let TOT determine the direction to attempt to satisfy constraints or optimize some variable? For example, say I have some solid kick motor on a satellite that is coasting on a transfer orbit from LKO to some higher orbit. Could I tell TOT to do a burn at apoapsis with, say, X km/s delta-v in order to enter a final state orbit with a period of Y hours, but with eccentricity allowed to vary freely because I don't care about that as much as the period and it gives a place to dump excess delta-v?

I don't know @QF9E's exact design, but wings can let you start building up horizontal velocity while having a TWR < 1. For example, you can get to orbit from mountaintops on Kerbin using ion engines (granted, with staging), but you need wings to get the required lift while accelerating.

Finally found some time to take a little break from my graduate research and do some messing around in KSP. Because ADHD (and not wanting to deal with load times), I decided to work on a stock KSP project instead of doing stuff in RO. Most of that involved building a rocket with a stupid number of SRBs. This monstrosity has 150 MN of thrust at liftoff and can yeet two large kerbodyne tanks out of the kerbol system with delta-v to spare. It does in fact have a purpose. It will be used to lift, wait for it, even more SRBs into LKO at the start of a really crazy (sandbox) mission I have planned. More on that later. I also decided to fly one of my older crafts, basically a giant pancake, because why not?

Testing, testing, testing... in more ways than one I have had IRL tests to do, and have final exams coming up, so I haven't done as much work on this as I'd like to, but over the course of a number of flight tests, I've managed to get my shuttle reentry code to semi-reliably bring the vehicle down to 1 km/s and ~28 km in a mostly intact state, however I'd like it to be completely intact and be quite a bit closer to the space center. (The control surfaces dancing to the music was not planned, but rather a happy accident. Control surface dancing will probably be removed at some point). One problem with the repeated testing is that each entry takes something like 30+ minutes IRL due to combinations of the size of things in RO, my lack of confidence in using physics warp on these tests, and the limitations of my computer (surface book go brrr). I don't really have the time to watch these things many times a day, so I made kOS log a bunch of data and plotted it using MATLAB. The results were very useful. The most obvious issue from the footage and plots is that the commanded roll jumps around in magnitude a lot, going from near zero, to 60+ degrees, and back to near zero again every 40 seconds or so. This is not good for conserving RCS propellant, and I doubt it's any good for maximizing cross-range abilities either. Also it just looks dumb lol. I believe this is resulting from the (currently) on/off nature of the energy management part of the roll control. Eg: Either it decides "Our energy is high, we might overshoot. Bank x amount so we go deeper in the atmosphere and slow down," or it decides "our energy is low, only bank by the minimum amount needed to make sure we don't miss the target." I need to adjust this behavior so it transitions smoothly between the two. I also apparently need to do some work on the roll energy control itself, because it was commanded those large roll values in spite of the pitch control (correctly for the circumstances) trying its best to maximize the glide distance of the shuttle, thus resulting in the shuttle coming down well short of the target. I suspect these issues stem from the fact that my code is (very loosely) based on a paper I read once called "Dynamic Guidance of Gliders in Planetary Atmospheres" as I was hoping to make my algorithm produce control outputs from the *current* state of the shuttle instead of brute force predicting the trajectory for different control inputs and iterating until something works. The algorithm in the paper was primarily intended for medium-to-low altitude guidance during the later portions of reentry,* and thus some of its equations rely on classic physics simplifications such as constant gravity (aka flat earth). In a twist that absolutely nobody could have seen coming, those equations don't really work that well when whizzing through the upper atmosphere at near-orbital speeds. I have had some success in making (dramatic) modifications to the algorithm, but clearly have work to do. By the end of this all I expect the code will have gone from being "very loosely based on this paper" to "having some of the same goals as this paper."

KSP will quite happily rotate your solar panels into RCS thruster plumes or through solid parts of your vehicle if they're close enough, which looks kind of dumb imho. It could also be useful if you want to keep them aligned a certain way, such as parallel to the ground (and airflow) on a Duna rover, or just straight out, untwisted if you're trying to land an end-of-life space probe on an asteroid Gilly with the solar panels as "landing gear" like NASA did that one time. Honestly I've low key wanted this since solar panels became a thing, but never really bothered to dig in to figure out how to do it. Edit: Although now that I reread, I'm not sure why one would want to do this on *all* solar panels.

Not sure if the "our space shuttle" was referring to a craft you made or the IRL space shuttle, but in case it's the latter: The space shuttle reentered at high AoA (often even higher than 30°) for the same reason that the Apollo capsules had a nearly flat bottom. "Bluff" (aka blunt) bodies make it easier to handle aerothermal loads because the air that gets decelerated in front of the vehicle has trouble going around it. So you end up with this thing called a "bow shock" that's separated from the surface by a distance roughly proportional to how blunt the body is and inversely proportional to the Mach number. See the thin dark line below (and if you look closely, above and around the nose) the shuttle model below. Another image that gives perhaps a clearer idea of what goes on near rounded bits (bow shock is much more distinct and on the left) (ssauce: Wikipedia): This shock is where the freestream decelerates (or accelerates depending on your perspective) to become subsonic relative to the shuttle, and in doing so heats up to the point it's a plasma. By keeping the bow shock (and hence plasma) separated from surface by an insulating layer of air, the energy the heat shield has to actually deal with is greatly reduced. Another reason for the high AoA is quite simply that it helps produce a lot of drag even in the upper atmosphere, which you want a when trying to slow down from 7+ km/s. KSP stock aerothermal heating is much more tame than that experienced IRL, so people generally don't have to take such measures to survive it, and to be honest I'm not entirely sure if stock aero considers things such as bow shock. I'm a bit rusty. Might be worth seeing how your SSTO handles with a high AoA reentry if feasible. It will require careful balancing, the COM needs to be almost on top of the COL.

Been working on my shuttle Entry-Descent-and-Landing kOS script. Put all the stuff for the entry phase algorithm together in a file and did a couple test flights. The first entry test encountered some rather bizarre control issues (control surfaces go wiggle wiggle) and the script kind of drove the shuttle deep into the atmosphere rather quickly. Combined together those resulted in the vehicle eventually developing a violent spin, then disintegrating under aerodynamic and thermal loads. (I do these in a "sandbox" simulation save, so don't worry about Jeb & Co. ) Digging through my code I found several bugs, one of the more glaring ones being that in a place where I meant to calculate the average descent path slope from the current location to the center of the "handoff sphere" (a location at ~30 km altitude some distance away from the runway where the guidance will change to a different algorithm to set up for landing), I accidentally calculated the *inverse* of this. So when the shuttle actually needed to follow a very shallow flightpath to get to the target, the script thought it needed to go almost straight down. Whoops! I fixed that and several other bugs, added even more debug information onto the terminal, then did another reentry test. This flight test was much more tame, but still showed there are some bugs left to squash in the entry portion of the script It kept commanding maximum pitch (or very close to it) and very little roll almost all the way down. This resulted in it doing most of the slowing down in the extreme upper atmosphere and not even getting much of a plasma trail (how disappointing). It also still came down well short of the desired handoff location, because by maintaining the super high angle of attack, it didn't actually use all the lift available to it, because it's operating on the "back" of the lift curve. But it wasn't running into any thermal limits requiring the nose to be that high, so I don't know what's wrong. Time for even more debug numbers. Yay! Anyways, once it got to about Mach 3 or so the script finally decided to bring the nose down to a reasonable AoA. After that I decided to try flying it semi-manually, but made the mistake of turning on FAR's roll and yaw assistants, which immediately tried (and succeeded) in murdering the shuttle, by rolling and yawing it so violently that one of the ruddervators was torn off, leading to an irrecoverable spin. Anyways, that's all for today.

Hadn't played KSP in a several months (gasp) because sacrifices must be made when doing grad school. Now that I'm on Thanksgiving break, I took the opportunity to boot up KSP, and just built a little jet to do some flying around in IVA. Had a blast. Of course it wouldn't be a KSP without some kraken shenanigans. I decided to do some hotdog piloting, but was a bit too cautious on my first flight under the bridge. Stalled and clipped a wing on the ground. Survived, but the plane seemed to keep spinning on the ground, despite the engines being shut off. Got out and watched as the plane continue to perform pirouettes and cartwheels, jumping into the air at times. Relaunched and did a proper flight, including a flight under the bridge, despite Discord trying to distract me. (Note the weird screenshot dimensions are because I recorded it as a vid and then cropped them out from the player lol) I taxied the aircraft around the R&D buildings, and it seems it might be possible to squeeze a flight through the tiny tunnel thing. Not sure I'm gonna go for it though. I have other things to do Now to get back to the RO shuttle Entry-Descent-and-Landing script that I never finished during the summer. I've probably got like 65% of the code there. I just need to make some kind of deorbit burn planner, put all the parts together, and test it. Although now that I say "just" I know it's going to be the hardest part lol.

It worked! I don't know how exactly, but it worked! I suspected from my previous flight that the gravity turn was lofting rocket too high, and the upfg code was having trouble bringing the vehicle to the relatively low altitude orbit insertion point without dropping into the atmosphere. So I made the gravity turn slightly more aggressive and raised the altitude of the orbit a little bit. On my first flight with the new settings, I walked away to do something during the launch and came back to see the rocket pointing almost straight at the ground. "Well that's worse than before" I thought, and reverted to the start, hoping to see how exactly it got to that point. Sure enough, right at the start, upfg converged onto some weird solution that pointed very steeply down. On a whim, I decided to wait it out and see what happened. The rocket ended up pointing down for something like 7 seconds... then the steering vector from the upfg code swung to point up very steeply (no pics here), and remained on there for perhaps 12 seconds. Finally, it came down to a more modes 10-15 degrees above the horizon, and slowly moved throughout the rest of the flight until... ...somehow it made orbit, getting decently close to my target orbit parameters too. I'm still scratching my head on the "point down, then point up, then point the right way" thing that happened at the start. I don't have a clue as to what could make it do that. But maybe I could solve the problem by making upfg run longer in the background passively before actually letting it steer the vehicle? idk