lushr

A log is still produced even though no crash occurs; the file is called KSP.log and resides in the KSP directory. It does not matter that no crash or visible error occurs, the log file is produced by every single run of the game. Without it, it's impossible to know what's actually going on in your FAR install.

This is referring to the cross section visualization used to evaluate rate of change of cross section for supersonic aircraft. It shows a graph along the aircraft's length. This is different than the static analysis graphs, which aren't shown in the 3D viewport. It's probably easier to just rewrite the shader for the cross section visualization, not least because KWT doesn't visualize the cross sectional area (since stock aero doesn't care about it). I have a few PRs to fix bugs in the simulation functionality that things like Trajectories and weirder kRPC systems use, on this topic.

Is it possible to save out the tables of values this mod computes? It'd be very useful for designing, tuning, and debugging aerodynamic guidance and control systems.

Is there a way to directly control rocket gimbal and control surface activation on a per-part basis? I'm implementing a control system that needs to produce independent inputs to the engine and the aerodynamic controls, but can't figure out if there's an interface to do so.

It's kind of hard to tell, but I think so? The main issue for me is that I can't use them to attain aerodynamic stability, since their lift appears to be basically zero. This is largely a problem for me because I'm trying to use them to do model predictive guidance for a Falcon 9-like first stage, and without aerodynamic stability the trajectory propagation will diverge (since it doesn't have a closed-loop controller fighting the instability). I'm currently using stock fins, though their control effectiveness leaves a lot to be desired and they cause the vehicle to be aerodyanamically unstable on ascent. At some point, I'll probably make a ModuleManager config to switch them over to the legacy FAR aero model and patch the mod to work with that. I've tracked down a few citations for modelling aerodynamic lift and drag of grid fins (which are weird! Odd stuff happens to them when they go supersonic, since the leading edge shocks interact inside the fins). Would they be of interest/help for picking the right coefficients for the mod?

Thanks very much for the help, it sounds like the best shot is for me to try to use the legacy FAR part modules to model the grid fin as a straight fin. From a quick skim of Kretzschmar and Burkhalter 1998, using a long straight fin model of the same area and width should be ABOUT right for the subsonic regime before the grid structure induces choking through interactions of bow shocks. This should even work fairly well with the existing voxelization of the grid fin, since they tend to induce higher drag (though only in the transonic regime and above and while at low AoA, technically) than flat fins. Does this seem like a reasonable approach? I wanted to avoid this, since it means I have to rewrite bits of the DLL that KRE uses, but it seems inevitable at this point...

On 1.3.1, I'm having some issues with Kerbal Reusability Expansion and FAR. I've asked on the KRE thread, and noone there seems to know how to solve this problem. The issue is that the grid fins don't appear to be acting as fins, and their effect on stability and center of lift is very similar to that of a flat plate of similar shape, size, and position. Using a Kerbal 1.3.1 install with only FAR and KRE installed, we have the following characteristics for a flat plate: Compared to a KRE grid fin: For comparison, here's a stock AV-T1: My strong suspicion is that the tiny little fins that make up the grid are too thin for the voxels to pick them up accurately, a hypothesis which seems to be confirmed by the debug visualization of the parts. I would very much like to use the grid fins and FAR together, but I'm not precisely sure how to fix this. I have a few ideas: The voxel grid could be reduced in size somehow, but this could have performance problems. The grid fins could be excluded from the voxel aerodynamic system and use some kind of arbitrary value forces. Moreover, I'm not sure how to implement either of these practically, and I don't even know if this really is an issue.

I'm having some issues with the grid fins and FAR (note: using 1.3.1 still). Neither appear to meaningfully effect Cm, dCm/AoA, or the position of the center of lift in comparison to a flat panel of similar size. For example, vs. For comparison, here's a stock AV-T1: I *think* what's happening is that the grid fins are being approximated by the voxel-based aero model, but the voxel grid size is too coarse to discover the holes between their constituent fins. To evaluate this hypothesis, here is the debug voxel display of all three evaluated aerodynamic surfaces: Something rather strange is going on with the grid fin compared to the traditional control surface and panel, though what precisely is not clear, and it's clearly much more holey than the flat panel. Are there any ideas for how to fix this?

That's really cool! I've implemented a closely related algorithm using Michael Szmuk et al's follow-on work to G-FOLD that is a true free final time approach, avoiding the golden section search for time of flight. Here's a demonstration video.

I'm having a bit of trouble understanding the drag and lift coefficient values for spherical spacecraft. For example, the following vessel, made using a Procedural Parts fillet tank made spherical: Since the vessel is completely spherical, I would not expect any dependence of the Cl or Cd on angle of attack. However, the chart shows a quite substantial dependence, which seems a bit odd (and, for due diligence, this vessel only consists of the tank so the CoM is centered on the tank's center). To check if this is a problem with Procedural Parts, I've done this again for a few different spherical fuel tanks, including the hydrogen tank from cryogenic tanks: Here's two PP nose cones back to back, which approximate a sphere: Cm dependence on AoA is better, but Cd still changes dramatically as a function of AoA. For the purposes of building an trajectory guidance system incrementally, I'm looking for a part that allows me to ignore Cl and Cd dependence on AoA, which in turn allows pointing without having to worry too hard about aerodynamic forces (only dependent on speed). A sphere would seem to satisfy this requirement, since it's perfectly symmetric along all axes, but FAR seems to indicate that all of the sphere-like-shapes I can produce still have lift and drag coefficients that are dependent on AoA. Is there a part that would let me conceal all the internal parts away from airflow while giving AoA-independent drag and lift coefficients?

I got my landing controller working on the Mun, thanks for the help! Warning, spoilers, I needed things to target.

Under 64 bit KSP on Windows, kRPC 0.4.1 fails to launch with this log: [ERR 20:38:16.581] ADDON BINDER: Cannot resolve assembly: KRPC.IO.Ports, Culture=neutral, PublicKeyToken=null [ERR 20:38:16.582] ADDON BINDER: Cannot resolve assembly: KRPC.IO.Ports, Culture=neutral, PublicKeyToken=null [ERR 20:38:16.589] AssemblyLoader: Exception loading 'KRPC': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 Additional information about this exception: System.TypeLoadException: Could not load type 'KRPC.Server.SerialIO.ByteClient' from assembly 'KRPC, Version=0.4.1.0, Culture=neutral, PublicKeyToken=null'. System.TypeLoadException: Could not load type 'KRPC.Server.SerialIO.ByteServer' from assembly 'KRPC, Version=0.4.1.0, Culture=neutral, PublicKeyToken=null'. System.TypeLoadException: Could not load type 'KRPC.Server.SerialIO.ByteStream' from assembly 'KRPC, Version=0.4.1.0, Culture=neutral, PublicKeyToken=null'. System.TypeLoadException: Could not load type '<>c__Iterator0' from assembly 'KRPC, Version=0.4.1.0, Culture=neutral, PublicKeyToken=null'. It looks like the KRPC.IO.Ports DLL didn't make it into the package, which is causing it to not launch. I can get kRPC to launch again by compiling and adding the KRPC.IO.Ports DLL from the other repository.

Quick question: how is the field return_is_nullable in procedures interpreted? Does the return of a nullable method not appear in the return value list at all, or is its value simply empty with some hole value left behind?

The new format for types is great! I was working on implementing a client in Julia (having a Python layer in between me and kRPC was getting overly annoying), and that solves one of my biggest headaches (parsing the type strings). Thank you very much!

Nothing that reflection can't fix - Trajectories was calling into FAR with it for years, no reason kRPC can't either, though it would probably be a good idea to submit a matching PR to the FAR repo to expose that functionality publically in the future. For this, it should be more than fast enough, especially considering the overhead in the wire protocol. For my application, it's fine if it can only be used in an editor scene, since the aerodynamics of the vehicle are assumed to be constant during the guidance phase, so precomputing the parameters and then saving to be used later is absolutely fine. However, you're right, it would be nice to get it working in the flight scene too, so that the system can adapt to things moving/exploding.