lo-fi

Known issue - been reported many times. There's an explanation in the OP, I believe (or there should be), but the short version is it's a KSP bug related to bounds detection on the skinned meshes the tracks use. We're working on a fix for the next release, but it's not looking to be easy.

Lol. I don't tend to be able to do real stuff. I sort of get an idea half way through, my mind goes off on a tangent and something else comes out entirely... A rough style is about as close as I get. If there's someone who's interested in making specific stuff, I'm always happy to take a model and do the track skinning and config wizardry, though. I have a feeling I'll end up reviving a lot of old wheels after the Unity 5 move...

I'm tempted to ask him if I can finish it, it's my absolute favourite for rovers. Just needs texturing and some props. Excellent, looks like someone's having fun turning the KSC into rubble! Very nice. I must do another set of long tracks in a different style - maybe American. But then there are a lot of parts to finish!

I've never actually tried assembling with KIS, smjjames. The RPM indicator will be negative on one side, that's quite normal, but it wouldn't surprise me if they didn't quite work correctly when first built. A save/reload ought to fix as you've found. My experience with tracks on minmus hadn't been good, though. The low gravity and low ground pressure didn't tend to mix well, which is, I suspect why the steering and brakes don't work so well. I'll hyperedit something similar over and have a play if I get a few minutes. The cockpit is from the the space tug by nil2work [removed link to defunct website] Sadly, the IVA is unfinished and he's not been seen for some time, but it's still excellent. Cool, I'll rip the sound out and implement in the wheel module. Will save a lot of hassle. Yeah, the equations needed a tweak for the TS stuff to be perfect. Think I've got it nailed.

Evening! We've had various issues with skinned meshes - such as get used on tracks - and detected bounds sizes in KSP. For some reason it generates bonkers numbers for the part sizes if parts contain a skinned mesh. This causes two issues: 1) The editor icons were always tiny. xEvilReeperx kindly addressed this with PartIconFixer. 2) Reported vessel sizes in the editors are way out of whack, leading to problems with the low end buildings in career mode. I've never been able to address this. I came across a few posts, the most helpful of which being this one: http://forum.kerbalspaceprogram.com/threads/103152-What-s-new-in-0-90. Having messed about with the GetModuleSize method, I can't seem to figure out what on earth it's supposed to do. It gets called three times when a part implementing it is added, some Vector3's get flung about and that's about all I can figure out. I was hoping it would get passed the vessel size before the part was added in the first pass, but that doesn't seem to be the case. Using: public Vector3 GetModuleSize(Vector3 defaultSize) { print(defaultSize); return defaultSize; } I get: KF.TrackLong added to ship - part count: 3 (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) (5.9, 9.5, 50.9) (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) (11.9, 19.0, 101.8) (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) (5.9, 9.5, 50.9) (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) The reported size of the vessel is H 1.0m, W 2.8m, L 5.2m before adding the track. Any pointers on how we're supposed to be using this interface? Many thanks

Ah... IIRC, there are some checks for whether to apply it, which presumably we're not. In any case, I'd handle the sounds from FKMW, so we can probably just remove the sound stuff, which might be easier than tracking that bug down. I'm working on fixing the Tweakscale float stuff once and for all. Nearly there... - - - Updated - - - Thanks, I'll revisit the code shortly. Any tips for optimisation, other than what we've talked about already?

Ah ha. The bug in question is the reported size of track in the editor. They're reported as huge, which is because of the same issue that causes the editor icons to be tiny without the part icon fixer. I believe the way to manually meddle with it is IPartSizeModifier(), but it's... bizarre... - - - Updated - - - Just got NullReferenceException: Object reference not set to an instance of an object at KerbalFoundries.KFDustFX.OnPause () [0x00000] in <filename unknown>:0 at EventVoid.Fire () [0x00000] in <filename unknown>:0 at FlightDriver.SetPause (Boolean pauseState) [0x00000] in <filename unknown>:0 at PauseMenu.Display () [0x00000] in <filename unknown>:0 at PauseMenu.Update () [0x00000] in <filename unknown>:0 Appears to be OK if you go to a launched vessel straight from the space centre. I had a craft off the side of the runway earlier, which I was clicking on and controlling from there. If I launch a craft from the SPH, the OnPause nullrefs start to appear every time I pause. At least I know why it was behaving earlier.. Presumably this is to do with what you were concerned about earlier, Aqua.

Cheers guys. Latest commit correctly toggles the dust and camera. Previously, it was looking at a local variable that never got its value from the persistence value.

Ah, I see. I'll have a poke about and see what I can find in other mods - if nothing else it's always instructive. Edit: actually, something I struggled with on the camera, and related to your comment about the redundant allocations.. unless I destroyed the camera, KSP kept rendering the flight view through it. Which isn't massively helpful. I'll have to try and figure out why that kept happening.

I see what you mean - that's not ideal! The Gui stuff seems to be behaving, but the icon is no longer present in the space centre (which may be deliberate?)... If you open it in flight, you can't then close it when back in the space centre, though. That list seems pretty sensible to me. I know almost nothing about the config node stuff, so I'll leave it to you guys. Agreed on the biome placements, that's a little out of our scope. Ahhhhh, cookies!!!! Thanks, quite pleased about that. Though there's still the issue of what to do about orbits when the game is merrily going about its thing and the coupled vessels are nothing more than masses in orbit. I'll get back about the nullrefs from DustFX.. EDIT: Then they magically disappeared.... Gotta love a good gimmick

Thanks to a wildcard suggestion from V8Jester, I finally made some solid progress with this: Also a big thanks to Baha for showing me the way with the Burn Together code. Still a lot of work to do on that before it gets released into the wild, but I'm no longer terminally stuck! Thanks to Gaalidas and *Aqua* for dealing with other bits while I'm off playing with crazy stuff. More to come I'd also like to see an end to the need for docking ports to tie rovers down for transport... Seeing some null refs by the way, guys. Mostly related to DustFX when the game is paused. I'll do some more investigation later and report back. I assume it's probably just some stuff that needs hooks into the OnPause and OnUnPause methods, so should be no big deal.

Thanks for the input. Just out of interest, how were you benchmarking? I set up using the stopwatch, but is there an easier method? Every frame is certainly too much. Or is there a better method in general? A few other mods - RPM, reflective windows etc. seem to use cameras to capture and apply somewhere, but is there just a price to pay for doing so no matter what you do?

Start a coroutine to wait a few frames, then try the conversion? Shout if you need some pointers.

You just need to remove the "mesh renderer" component. Leave mesh filter there, though. Edit: Ninja'd!

I remember xEvilReeperx saying that pulling stuff out of the GPU memory would be expensive too. Looks like its mostly under control with the gui and dust, minor bugs aside, so I won't poke my nose in Yep Tyren, we've had then for a while, though they may well need updating. Also the ERS wheel and something else I can't remember. Any wheel can have a KF config made, so long as its not a complete vehicle in one part.

Anything wheel based will break, yes. Parts and plugins will need a major overhaul as far as I understand.

That's pretty much where we're headed. May not be many new parts in the next release, but a bunch of nice features. Parts will follow as they are completed. However, both Zodius and Electronîcfox have parts in the pipeline that are set to use the plugin, plus we have configs for stock and some other mod wheels. And new repulsors, of course...

Part Tools .23 works just fine with 4.2.2. Which is the version you should be using. Installing it, such as it is, is just a case of unzipping into the assets folder inside the project directory Unity creates when you first start and create a project. This will usually be inside Documents\Unity IIRC

Hehe! Ninja! I really need to start bashing the configs into shape so we can release this stuff at some point..

Looks great! The camera toggle does nothing just yet - the state needs to be picked up by the vessel module and dustfx module. The orientation marker bool gets picked up by the orientation marker module. Just reads the bool and figures out what to do. Actually, no I didn't go to the poles on Duna. Will do later. I checked that the load is successful, have up to date MM, only other thing I'm running is the dev helper and a couple of parts. Very odd indeed. I'll have another play later. Thanks V8Jester. We'll get there eventually!

Marvelous! Done Not surprised, it's all just sort of fallen out of my head and been beaten into shape until VS stopped bleating

As it happens, yes. Thanks for the pointer, it's worth a look Apologies for off topic! I'd imagine you may want to make some rework style models if I can get it to work, though

Cool. It's idle curiosity really! I did a bit of googling - there seems to have been a brief discussion a long while back, but not a lot more I can find. Feel free to shout me, Ziw, if you're listening in. I think you picked up IR recently IIRC, so f I can be of any help... I've played a lot with joints in my own meddling, although persistence and time warp issues have so far scuppered what I was trying to do. I'll give it some thought, Zodius. Not completely straightforward, but I doubt it's insurmountable.

I'll maybe ask in the IR thread. Projection tests whether a joint has been bent outside its correct position or rotation by a certain amount and snaps it back if not. It's quite powerful. No, not something I've had a chance to look at. I guess it might be possible to keep checking the dot product of each axis against something in the vessel and see if it's changed, but this seems... insane? Not really sure how to approach this, as it could lead to all sort of crazyness if not implemented correctly. The steering calculation stuff in KF is fairly hefty, so I wouldn't want to just force a recalc every tenth frame or whatever. Didn't you have to manually set something in the stock module to get it to work properly, or was that something else?

Loving the tilt rotor goodness! Maybe a question for the main IR thread, but has anyone messed with setting up projection on the IR joints? My own experience has been very positive - it makes rock solid joints if applied correctly. To the point where it will pull the joints of the parts it's attached to apart rather than shift itself! Granted, it's been a long time since I messed with the IR code, so this may have been tried, or there are reasons it's not possible.. Zodius, if you're waiting, I can do a release without any of the new parts? We're mostly done with the plugin, so there are just a few config updates to get through for existing parts now.