Jump to content

Booots

Members
 View Profile  See their activity

  • Posts

    378

  • Joined

  • Last visited

 Content Type 

Everything posted by Booots

  1. Booots
    Another development update: It turns out the threading is still causing something weird. I was pretty sure I had taken all appropriate precautions but I'm still getting a different result depending on if I the drag cube calculations on a background thread or the main thread. It's super weird (as multithreading bugs often are). I've narrowed it down to one or three methods, but I still can't figure out where they're going wrong. Once I get those sorted out, it's a matter of drawing axis on the graphs and working out tooltips and this should be ready for a beta release.
  2. Booots
    I love the jump effect too, and I wish I could take credit for it but that's all @TMarkos's work. I'll do some more testing this weekend, but I was pretty sure all was working on the latest version. Any specific situations I should look at?
  3. Booots
    Thanks for reminding me. I'm making that same assumption so far too. That is possible with the current solving framework I've got, but it would add a lot more computation time because it adds a second level of equations to solve. I have to solve which AoA the craft needs for level flight, then what control input is needed for that AoA, and then what effect that has on the lift produced (and then changes the AoA needed) and so recurses. Actually, y'know... It might be faster to solve what control input is needed for level equilibrium flight directly because that removes the recursion need. I think this will be a later feature to add.
  4. Booots
    Yeah, it's the threading that's doing it. Also, I'm guessing you're stuck with the license because of inheriting a license from an older version by someone else? If that is the case, you could theoretically license your own bits of the code under a different, but compatible license as long as the project as a whole stays GPL (according to my reading, at least). Since it looks like the SimulatedVessel and SimulatedPart classes are by you, personally, doing this to those files would let me avoid the GPL for this project, too. Just throwing it out there as a possibility, not actually asking you to do that for me - I don't like imposing on other authors.
  5. Booots
    Also, as I start planning for a beta release in the next week or two, I need to sort out some licensing things. I'm using @TriggerAu's KSP Plugin Framework (which is MIT-licensed), a root-finding algorithm that is BSD-licensed, and a derivative work of the SimulatedVessel and SimulatedPart classes from @sarbian's MechJeb2 (which is GPLv3). I'm not very familiar with open-source licenses and so I want to make sure I get this right (or at least, right by the people who's code I'm helped by). My current plan is this: my own code will be MIT, TriggerAu's code stays MIT, the BSD code stays BSD, and my derivatives of Sarbian's work will be GPLv3. The compiled DLL (and the project as a whole) would then have to be GPLv3 because it links to GPL code, right? And from what I understand, MIT and BSD code is compatible with such an arrangement. TriggerAu and Sarbian, are you both satisfied with this arrangement?
  6. Booots
    Just pinging a few people who have asked for a feature like this in the past. Would you mind giving some feedback? Is this starting to fall in line with what you envisioned? @p1t1o @Jonfliesgoats @BT Industries @Spartwo @ZooNamedGames. And @eddiew, you once said "I'm going to be that guy and ask what the wind tunnel/testing ground will offer that launch/try/revert doesn't..." so I'm pinging you to see what your comments are. Does this show promise as a design tool beyond repeated testing?
  7. Booots
    Yep, I've seen that one in the last couple versions too. It's probably a relatively easy fix, but the error message doesn't seem to impact gameplay at all. Thanks for pointing it out.
  8. Booots
    Okay, so I've gotten some of the GUI issues sorted out. I'm still having trouble with my new graph-generation method, but when logged to Excel, the data looks good. Not the best visualization, but it looks like my new threads are getting the same-ish data as before, but in a fraction of the time and without cross-threaded artifacts. I've also added part highlighting to add a sort of CFD feel. Now it'll highlight high-drag parts in red, and low-drag parts in blue, with green somewhere in the middle. Seen here, the engines are the draggiest part since they have no taper to the back. The wings (because of the drag component of lift) and the nose also contribute a fair amount. At higher speeds, the RCS pods and antenna also turn orange/red because they stick out into the airstream.
  9. Booots
    That controls how close and how in-line parts have to be for ReCoupler to decide they are meant to be connected and connect them. Radius is the distance between the attachment nodes, and angle is the angle between the forward vectors of each attachment node. If you're having trouble getting parts to connect, try increasing either or both of those.
  10. Booots
    All I wanted was to figure out how much excess thrust I had for my spaceplane along its ascent profile. And then I wanted to know the lift curve slope and level flight AoA so I could program my kOS spaceplane autopilot better. Next thing you know, I'm writing a mod to work in the Spaceplane hangar to calculate flight envelopes, alpha curves, and so much more. And it works, sort of totally! Check out the release thread here: https://forum.kerbalspaceprogram.com/index.php?/topic/177302-ksp-142-kerbal-wind-tunnel/ This shows that the Aeris 4A has a ceiling of about 22km and a max speed at sea level of about 790m/s and a max overall speed of about 1360m/s at around 14km using its air-breathing engines. Then, at 15km and at 964m/s its level-flight AoA is 2.8 degrees and it has 365kN of excess thrust. Great! But now I want to freshen up the GUI (thanks @TriggerAu, but this was clearly designed for Transfer Window Planner ) and add in Lift, Drag, and L/D curves for a given altitude and mach number. I also want to move to using background threads for calculating (right now, I either hang the program for 20 seconds while it calculates that graph or put up with artifacts from my non-thread-safe implementation on the BackgroundWorker, as you can see). First, some credits: Thanks to @linuxgurugamer and @Boris-Barboris. I learned a ton about the aerodynamics model from your Correct COL mod. Also your method of drawing line graphs is coming in handy for the lift curves I'm working on drawing. Thanks to @TriggerAu. I learned a ton about making the graph from your Transfer Window Planner. And thanks to the MechJeb team. I'm using a lot of your tricks to make things more thread-safe.
  11. Booots
    Gotcha. So what you're saying is that Unity won't let the GC clean up the texture once the reference is changed and it goes out of scope. Confirmed from this: https://forum.unity.com/threads/unused-textures-do-not-trigger-garbage-collector.476758/
  12. Booots
    Okay, thanks! So if I keep reusing the same Texture2D variable for a texture that changes through the life of the plugin and then Destroy it in the OnDestroy method of the main plugin it'll be all good? Or do I need to Destroy the Texture2D prior to each change/load of a new image for safety?
  13. Booots
    Sorry to revive a month-quiet thread, but I was hoping for some clarification on things discussed here as I'm also running into texture issues building a mod for 1.4. @sarbian, can you expand on what you mean by "they are never removed from memory"? Is any Texture2D persisted forever, whether loaded or created (a la Transfer Window Planner, with a call to new Texture2D() and then bitmap created during runtime)? Or is it just the Texture.LoadImage() method that puts something in memory until the game closes? @linuxgurugamer, Any idea why Unity needs a power of 2? Does it have to be square or just each dimension needs a power of 2? Also, with the method outlined here, can you have textures of arbitrary size? Thanks everyone!
  14. Booots
    This is a very relevant question. I think what @stubbonjeb is asking about is an IDE. I tried using Xamarin (Monodevelop) as the tutorials suggested but the current version (a year ago, when I tried this) could not compile against .NET 3.5 as KSP requires and the older versions are not available. I gave up developing mods on my Mac and just set up a Windows partition and installing KSP and Visual Studio on that because it was easier. @Ty Tan Tu, I hadn't heard that the Unity environment had a built-in C# compiler. Is its IDE any good?
  15. Booots
    @Norcalplanner, I'm loving the updates on how you're using this mod. It's super rewarding to see people using the things I've worked on. 1) Maybe? It depends on how the welding mod works. I think I remember reading that welding two parts with the same module breaks. If that is the case, you'd just have to make sure you don't weld more than one beacon or more than one techbox into a part. 2) The techboxes go on the beacon vessel, not the travelling vessel. 3) That's a personal choice. I generally have a small beacon in a low orbit and a big beacon in a much further orbit but I don't put them outside the SOI unless I have to for G-limit reasons (Laythe comes to mind that I had to have a pseudo-L4 relay). 4) Nope! Any beacon can transfer to any other beacon, regardless of type. I hope this helps clear some things up. My bad, I didn't realize I had set the links to specific versions rather than just the release page. Fixed now. (At least for GitHub, my work's filter won't let me change the SpaceDock one) As @wile1411 said, we'll probably need a bit more info. They shouldn't need 100K EC, so something may be wrong. Can you confirm you have the most recent version? I ask because the old version had some bugs with EC consumption but I thought I had fixed those. There is no cooldown period between starts. But depending on your equipment and orbit they could consume a lot to start and/or to keep running.
  16. Booots
    Sorry for the slow reply. Which version of ReCoupler are you using? It looks like the attachment nodes there have been 'phantomly attached'. That's the technical term for the older version of Recoupler connecting them and then forgetting it had done so. You'll have to delete the parts that should have an attachment node but don't and replace them from the part selector. That should fix it, but if it doesn't, things are gonna get real interesting for me...
  17. Booots
    I wish I could Like this comment multiple times. I wonder, has anyone unknowingly walked into the um, 'effect' of not including one? Any fun stories out there? You are right that minimizing relative velocity could save you a tiny bit of Karborundum. But retrograde orbits are not necessary - just wait until you've gone 180 degrees around the planet and your velocity vector is now going the other way. And really, the big factor is relative planet velocities. Most of the Karborundum cost comes from simply using the alignment matrix and not the velocities, though.
  18. Booots
    Is that using Infernal Robotics? ReCoupler won't create a joint if there's an Infernal Robotics hinge somewhere between the two of them. If not, I'm not sure what's going on here because it's hard to see the structure of your particular craft here.
  19. Booots
    Thanks for pointing out that the CLS compatibility stuff was still included in the distribution. I've put out a new update removing it from the distribution because CLS and ReCoupler now play nicely together without the custom CLS version I used to be packaging with ReCoupler. You should be fine removing the CLS Compatibility stuff and just installing the ReCoupler folder alongside the official CLS plugin (although CLS is not required for ReCoupler).
  20. Booots
    Thanks for pointing this out! It's fixed now. Also, good news! v1.0.0 of ESLD Beacons appears to be compatible with KSP 1.4 so there shouldn't be any need for an update! Cheers!
  21. Booots
    Good news! This appears to be compatible with 1.4 without any need to be recompiled. Carry on with the versions you're using! On the downside, it doesn't appear to be a stock feature yet... Oh well, maybe in 1.5!
  22. Booots
    Good news! This appears to be compatible with 1.4 without any need to be recompiled. Carry on with the versions you're using! (Sorry @eberkain, this means I'll be holding off on an update for a little while longer so you'll still have to wait for your settings option.)
  23. Booots
    Is there a way of specifying the descent profile from the VAB that is then saved in the craft file for eventual use in flight? I know it's persistent once set in flight, but I would really like to set it once in the VAB instead of every time I launch a new vessel using a tried-and-true design. I'm envisioning a part menu button that is visible only in the VAB and opens up a window similar to the one in flight that lets you edit the values stored in the TrajectoriesVesselSettings module (descent profile and maybe even target data). If this isn't already available somewhere I might put together a pull request since I don't imagine it would be too difficult. I'm just not the greatest with UIs so it would certainly need some polishing after.
  24. Booots
    Oh man! Finally gaining some traction on working around the whole "ships are built via a tree" problem! And yeah, it doesn't do surface attached parts because it needs a proper attach node, but you're absolutely right about adding structural parts with nodes. Once 1.4 comes out, their new structural panels have lots of attach nodes so that should make things easier for you. Cheers!
  25. Booots
    I installed this one wayyy back and even though it hasn't been updated, it still works great for me and I use it on most of my science vessels. I think you'll find it a good size for what you want. The last page of the thread has some tweaks to make to the cfg to bring it up to more modern standards of temperature and breaking force.
×
×
  • Create New...