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.

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?

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?

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.

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.

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.

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.

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/

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?

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!

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?

@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.

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...

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.

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.

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).

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!

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!

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.)

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.

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!

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.

Sorry @linuxgurugamer if we're hijacking your thread. We could go elsewhere if you want. Right, 1m/s is obviously much too fine. I do 30 m/s by 750m steps and still get minute-long calculations for a moderately-sized mk 3 spaceplane. There are optimizations I can do and that I'm working on that might cut that time in half. Still, it's not just a line, but a surface and that means the number of calculations is squared. One of the major time sinks is calculating AoA. While in the real world, there is an approximately linear relationship between AoA and lift(until you near the stall region), this relationship would only be approximately accurate for a small range of Mach numbers and altitudes before the effect of those variables throws it too far off. I've been using Newton's method of root finding to locate the AoA where lift offsets weight. Unfortunately this means I have to iterate over all of the parts and calculate their lift at each AoA guess until it converges (about 8-10 times per speed/altitude pair). @Boris-Barboris is right. Any deflection of control surfaces to hold that AoA changes the amount of lift produced and thus the AoA required. Fortunately, this should? be minor and so I've just been assuming no deflection. (I think would be hard to simulate deflections)

I'm seeing that EnrichedUranium has flowMode = NO_FLOW which means unless your engine part itself has EnrichedUranium in it, you'll get the EN depleted message because the engine can't draw any.

From the Module Manager Syntax guide, exponents are @value != #exponent So, here you go: // Set up areaScale = #scale areaScale != 2 volumeScale = #scale volumeScale != 3 // Apply @mass *= #volumeScale @volumeBasedItem *= #volumeScale @surfaceBasedItem *= #areaScale // Clean up !volumeScale = 0 !areaScale = 0