6.forty

I can't imagine why not. If someone sets up a repo for it, I'd bet we could have all the configs updated pretty quickly. That would leave the Virgin Kalactic and Kinetech plugins, are they necessary? I don't know what they provide.

Was it spamming null reference exceptions to your log? lightName is missing and emissiveName is wrong, so the code probably choked on itself. I suppose it wouldn't be a bad idea to have some error handling. Try this for the config: MODULE { name = ModuleEmissiveLight lightName = SIL0225DCLS useAnimationDim = true lightBrightenSpeed = 2.5 lightDimSpeed = 2.5 animationName = SIL0225turnON resourceAmount = 0.0015 useResources = true emissiveName = light_geo lightR = 0.8 lightG = 0.85 lightB = 1.0 } All the fields for the original ModuleLight are left in place, only added the bottom four to it.

Just finished a little plugin to get some glow on with these in 1.0.2, here: https://github.com/6forty/EmissiveLight Source, license, plugin, all there. Plugin DLL is in the "build" folder. In part configs, just replace ModuleLight with ModuleEmissiveLight, move emissiveName into that module, and remove the ModuleKrLightColor block. Default colors can be set with lightR/lightG/lightB just like the stock ModuleLight parts. Uses stock tweakables ingame to set light colors, and they've been made visible in flight.

Works mostly fine for me after a few little tweaks to the plugin @alexustas: I think there's something different wrt 0.90 to 1.0 with the lights' culling masks on the parts. If I don't set them to -1 in the plugin module then the lights will not emit onto the world, only on other parts. Setting that to -1 is why Jeb's bombarded with bright colored light in the IVA in my screenshot, I imagine. I know nothing about Unity's layers, so messing with the culling mask was a wild guess and stab in the dark.

AFAIK the problems with procedural parts not voxelizing properly is unique to procedural parts, they must send a message that the part's geometry has changed otherwise FAR won't know about it. Static parts shouldn't have any problems with that.

Yer a wizard, that does it. What was it that 64-bit made the difference?

Just realized why you can't reproduce it, it's something platform/arch specific. I'm on linux and on a hunch I fired up x86 and everything is fine there. It only happens on x64. Literally the first time I've ever had an issue with x64.

Found a bug with the UI caused by B9 procedural wings, setting the wing tip width to 0.0 causes the cross section graph display to disappear, wave drag displays NaN, and calculating stability derivatives results in the UI doing this: Here's a Player.log of it happening with only FAR and B9 wings present.

Just grabbed latest build, with FAR 0.15.1 a wing tip width of 0.0 causes FAR to drop its spaghetti for me. Here's the tip width at 0.5 and FAR's graph active, all good. And here's the tip width at 0.0 and FAR's GUI breaking after trying to calculate stability derivatives. Graph wasn't turned off, it disappeared on its own and wave drag area is NaN. Has to be some wonky math going on somewhere. It's at least partially a bug in FAR. Edit: Here's the Player.log from a bone stock KSP + B9 wings + FAR, loading a plane with wings that have the tip width set to 0.0. At line 22,078 there's this exception, if it helps any: ArgumentOutOfRangeException: Argument is out of range. Parameter name: index at System.Collections.Generic.List`1[UnityEngine.MeshFilter].get_Item (Int32 index) [0x00000] in <filename unknown>:0 at WingProcedural.WingProcedural.UpdateMaterials () [0x00000] in <filename unknown>:0 at WingProcedural.WingProcedural.RefreshGeometry () [0x00000] in <filename unknown>:0 at WingProcedural.WingProcedural.UpdateCounterparts () [0x00000] in <filename unknown>:0 at WingProcedural.WingProcedural.Update () [0x00000] in <filename unknown>:0

Haven't found any Kraken here with FAR, but I have managed to get a little over Mach 9 and a 2Mm apoapsis with this little plane running the tail jet.

Not sure whether to post here or in the FAR thread, but with 1.1.2 the wings don't seem to be 100% compatible with the new FAR. FAR's voxeling works fine on them and picks up the shape changes, but the CoL indicator is still showing a vector like FAR isn't taking over. Doesn't seem like a FAR issue, it shows only the indicator dot with all the other wings I've tried (stock, KAX, Firespitter).

That was it, all my easings would default to 0.1 and Defaults.cfg showed Ease = 0 for each controller. Deleted the cfg, reloaded, and all's good now.

Think I may have found a bug with setting targets. When I put in a new value and click the Target Hdg/Altitude button with the assist already active, the UI updates with the new value but the assist itself doesn't seem to change; I have to nudge it with WSAD for it to respond to the new target value.

In the gist I posted I've got OnPause/OnUnpause toggling the particleEmitter.enabled field, Unity's docs imply its use is for pausing so it's not the most appropriately named field. I actually want it on all wheels I tried @PART[*]:HAS[MODULE[ModuleWheel]] for stock wheels, but it would never add it; I guess I need to use @MODULE[foo] instead? I just saw your edit, disregard the color values I had set. It was just to have each dust color be distinct and obvious while I was messing with things, I had left the originals there in a comment block so I'd have them handy to revert back to normal colors. I've updated the gist with the original colors restored, removed a few bits I only used for testing, and hopefully the comments are more informative now.

Ooh, I like that. And it'd be easy to make it action group toggleable with color tweakables.. Here's the class as I've currently got it: https://gist.github.com/6forty/befd687add0c77403056 The colors are all messed so I'd have definitely distinct differences in dust colors, and there's a KSPField added to show the current biome color choice as decided by GetBiomeColor on the part's context menu. It's beyond superfluous since that works fine without IsPQS. Not sure about the issue I was having with it, I have no clue how PQS stuff works but I imagine it's responsible for detecting whether you're on the runway to use a generic dust color instead of the biome color.