Jump to content

Booots

Members
 View Profile  See their activity

  • Posts

    378

  • Joined

  • Last visited

 Content Type 

Everything posted by Booots

  1. Booots
    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.
  2. Booots
    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?
  3. Booots
    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).
  4. Booots
    I don't know how well a table would fit in the UI. What about adding a new set of graphs plotted against altitude? Then we could plot various speeds for that altitude.The other challenge is that there can be more than one stall and max speed or local maxima of best cruise (like in the picture @neistridlar posted). I could easily take the lowest stall and fastest max, but which local maxima of best cruise should I use?
  5. Booots
    Alright, time to acknowledge the limitations of this mod. There are some assumptions that my model has to make in order to calculate the flight envelope in a reasonable time (it is crunching over 400 data points during which it has to solve for the AoA that'll offset the weight of the vessel, after all). Assumes no control deflection (the AoA graphs do, but the flight envelope doesn't). Assumes no structural deformation (if your wings fold upwards any, this won't model that). Assumes the landing gear don't rotate (what I mean is, I activate the retracted drag cube but if the drag cubes rotate somehow in the retraction, this won't quite catch that. The safest bet is to retract them yourself if you want a possibly-more-accurate simulation.). Assumes no thrust gimballing. Assumes no torque provided by RCS or reaction wheels. Graphs assume linear interpolation between data points. What this means is that the level flight AoA and/or drag force may vary slightly from what is predicted based on the actual control surface deflection and wing positioning. The pictures you posted look pretty close (within a few pixels) which could be within the the simulation error or graphing error. The pitch input graph, on the other hand could very well be inaccurate. I'm not very happy with my method of predicting control surface force (I'm basically trying to recreate stock methods as best I can with what's in the API description and may be wrong). To answer your last two questions, the lift slope graph isn't a terribly important design chart, but does offer some insight. It shows the change of (Lift Force)/(Dynamic Pressure) with angle of attack. As for best fuel efficiency, I think that, based on the way KSP engines work, your best conditions for fuel efficiency are where you have maximum excess thrust so you can throttle down the furthest. Does that make sense? I thought wrong. Best endurance is at max L/D (within the flight envelope) and best range is best V*L/D, which is not currently plotted or calculated anywhere in this mod yet.
  6. Booots
    Updated to version 1.0.1! This version adds axis labels and auto-adjusting axes. Thanks for the feedback everyone! Download links at the top will get you the new version.
  7. Booots
    Good call! Your way will get you the number you're looking for, but is a bit trickier than the way I would do it. If I were you, I'd pull that from the flight envelope page, like this: The colored region represents the conditions where your aircraft can maintain steady level flight. The horizontal axis is speed and the vertical axis is altitude. The white line shows your stall speed - the slowest you can fly without falling out of the sky. The black line shows your maximum speed - the fastest your engines can push you. The green line shows your maximum excess power speed - the conditions where your engines have the strongest advantage over drag, allowing you to use that excess power to climb or accelerate. So, the red arrow points out your stall speed at sea level - the speed you need to get up to before you can take off.
  8. Booots
    Oh yes! My bad. My old professors would be so disappointed with me. Adding axis labels somehow fell off my to-do list. The tricky part for that will be figuring out how to rotate the vertical axis label. I'm going to the lake for the weekend, but I'll do that when I get back. For now, I'll list the axes here. On the flight envelope graphs, the horizontal axis is speed [m/s] and the vertical axis is altitude [m]. The color axis reflects the variable being plotted. Hover your mouse over the graph to get the units. On the AoA graphs, the horizontal axis is angle of attack [degrees] and the vertical axis is the option selected below the graph. Mouseover the graph and it will tell you the units. On the Velocity graphs, the horizontal axis is speed [m/s] and, again, the vertical axis is the option selected below the graph. Mousing over the graph will again show you the units. Thanks for the feedback! That's why I made this mod - I had a spaceplane that should have been able to go fast enough but only rarely did I happen upon the flight profile to make that happen. I needed to see what altitude/speed profile I had to fly to get supersonic. In future versions, I'll be able to have it draw the line of maximum excess thrust to show the most efficient climb-acceleration profile to fly to minimize fuel use (and calculate how much fuel is needed). Oh yeah, and auto-adjusting axes are in the works. The challenge is having the program efficiently find upper bounds on the fly. Same with the AoA charts where only the middle is viable flight. Speaking of FAR... It's not currently compatible, but I would like to add that. The challenge is multithreading the FAR calculations. I scratched together enough open-source info on the stock aero stuff to make a threadsafe aero calculator, but FAR's methods are not threadsafe. So I could add it now, but it would take a few minutes to generate a flight envelope (instead of a few seconds). I'm hoping to work with the FAR devs to find a way forward.
  9. Booots
    Because I forgot my schooling and didn't label the axes yet, here they are: On the flight envelope graphs, the horizontal axis is speed [m/s] and the vertical axis is altitude [m]. The color axis reflects the variable being plotted. Hover your mouse over the graph to get the units. On the AoA graphs, the horizontal axis is angle of attack [degrees] and the vertical axis is the option selected below the graph. Mouseover the graph and it will tell you the units. On the Velocity graphs, the horizontal axis is speed [m/s] and, again, the vertical axis is the option selected below the graph. Mousing over the graph will again show you the units.
  10. Booots
    I present to you fine spaceplane enthusiasts... the Kerbal Wind Tunnel mod! We all build spaceplanes to fly faster and higher, but how do you know how fast or how high your current design can go? In the real world of aircraft design, engineers calculate the flight envelope for their aircraft before the first test flight rolls out. This mod runs your spaceplane through a virtual wind tunnel while still in the SPH and predicts its engine and flight performance at every speed and altitude. It also gives you a readout of various performance curves, plotting against angle of attack: ... and velocity: Try it out and start building even better spaceplanes today! You can even output the data to a CSV file to incorporate knowledge of the performance data into a KOS script or the like! Check out this Imgur album for more details on these images and more: https://imgur.com/a/D2i4Fge Download it from GitHub: https://github.com/DBooots/KerbalWindTunnel/releases Or SpaceDock: https://spacedock.info/mod/1927/Kerbal Wind Tunnel Source: https://github.com/DBooots/KerbalWindTunnel Released under the MIT License (with sub-components under their own license). P.S. This mod incorporates a pretty sweet graph-drawing library I made. If anyone's interested in super-simple graphing of data, hit me up.
  11. Booots
    Can anyone point me to the proper size for AppLauncher buttons? I've got them at 38x38 pixels, which I thought was the right size, but they're blurry still like they're being resized. Or does it have something to do with getting them via GameDatabase.Instance.GetTexture() ? I think I remember seeing some discussion that that only works for power-of-two sized images, but I don't know how else to load a button texture. Edit: I found the answer. It is 38x38, but the reason it was blurry is because of the method used to get the texture. Instead, use the method here:
  12. Booots
    I've put out a new pre-release on GitHub: 0.9a. As you can guess from the numbering, I'm getting really close to a proper release. There's just a few to-do items left - icons being the main one. If anyone wants to offer their services, I'd be most grateful. (@Rodger, any chance I could rope you into doing another icon for me?) Wish list items like calculating best periapsis and fuel burn along the best-time-to-climb profile will be post 1.0.
  13. Booots
    Isn't it? Can you provide a bit more detail? Does it cause it to crash or something?
  14. Booots
    That's okay. I wasn't going to ask much of you besides your blessing. Thanks! I don't think so. Keep in mind that this isn't doing real CFD or anything. People use GPUs for hard-core CFD because they're good at solving linear algebra like finite methods use. This mod isn't doing any of that because KSP doesn't do that. This mod is just running KSP's native lift and drag functions a bunch of times which amounts to evaluating baked curves and combining the results.
  15. Booots
    Absolutely nothing! I love CorrectCoL and it was a large part of the inspiration for this. Speaking of CorrectCoL, @linuxgurugamer, how would you feel about merging it into this? If KWT is having CL/CD-alpha curves, why not have moment curves as well and sort of have all the aero predictions in one place? CorrectCoL would then be the lightweight cousin that makes the blue CoL marker be in the right place. On the development side, how is everyone finding the calculation time for the flight envelope? Is the multithreading I'm doing keeping it at an acceptable level across different hardware setups? My dev computer has 6 cores and so it's always been super fast for me - is anyone trying this on a laptop or something lightweight? And how about the UI? Are the different tab-like things working out? Would anyone be interested in the ability to layer different curves on the line graphs (i.e. have both lift and drag showing at the same time? That would require a bit of reworking things behind the scenes, but could definitely be doable.
  16. Booots
    I found it. Your landing gear are extended. If you retract them and click 'update vessel' I think you'll see values more in-line with what you see in flight. So yes, the drag values are far too high because landing gear have high drag when extended.
  17. Booots
    Oh interesting! Thanks for trying this with a complicated spaceplane! I made this to show things like those sweet spot islands. I had a Mk3-based spaceplane that I suspected had a situation like that where I needed rockets to push through but then could turn them off and keep accelerating. I'll have to download your ship and add it to my testing regimen. I'm surprised it's not accurately predicting your flight envelope, I thought I had all the prediction stuff nailed... Maybe the fact that they're multi-mode is throwing it off. The wind tunnel calculates using whichever mode they're set to start as, are you changing modes before going supersonic? It also only uses the engines in the lowest stage that has engines in it (though I think yo' stagin' is alright for this ). The lift/drag ratio it's showing is calculated using the actual force results from the simulation, so I'm also baffled why that wouldn't match up. My first instinct is to claim that the native KSP L/D display might not be accurate (normalizing the drag value by something), but I'll do some digging. It might even be resolved by the next point you raised. And no, orbital freefall isn't accounted for yet (it's on the to-do list). That can be simplified to a vertical force with magnitude m*v^2/(a+R), right? That'll actually help reduce drag because the AoA can drop since the wings don't need to lift the whole vessel. Thanks for reminding me!
  18. Booots
    EDIT: There's a new version on the Github page ( https://github.com/DBooots/KerbalWindTunnel/releases ) if you want the latest. Replies injected into the quote in blue. Teal is less than green. I'll see if I can show the colour scale somewhere to make it easier. It essentially goes teal-green-orange-red. Thanks for pointing out that I should add tooltips to the options so people know right away what it's plotting. Thrust available is what your engines are putting out at full throttle (accounting for the thrust limiters) for a given altitude and speed. Excess thrust is thrust available minus drag. Also note that Thrust Available is only the component in the direction of flight (so thrust times the cosine of the angle of attack (the angle of attack is set to the AoA needed for level flight at that speed/altitude)). And yeah, I figured somebody would have to be real Kerbal to want to know their top speed with airbrakes deployed. :p Although depending on how they're coded, if you click 'Update Vessel' while they're deployed it might account for them (that's something I haven't tested). Also, for accurate results, make sure your landing gear are retracted before it calculates. Down the line I want to have an option to auto-retract them or at least put out a message on the screen warning that they'll throw off results.
  19. Booots
    It's ready for a pre-release! Grab it here from the Github page: https://github.com/DBooots/KerbalWindTunnel/releases @eddiew@ZooNamedGames@Mathrilord@MaverickSawyer, would you guys mind trying it and letting me know what you think? Thanks! Edit: It still has the same icons as my ReCoupler mod (I'm not good with graphics) so don't be too confused.
  20. Booots
    Success! While the puppy napped today, I found that one of the KSP functions I was calling was resetting a few FloatCurves to the global ones in the game instead of the cloned ones I was using for each thread. Now there are no more cross-threading issues and the results look good. Now it's just a matter of cleaning up the UI; adding axes and units and stuff to the graph; adding tooltips and the ability to click on the graph for info (this, admittedly, might take me some time); and then a releasable version should be ready to go. Later version features I want to add: A line showing the optimal ascent path for a given orbital altitude (and an estimate of the rocket stage's dV requirement). Accounting for the deflection of control surfaces. Anything else?
  21. Booots
    Oh interesting. I know exactly the place it's throwing that exception. It's been broken for a while, but used to still show that message anyways. I'll see what I can do. I haven't had a lot of time for programming because my new puppy needs lots of supervision.
  22. Booots
    Sorry I haven't posted any updates in a while. My girlfriend and I adopted a puppy a few weeks ago. And while he's super adorable, supervising him is almost a full-time job so I haven't had any time for working on this. I'm hoping to get a bit done this week, though!
  23. Booots
    You may have to delete PartDatabase.cfg to force KSP to update the values it has cached for the DragCubes (this applies even to DragCubeModifiers).
  24. Booots
    I've never modded parachutes, so I don't have the definitive answer for you, but I would look at the ModuleDragCubeModifier down near the bottom of the .cfg and/or the drag cube definitions to make sure the drag cubes match your model and that the drag cube modifiers are set correctly. @sarbian wrote a good description of how some of these things work: https://forum.kerbalspaceprogram.com/index.php?/topic/108665-cfg-modding-parachutes/&do=findComment&comment=1911077
  25. Booots
    I copy it to the each SimulatedPart, SimulatedVessel, and SimulatedLiftingSurfaces when they're created but these are then shared between my background threads. I am locking against these everywhere I use them, though. Same with the cloned DragCubeLists. I'd rather not have to clone the whole SimulatedVessel tree for each of the 12-ish background threads and just use locking (because that should work, right?) because I suspect cloning will take longer than the time penalty for locking.
×
×
  • Create New...