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.

Thanks, I tried to strip the sounds and sparks from CollisionFX myself and all I managed to get were debug spheres popping up but no particles. I built yours and it still wouldn't work, turns out I can't make Module Manager configs or something; had to manually add the module to a set of wheels, then it works. But the dust color switching doesn't seem to be working. I wasn't sure if it was just too subtle for me to tell, so I changed dirtColor to red, lightDirtColor to blue and still only gray. Not sure why though. But you might want to put the OnPause and OnUnpause events back in, using dustFx.particleEmitter.enabled to pause/unpause the system. Without that, the game will pause but the emitters kinda don't. Edit: figured out why all my dust was gray, I shorted IsPQS to always return true and GetBiomeColor works now. I have no idea what that IsPQS actually does. Edit 2: Don't mind the choice of colors. Two minor kinks to work out, though.

Definitely looks and sounds like you've got Unity's physics bugs and KSP's "symmetry" more tamed than I had, and in a much cleaner way too. So happy to see the tracks are still around. Took a look at CollisionFX on github (seems up to date to me) and sadly that's just how ParticleAnimators work, it applies to all particles of that emitter. I'll poke around it tomorrow, I've got the day mostly free.

Is there anything on github or bitbucket to look at? A couple ideas come to my mind, but depending on how the emitters are written the ideas might be irrelevant and useless.

Yep, that did it. I had only adjusted the Min/Max AoA setting and thought the clamps were clamping some other value. This is with FAR, just my bad designs needing double-digit AoA to cruise up that high.

I've definitely got it working now. I've got an hour long flight cruising at 19k in the background and I don't even need to babysit it, it works great. It holds about 50m lower than the target though, but that's probably because I have no idea how PID controllers work or how to tune them.

It probably did activate when I set the target and I sort of unconsiously deactivated it before takeoff. I noticed in-flight it does after I had posted that. Basically user error, I was trying to pre-set the target before takeoff to avoid fiddling with Unity's lack of UI focus and my backspace being bound to "Abort". My question was more about the target value changing just by activating the assist, but I think now I'm just trying to use it wrong.

Should my target altitude be resetting to the current altitude when I enable vertical control? I set it to 19.5k on the runway, clicked the "Target Altitude" button and got the target updated message, but when I ticked vertical control on around 17k my target reset.

Nice, so much better than needing to keep the debug log up. But if I could suggest a suggestable, maybe use DateTime.Now for the timestamp just to be a bit more human readable.

Make a folder in GameData for the track parts to live, place the plugin DLL in that folder with the track parts folders. The old config files will not work, so replace them with examples from here: https://github.com/6forty/trackar/wiki

You can find the code here: https://github.com/6forty/trackar Anyone can do whatever they want with it. If you want to work on it, I can add whoever as a contributor. Or you can fork it or host it somewhere else if you'd rather.