atomicfury

@infinite_monkey and @Jvj, I see the same problem with some of the resource harvesters and converters not working with Karbonite. I poked around in the error logs and found errors showing modules ModuleResourceConverter_USI and ModuleResourceHarvester_USI not found. After looking at MKS, it looks like they were renamed to be USI_Converter and USI_Harvester. I did some editing on the .cfg files to test this and that appears to be the problem. I'm going to report this issue over on GitHub but leaving this here if others have this problem.

I'm seeing the (probably) same issue as @tsaven, the hab multipliers appear to be 0 during vessel construction, USI-LS 0.5.5.0. I put the vessel in orbit and the in-flight numbers were correct. I cleared out all other mods except a clean install of USI-LS and got the same behavior. I reverted to USI-LS 0.5.4.0 and the hab multipliers show up during vessel construction. I'm going to poke at this a little more on my end in case I've done something dumb, but I wanted to put this out there if others are seeing the same thing.

The debug messages are still on! Otherwise seems to work fine.

Airbrakes are treated as a special case in the stock aero system - they have there own set of curves, or at least they did in 1.0 and 1.02. I gave up working on them since I was just trying to get the base functionality in for stock aero. If someone out there is working on them, the code could check for the special modules/curves if the brakes are on, but see what Youen says about changing parts during flight below. I haven't stopped in for a while. Sorry to see folks are having trouble with spaceplanes and wing parts - I never figured out what was going on exactly. Real Life is a bit to busy for me to help now, but here may be some hints in case someone out there is working on this. During testing I found that wing lift was off, and I thought it scaled to angle of attack. I suspect that I missed a rotation or transform for the wing relative to the airstream, but I could never track it down. I know also that unless you forced constant updates, control surfaces might mess things up - when the cache gets built it will use the current state of the control surfaces (angle of deflection and whatnot) to build the cache. If you leave SAS on during re-entry, the control surfaces could move, changing their aero forces. The more control surfaces a craft had, the worse predictions I saw during testing if they kept moving.

Does your craft have any wings, control surfaces or fairings? The stock aero prediction system isn't working quite right with those at the moment.

Make sure you have the latest toolbar. Also watch out that toolbar moves when you go into mapmode - you'll have to hunt down where it appears and turn on the Trajectories button.

Just tried out a Jool aerobrake with the new Trajectories. Worked like a charm! In other news, roaring in at ~10 km/s will generate some heat.

@Gfurst, The code reads the PhysicsGlobals curves - so if you modify Physics.cfg or use ModuleManager to change them, those changes *should* come through. Nothing is hardwired. I'll warn you that the drag/lift associated with wings is a bit off. Regular part drag and body lift are pretty much spot on.

I've tested it with 0.15.2 "Ferri" and it seems to work fine.

KSP now uses the classic drag equation. Drag depends on atmospheric density, velocity, area and a drag coefficient. Atmospheric density and velocity are straightforward - area and drag coefficient are calculated by KSP based on the part geometry and the direction of flight relative to the velocity. One of the best forum discussions is here.

I have good news. (No, it isn't done yet, hang on!) I've patched in some stuff to access the stock aero drag system. Many thanks to sarbian who answered questions and NathanKell for the AeroGUI mod which I use to check my predictions. The job isn't done yet. But I can now accurately predict drag and bodylift as a vessel re-enters while in retrograde. My code can't accurately predict wing lift/drag yet in stock aero. There is a nasty bug if you start with a stable orbit, turn trajectories on, then lower periapsis into the atmosphere ... bad stuff happens. If you start with a periapsis in the atmosphere, it works OK. The other major problem is that performance is slow - now stock aero needs the caching system FAR uses. That shouldn't be too hard of a job but will take some time. I'm not willing to upload a test version until I can squash the bug where you start in orbit but then re-enter. Any brave souls who want to help in development can take a look at my github aero_dev branch for the source.

Wow this looks cool! I will tinker with this. I've had a few mod ideas but the GUI development process is intimidating. Is this intended to work as an API like blizzy's toolbar (looks REALLY close already) and what license do you plan? Also, I'm thinking you should add your /lib directory (with the dependence .dlls) on github to .gitignore and remove them from github. I could be wrong, but I recall that being an issue in the past. Summary: I think this is useful!

Progress report, first I had to figure out how to predict pressure, temperature and density at a given altitude. That part is done, I can get predictions of pressure, temperature and density really close to the actual values given for the vessel and/or parts. That's necessary to get the drag/lift forces right. Secondly, I needed a way to understand what forces are acting on the vessel. It's done on a part basis - I studied Nathankell's AeroGUI mod and figure out some more info about stock aero. I then went down the wrong path trying to implement Mechjeb's simulation - which as sarbian points out was made to be thread-safe and is overkill for this mod. I got in way over my head. Learned a few thing along the way, like I forgot all my vector math. sarbian helped clue me in to certain methods and calls that allow predictions for stock aero, notably Part.DragCubeList.AddSurfaceDragDirection. I've got that working in a test plugin trying to replicate the forces shown in AeroGUI. Then RealLife got the better of me while trying to figure out the vectors. Hopefully I'll get some more time soon. It has been a real mental exercise - I'm used to FORTRAN/C/Python in a command line environment, so learning C# with Unity/KSP has been challenging.

Which method in DragCube? Or is it in DragCubeList? I had pulled out your code (MJ 2.5.0) and implemented it in a test plugin and I've been compared to readouts from NathanKell's AeroGUI. I'm seeing more drag and less lift than stock, but part of that could me porting to code over to a tiny plugin.

I'm trying to figure out the new drag system, specifically for simulation and trajectory plotting. The simulation part is why I can't just pull the info I want right off the parts, I need to simulate a future vessel/part state. (I think.) So Physics.cfg defines four drag curves, among other things, which get put into PhysicsGlobals in KSP. The four float curves I'm interested in are: DragCurveMultiplier DragCurveSurface DragCurveTail DragCurveTip You can look at the curves in the aero debug menu. The four of which get evaluated against mach and combined somehow to get a multiplier on area from a part's dragcubes. Anybody know what it is doing? Well, someone does, the mechjeb source reads that you normalize the dot product of the cube face direction and the drag vector like so: (dragdot+1)*0.5, which I don't know why it does that. Trig identify? Mechjeb then does two different interpolations on the tip or tail drag depending on that normalization. Anyone have any clues for me?

In the Physics.cfg in the KSP directory there are a variety of float curves defined - the 'machcurves' affect drag based on mach value. I think. But don't edit Physics.cfg, because sarbian added the ability to modify those values in ModuleManager. You can also view the curves in the debug menu under Aero I think.

ferram just closed the github issue and committed some changes, next version of FAR should not rip wings off anymore. So don't work too hard on that hack.

@futrtubl, indeed Mechjeb implements predictions for stock aero. Almost everything I've learned is based on trying to back out what MechJeb is doing and comparing to Trajectories. I'm learning I have forgotten all my vector math from college. I've also learned there are several drag curves that are functions of mach and well as direction, each part has a drag cube, such that vessel drag is a linear combination of those part drags (as a function of direction). Air density is important, and is a function of the temperature, which varies by location. All this has to be pieced together in such a way to determine total drag force for a vessel for use in Trajectories. I haven't even discussed lift yet. (Lift actually looks simpler). Compare to what ferram did, which was to hand all that off a single API call that figures the total drag/lift for any velocity direction you want in FAR. ferram = awesome. Anyways, I've got a test plugin I'm building to try to pull the stock aero lift/drag out as a prediction. My hope is to build something that can be plugged right into Trajectories. Anyone else lurking out there and want to discuss stock aero? I'm thinking of starting a thread in Plugin Development.

Thanks Youen! I tested it out and it worked for a retrograde reentry just fine. I was trying out the FARAPI, but was getting nonsense results. Upon examining your code, I was using stock rho instead of FAR rho and I had messed up the world vector. WARNING! I found during tests that the calculatevesslforces call can induce aerodynamic failures in wings in extreme cases. I opened a github issue on FAR. So if someone here tries to predict a really steep trajectory from a really high velocity, your fins/wings might get ripped off for no apparent reason while still in orbit. The good news is that if the predictions are accurate they were going to get ripped off anyways. I am making some progress on stock aero. I'll report back as I try a few things out.

@stupid_chris, Thanks! I had tried an invoke earlier and messed that up somehow and fell back to delegates. I read somewhere that delegates are faster but that may not matter here. This looks cleaner so I'll give it a try. In the meantime though DMagic gave me a clue on what else I was doing wrong. @DMagic, Since the method isn't overloaded it appears the method gets reflected correctly without the type. One your second point, your suspicions are correct - the out is significant on the force and torque and it needs to be specified. Also, when I put the out on the arguments, I found out that you have to pass a Vector3 instead of a Vector3d. After some more googling I found I also needed to specify some Bindingflags which seemed to help. So now I have two working reflection options. It compiles and, well, there is something else wrong. But not this. Thanks! After I clean the code up I'll post something for future reference.

Help! I'm trying to interface with the FARAPI via reflection. I'm new to C#, but I found several examples that seemed to work in other mods. The code snip below finds FARAPI, gets the method, then crashes out on creating the delegate. It looks like the method arguments are wrong. I've been struggling with it, maybe someone here can give me a few pointers. I'm probably missing something obvious. FARAPI definition in FARAPI.cs public static void CalculateVesselAeroForces(Vessel vessel, out Vector3 aeroForce, out Vector3 aeroTorque, Vector3 velocityWorldVector, double altitude) The exception: ArgumentException: method arguments are incompatible at System.Delegate.CreateDelegate (System.Type type, System.Object firstArgument, System.Reflection.MethodInfo method, Boolean throwOnBindFailure) [0x00000] in <filename unknown>:0 at System.Delegate.CreateDelegate (System.Type type, System.Reflection.MethodInfo method, Boolean throwOnBindFailure) [0x00000] in <filename unknown>:0 at System.Delegate.CreateDelegate (System.Type type, System.Reflection.MethodInfo method) [0x00000] in <filename unknown>:0 Code snip: // FARAPI Hookups private delegate void CalculateVesselAeroForcesDelegate(Vessel vessel, Vector3 aeroForce, Vector3 aeroTorque, Vector3 velocityWorldVector, double altitude); private CalculateVesselAeroForcesDelegate _CalculateVesselAeroForcesDelegate; private void initFARModel() { bool farInstalled = false; Debug.Log("Trying to detect FARAPI."); var farapi = AssemblyLoader.loadedAssemblies.SelectMany(x => x.assembly.GetExportedTypes()) .FirstOrDefault(x => x.FullName == "FerramAerospaceResearch.FARAPI"); if (farapi != null) { Debug.Log("Found FARAPI. Attempting Reflection..."); var method = farapi.GetMethod("CalculateVesselAeroForces"); if (method != null) { Debug.Log("FARAPI method valid. Creating delegate..."); _CalculateVesselAeroForcesDelegate = (CalculateVesselAeroForcesDelegate)Delegate.CreateDelegate(typeof(CalculateVesselAeroForcesDelegate), method); } if (_CalculateVesselAeroForcesDelegate != null) { farInstalled = true; Debug.Log("Loaded FARAPI"); } else { Debug.Log("FARAPI found but could not delegate API."); } } }

I had that exact same question and found this: http://en.wikipedia.org/wiki/Area_rule Basically keep the way cross-sectional area changes smooth across your plane design.

I tried my branch on Minmus - seems to work with no atmosphere. I'll give your main branch a spin. I'm hoping to have some free time to poke at the aero this weekend by examining MechJeb's aero code.

@Youen, I forked the repo and tinkered a bit over the weekend and patched in all the obvious 1.0 compatibility stuff. Mostly a new atmosphere depth function, density takes temperature and pressure, and the applauncher wasn't working quite right. I *think* I fixed all that. There may be a NullRef lurking in the applauncher cleanup/ondestroy but I haven't had time to recheck that. That being said, the predictions in atmosphere predicts falling like a brick as soon as your touch the top of the atmosphere. I haven't tried it on the Mun or Minmus yet, as I was just trying to get it to compile and load. My fork is over here. I'm new to github so I'm not sure how to pull request it to your repo.

With the latest ModuleManager you can just define a .cfg. The next Community Tech Tree update will have some solid examples for you. Check the thread out here. Or if you just want the link to the example .cfg go here: http://forum.kerbalspaceprogram.com/threads/100385-Community-Tech-Tree-1-1-last-updated-19-11-14?p=1884633&viewfull=1#post1884633