Razgriz1

I haven't tried my hand at making the wings surface attached yet, though I suspect it may still have issues with the part switch. I'm not familiar enough with how the part switching works to know how to properly convert that to surface attach. If someone does know how to do this, I have worked out the FAR configs, at least preliminarily.

The primary issue is that FAR can't handle the part switches. It calculates the part's aerodynamic properties based on the original attach node, so one wing is fine, but then when you put the other one on, its aerodynamic forces act at the location where it would have before switching the part. This causes unbalanced aerodynamic forces that are uncontrollable. Another smaller issue is that, to my knowledge, FAR cannot handle multiple control surfaces on the same part, meaning that it can't really deal with the split rudder quite correctly, although that one is easier to fudge the numbers a bit to approximate correct behavior. See this discussion in the RO Github for a bit more information on the issues with getting SOCK to work with FAR.

Also it requires FAR in order to pull the data it needs, and SOCK is not well suited for FAR. I haven't completely given up hope yet, but it's not looking super promising.

Ah I had not seen that you were asking about the Moon a few posts prior. You can sometimes launch pretty closely to the orbital plane of the Moon, it just depends. If you feel like doing a little bit of math, you can work out roughly where the Moon will be at the end of a transfer orbit, and then plan a launch window such that your AN/DN lines up with this point, and then perform your TLI such that you arrive at the moon at your AN/DN (roughly speaking, since you don't really "arrive" at the moon in N-body orbital mechanics). This is what the Russians had to do when launching to the Moon since their launch sites are too far north to launch into the plane of the Moon. You don't have to be exact, as you can make small trajectory changes once you're on your way, but you want to at least be in the ballpark. Fortunately the Moon's orbit is slow enough that it doen't move a ton over the course of your trans-lunar orbit. Here is a pretty interesting webpage explaining some of the considerations NASA had to make when choosing launch windows for the Apollo Program.

You can always reach an orbit with a higher inclination than your launch site, no matter where that launch site is located. You cannot reach an lower inclination orbit than your launch site, unless you do something like a dogleg maneuver during the launch. The angle you aim at for any given launch depends entirely upon what kind of orbit you need to target for the mission you're flying. If you have a target inclination in mind, then you can calculate your Launch Azimuth to figure out what angle you need to be aiming toward. All that being said, NASA does not launch polar missions from Cape Canaveral. This isn't because they can't from an orbital mechanics perspective, but rather doing so would require overflying the northeastern US or Cuba and South America. The maximum inclination typically achieved when launching out of KSC is about 57 degrees, or thereabouts. NASA primarily conducts its polar launches by launching southward from Vandenberg AFB, as that takes you straight out over the Pacific Ocean. EDIT: I did not see that there was a reply on a new page to this topic, my apologies for repeating some of what @mateusviccarisaid

I'm sorry I don't really have time to help you try and track that down. I would definitely suggest trying the bisection method that Chris-Kerbal mentioned. Remove half of your mods at a time to find out which half contains the offending mod, then repeat on that half, and iterate down until you isolate which mod is causing the issue. If you are sufficiently familiar with some of the mods and you know that they don't in any way affect the parts concerned, you can skip those. Things like JNSQ, EnvironmentalVisualEnhancements/Scatterer, SCANSat, and Waterfall for example definitely don't affect the control surface module that I've seen cause this sort of behavior.

I don't see any mods that I know cause this behavior, but I would suggest either RetractableLiftingSurface or whatever mod it's a dependency of would be a good place to start looking.

Trajectories also does not take into account roll angle, so you can't use it to plan out crossrange at all. I have been kind of working on a reentry script using kOS for the shuttle in JNSQ. I initially target a reentry orbit such that the apoapsis is at roughly 350km, with a 45 km periapsis directly over KSC (or its projection onto the orbital plane for an inclined orbit) and then hold 40 degrees until the aerodynamics force the nose down. However this profile also assumes a roll angle of 20 degrees with roll reversals, as I was trying to figure out how to work in crossrange control as well. This is also a much shallower reentry than the typical one in order to take advantage of that crossrange capability, so be warned this isn't a "One Size Fits All" trajectory without some sort of feedback control and is much more sensitive to vehicle mass than a steeper If you're interested in taking a look at or trying my script for yourself, its located here: https://github.com/Jakathan/shuttle-guidance I haven't had too much time to work on it lately, but it's at least in a semi-usable state. Note that the currently used variables are for a FAR atmosphere/body lift config, but I left the values that worked for stock in there, you'd just need to read through and replace the FAR variables with those.

If you post your modlist/gamedata folder I may be able to help narrow down the ones that are likely to do it.

There are a few mods that cause it to do that. AECS motion suppressor is one that I remember off the top of my head. Look for mods that alter ModuleControlSurface. The way most Module Manager patches are written will only affect the first instance of a module on a part, and since the split rudder has two of them, most patches ignore the second one. This leads to the two control surfaces having different response speeds, hence the clipping.

The folder above it exists (i.e. \toolbox\matlab\) and it contains some other folders, but not that one. same thing for v93 (whatever the previous version of the MCR you had used was...)

Yes the error is repeatable. I did reinstall the 2021a MCR, and it still throws this error. It looks like the 'funfun' folder referenced does not get installed by the MCR installer. I also tried "borrowing" the 'funfun' folder from my R2018b MATLAB installation to see if that would fix it, but then it threw an out-of-memory error from a likely infinite recursion, although I don't know if that was just because of the older Matlab version I pulled it from. I don't have R2021a installed on my machine so I cannot test it out in a full MATLAB environment for you.

That's interesting! I noticed that some of the moons came before their respective parents but didn't think much about it since the celestial body catalog still properly ordered them. I rearranged the config file myself and that did fix the problem as well. I've got another one for you. I was playing around with the Halo Orbit Constructor in Prerelease 8 using the stock bodies and the same parameters used in your example from a few posts ago: This example works fine in Prerelease 7, but when trying the same thing in Prerelease 8 gives the following error: Log file: It seems to run the computation fine, but somewhere it's trying to access a function that is not included in the compiled script. I'm not super familiar with compiling matlab scripts, but shouldn't that sort of thing get wrapped into the compiled file? At least that's my understanding of how it's supposed to work.

Here you go: https://drive.google.com/file/d/1fp1eys6KXnP9DHfRBhQAYIAjumfo2q_S/view?usp=sharing The only changes I made to it from the base file generated were: added propType = numerical_integration to all bodies changed Sun's epoch (was 0.0000, changed to 224.9 to match other bodies) as the first popup I got suggested Changed bodycolor values for most bodies because gray is boring

Hey @Arrowstar, maybe found a bug when trying to build the state cache for RSS with Principia using Prerelease 8. I generated the bodies.ini file using KSPTOTConnect, then added propType = numerical_integration to all of the bodies in the file changed the Sun's epoch to match the others, and then tried loading the file. Log file:

@ReddyI'm gonna need to do more testing anyway just to make sure it's doing exactly what I think it should. I've only ever really used it on one vehicle, though I have used it in two separate stages of the vehicle, where the offset is different (i.e. Shuttle+ET vs shuttle alone with OMS). I'm happy to help you flesh this out some and to add my function as an example of something you can do with it. We can continue this discussion on the issue over on Github.

@Reddy yeah, my function should work. I'm more than happy to try and adapt it for your script, though my understanding of delegates is somewhat lacking at the moment and I don't really understand the benefit of doing that over just a normal function call. I'd need to do a bit of learning on that subject before I'm able to help you with that. But yes, generally what my function does is takes in an input direction, i.e. the normal direction you would use for steering, and outputs a transformed direction that you can lock your steering to. This transformed direction is the direction you need to point in order for your thrust vector to point through your center of mass in the original direction you input into the function. If your nominal thrust vector is already through your center of mass, then my function should just return the same direction (or near enough, due to floating point error) though I'll admit, I've never tested it on anything that didn't have offset thrust. Edit: Scratch that, I think I get it now: you would do something like LOCK STEERING TO SteeringTransform(<target_direction>) and that SteeringTransform would be a delegate that defaults to just outputting the input with no transformation, but you could set that delegate to something else that does do a transformation instead of like say an if statement with a switch variable. I never really understood the benefit of delegates until just now... Most of my programming experience is just bespoke scripts for things at work or in KSP. I'm not used to generalizing my code. If you come up with how you'd like to implement this on your end, I can see how I might hook my function into this and see how well it works.

Is it an actual shuttle-style spacecraft where the thrust vector is not necessarily in line with the forward vector of the vehicle? If so, you can't really use this code as it currently is to fly a ship like that, as the estimation the script does assumes that your thrust is all acting in the same direction that your ship is facing. If it's like the Space Shuttle, and you don't have a way of compensating for that, then the script will think you're getting less thrust than you actually are, due to some of it acting perpendicular to your facing vector. This invalidates the scripts calculations, and thus it cannot plan its burn duration or attitude correctly. This doesn't really become apparent until the end of the burn, where it's trying to fine-tune the orbital insertion. That's why I wrote the function I was describing above There's also just some inherent issues with kOS's built in steering if you're trying to fly vehicles where the thrust is significantly offset if you don't appropriately correct for it.

At the risk of speaking for Reddy again, this code does not do any sort of auto-warping.

What would be the proper way to apply two separate control surfaces that need to move independently to one part? In particular I'm looking at a shuttle-style split rudder. Is it correct to add two separate modules referencing the two transform names? How does one deal with the two different control surfaces vs the one static surface?

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.