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

I'm not dead! Just been debugging kOS scripts, which feels like it sometimes. Continuing my habit of making things unnecessarily complicated, I decided to have my shuttle entry guidance script use a program based on the actual space shuttle guidance program Unified Powered Flight Guidance (UPFG) for deorbit. This program will be able to handle ascent, deorbit, and orbital maneuvers (maybe even abort maneuvers later). For now I've been testing the UPFG code on ascent, as the most complicated parts are the same as what will be needed for deorbit. Also, interfacing with a basic gravity turn at the start was quicker and easier to debug than getting the rest of the entry guidance working. After a several days of debugging, I finally got a flight that makes me think I can safely say I've got the UPFG iteration and steering almost working. The algorithm converges on a solution pretty quickly and issues consistent steering commands... The time to go (Tgo) and velocity to be gained (Vgo) decremented over time in a manner I would expect, but the pitch of the steering vector seemed to be a bit off, and I'm not sure why. The altitude began to drop significantly and the Vgo vector slowly angled up over time, until... ...10 seconds before cutoff, on entering terminal guidance, it hit a bug that killed the script. I'm not sure exactly what the trajectory would have looked like if the script had run to completion, but I don't think it would have gotten the perigee out of the ground, let alone the atmosphere. There's a possibility I just gave the script an unworkable combination of gravity turn, target orbit, and vehicle, so I'm going to fiddle with those before diving back into debugging the code. Hoping that works because I've spent way too much time on this Once I get this working, I'll have to interface it with the entry guidance, and add a staging manager if I want to use it for ascent with anything other than this shuttle on this launcher. Edit: What really kills me doing this is that my computer for some reason doesn't always dedicate its full performance to running KSP. Sometimes it will run at near real time. Sometimes it will run at a slow, but tolerable 1/3rd real time. But other times it will run at a mind-numbing 1/10th real time, with no obvious rhyme or reason

I'd say go for it! It can look intimidating at first, but it's actually not too hard to learn if you take it in steps. Start off with something simple, like making the script print something on the screen. Then perhaps make a rocket stage and fly straight up, then try making it do a simple turn over as it gets higher, etc. The kOS documentation on GitHub helped me a lot with learning it (and still does today). It gives an overview and tutorials for using all manner of features. I started working with kOS quite some time ago, if I were to guess, shortly after it became available (whenever that was), but I don't remember exactly. Having learned it actually made it much easier for me to get the hang of IRL coding languages as I went through college these past few years, so I highly recommend it both on a gameplay and brain-training basis. This being said, be sure you're someone with a good amount of patience. You will encounter bugs in your code, and it will often be frustrating. Sometimes if you make a complicated code, you'll spend an hour trying to figure out why it won't work, only to find out you forgot a negative sign on a number (facepalm). But, at least for me, when everything finally works, it's incredibly satisfying

Continued working on my shuttle landing program. I've made significant progress, the script now actually tracks the heading alignment circles instead of doing the big weird curve thing, and butters the bread on landing. It even lands right in the touchdown zone. Rollout could still use some work though. The drag chute isn't deploying, and the brakes could be a bit more aggressive. Also it would be nice (but not critical) to stay on centerline. Edit: The landing speed looks a bit faster than it really is, because I sped up the video to get real-time at the beginning, not realizing the lag decreased a bit as time went on.

I've been continuing work on the approach/landing guidance for my eventual full shuttle EDL script. It now has proper distance-to-runway calculation (including the curved path instead of just crow-flies distance), better glideslope and speed controls, and an improved user-interface with all sorts of useful numbers to feast the eyes on. Sometimes the touchdown is buttery smooth. Other times... not so much, it touches the runway and then bounces back in the air (see previous post). I think the occasional hop after touchdown is just a bug I have to live with, maybe related to a different bug that happens sometimes in which things submerge in the runway. I decided to start logging data to a .txt file to help get a better idea of what's going on, and it's helped quite a bit. Some parts of the script seem to be working perfectly. For example, two PID controllers (well, 4 including kOS's cooked steering ones) work in tandem to control the pitch of the vehicle. I have a particular target glideslope I want to approach the runway at. I multiply the resulting glide ratio (tan(glideslope)) by the distance to the runway to get a current desired altitude, and along with the actual current altitude that goes into the first PID controller which outputs a desired descent angle which will be a bit shallower if the vehicle is below the actual target glideslope line and steeper if it's above it. This target descent angle and the actual current descent angle is put into a second PID which outputs a pitch angle command for the steering. This system is working great, with the shuttle (blue) quickly locking onto the glideslope (red dashes) and staying there the whole way down. The altitude error is less than two meters by the time it hits the landing flare, and I expect with better tuning I could make it be on the order of centimeters, but really who needs that? Other things are a much less than perfect. In particular, the heading control seems to have a mind of its own. The vehicle is supposed to fly from where it starts in more or less a straight line (red dashes) to a heading alignment circle (yellow dots), turn around it, and go straight in for the final approach. However, instead of doing this, it makes this great big gradual curve (blue) basically all the way in to the final approach phase which seems to have no relation at all to the HACs. For now I guess this isn't really much of an issue. It works, the shuttle reaches the runway just fine. But things might get more interesting when I try bringing the shuttle in from higher altitudes/speeds and from positions requiring a turn angle greater than 90 degrees. Having it accurately track to the HACs, while perhaps less graceful than the wide turns the script decided to do, would be useful for making simple energy/altitude calculations needed for interface with the eventual reentry guidance that will come before it. Eg: After entry, the script will need to quickly decide based on its energy (altitude and airspeed) and position which of the four HACs (two at each end of the runway) it should fly to, whether it should make more than one turn around the chosen HAC, etc. to land safely. Straight lines and circles are easy. Weird wide curves are not. Anyways, hope I haven't bored you to death with the technical jargon.

Almost got my landing script to butter the bread. Almost. Would be nice to get this part working properly... then I could move on to the real interesting stuff, eg: reentry.

Ok, so I noticed the weird behavior was starting at exactly 1 km out from the runway, which happened to be where my shuttle exited the Heading Alignment Circles (HAC) (circles along which it turns to align heading with the runway). I moved them out to 6 km from the runway so there would be more altitude to recover from the strange roll/pitch maneuvers, and all of a sudden the weird maneuvers disappeared. So with that done, and some slight tweaks to the yaw control gains, I got my first unassisted landing on the runway.

In theory that shouldn't be possible because my code isn't directly giving control inputs to the shuttle, but rather giving kOS a vector to point the nose at and a vector to roll the top to, and then letting the mod itself decide how to actuate the controls to achieve that orientation. I suspect something's off about the vectors I'm giving it (so I'm going to make it draw them on the screen), but it's possible kOS is just bad at counteracting some coupling between roll, yaw, and pitch and that's causing the problems. I really hope it's not the second one there, writing custom control surface actuation logic would be a real can of worms.

Tbh the graphics are so incredible here I probably wouldn't have realized it was KSP if it wasn't posted on this forum.

Slowly making progress with the autoland script. Consistently ending up with more of the shuttle intact after landing now. It still is occasionally making strong rolls right above the runway though, and I don't understand why, because from how I wrote the code, it should only use yaw inputs to control centerline error after entering the landing flare, and small ones at that.

I've been working on an autoland script for my new space shuttle in realism overhaul. Been doing test simulations of the post-entry portion of the script by dropping it from a carrier aircraft. The approach phase is working pretty good. The script does gentle banks and controls the glideslope well. No speed control yet so airbrakes are manual. Flare and rollout need some work though. The script gets more and more sensitive to errors from being off the centerline as it gets closer to the runway. As a result it tends to start making sudden, dramatic corrections just a few meters above the runway. I wish I had been recording last time I did a test flight. The script decided that 10 meters above the runway was the perfect altitude to make a sudden 30 degree left bank and slight nose-down maneuver because it was 2 meters right of centerline. Was the perfect opportunity to make a "to be continued" meme.