Booots

Hey folks! I have some time tonight so I'm going to be looking into those errors and confirming this mod still works on 1.6.1. I'd also like to get the post-jump orbit predictions for jumps without the compensator.

There’s a series of GameEvents that get fired when the scene loads. Maybe there’s a unique sequence or attached data for a revert? https://kerbalspaceprogram.com/api/class_game_events.htm

Right, that's because I'm trying to use the stock PopupDialog for that window (because it's apparently better?) and it has a very aggressive input lock. I don't think there's anything I can do unless I migrate that window back to the old OnGUI style.

@neistridlar I tried making some stability envelope plots tonight. I managed to get it plotting stability range (range of stable AoAs around equilibrium), pitch torque coefficient derivative around AoA_level, and what I called stability score (the integral of the restoring force coefficient within the bounds of the stability range). Unfortunately, It ended up making the computing time longer than what I think is acceptable. I think I might just leave it disabled in the code for now unless I can figure out how to speed it up. After all, users can use the AoA plots to try speed/altitude combinations that are relevant to them for now.

Alright! Good news! I think I found and squashed the "Stuck at 0%" bug. Try out the newest version (1.2.1) and let me know if it persists. This version also includes the much-asked-for feature of adjusting graph axes at will. Just click the settings button to the bottom left of the graph. The save data button has moved to the right side to accommodate the new button. Once you click 'Apply', the graph will show the new range. Be patient, because if the old data doesn't cover the new range, the graphs will refresh once the new data has been calculated.

RO shouldn't be a problem from a Kerbal Wind Tunnel perspective. Though I haven't tested it, it pulls all the atmospheric and gravity data from the celestial bodies loaded in-game so that should be okay. FAR compatibility is on the horizon for KWT.

@dkavolis and I are chatting in DMs right now, and it's looking promising. Is there any other tools you think would be a good fit to add to the Wind Tunnel?

I haven't personally tried FAR (nothing against it, I'm just happy enough with the new stock aero), so I don't know what analysis tools it has. I would never claim to outright replace something another mod provides, so I'd imagine this supplementing FAR's analysis tools with some more comprehensive info.

Exactly. Until/unless FAR makes improvements to their API that lets me access the data I need (or I recreate their methods inside of this mod, which introduces maintainability, versioning, and potentially licensing issues), FAR unfortunately can't be compatible with this. I would really like to make them work, though. Good news everyone! I managed to recreate the 0% hang-up. Now I can work on figuring out why it's happening. My debug logs show nothing, which is super... helpful. The bad news is that you'll have to wait for the new axes adjustment feature, which is all ready to go, because I want to include this bug fix in the next release. Cheers!

Since this thread seems to be serving as the de-facto crowd-sourced info on DialogGUI, I thought I'd just post about something I discovered for editing the text in TextFields. It is possible to change the text after the window has been spawned if you keep a reference to the DialogGUITextField object via code like this: textFieldObj.uiItem.GetComponent<TMPro.TMP_InputField>().text = "Insert new text here"; I'm guessing there's ways of editing text of labels and images shown in other objects through similar components of the gameObjects these DialogGUI classes create.

Oh, good question. I think KSP only shows lifting forces and doesn't have an indicator for drag. Maybe CorrectCoL takes it into account? Or has an option to? Those indicators are out of scope for this mod, though, sorry. I'm working on a feature right now to adjust axes limits to anything you want. I've got it almost working, with just a few things to iron out. If anyone's watching the GitHub page, they'll have noticed the batches of commits that usually precede an update.

Yep! I made sure to include that fix in the latest release. If you think it's still inaccurate, feel free to double check my math here: https://github.com/DBooots/KerbalWindTunnel/blob/1.2/Wind Tunnel/Wind Tunnel/DataGenerators/EnvelopeSurf.cs#L345 Also, @AeroGav, I love seeing what you're doing with this mod! Thanks, and keep it up! Can you guys post logs when that happens? I couldn't see anything suspicious in the first log @Raiden60 posted, so the more info the better. Because it sounds like it might be related to my threading system, what sort of CPU are you guys running on?

This is exactly the best place to post about this! It sounds like something is going wrong when the mod tries to set up the calculations - I've seen situations like that before. Can you recreate that situation in game and then upload your KSP.log file to DropBox or someplace and post a link? Can you also include a list of mods that you're using? I'll try to fix your bug once I have that info.

Maybe while you’re revamping the stack couplers make ReCoupler stock (or some other tree structure workaround) so that they can be used upside down as well!

Newest release is out! Version 1.2! New Features! New fuel economy and fuel burn rate graphs! New lines for time-optimal and fuel-optimal graphs! (Possibly inaccurate, occasionally buggy) GUI improvements to hold all these new graphs Ability to select multiple graphs at once Remove frame stuttering while calculating (makes it a tiny bit slower though) Also bug fixes, but those are old news. Some of you have had strong opinions about the GUI, so please check it out and let me know what you think! Also, if I'm missing any graphs that you would like to see, let me know because it's versatile enough at this point to graph basically any parameter.

The newest release has near-optimal ascent path calculating. I'm still not convinced my math is right, so anyone that is so inclined should feel free to check it. Thanks!

Hey everyone! I'm back working on this after a busy summer with work and RL fun times. @neistridlar: stay tuned - I've solved the math for determining near-optimal ascent profiles for fuel or time. I've got a working prototype and now just need to add GUI options for it and make it robust enough for users at large (you guys do tend to break things in new and exciting ways ). Speaking of such... That's exactly what I'm doing. I'm seeing a NullRef in the logs, which implies I'm looking for a value the mod engine doesn't provide. It also narrows down which item it is in that it has to be a reference-type rather than a value-type, which should help me find why my mod isn't handling it gracefully. I'm too interested in the ascent profile solver right now to sit down and bug find, but I promise I'll get to it soon. Oh right, I keep forgetting to add the centripetal force. It's a super easy fix. I'll get to that right away too. To get it to take your rocket engines into account, just move them into the first stage and it'll recognize them. It calculates as if all engine in the first stage are on full throttle the whole time. I might have to add some more complicated options for the ascent profile calculator to model the post-flight ballistic portion of the flight, but I like to keep things simple when I can. That's it for tonight! Despite my long absence from the forums, I'm back developing this so stay tuned.

Thanks for the data, I'm looking through it now. For future reference, the KSP.log file is usually sufficient. The output_log file has a ton more information and is less nicely formatted, which makes it harder to sift through. But no worries, I found a clue that will help. I'm not able to open that craft file, though (probably because I'm still developing on 1.4.4). Do you have any other mods installed that will cause issues loading it on vanilla? Can you post a picture of it? It looks like my vessel caching system is failing when it comes to one of the engines; Do you have any mod engines on it? Thanks!

Version 1.1 is released. It includes some performance improvements and now actually calculates your max lift AoA! No more pesky NaNs showing up in the display. Some of your requests for more graphs have been added in the back end, but I need to re-jig the GUI to have place for them. I'm also working on the math to show fuel consumption and fuel economy data as well as drawing the fastest climb line and other useful stuff. My brain hurts from the calculus! Cheers everyone and thanks for your support!

Oh right, I've only marked them as 1.4.2 because that's what I compiled them against since I haven't gotten around to updating my dev computer. They seem to be working fine, though (if a little slow on my old laptop - I'm away on vacation so I don't have my dev computer handy) so I'm going to mark them as compatible to 1.4.5 and recompile them when I get the chance. Edit: As to why this isn't on CKAN, I don't know. I checked the box on SpaceDock to request it be added. They might just be a little behind. I'll look into it.

That's actually a good question, and something I probably should have addressed in the first post. Once you've built the first draft of your craft, instead of test flying it, you can take a quick look at the flight envelope put out by this mod. It will tell you the altitude and speed at which your air-breathing engines won't be able to put out enough thrust to overcome drag (where you should switch to rockets). That information will help inform you on if you've got your SSTO overpowered enough or if it needs more/less air-breathing engines. If your maximum altitude isn't high enough, that means you need to add wing area (or more powerful high-altitude engines to push you fast enough that your existing wing can lift the craft). Varying the main wing angle of incidence won't actually affect your flight envelope much at all - instead it will just change the angle of attack required to hold any given point. After the design is done, this mod will also help inform how you fly your craft. The line of maximum excess thrust (which isn't plotted yet, but is made up of the speed at which you have most excess thrust for a given altitude) can help you optimize your ascent profile more than a simple rule-of-thumb like your 8-15 deg path. By flying at the speed with the most excess thrust, you have more available power to put into climbing - which will actually help you get to altitude faster. Some craft, in fact, are unable to get to their max speed and altitude by simply flying a constant climb angle. One of my designs has to accelerate while level at around 10km and then resume climbing. Otherwise the engines lose power faster from the high altitude than they gain power from high speed and so my climb and acceleration peter out. (This is why I made this mod, because I couldn't understand why I didn't have enough power despite all the times I yelled Moar Ramjets!) Does this help a bit? Yep! @linuxgurugamer's CorrectCoL mod is really good at showing stability and I hope to incorporate a lot of features from that into the AoA plots here. I'm still not terribly confident in my torque and pitch input calculations, so I'm going to keep working on that. Once I work out the math for a good metric of stability, I'll make a flight envelope plot where green is stable and red is unstable (hooray for three axes!). I'm curious what your idea for a 4-dimensional plot involves, though! Since there's also a difference between the stable range and the controllable range, I may also make a plot showing what regions SAS could even hope to keep your spaceplane stable (i.e. show the controllable range with 90% input, saving a bit of input for oscillations/perturbations or pilot input).

It will recognize anything that inherits from the ModuleLiftingSurface class. I took a quick peek at those mods and they all appear to. Procedural wings might be problematic, but it looks like it just wraps a ModuleLiftingSurface and changes the values on that. Can you post a screenshot of the envelope? It could also be that you have a TWR greater than one, in which case your flight envelope won't have any 'blank' areas because you can just stand on your engine (while excess thrust will be near-zero because the forward component of thrust is small when doing that). Okay, more configurability on detail and range for the graphs is going to happen. It'll just take me a while to figure out the UI for that. I'm not sure I quite follow your suggestion for the highlighting, but I'm super open to suggestions on how to make that more useful to people. Oh, that makes more sense and would actually be doable to implement. Now that you suggest drop-downs, I'm thinking of getting rid of the selection grid under the graph and just moving to a drop-downs where you can select which graph (or graphs (plural) for the line graphs, they could have toggle checkmarks in the drop-down). It would make the UI a little less obvious but cleaner and could hold more graph options.

Other people have suggested plotting an arbitrary curve or an arbitrary set of variables too, but I'm hesitant to add that feature because I feel like it would be overly difficult to code in a text-to-math parser. My graphing library and linq extensions could easily handle extracting and plotting any function but the challenge is interpreting what the user wants. I'm not sure how to a) integrate that into the UI, and b) have a robust math interpreter. For now, I think that arbitrary plots will have to stay on the wishlist. For super-users like yourself, I might recommend using the export-to-csv button and using Excel or Matlab to play with the data. My code will definitely allow for resetting the range for the axes and recomputing for higher fidelity. Again, the hard part is fitting it into the UI. In case it's not already apparent, my background is in engineering, physics, and back-end programming. The hardest part of this mod was coding in all the buttons and labels. What I might do is have it put out a regular-detail graph first, and then work in the background on a higher-detail one (based on the bounds of the first-round data) and update the visible one once it finishes. Oh hey! That sounds super cool! I think I will go the route of adding a few *-vs-altitude graphs. That'll take me a little while to do, so don't expect as fast a turnaround as we got for the axis labels and auto-axes. One challenge is that all the good altitude graphs are gonna be minima and maxima which is hard for the code to solve efficiently. Instead of the quick functions of the AoA and velocity graphs, the altitude graphs will probably have to just pull slices from the envelope, but that comes with the drawback of fidelity (ie. it's easy to pull the local max from the envelope data matrix, but you can't say if that local max is truly the local max or just the nearest data point to the real local max). Or I'd have to implement a minimization algorithm, but that comes with the drawback of being computationally expensive. For the cruise maxima, you're right that I could take the better of the two, but that could cause a discontinuity in the line, which my graphing code will interpolate between, potentially causing weirdness.

In case anyone is unaware, I've put out a full release over in this thread: @neistridlar, since you've proven yourself as an assumption-checker can I verify one more thing with you? People have asked for a readout of fuel needed to climb-accelerate as well as the "best profile". I'm interpreting best as best time and/or least fuel burn. Am I correct in believing that the best time-to-climb/accelerate is the path of maximum excess thrust from zero/zero up and to the right? The best fuel-burn-to-climb/accelerate, then, would it be the same? I'm thinking not. Is it the path of best L/D up and to the right? Is there any proof the two paths will converge at the top right-hand corner of the envelope?

Oh you're totally right. Fuel burn rate is proportional to actual thrust (not excess thrust like I was thinking). I'm going to edit my post so I don't lead others astray (but let the record show I was incorrect and @neistridlar was right). Since fuel burn rate is proportional to actual thrust, and actual thrust = drag for Steady, Level Flight (SLF), your least fuel burn rate is a point of max L/D (within the flight envelope, of course). But fuel burn rate only determines your endurance, not range. You're entirely correct that the point of max V*L/D is your best range and is something not currently plotted. I think I may drop the lift slope envelope chart and replace it with a fuel economy chart (in kg/km, since the thrust available chart is already proportional to fuel burn rate in kg/hr).