Gaalidas

So, i've done a little research on how addons for KSP can hook into the base part module's setup to set their own procedures and whatnot. It's something that never made a lot of sense in class mainly because it was never really necessary to use them. Virtual Classes. So, I'm going to do some fiddling locally and see what can be done here. The short of it is that I will likely propose that some of the base KSPWheel modules include a method that uses the keyword "virtual" in them. These methods can be completely blank as far as what's in them but, if called from somewhere in the other classes, it would allow me to inherit the class and then use the "override" keyword to hook into the parent module and modify some things. Again, I'm not ready to make a recommendation just yet, but I'll be looking into this in the next few days/week if I get the time. This would allow me to make a real add-on for KSPWheel to re-implement some of lo-fi's old code without having to modify the original modules at such an extensive level that I've been having to do to implement the code. A cool side note: this is how the "override OnAwake()" method works when inheriting "PartModule" in our own modules. Again, I'll keep y'all posted on my progress. I'm gonna get an auto-configure working if it kills me. Would you believe I don't actually play anymore... at least not right now? I just checked the configs cause I've been in the source code for a while now and noticed you'd renamed all the modules. The DustColors.cfg probably isn't slowing anything down, and it would make an alright fallback I suppose if it could be updated. Current KSP, however, has a bit more ram allowance than the old ones the camera was implemented on originally and I doubt it would cause much extra latency. You might just merge the camera disabler with a global dust disabler and take DustColors.cfg out of the loop entirely. It wasn't really meant to be a long term solution anyway, and would have no use outside of the stock planets as they are now.

I'd like to point out a few things with the current release of this mod. In the KFCommunityTechTree.cfg file: - @PART[KF_*]:HAS[@MODULE[KFRepulsor]]:NEEDS[CommunityTechTree]:FOR[KerbalFoundries] This will have no effect at all considering the module in question is now called KSPWheelRepulsor - @PART[KF_*]:HAS[@MODULE[APUController]]:NEEDS[CommunityTechTree]:FOR[KerbalFoundries] This will also not have any effect because the module in question is now called KFAPUController Is DustColor.cfg even used anymore? If it is, I really don't see a point, at this time, of keeping it. At the very least it was never updated to reflect actual biome texture colors so I would either remove it from the process or give it an updated run. You might be able to update it on the move by detecting the biome a rover is in while rolling, and selecting an average color to attach to the config. I'd still just take it out though considering how easy it is to sample the terrain using the camera.

A really good example is the surface track. That's basically a track, but with the mount on top. So, Yes... I think it would be reasonable to request a wheel where the suspension system is packed inside the wheel space. However, it would probably help any world-be-modeler if they had an example that you could provide for what you're looking for.... something either in another game or the real world that would fit what you're thinking about, before a solid assessment can be made as to what can and cannot be accomplished. I will say this though: I don't think new parts are really a priority at this time. I could be wrong, but this is what I've gathered from the activity lately. lo-fi had a special talent for making wheels, which work well within his original code, at record speeds. This is not a common trait... and his absence is a blow to this project. That being said, I've been wrong before so... yeah... The do-ability of a wheel that has mounting nodes on both sides is something we could actually accomplish now, but it wouldn't have quite the appearance you're aiming for without the source unity projects for lo-fi's models. The nodes themselves I could accomplish with some config tweaks if appearance wasn't an issue. The difficulty here is in the modelling of the part itself. Other problems that could crop up are related to part hierarchy and whether or not attaching more of the ship on the other side of the wheel is going to be stable. With the mod called "Recoupler" it might be alright, since it can attaching parts that would not normally attach in the editor if they have attachment nodes in the same location upon loading into the flight scene, but without it there might be some unforeseen issues. Keep in mind, I'm just theorizing and hypothesizing.here from a purely logical standpoint. I'm really jsut a coder, and not an amazing one at that. Yes, i did create all the original part's stack nodes back in the day, but I got lucky with those. On the note of suspension-only parts, I've been asking for those since I first started working with lo-fi a really long time ago. It has it's own set of issues though, since you're not just working with colliders, but rather IR-style movement of everything attached via that suspension node in the hierarchy. I didn't understand that way back in the day, of course, but I know now why lo-fi shot me down when I would talk about it. It's more in the realm of an IR plugin than a KF plugin. I always did think that IR and KF (or KSPWheel nowadays) would be capable of doing great things if coded for interaction between their modules and sharing of data. Finally... I've done some poking around in the current KSPWheel code, the old KF_plugin code, and some of my own code in an attempt to get lo-fi's deceptively simple auto-configuration code to work with it. I'm really close to a possible way to allow a user to select if they want the steering constraints to be auto-generated, but I've run into the block with how KSPWheel is currently coded. Specifically, it's not coded to be easily extended by an outside plugin. I really need some way to hook into it, or I'd need to simply integrate the old code directly into the current project. I'm cool with that, since it's not really my code anyway, I'm just making it function again... but it's requiring me to make some changes to the steering module in just about every method contained in that class. I ain't done working on this baby though... so who knows what I'll finally come up with. I still have a few tricks up my sleeve for overriding values in the main modules without having to alter the original code... long as the information I need to alter are exposed to the configs. Either way... progress is starting to be made. The goal is for the end user to be able to click a button on a single wheel's context menu and have it auto-calculate steering limits based on its position on the craft, within the wheel's group number or on all of the wheels on the craft. I'm also trying to find a way for the original values to be saved and for it to be a toggle where, while on, manual changes will be disabled and, when turned off, the original settings will be restored. I'll keep y'all posted.

That I could see, possibly. Technically you can make anything appear to be anything, separate from the actual functionality of the part. A good example of this is the repulsor which, in it's very earliest design, was simply a wheel without the wheel visual geometry. It's a lot different now of course, but that's where it started.

Early versions of the color sampler for the DustFX certainly could have handled the complex predefined values for such things. Before the camera came into play we even had a "landedAt" method that somehow was able to detect specific places such as the statics around the KSC. I imagine, with some looking at Kerbal Konstructs, there may be a good way of detecting a static vs. the ground and possibly even what static it is that we're colliding with. I keep running into things that keep me from spending a large amount of time in the code. It's irritating. On the subject of scaling... TS support was in the previous major iteration of this mod, back when lo-fi and I were the main contributors. Good times. In the end, however, there was too much custom code to handle different variables to pass to TS that it just made sense to pull away and implement it separately. TS was amazing for KF back in the day though. I built most of the old TS configs for KF. Heck, I remember when TS didn't exist as anymore more than an afterthought mod for a specific part mod. Good times indeed.

I am so much of a multi-posting offender today... but you'll forgive me due to the size of my posts I'm sure. Otherwise... judge me as you will. As our host has iterated, this isn't something doable at this time. However... it would be so extremely easy for this to be a thing on the code-end that I'm shocked it wasn't made a thing from the get go. My philosophy in coding modules for KSP has always been to put the power in the part-config and, if possible, user's hands. I altered lo-fi's code to his great annoyance, I'm sure, to take away hard-coded values for resource usage and other such things and place them in the configs with a hard-coded default for non-specifying module definitions. Even then, some of thsoe defaults were put in mod-specific persistent config files in the dll directory so they could be configured outside of the running game. I even played around with the idea of expanding the config-panel I had in the old KF plugin to allow specifying a default resource to be taken up by the wheels by default, populated from the loaded resource types in the config nodes. I'm sure lo-fi secretly hated me for that, but I always felt that the person who might use my code in the future would want an asy way to alter things to work the way they wanted them to. As such, most (if not all) the original KF animation controllers came with an easy way to select whether the default state could be toggled, by scene or globally, as well as what it would start with and whether or not it could be reversed after animating. When possible I even tried to give the editor scene the ability to alter the speed of the animation. If I were doing it now, I'd probably try to add adjustable lengths of the extension-retraction animations too on a per-part, per-craft, or global scale. I guess I just figured it was my job, as the programmer, to think of all the ways a future user might want to configure the part module and then make sure that my code exported as many of those options as possible to the module config while still maintaining default values in case a config is missing something. It's much the same as if you look at the stock KSP part modules. You can leave a lot of things out of them and still have a working part because they have allowed almost everything to be specified per-part while maintaining default values for missing data. So... yeah... if no one else gets to it in the near future, you may see some new code hacked together from me. Otherwise... hop to it coders. Chop chop.

On that note... The first versions of DustFX used a form of ground-region and/or location and/or biome detection method to specify high and low color ranges (though I pretty much stuck with non-ranged values for them at the time of working on that). Now we use, primarily, a camera that doesn't see the vessel and just averages the texture colors it's getting. That aside... you could use a combination of biome-detection and texture-color-range detection to set up an approximate slippage scale that could then be adjusted along with the dust colors. In fact, that would allow for dust densities to be adjusted not only on the speed of the craft relative to the terrain but also based on the estimated density of the terrain. Obviously there wouldn't be any perfect setup unless we could get access to the stock terrain/biome stats if they even have any form of terrain density/stability statistics. I seem to remember there being a setting in the game detail settings that had some form of density setting for planetary features, but I don't know if that means anything when you interact with the planet in the end. Of course, the code could be revived, which handled complex persistent settings for the old KF, to store pre-generated stats for some estimated terrain locales which could be updated on the go to create a slow-built database of estimated values for this sort of thing. It shouldn't be too hard to re-implement considering all it did with KSP specifically was integrate with the config node system which, while frustrating at first, turned out to be easier to use than expected. Another variable that could be used in estimating slippage would be the estimate temperature range of the planet as a whole, and then of the latitude of the craft vs the equator. Warmer material would likely be muckier than colder surfaces except when dealing with concrete (so, an exception in the case of anything with an estimate color of gray but not if it's blue-gray so ice doesn't become super stable... could be tricky to code). It would be so much easier if the actual texture could be detected under the camera so you could make overrides for specific texture names on the surface. I'm rambling again I think... I suspect that most of this would be impossible using the stock game implementation of planets. Using the code from planet expansion packs might allow detection of such details directly from the planet comfig files included with supporting mods. As far as I'm aware, however, these mods do not replace the stock planets with their own configurations so it wouldn't be too useful to us for stock surfaces. Either way, I foresee a lot of interaction between mods we don't control to make it all work. I could estimate things based on the sampled color of the terrain, but that's pretty much it without reviving and overhauling code form other sources. I won't say it's impossible though.

On that note, I did at one time extract the texture swapping portion from Firespitter.dll into my local KF project with the intention of digging out useful code to make a part of KF... but never really took it anywhere after migrating the basic functionality. I actually didn't really like how it was implemented in the part configs and was going to alter it for ease of configuring and, possibly, integrate with the existing KF model swap mechanics at the time (used for non-symmetrical tracks that needed to be able to be attached in symmetry modes such as the Screw, aka hypnodrive, and one of the larger tracks.) It's just another of my abandoned projects from when I took over KF a long time ago. if someone were to analyze how it's done in one of those other mod packages and then modify a copy of the existing texture used on the current model, creating a patch with MM wouldn't be difficult. What can be difficult, however, is if the model is extremely complex and has multiple texture calls for different objects and textures. I remember a few complex models that called up a copy of the same exact texture several times and using firespitter was nearly impossible because you needed a separate module for each object that needed to be specified exactly and couldn't be multi-specified. Again, that's why I wanted to rewrite it. KF already had code to find the model object names for use in other calculations and I figured I could integrate with those modules to make object and texture matches auto-populated (or auto enumerated, in coder-speak).

If i get a chance, i'll try to add some stuff for the shadow to put into his next release to expand the action group functionality. Either that or I'll put them in an add-on for KF that I'm mulling over. My plan right now is to try and create an add-on rather than integrating directly into KSPWheel. That way I can add the vessel-aware steering and expand on the module action groups without modifying the original code. This will also let me get around my lack of ability to compile with C#6 features using SharpDevelop (I prefer that to VS due to the fact that VS takes several years longer to load everything up than SharpDevelop does. Something to keep an eye of for the wheel/repulsor group functionality: if you're using symmetry and decide to use an action group to update the like-grouped parts, you cna easily end up activating something twice or more for all the action-grouped parts under that symmetry. I know we did a lot of work in the original mod to counter this possiblity, but I have yet to check on that in the current code. This was more apparent when I had the action groups available to increase or decrease the height on the repulsors by a set interval. If I activated the action group on one repulsor I could then iterate through the rest of the group to update them all. However... if I action grouped a symmetric part it would then activate the command on both parts in the symmetry resulting in double the increment/decrement. That's the trouble with adding action group commands to parts that also have their own settings sharing system, such as the wheel/repulsor groups.

To be fair, I created the Dust and some of the action groups for the original mod... which is pretty much nothing like the current one except in the parts. Oh... and, if any of the parts have retained their stock nodes for optimal placement, you can blame me for those too. Only other thing I did was inspire the smart people to add Tweakscale support to it.

I've been trying to look over ways to integrate the old code, but somehow my copy of the source got really screwed up. Gonna re-download a copy and get back to it. I still have to figure out a way to get around the fact that I can't properly evaluate the "nameof" calls... but I can easily revert that to the old method for testing purposes I think... I make no promises, but I'm definitely giving it a hard look.

Except I think you pretty much imported the dust system directly, didn't you? Either way, I think the old KF code needs to be looked at again for features that could be included with the new code. lo-fi had them very customization while still allowing a user to just slap it on and make it happen.

I thought the mod, under lo-fi's code, already did some of that in the background. KSPWheel must have changed a lot of the back end stuff. Then again, I never totally understood most of this stuff.

Hmm... I'd need to see a shot of the problem happening... but right off the bat I can think of a few things that might cause this. First off, I'd make sure the wheels are truly attached the right way up. Beyond that, I could imagine that something has been borked on the scale implementation, which would be a configuration problem and totally not something you could fix yourself. I would also do a test with a craft layed out the same way except with the normal sized wheels to see if the problem is with the wheel itself or whatnot. I do know more recent work on this mod has implemented damage states and, if the wheels are being overloaded then they could be breaking upon trying to turn. Either way, it sounds like a bug.

Just hoping this thing is still compatible with 1.2.2 before I start telling the streamers I watch about it. Don't want to cause issues with those guys.

So... I was watching a mod spotlight of this mod that Kottobos did recently and discovered some issues that I'd like to address at this time. I took a dive into the source code and added something that I think would benefit the end user. This is related to the information about each size of part in this mod from the editor. Right now there's not a lot of information provided outside of a giant wall of text in the description. This can be displayed in a better way in similar fashion to the fuel tank amounts that are shown in the part info panel. After going through the code and making some adjustments, I came up with this little bit that you can add to the top of the "ModuleMassAccelerator" class just above the "armNetwork" method: public override string GetInfo() { // Adds a part info entry to the part details. string result; result = string.Format("Mass Accelerator Module.\n{0} {1} used for every 100kn/second.\nLoading Distance: {2}m.\n", resourceAmount, resourceName, loadDistance); result += master ? "Control Unit" : "Extender Unit"; return result; } This will enable the said display and stick that formatted information into it, I believe. It's been some time since I compiled a plugin for KSP but, as this worked back when I was working on Kerbal Foundries, so it should be fine now. It should also be noted that this technique works for any module added to a part config, and the string can even be put into a "KSPField" and returned in the above method so that extra descriptions cna be defined inside the part.cfg under the module in question. Note: the line with the "string.Format()" in it should all be on one line, and should paste into the code properly if copied as one line. In case it doesn't, I would suggest altering it to be on one line again. Most IDEs will likely be able to figure out what you're trying to do either way, but better to be safe. Anyway, that's my little contribution to the future of this mod. Take it or leave it. I think the end user will thank you for adding it though. Edit: Another thing I noticed in the display of the context menu (right click when in flight) is that the unit of measurement is displayed right on top of the number without any spacing. This is because the units display in KSP assumes it's displaying an abbreviation of the unit. I would suggest changing it to this: [KSPField(isPersistant = false, guiActive = true, guiName = "Accelerator force", guiUnits = "kn")] public float acceleratorDisplayForce; //in kilonewtons This will display it as, for example, "1107kn" instead of "1107KiloNewtons" or some such thing. Much cleaner. One additional thought... though this would require some code rewriting and such... would be to simplify the construction of these drivers by eliminating the different parts for the Network and Control nodes. On launch, you could have the module check to see what order they are attached in and automatically select the proper node type. You could also add a context menu option to allow the user to select which part to use as the control node which would then reset all the others to act like network nodes. If you're interested, I could look into modifying the code for you to allow this to happen. I would also think that adding a remote control unit that could be attached to a craft would be awesome. This would be a small box-like part that could allow a user, on the craft that wants to be shot out, access the mass driver control unit remotely. The code would simply search for a control node on a mass driver enabled craft within the range of the launch range plus a little leeway, and then pass commands to it. I'd be interested in doing this as well if you'd like.

That's what always stopped my in my tracks. A lot of UI work has been done in other mods to allow for configurable presets, but it's a lot of work to get right and I never had the patience to sit down and tweak things with super-slow load times of KSP and whatnot. I also never fully fleshed out how I was going to make these groups accessible. There are some options that are usable on any of the wheel parts, but others are more specific to that part. My initial idea was to have a separate module handle action groups and passing that action to the main module. This would allow one to easily restrict certain group functions from being available on a per-part basis in the part config files. I need to experiment further on this.

The swap was in the editor only, and was originally intended as an automatic swap that would only work if the part was attached on the correct side that matched the default state. The other side would then swap to the other tread-direction and/or any other swaps for that sub-model. It was a similar thing to the model swaps in the B9-HX parts or the Firespitter texture/mesh swappers. No plans were made to allow this to happen on-the-fly in the flight scene from what I was able to tell. I've yet to launch the game and investigate... but it sounds like you have an automatic switch system in place. Now you just need an override button added to the part that will override the automatic swap for that specific part (if not placed in symmetry mode of course, since parts tend to stay connected when symmetrically placed.) The wheel is part of the medium wheel design if I'm remembering correctly. If you look at that wheel model (I assume we're still shipping that model with the mod...) you'll notice it has a steering swivel that could, potentially, turn around full circle. In fact, If I remember correctly and it hasn't been reworked, that model also has a repulsor plate stuck in the middle of the wheel on the outer edge which was part of the repulsor-wheel transformable part. That aside... the crawler wheel was one of the very first exotic steering systems lo-fi experimented with. Way before your involvement with this mod. In fact, the model wasn't even fully textured back then either and I don't think we even had a proper working model for the repulsors... or, at least, not the surface-attach repulsors. The vision, from what I was able to gather, was a wheel that would act like the normal medium-wheel for the most part but, upon switching modes, would synchronize the steering angle between all wheels of the same set (the entire craft back then, before wheel grouping) to face the exact same way relative to the front of the craft. That way the craft could move it any direction without turning. That's where the code stopped being worked on from what I understand. The problem with it was that, once switched on, the wheel could never be reset to center again. The relative steering system, which turns the wheels by differing degrees based on their position on the craft, wasn't turned off either. This meant that you could use the regular turning keys to turn the vehicle while the wheels were centered on a different angle. This was great, for the most part, but also made it difficult to reset all the wheels to normal center. In the end, your craft would never drive straight ever again due to the fact that you couldn't get them to re-center the crawler portion even when you turned off the crawler steering system. Now... re-centering them seemed like trivial stuff... to me anyway. However, I was not a coder back then at all and so couldn't do it myself. I also didn't have access to th repo back then. lo-fi was more interested in buffing his steering systems and making new models. He also wanted to incorporate tracks, which started with the RBI inverting track and the crawler track. It wasn't until I started coding and picking up errors in his code base that I got involved in the project and, by then, crawler steering was history. I still think the centering could be fixed quite easily if that module were to be resurrected. The fact remains that, while in crawler steering mode, you wouldn't be using the wheels in any normal fashion. The best idea is to simply turn off other steering modes while the crawler system is active and then return it to the previous mode when finished. Re-centering the forward vector of the wheels should be optional, and possibly have a way of re-centering to a specific angle. This would allow one to make a craft that can drive backward without having to change the angle of control. All that means is that the steering system center itself on that new angle instead of the forward vector of the craft. Control is the next thing I want to mention. Originally he had the crawler steering always active, like I mentioned earlier, where the variable steering would still work even when crawler angle had been altered. The controls for the crawler angle were mapped to the alt-maneuvering controls (I forget which keys... the ones on the other side of the keyboard used for translation maneuvering when in rotational mode for standard RCS systems) but there was a nicer system discussed early on. The idea was to make it very intuitive by making the wheels respond to the relative direction, based on the craft's forward-vector, of the button pressed on the numpad of your keyboard. If you are facing forward, like you are when launching the craft, and you pressed the 1 key, your wheels would all turn to face back-left and then start moving that direction. Depressing the button would stop the movement but leave the wheels where they are. Pressing a different button, like 5, would cause them to reset but not move the craft anywhere. 8 would reset the wheels to forward and move the craft, 7 would angle toward the front right, etc. I always figured you could add a precision mode based on the numlock state which would stop the movement action, but angle the wheels in the direction pressed, varying the speed of the angle change based on how far from the current state the button is. For example, you have numlock on and the wheels are facing forward. You press 7 and they slowly turn towards the left until they reach the preset angle and then stop. Lets say you hit 1 instead of 7, then the wheels would turn rapidly towards the 7 mark, then half speed towards the five mark, and then slowly towards the 1 mark until reaching the preset angle. Hit 2 instead of 1 and the wheels will either default to turning one direction, or they would approach the angle from the nearest side they are currently facing, again varying speed as they get close to the desired angle. It's a lot of stuff that could be slowly implemented over time as long as the angle of the wheels could be made into a public variable accessible from the vessel-level. When vessel-modules made their mark on the modding community, I thought that, perhaps, such a system would be at home in such a place as a vessel module so that the wheels weren't constantly re-hashing the same commands individually. If the angle, and the angle changing methods, were usable from that scope, then one could also create action groups to fine tune things, and even set up wheel groups to crawl separately from the rest of the craft for some truly inspired creations. Anyway... that's the whole story from my point of view from the beginning onward. Yes, I'm that old.

Back in the day I was toying with an idea to create a sort of repulsion-steering module. The thought behind it was that a repulsion plate could be angled and used to "push" in a direction other than straight down, thus gently nudging the craft away from the surface if one exists within range. In KSP this would be, basically, an RCS port using the repulsor system instead of fuel. It would only apply force if a surface to repulse against was detected within range. This also tied into my idea of an anti-repulsion mode for the repulsor. (attraction module?) that was going to allow me to make repulsion crafts able to climb hills without needing a constant thrust to counter gravity-sliding down the hill. This would also have been the start of a repulsor drive. I coded the basic constructors for the system and then had to give up due to school. I might have time in the future to pick it up again.

Back in the day we had a switch that could be hit to toggle the left/right side. The attach nodes were also my idea for extremely precise and stable connections to the craft. It helps a lot when retrofitting rover body mods to use tracks instead of the native wheels that come with the mod in question, which usually have attachment nodes for their wheels. What... no plan to resurrect lo-fi's crawler wheels? So sad... Overall man... looking amazing with all the new content. I intend to look into a few of my ideas for improving the dust effects and other improvements I was working on before I gave up on the project... I'll let you know if anything pans out. Otherwise, though, good stuff. Keep it up.

The repulsors will likely enable as if they had been loaded into the flight scene directly since, upon undocking and/or decoupling, they are technically being respawned as a brand new vessel. However, some states do carry over to the new craft so it's possible it would work as intended but might activate for a split second before the settings are applied properly. In older test-builds I did, when I was heading this up, I had them disabled by default which meant you had to have a grounded landing option for your vessel for the first launch. I never thought about decoupling or undocking.

I think it's likely that you'll have to go procedural for drag cubes... I stopped coding for KSP before the drag-cubes became a real thing so I have no idea what the code for that looks like.

Popped back in to see that things are progressing nicely. Water propulsion, water spray... wow... coming along very nicely. As for action groups... I remember doing a lot of those back in the day and, if need be, I can create as many of those as you'd like for anything that can be changed in-flight using a context menu. I did, at one time, want to create a way to configure things in the editor and/or the part configs to modify what the action groups did. For instance, an up/down adjustment that can be set to a custom rate of change. That I never really got functional, but I never got a chance to test some of the ideas I had with editor-only tweakables allowing per-part adjustment of change rates when using action groups later on in the flight scene. I'm a big supporter of action groups overall. Chassis... I remember the old mod (Rubber-band Inc. I think) had the really massive tracks in a chassis format as a part... I don't remember if it was a multi-mesh part or a complete mesh though. A steering module separate from the wheel/track itself is something I've had on my mind for a long time. I would agree with previous posts that this is more in the realm of IR part manipulation, but there is a lack of ability to tie that in with the steering if KF so that it uses the rotation of the IR part instead of the track's native steering and stil lallows for the tracks to behave properly. I'm thinking some kind of new module, perhaps even a new plugin, that relies on both KSPWheel and IR, to bridge the gap between the two mods will be needed to really make that type of thing a reality.

Just want to come in here and mention how seriously awesome that crane is. So... on the modeling topic... no, I can't do any of that. However... if someone could, at the very least, nab those stock wheel models and simply add the geometry to support the extended suspension and what not added by KF, that would be an excellent way to start the expansion of the KF-enabled parts. It would be a bit better than the old project to simply make configs for the stock wheels. On top of that, the new stock-modified parts could still be made to seamlessly replace the stock parts at run-time using MM configs so users could plug this mod into their current games and not have to rebuild their vehicles to use the new features. Just something to mull over. Also... something lo-fi was dabbling with back in the day was landing legs that could be adjusted on the fly... possibly even auto-level/auto-extend to the ground to keep either the craft level with the gravitational down vector, or keep the legs at a specific angle while still resting on the ground properly. Might be something to take a better look at. As for the issue of too many controls on the individual wheels and/or key configs and whatnot... that was one reason why I made a GUI to handle some functions of the wheels that didn't need to be part-specific. What I didn't manage was to make those settings stick to that craft rather than being global changes. I did have an idea for a part that could be attached somewhere on the craft that could contain action-groups/context menu tweakables for various settings that make little sense being on a specific wheel. Examples of this might be the turning speed settings that would not work very well if applied differently to a specific wheel. Another good example might be motor settings and whatnot. The motor itself should still be part-specific, but the settings for such motors I would think would make more sense being synced for the craft itself. Alternatively, i had to thought of simply dynamically adding a control module to the root part of the craft, or the main control part if I could get the code to detect that. It wouldn't work too well when a craft has multiple control parts, or has a root part consisting of a panel in the middle of the craft, but you get the idea. I never really released any of my WIP code for that.

THAT... was awesome. I know what's happening there too I think, depending on the current implementation of water-repulsion. In the old days we used an invisible plane that would be kept under the craft (within reasonable speeds anyway... I never got around to adjusting the re-positioning-rate based on craft speed). Under extreme circumstances the repulsor could skip under that plane and get stuck since, technically, it was really just a wheel collider that had no visual model associated with it. Think of it as a wheel that's reacting to a flat panel clipped just above the top of the stock collider, but below the suspension. The stock wheel will fight that panel a lot and often glitch out completely. Repulsors, however, have extremely strong suspensions and, upon reaching land and no longer needing the slider plane, they will react violently, like a spring-loaded jumper-toy, when the water-slider gets removed and the colliders are free to do their job. My only solution, in theory, was to make water-logged repulsors not actually function at all. However the repulsors in your video were not under the water so technically, if re-booted, they could be made to re-initialize the water slider and slowly re-elevate the craft properly. An alternate solution could be to temporarily reduce the suspension height to zero when the water-logged situation is detected, remove the water slider completely, and then either re-initialize and slowly raise the height back to the set value by the user or have them remain unusable under the colliders detect the planet surface and then reinitialize the repulsor and slowly step up the height. Either way, the kracken gets a real kick out of people trying to go from under water to land with repulsors. Edit: one more note... I think that a repulsor could still work under water if the craft is near the planet surface... but I don't see that being a necessity unless someone is sinking a super-heavy craft that totally overwhelms the buoyancy of its parts. End edit. In previous versions of KSP and KF there was no stock underwater behavior. It was all due to camera bugs and workarounds that anyone got under water at all. There wasn't any stock buoyancy interaction with water either... if buoyancy was even a thing in KSP. I took over KF when under-water had just become a thing and did some preliminary work on it before I had to close up shop. I never got anywhere though really. I was still working on the water spray effect when that update came and, at the same time, KF started nullreffing anyone who paused the game or entered a menu during flight and I got overwhelmed. By the way... with the hovercraft skirt idea, you could just build the parts as if they were single inflatable air-bag like parts. When placed side-by-side they could, as bad as it is, clip through each-other slightly to give the illusion of simply being a bumpy skirt. If the parts then changed shape slightly with compression and movement, then the multiple parts would creat an interesting effect similar to how the tracks react to being on the edge of an incline with each section of the suspension reacting to the shape of the terrain independently. Alternatively you just have a set of basic shapes and make use of tweakscale integration to make them fit to the craft the user wants. Procedural shapes for KF-based wheels have been discussed, but the complications were always a bit too part-specific to allow for procedural lengths to correctly spawn a dynamic number of colliders to match. On paper, so to speak, it was very possible but, under Unity, not so doable. EDIT: one last little thing before I finally shut up for the next hour (at least, after that no promises). I saw on the last page a question about turning the dust effects off. My original GUI had that option and I put it in specifically with low-end rigs in mind. Actually, it had two options: one for turning off the camera sampler (which does have some performance drop to it) in favor of hard-coded values that were never fully updated with actual color data, and another for turning the entire thing off globally. I may have also had a slider for capping the effect thickness, but I don't remember if that ever got released to the main distribution or not. I was also experimenting with the ability to have a craft with lots of wheels self-limit the dust to a certain number of emitters per a certain unspecified unit of measurement and/or if another wheel part was detected in close proximity in the backward-vector of the part/craft orientation. As you can imagine, the code got really complicated and hard to keep track of. I never got anywhere with detecting the proximity of parts in real time like that without totally revamping how the dust module was applied to any specific part. My most successful attempt basically made use of a dummy module attached to the part itself which would allow setting part-specific parameters for the dust on that wheel. When the craft was loaded into the simulation ("flight scene" I believe) a vessel module would scan the parts on the craft for the existence of this dummy module and then dynamically add the real dust module to those parts, if the vessel module detected that they were worthy of it after looking for proximity and/or position on the craft of the wheels in question, and load in the data from the dummy module into them for use in fine-tuning the specifics of that part model... and then apply any global settings that had been set in the GUI and/or the config file. It's all quite headache inducing, but I was on a roll back in the day... then the water buoyancy patch came out and I was screwed over.