Razgriz1

That is actually THE thing that makes it unusable. You can deal with node attachment by manually offsetting the mean aerodynamic chord, but with the mesh switch, it just picks the first node in the list and always uses that one as it's calculation point, even if the node is switched off in the part switch. So when you do the manual offset, on one wing it's fine, and on the other it's inside the fuselage. I have a version where I moved it around to where it is in roughly the same point on both wings, but it is in no way near correct. I took a stab at creating my own parts that had the default mesh opposite the originals, but I'm not familiar enough with how mesh-switching works in order to be able to do it. I just ended up with a part where both meshes were present simultaneously and haven't had time to sit down and work out exactly how I could make it work.

There are no FAR configs for SOCK, as FAR cannot properly handle the part-switch wings

Allow me to introduce you to the wonderful KSP Trajectory Optimization Tool. Not only is it capable of calculating multiple flybys (in literally any planet pack, as it can import whatever planets you have loaded) but you can do entire mission planning/optimization and launch vehicle design/optimization. It can work with N-body gravity as well, if you use Principia. Huge shoutout to @Arrowstar for this amazing tool.

@KeaKaka your config includes !ReStock presumably because you copied it from Stock Waterfall Effects? Since @MikeD has ReStock installed this causes this specific cfg to not run. As Benjee copies the Vector model before it is modified by ReStock, this is unnecessary in this particular case. MikeD, you can just remove &!ReStock from the first line of the config inside the brackets so it's just NEEDS[Waterfall] and that shouldTM help.

Just create a text file using something like Notepad on PC or TextEdit on Mac, paste the contents of the config KeaKaka posted, and then save it literally anywhere in your GameData folder or any folder inside there. You can name the file whatever you want, but make sure that it has an extension of .cfg as that is how Module Manager recognizes it as a valid file. So for example, the file could be saved as SOCK_Waterfall.cfg Be careful, as some text editors will still try and append the .txt extension after anything you type for a file name. If that happens, you can just manually go in and rename to file to remove the .txt extension.

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?