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?