Ruedii

Good to know. Probably still needs a lot of tuning, but I have felt less hard stutter. I wish they'd implement COW and Invalidation techniques to get full concurrent GC at the expense of efficiency. Oh you might want to look at the aeordynamic calculations and the aerodynamic FX routines to see if all of these are properly running everything possible in TLAB to reduce heap usage.

So enabling that feature might be an option. BTW They probably should update their Ubuntu version requirements. Ubuntu 16.04 , 18.04 and 19.10 are both currently compatible and have update support the line "or compatible" might work here as well. Ideally they should look at possibly building against Steam Runtime. This might improve compatibility.

What's the current Unity version, if it is 2019.x or 2020.x is there a chance we could get that experimental incremental GC in the update?

Could we get 0.4688m and 0.3125m sized probe parts added to (very) late tech tree under new nodes labelled "micronization" and "additive-subtractive micro-construction" for basic probe design, and "micronized rocketry" for propulsion.

GitHub also allows you to fetch incremental changes from the Git repository if they are published. If you are crafty enough you can even apply select changes to an older version

Same set as for me. I have restock installed. This might be an issue.

Might have also been in SXT or RLA. Both of those have updates as well.

I'm still running into a few missing textures. Do you want me to make a public list on Google Docs? (Spreadsheet works best for this.) This might be an interaction with Restock. Any parts that utilize stock textures should check that. If I have the time I will uninstall restock and see if it fixes things.

They should add an option to attach two parts together IF they align close enough. This could allow for much better options.

Yes. There are ways around this, though. Namely, MiniAVC can be moved to it's own directory to avoid this sort of issue.

Quick tip: End your log files in ".log" to get them to view properly on Google drive. You shouldn't be using Proton to run KSP, it's a native Linux game, not a Windows game.

Sure is. Never liked it much either. I don't even use the tail gunner seat in this mod. I just use the various other modules. I did test the tail gunner seat, just because, and everything but the gun functions fine without BD Armory. I prefer to just use the regular seat instead, though, since I don't play with BD Armory.

Any photo upload site is good. Just nab a screenshot. If you want to share the craft files, you can use Steam if you use the steam version, or use Kerbal X for all versions. Yes, you can use crafts that require, or are enhanced for mods.

Yes the guns require BDArmory. You need an updated BDArmory version (which is available) to get them working again. I haven't tested them myself. All other functions work perfectly, BTW. As a note, the gun targeting animations have been broken for a long time, long before 1.5.x. Still, as far as everything else on the gun goes, it works fine. (Sorry about the double post, I provided more info anyway.)

I would like to congratulate Squad, Private Selection and 2K on a much better privacy policy this time around. The EULA still needs work. I recommend explicitly allowing court legal appeals to the arbitration clause if the arbitration method and judgement are found to be unfair due to fault of the other party. I would also have some sort of handling of class action cases, instead of of handling cases one by one when mistakes happened. Mistakes do happen to the best of us, and dealing with those who were affected can get very costly, very fast for all sides, especially for 2K, the parent company. Another company was recently hit with this and their arbitration clause that did not permit class action cases almost drove them bankrupt.

I gave you two crafts, the instructions to fly are in the KSP manual. Now where all your presumptions are; They are all in your formula which does not account for any of those things. You provided the formula, the burden of proof is on YOU to show they account for these things. This includes, the curvature of the top of the atmosphere. I provided you with TWO crafts, and the instructions to fly it I already provided. The stock craft "Comsat LX", and the craft I linked on Steam. Comsat LX was verified by the entire team at squad, so you KNOW it can make orbit. If you can't make orbit your method doesn't work. As a note, Comsat LX has 25% more fuel than my original design, specifically so beginners can get to orbit with it. I can get to orbit with it removing the extra upper fuel tank. The Steam craft demonstrates WHY you need to lower throttle. Simply put a gimbal-only launcher cannot operate with zero thrust or an angle above Try it, it will flip. However, if you lower thrust you can maintain your control while still assending to the target 71km.

Do you need a video? Do you need a craft file? The angle is more efficient because of oberth effect. Simply put, fuel burnt facing the horizon has more of it's energy go into orbital energy, and less into steering waste. Your math is not scientific. It's fuzzy math making false predictions. Specifically, it presumes a linear trajectory. Do you launch with a linear trajectory? Do you launch with your nose pointing any direction other than prograde? If so, that's your problem. You are applying 8th grade algebra to a math problem that requires calculus. THAT is why you are getting a wrong answer. You are specifically using formulas made for model rockets and low altitude sounding rockets, where the curvature of the earth becomes moot. You are failing to account for orbital mechanics, and the oberth effect of how energy spent towards the horizon will raise both your apoapsis and periapsis, and energy spent burning straight up will lower your periapsis, while raising your apoapsis, and do so at a lower efficiency because it's spending energy doing both. Here is a list of ALL your presumptions: You are presuming Kerbin is flat. (The curvature of kerbin means that flying in a straight line towards the horizon is actually upwards.) You are presuming the only option is to fly the rocket in a straight line. (A gravity turn is curved through the full flight, not straight. You are on a suborbital arch instead of a vertical climb) You are presuming your rocket has the same ASLISP as Vacume ISP You are presuming your rocket has the same start and end TWR You are presuming your rockets has the same ASL Thrust as Vaccume Thrust. You are presuming the start weight and end weight of the rocket are the same. Claiming all this stuff is moot is a Trumpian claim, not saying what my experience has proven, as well as what EVERY SPACE AGENCY ON EARTH DOES! BTW, if you want proof, there is a Stock craft I built while working with the experimental testing team that is in the game. All of Squad has tested it. It's called "Comsat LX" I actually added substantial additional fuel to that design from what I could launch with, because I wanted to make it reasonably easy to use, and wanted it to deliver the satelite to orbit without relying on the satalite's fuel too much. Here is a test craft to steam with the minimum to get into orbit. https://steamcommunity.com/sharedfiles/filedetails/?id=1945768347 A rather haphazard, imperfect launch got me 400 Delta V left in the satelite after achieving full orbit. As a note, this later one is one of my designs Squad considered "too difficult for a beginner to fly." In order to make it flyable it also needs a higher tier probe core than Squad wanted in the stock crafts they were adding, because it requires the SAS Prograde Lock feature to be able to fly straight. I also had made a jet with similar issues, but that one was more a demonstration of pushing the limits of aerodynamics. (It had a unique ability of being able to recover stability, after losing it.)

Except you are failing to account that more powerful engines add more dead weight and are less efficient. Also, engines burn less efficient at low altitudes. Additionally, fuel burnt at a lower angle, at an altitude of 24Km is much more efficient, than fuel burnt at 80 degrees. at an altitude of 0km. Finally, you are presuming the flight is a straight line, not a curve. When you can launch to full orbit with less than 2800 Delta-V expended, and less than 1500 ground equivilant Delta-V expended, come back, as that is what I get with my technique.

The ideal launch method is to start at between 5 degrees and 15 degrees from vertical (depending on launch thrust to weight ratio) then keep your nose at prograde as prograde slowly lowers. To deepen the curve lower throttle, to heighten the curve, raise throttle. This drastically reduces drag and wasted fuel.

I keep getting massive performance loss with Kerbal Konstructs. Is there a way I can determine which Kerbal Konstructs mod is causing it, and change it out for something else. (I am suspecting KSC++, but I can't be sure.)

I'm getting a ton of debug spews on MiniAVC, a bunch of error spews followed by an endless loop of NREs that continues as long as I play. I know that the other errors are an issue, and I will examine them, but it should not hit NREs, and should absolutely not spam them. I also noticed that the first dll found alphabetically is being loaded, not the newest version. Here is a small snippet of the NRE that keeps repeating. I can post a whole log to github or pastebin if you want. [Exception 04:24:37.0676660]: System.NullReferenceException: Object reference not set to an instance of an object at MiniAVC.AddonInfo.get_IsKspExcludedVersion () [0x00000] in <946c68c810554a77bc35cab54adcb678>:0 at MiniAVC.IssueGui.DrawNotCompatible () [0x00030] in <946c68c810554a77bc35cab54adcb678>:0 at MiniAVC.IssueGui.Window (System.Int32 id) [0x00006] in <946c68c810554a77bc35cab54adcb678>:0

Stubby nosecones, and short tails are still missing textures. I haven't checked all the other parts. I think the engines are all fixed, now. Big thumbs up for that!

Yes, but KSP doesn't currently support Metal. We have to wait for support before we can use it in mods. Additionally, users of older MacOS versions will be stuck without BPTC compression. However, it's worth noting that unlike DXT3, the OpenGL Mac version of Unity will simply decompress the texture on load. This means only minor performance loss and slight texture memory usage increase for Mac users. It's not like it will break. https://docs.unity3d.com/Manual/class-TextureImporterOverride.html That is very good to know.

This looks like an issue with the conversion program used, not the algorithm. DXT5 normally supports better quality alpha with fewer artifacts. However, if the material was created to take advantage of the artifacts, you need to simulate them in the conversion.

I was saying forward thinking. BPTC is higher quality. However, since Mac doesn't support it, this could be an issue. Vulkan is supported by MoltenVK on Mac and Unity's build pipeline for Metal is simply Vulkan piped to MoltenVK.