Razgriz1

That would definitely be cool. Very launch livestream haha! It's definitely a somewhat niche requirement. The Stock Shuttle Orbiter (which is what I fly) has a bit of a hack that rotates the command direction 15 degrees down, but kOS does not like having the command point switch partway through launch, and it wasn't quite the right angle for the OMS engines, so I thought I'd try and solve it myself. I'm actually fairly proud of my solution. It turned out to be a lot easier than I thought it would be. Basically I just get the position of each of the engines and weights them by their max thrust and sum those vectors. That gives you the offset vector that you need to use instead of your facing vector for steering. Then you just rotate the desired steering direction around the cross product of your forward vector and that offset thrust vector by the angle between them, and lock your steering to that new direction instead of the initial direction. My code for that is at https://github.com/Jakathan/shuttle-guidance. Specifically the function is shuttleSteerDir(<direction>) in lib_shuttle_mnv.ks. It's as simple as wrapping whatever steering direction you want to use in the the function and it should take care of the calculation. It should be able to handle both pitch and yaw offset, though I've really only done significant testing on the pitch offset since that's what's required for the shuttle. I need to do more OMS engine out scenarios to test it more. p.s. Don't look at the entry guidance portion of the repository, it's not very good

Having more engine-specific throttling control would be very nice. I'm happy to help you verify that it's still working on the current kOS version again. They do a pretty good job of maintaining backwards-compatibility over there so hopefully it won't be an issue. Perhaps my biggest vote for UI improvement would be something along the lines of ETA to upcoming events or something along those lines. What about his PR do you think needs tweaking? I may be able to help with that if needed. I've got a somewhat modified version of his PR in my own version of the script, as well as the ability to steer the craft so that the thrust vector is pointing through the CoM toward the steering direction as opposed to just the facing vector. This is useful for flying the shuttle after booster sep, especially through the roll to heads up maneuver.

+1 for Halo orbit planner! I've always meant to learn how to plan a mission to one, but now I guess I don't have to! I'm always amazed at how quickly you add things to this, @Arrowstar! Keep up the great work!

I haven't had any issues at all. Your code is pretty solid and very clean. I've tweaked it a bit for my personal use, and incorporated the Aram1D's pitch table ascent mode into my own version but the base code still works great. I'm glad to hear you're still working on it! Any hints on what 1.3 will change/add?

Has anyone attempted to write FAR configs for the wings and control surfaces for this shuttle? I tried my hand at it, but they don't seem to be applied correctly. I think the tutorial on the FAR wiki is somewhat out-of-date.

Yes, this still works with the current version of kOS.

Aaaaaand just when I think that I've started to make some progress with reentry guidance, someone else comes along and WAY outdoes me...

I am not really aware of any autopilot mods that are particularly well suited to landing spaceplanes without some sort of engine to maintain speed in the atmosphere. Your best bet is probably a custom made autopilot using kOS. That is my current pet project, but I am focusing more on the entry guidance portion of it than the landing right now.

It's not that hard to either create your own config file from the Restock config that matches the weight of Benjee's, or to edit the config file that copies the stock vector to copy the restock one instead. I had done that in the past, but I don't have access to the computer with those files on it right now or I would post an example.

Looks like you've got Waterfall Plumes on the SSMEs, which is the only engine included in that config. The SRB's do not have Waterfall configs, and there really aren't any plans to create SRB plumes per Nertea from the Waterfall team.

If you have Restock, you'd also have to take out the &!ReStock part of the SSME patch I posted as well, otherwise it won't use that patch. Strictly speaking, that isn't really necessary anyway since Benjee's SSME copies the stock vector, not the Restock Vector, so I should probably remove that anyway.

Module manager patches can go anywhere in GameData. I personally keep all of my own patches in my own folder in there to keep track of them. You probably will need Stock Waterfall Effects though, as I believe it uses the templates included in that as a basis for these.

I found that @Knight of St John's Stock Waterfall Effects Vector and Puff OMS effects worked quite well for Benjee's shuttle engines. I made my own config for them based on these, by essentially just tweaking the plume scales and offsets.

You first need to load them into memory. Since my files only contain functions (and the lazyglobal modifier) just run the scripts as you would any other script. That's what the first two lines of the example are doing. Once you do that, you should be able to run the functions from the terminal (I think you can do that in kOS anyway). Alternatively, that example script in the readme should be a complete script that will calculate and perform the reentry burn and entry guidance, as long as you replace the <coordinates of KSC> bit with the actual coordinates of the landing site you want to target. I should probably reword that, as it can really target any arbitrary geocoordinates, not just KSC. You may also need to change the path of the files depending on where you place them on your local machine. In the future, if you have more questions like this, you should probably message me, or create an issue on GitHub so that we don't bog down this thread with only tangentially related content.

So the "nominal" entry I based the guidance on was a 5 ton downmass from a 350km orbit, but I tested several different altitude and downmass combinations. Really the whole point of this is to make it so it doesn't really matter what the downmass is. In theory, a higher downmass/higher energy reentry should cause it to have a higher roll angle. It's more sensitive to the downrange position of the entry interface point than anything else, which is kind of the next thing I'm looking at solving. My script does use the stock fuel valves to drain the remaining OMS fuel prior to reentry, but it shouldn't make that much of a difference, and I have not noticed too much difference in controllability keeping the fuel in the shuttle. I did that primarily for realism purposes.

@DJ Reonic (and anyone else who may be interested!) So I think I actually have the entry guidance scripts in a somewhat usable state right now. The deorbit node creation function should be usable pretty in pretty much any situation you'd want to use it, targeting any ground coordinates at any inclination, as long as those ground coordinate will reasonable pass under the orbit ground track. Right now the burn anomaly and the target periapsis are hard-coded to what seemed to work well, but I'm looking into the math to figure out how to target a specific entry interface downrange distance and flightpath angle instead, which should help generalize it to planet size and initial orbit somewhat. If anyone has any knowledge about that, suggestions are welcome! Entry guidance is definitely dicier and much more WIP, but I've tested a few configurations and it seems to preform reasonably well. The current entry guidance function is designed to work with FAR and JNSQ Kerbin, though there is some commented out code in there from testing with stock aerodynamics on JNSQ Kerbin that should still work. Essentially it uses a target altitude vs downrange distance curve that I worked out by flying some nominal flights and then spline fitting in Matlab. I'd like to eventually switch to using something like a target total energy state or a target drag value, but this was the easiest to get working first and seemed to give decently consistent results. It's nowhere near as smooth as I'd like it to be, but I feel like it's in a state now that can be shared with other people. With that in mind, I've set up a GitHub repository: https://github.com/Jakathan/shuttle-guidance I have some grandiose plans of trying to build out a pretty solid general purpose guidance computer for the shuttle, but apparently I decided to start with one of the hardest parts... Oh well. Please feel free to give it a try and see how well it works for you the README should give you a pretty good idea of what's in the code and how to use it. I'm new to git, so I think I set everything up right but I'm not entirely sure. Yell at me if it's not working for you and I'll see what I can do! Eventually I'm also gonna post this over on the kOS subreddit and let them tear it apart, but I still want to iron a few things out first.

Music to my earholes!

KSP drag is not the easiest thing to wrap your mind around either. I might be able to get Close Enough™ by just getting a "nominal" altitude/downrange relationship and using roll angle to follow that. That's the next thing I'm going to try. As long as it's close, the Approach & Landing phase should be able to handle quite a bit of error. Once I've got something good working decently, I definitely plan on sharing it here. I've put too much time into this now to not

I think you're probably referring to Relatively Adequate Mission Planner and yeah I started out by attempting to adapt that into what I wanted, but it turned out to make too many assumptions and simplifications. I'm still using the Approach and Landing script from that script pack for final approach and landing but once I sort out reentry a little better, I plan on writing my own version of that too. Right now, I have the capability to target deorbit burns from an inclined orbit, and perform roll reversals during reentry when crossrange gets too high. I'm currently trying to work out a good way of using roll angle to control downrange instead of alpha modulation, as that's how the real shuttle did it, but that's proving to be a very complicated task lol. Unfortunately the Trajectories mod does not seem to account for roll angle in its calculations, so it assumes the lift vector is vertical. When trying to use roll, even just to correct crossrange error, the Trajectories prediction is off. I may just switch to only using roll to correct crossrange and then using alpha modulation with trajectories to control downrange but I want to avoid that if I possibly can. I have lots of data logs from a lot of flights that I have pulled into Matlab at this point lol.

Edit: Good job me clicking submit instead of add image... Here are the plumes I was talking about, now that I have a chance to actually fire up the game again.

IRL most docking mechanisms are only compatible with one other type of docking port Often times there's even the added constraint of active vs. passive ports.

Am I correct in thinking that Trajectories assumes a roll angle of zero degrees when calculating the trajectory as opposed to whatever roll the vehicle is currently at?

Use translational RCS to make small velocity changes, just like you would when you are getting close to docking. Edit: also, unless you're actually getting to the point where you're actually physically docking, or you're attempting to station-keep like some of the Gemini missions did, you don't really need to COMPLETELY zero out your velocity. You just need to get it close enough so that you can plan your next step.

For those of you who use Kerbal Operating System, I wrote a function that calculates the angle offset between the ship's center of thrust vector and it's forward facing vector, and then uses that to adjust a steering direction you input so that the thrust vector points through the center of mass in the same direction as your input direction. It should even be able to handle OMS engine out scenarios, though I have not really tested that yet. //lib_shuttle_mnv.ks @lazyGlobal off. function shuttleSteerDir { //Returns a direction that aligns the thrust vector through the center of mass toward the input direction parameter steerDir. local thrustAng is round(vang(ship:facing:forevector,centerOfThrust()),2). local rotationAxis is vcrs(ship:facing,centerOfThrust). local newDir is angleAxis(thrustAng,rotationAxis)*steerDir. return newDir. } function centerOfThrust { //Calculates the center of thrust for currently active engines. Returns a vector in ship-raw coordinates local eList is list(). local avgPos is V(0,0,0). local maxT is 0. list engines in eList. for eng in eList { set avgPos to avgPos + -eng:POSITION * eng:MAXTHRUST. set maxT to maxT + eng:MAXTHRUST. } SET avgPos to avgPos / maxT. return avgPos. } This is part of an attempt to completely fly a mission with the shuttle autonomously and return. Reentry is proving to be somewhat challenging though

What are you seeing that's not working with FAR and the Stock Shuttle Orbiter Kit? I'm currently playing with both. I had to bump up the heat tolerance of some of the internal parts a bit but other than that it seems to work fine.