Jump to content

Booots

Members
  • Posts

    378
  • Joined

  • Last visited

Everything posted by Booots

  1. Wow, @Snoman314, you have an awfully low bar for "abandoned", given that it's been exactly two weeks since you raised that issue. I have the same container of milk in my fridge now as I did then! Dunbaratu, in fact, has since un-narrowed it down, and the issue was never with "all other mods installed with it", just your report of kOS. I saw the email alert for this post (because I follow all developments with my work quite diligently) at 5:30 this morning and got so worked up by your misleading and incorrect claims that it is "broken and abandoned" that I couldn't go back to sleep. I kept thinking of all the ranting things I wanted to say, but I'll restrain myself - this is a thread about my mod, not about why mod-makers often seem so frustrated. I will look into the issue in case I can do anything to relieve the problem, but until then, use the workaround you've already identified so you can have your kOS and Wind Tunnel too. Just thought everyone should know before trying this mod: it's really awesome, took hundreds of hours to create, seems to works for 99% of users, and is in no way abandoned. -Sincerely, the author. ----- @Bla Bla, I haven't forgotten about your issue, I just haven't been able to recreate it myself to track down the root cause, even with multi-mode engines.
  2. I've finally solved this, so I'm posting the solution here for any future forum-trawlers looking to do something like this. It turns out that I was so, so close initially. There are two similar options depending on what you want, exactly. If a single patch is enough you can draw it with OrbitRenderer (you can also change the colour this way), or you can use the PatchedConicRenderer if you want multiple patches for encounters and escape. Working code that includes both is included in the ESLD Beacons code, found here. The key steps are: Create a new GameObject: this will hold all the necessary components. AddComponent<OrbitDriver> to the GameObject. Set the OrbitDriver.orbit to the orbit you want. Set the OrbitDriver.updateMode to OrbitDriver.UpdateMode.TRACK_Phys; AddComponent<OrbitRenderer> to the GameObject. If you want a simple orbit, populate the OrbitRenderer fields as needed, and you're done! Set the OrbitDriver.vessel to an Vessel object (I know, I know, we'll break this link later. See the comment in the code as to why we need it.) Otherwise, AddComponent<PatchedConicSolver> and AddComponent<PatchedConicRenderer> to the GameObject. Disable the OrbitRenderer by setting .drawIcons = OrbitRendererBase.DrawIcons.NONE and .drawMode = OrbitRendererBase.DrawMode.OFF; Set the OrbitDriver.vessel to null at the earliest chance AFTER the PatchedConicRenderer has run its Start() method. I use a Coroutine to check until PatchedConicRender.relativeTo != null and then set the vessel to null.
  3. Done! There's still one more bug that I know of (though I doubt any of you will encounter it, except maybe @eddiew ). I've fixed that exception and reintroduced the post-jump orbit predictions for jumps not using an AMU. And, if I may say so myself, they look good! Pick up the newest over at SpaceDock or Github!
  4. Great news! I fixed the error, and have something resembling orbit prediction working! I would like to make it a bit better-looking before I publish the update, though, so you might have to hold on a week or so. In the meantime, the workaround is to always have an AMU active on your beacon. The error only occurs when there is no velocity compensation. In earlier versions of KSP it would fail quietly and still work, but they made the error-checking more aggressive.
  5. 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.
  6. 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
  7. 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.
  8. @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.
  9. 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.
  10. 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.
  11. @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?
  12. 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.
  13. 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!
  14. 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.
  15. 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.
  16. 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?
  17. 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.
  18. 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.
  19. 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!
  20. 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.
  21. 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!
  22. 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!
  23. 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.
  24. 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).
  25. 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.
×
×
  • Create New...