a.g.

The problem is in how the color in the textures is blended into the final image by GPU - specifically, how it interprets the alpha channel value. The naive alpha model that everyone knows, where transparency is just added parallel to unchanged color data, does not actually allow mathematically sound linear interpolation. It's easy to realize: if you interpolate white fully opaque color and black fully transparent, you should be getting white half transparent, because in reality there is only one fully transparent 'color', with no actual color information. Instead you get half-transparent grey (or dark green like with these images) - that spurious black leaks into the visible image. The solution to this is to multiply the color data by the alpha value before interpolation, instead of after - this is called premultiplied alpha. This obviously requires appropriately prepared texture images, and an option in the rendering engine to stop it doing the exact same multiplication during the actual final blending. Alternatively, in this case you can get away with a texture that in effect contains only alpha data, and fixed color for all pixels. What I've done to those images is basically: 1. Open in GIMP, right click on the layer, select Add layer mask, then Transfer alpha from layer. 2. Right click layer again, check Disable layer mask and uncheck Edit layer mask if set. This reveals the green on black color channel data. 3. Paint the image all flat green. 4. Save as png. (You might potentially also try to instead convert them to TextureFormat.Alpha8 after loading in your code to leave only the alpha channel in memory, and apply the green color via that color thing. This would allow an option to change the color ) Regarding the observed blurring, I wonder if Unity/KSP is doing any silly in-memory compression of the texture images on the fly as they are loaded. These particular textures absolutely must not be compressed. Are you using any KSP functions to load the pictures, or pure original Unity API? Edit: Ah, btw one image is named "HUD_..." and thus fails to load on linux unless renamed.

When the HUD is scaled, a black halo appears around its green elements. This is an obvious non-premultiplied alpha artifact, and to fix it you need to either find a way to render your textures with premultiplied alpha, or modify your png images to work around the issue. Specifically, you need to make the image contain a constant green field in the color channel, and only use the alpha to outline the elements; currently transparent areas are black instead. Note the difference after I edited a few images: It does make the image appear more blurry and hard to see over the bright cyan/white portion of the sky near the horizon - but easier to see over the grass.

Unity engine isn't multithreaded, and you probably can't do any raycasts etc from non-main threads, so they would be useful only for stuff like solving more complicated equations which don't require access to the world.

I'd worry more about terribble wobble causing them to be nearly useless for attaching anything of any significant mass if they become physical. The physics engine acts quite badly if very light and small parts are used between very heavy ones. I didn't test it though.

From B9 release notes, with the totally incorrect part crossed out.

That suggests ModuleManager is not installed or working correctly.

There was a range of B9 versions for 0.20 that did significantly overproduce intake air by a factor of 10 in some cases. When it was fixed in 3.1, the release notes said that it was only a display problem, but that's incorrect - the intakes did produce excessive air. Edit: link to the relevant discussion in the FAR thread.

The executable in 0.21 appears to be byte for byte identical to the one in 0.20.2, so it would seem yes.

Note that double clicks don't work properly on linux (this is a unity issue parallel to the mouse wheel problem), so there shouldn't be any critical features that are only accessible via double-click.

It seems I've found some very specific corner case bug: if I load the 'B9 BRV-4 Heinlein' craft in SPH, launch, end flight back to SPH, and then immediately launch again, all drag-related values in flight data go NaN, and the console is full of "FAR Error: Aerodynamic force = NaN at B9.Utility.InfoDrive". It seems to occur only with this craft, and reloading the craft from the file between launches prevents it; likewise, restart flight also fixes it. I wonder if this is even something generic, or limited to my specific setup too. I could try adding some prints to try and debug this quirk, except that I don't understand much in the actual aerodynamics related code.

This all suggests that with the game constantly changing, and the forum rules being what they are and everything, it is unwise for anybody to rely on any mod unless either they have the skill to update it themselves when it breaks, or the mod uses a license that explicitly and unambiguously allows others to update it if the author goes missing. And supposedly 'still being here', but not communicating any intention to update or not do so, or the opinion on others doing so, or otherwise clarifying the license, is being missing. Also, the license should be included right in the archive of the mod, just in case the forum data loss strikes again.

Incidentally, do only forward-facing (relative to velocity) nodes create additional drag without nosecones, or do backward-facing ones need them too, e.g. in case of drop tanks and similar things?

Somebody else with the same problem posted some commands to apply the change in another thread: http://forum.kerbalspaceprogram.com/showthread.php/33232-Linux-version-does-not-start-unless-some-files-are-removed?p=430800&viewfull=1#post430800

Did you install the latest fix release? That problem is supposed to be fixed there, unless I misunderstand what you mean.

Does your stack trace in Player.log contain the address 0xbcec9f? If so, check out this bug: http://bugs.kerbalspaceprogram.com/issues/752#note-2

Well, actually the flow number in the menu perfectly correctly represents the actual intake air produced, as shown by my flame-out test in the FAR thread: http://imgur.com/a/dAL2W . The air speed bit is just the way it makes a stationary intake produce air by adding a constant to the actual speed; the only difference from the stock intakes is the exact value of the constant.

The quadratic unitScalar is labeled as an intake bug in that MechJeb code too, and it does look like a bug - probably something like a "speed = (speed + intakeSpeed) *unitScalar" line repeated twice or similar. Re intakeSpeed, fortunately the required change if you only want to reduce area while keeping the final value the same is actually increasing it from 100: in the above case, to as much as 455.8.

Can you post the Player.log?

Well, if you take that formula above: and substitute numbers from this screenshot, you get: Which is very close to the displayed 5744.44. Now, if you remove the 250x adjustment, the result would be: To achieve the same result with smaller area you need to use unitScalar2 = unitScalar*sqrt(coeff), and, if I did the math right, maxIntakeSpeed2 = maxIntakeSpeed*(unitScalar2+sqrt(coeff))/(unitScalar2+1): Note by the way that there doesn't seem to be an 'intakeSpeed' field in the intake module, but there is a maxIntakeSpeed. Unless it is doing something tricky with it, that intakeSpeed property in the config might not be having any effect.

Don't jump to conclusions too soon I actually did a flame-out test with the biggest intake, and the engines flamed out at 100% on the dot, so the numbers perfectly correctly reflect the actual air produced: http://imgur.com/a/dAL2W

Um, actually unless you changed things since the release, it is using intake.airFlow, which is exactly the air flow value displayed in the menu. Thus, either the value is wrong in both cases, or it is actually right; the only way to resolve this definitely is by doing a flame-out test in the game. Now, Taverius says that unitScalar and area have been multiplied/divided by the same value, so the result should be right. However, if this code from MechJeb is to be believed to be a faithful representation of the current intake code, the actual formula for the intake air produced is: Which represents a quadratic dependency on the value of unitScalar, but only linear on area.

I'm just very impatient when the choice is to either make a bug report and wait potentially days or weeks for a fix, or fixing it myself in an hour. After that attaching a patch to a bug report just saves time and misunderstanding of what is meant - and you can consider all the points above as bug reports, because without the fixes the tool can't actually be used effectively (or at all without some fixes) for planes or rovers. The only reason I included the .cs files is that windows users often don't even know what a patch file is, or what to do with it. You are free to ignore the patches of course, so long as the end result addresses the actual issues. Since now it seems to work satisfactorily, I don't plan to do any more changes.

Personally I find that both actually make controlling big planes harder - they have enough inertia to be manually controllable with trim and careful key presses, while SAS constantly overcompensates and makes things shake horribly. Things like MechJeb or FAR stabilizers work much better than stock systems with their default coefficients.

That's not an error, that's me telling that it ends up as a big file name with backslashes and stuff, put into the root of ksp dir. To fix this, don't use backslashes, since forward slashes actually work everywhere, even on windows. Or there should be some get separator function somewhere. Edit: I've been tinkering with the source further, so here are a number of changes I think are useful: http://filebin.ca/jTUvpJogaBJ/tweaks1.zip * Fix the [ and ] switch support. * Use KSPAddon (this and the above are unchanged from my previous file) * Instead of replacing the control value when active, add to the current value and clamp to -1...1 so that trim works (auto-stabilizers in e.g. FAR work basically like this). * Install the fly-by-wire callback first in the list, so that it runs before other handlers like the above mentioned auto-pilots; this makes them see the control values as user input and properly switch off. This bit is tricky, because I found a bug in mono that breaks the most simple way to do this. * Add support for the rover steering and throttle controls. * When the caps lock mode is activated, multiply produced control input by 0.4 to allow more fine-tuned control.

One thing you could quickly check is if the (unreleased) 64-bit build for windows contains the string "asm_flags may not have been initialized" that is used in that source code file inside the relevant ifdefs - if it does, chances are it has the same problem.