Gaalidas

I have been given the blessings and permissions to continue the Kerbal Foundries mod in the absence of our fearless leader lo-fi. He's moved on, more or less. Considering all the work he's put forth to reinvent the wheel, quite literally, I believe he has more than earned a long vacation. I don't believe he's gone for good, but we may not actually hear a lot from him. However, I share in his vision and still have a lot of interest in this simulation (I prefer not to call KSP a game since it is so much more.) New: (10/27/2015) Forum user "run1235" has done some work on getting some of the KF parts into appropriate CTT (Community Tech Tree) nodes, and I have compiled those configs into an easy MM (Module Manager) patch. Once decompressed, the GameData folder within is ready to be simply dropped on top of your existing one. Nothing will be replaced... at least I don't think it will. The file is using a new directory structure that will be used when I update this mod next, but should be fully compatible with whatever you all have installed right now. Of course, it goes without saying that you'll need Module Manager and CTT installed to see any effect from this patch. (Yeah, I just said it... so I guess it goes with saying, eh?) Archive is located here: Dropbox Link The following is a statement regarding support of a certain 3rd Party tool, or the apparent lack thereof. I do not support the use of CKAN or any other mod-updating tool. No one is stopping you from trying it but, if it fails, it is not my problem. I will not write extra batch files to force this tool/utility to recognize the new version of the MOD that is available. The problem exists within the tool/utility and it is the job of those authors to fix the problem with how they handle such things if it is worth their time to do so. The only supported way of installing this mod is the way everyone installed mods before CKAN came along, and that is to drag the folder into GameData directly from the zip. It isn't too difficult to track new versions of the mod on your own, or through the KerbalStuff subscription system. If/When KSP releases an official mod managing application, I will do everything possible to make sure everything works as intended. It is not my intention to be the rear end of a mule to anyone by saying this, but the fact remains that I am only the new maintainer of this mod and for the last year or so I have only been contributing to it with no access to the KerbalStuff release page. KerbalStuff does not allow me to change the version numbers for past releases, so the best I can do is remove the errant releases from the site to fix any issues people might be having with a 3rd party mod manager. that I have done, and that is all that I can do at this time. This has nothing to do with willingness to work on a solution, but rather has to do with my limited time and energy to worry about it. The only true reason I am taking the lead with KF right now is because I do not want to see it simply disappear with the disappearance of lo-fi from the modding scene. This is not to say that new and exciting things are not being worked on, but I cannot spend as much time on it as I used to. Unfortunately this also means I won't be able to re-publish to KerbalStuff, or work on moving everything over to my github repository for the continued work at this time. So please take this into consideration before you send me a private message with some new idea about how I can fix CKAN or how I should be taking better care of version numbering for releases that were published before I took over the mod. ------------------------------------------------------------------------ Old News: (pre-10/27/2015) Now, on to some newer stuff. I'm working on writing a set of modules that might make it easier to convert old wheels to the KF modules. I make no promises, but there are some parameters that can be brought it automatically from the existing ModuleWheel information about the wheel itself such as the transform names and collider names. Other values can be initialized at their defaults and work with most wheels that have been created for KSP. Ideally, one would still write their configs specifically for the KF modules, but I might be able to make it easier to do quick and dirty conversions by simply adding a new module to the config and letting the plugin do the work at run time. I'm also dabbling in making DustFX into something that will work on KF wheels, stock wheels, landing gear, etc. without requiring separate plugins to be loaded. In that same line of development is an attempt to make the KF functionality more modular allowing for wheels that have no suspension to speak of, but could still use the more efficient steering mechanisms. The opposite is also desired, having a wheel that has no steering at all but still could use the suspension system. Finally, I am working on a way to re-use the WaterSlider module to make tracks/wheels/screws usable in water. The plan is to basically place the water slider slightly under the water, but high enough that the craft can still be considered not-splashed. The wheels/tracks/whatever would then have a solid surface to roll over. There would, of course, be code written to maintain a higher drag on the craft due to having to displace water instead of atmosphere like a rover does on land. I'm also going to try and make the depth of the slider panel respond to the scale of the wheels on the craft but, with multiple wheels capable of having different scales, keeping track of what depth should be used could be tricky. All of this is being done, however, to circumvent the issues with buoyancy, annoying splash effects, and stability in water. The inspiration is to imitate an over-filled, monster-sized tire on a small vehicle allowing the vehicle to float and/or maintain enough speed on the water to hydroplane across the surface in a semi-controlled manner. So, that's my news so far. Fixing links and such for this thread is still on the to-do list, but it all comes down to time and energy. I don't get out of my later class until 7:40pm on most week days, so I end up with little time to do any hobby work.

Just when I thought the crazy stuff had reached it's finale.

RoverDude usually uses his own, slightly buggy, implementation of a transparent pod. His use of RPM now just throws a monkey wrench into what I already thought I understood about the rover guy's brain. It's just another mystery that we may never figure out. Not that I'm complaining... RPM implementation would be preferable. In some of his other pods I've managed to glitch it so that the IVA gets separated from the craft in non-IVA view, complete with my Kerbal sitting inside it. RPM never did that to me.

Well, if you ever come up with something truly amazing, send it out my way and I'll see if it can be spread around. Feel free to back-seat mod, if you catch my meaning. As for the other stuff, I'm not through messing with it, but I'm definitely not thinking anything will be doable during flight. I'm aiming more for extra control in the editors and/or for part makers in the future. Also, I've grabbed local copies of your development branches and I fully intend to post up some of the more complicated stuff and see if the community can make any sense of the various final pieces of the puzzles. I also really want to see about getting crawler steering working again somewhere down the line. I have another week before school starts, so I might as well brave a possible headache once more. Don't remind me about U5. That's scary stuff. I'm in way over my head in that regard.

That definitely sounds like something I'd like. I'm going to be taking over the maintenance of kerbal Foundries soon (I think lo-fi got burnt out on KSP development, he's actually throwing the proverbial towel out the window) which is where DustFX finally came to rest. Still, collision sound effects have been my greatest adversary (at least, when not struggling with the crud that's involved in making custom GUI windows. That was a nightmare.) We squashed some of the most persistent nullrefs when we stripped out the collision sound effects from my adaptation of CollisionFX. Thinking about a random sound effect selector for a moment, I imagine the randomization part would be pretty simple to set up. We already have random number generators with definable ranges, so I would think setting up an enumerator for all the sound clips you have, and then have a random number drawn with a minimum of 1 and a maximum of the enumeration's length, you could then take that output and match it to the index in the enumeration and bingo, all ready to emit the sound effect. For configurable sound effects, you can simply set up a few config fields. One for the sound clip path, and a second for a comma-delimited list of clip file names (using two fields reduces the need to have the entire path for very clip) which is then parsed out at startup and enumerated with a prefix of the path for the clips. Alternatively you could simply require all sound clips to be in a specific folder and simply reference them by name. A third alternative is available, though I'm unsure how to make it happen, but I know there are mods that can reference images by name on the global level, without requiring a path to be declared. You might be able to adapt that for sound clips. But there I go again, derailing the thread. Get back on topic you crazy people...

It'll all be on hold for a week or so while I figure out what we're going to do about loosing our fearless leader and all, but I ain't done with this mod yet. I did take a look at the KFModuleWheel module and I actually don't think there's much more than can be exposed at this time. It may be that everything you need is in those float curves, but I need to get a crash course in how those float curves work, especially in regards to the third and fourth numbers in the data. I'm also vaguely aware that some of those parameters are actually in the model configuration as well, but I'm unsure if our modules are working alongside those parameters or overriding them completely. I'm a bit out of my element with most of what was done to make these wheels work before I joined the project (that's about a month worth of development that I never saw).

Dangit... you're leaving us for good? I can't imagine ever leaving this stuff permanently. Honestly, this mod will likely go nowhere as far as new content if you're giving up on it. I can add new features and what not, but once they update and break things I'm going to be completely lost. What brought on this sudden interest in not continuing? EDIT: I'll continue updating this mod as long as I can, I just really think it's going to be way over my head when KSP is updated to Unity 5. Also, I'd really be interested in getting a hold of the source for the texture animation plugin that you distribute with KF, and any work in progress assets you've been working on lately. Also, I'd be interested to see the current progress on the tie-downs and the hitch. At the very least, if I have your latest work on that I might be able to put up a plugin-dev thread to try and get the community involved in polishing that up. Ideally I'd like to get a basic framework of this plugin put together that other developers could then hook into in order to add features to the base mod. That way things like DustFX, water sliders, new types of steering or load-bearing modules, etc. could be created independently as plugins for the overall KF mod. That's my long-term idea right now anyway, and it would allow the end user to pick and choose what features they want to install based on preference and performance needs. I'd suggest you update the content repository on github with anything you've been working on that you're willing to release to us, and then just make sure that any WIP code is in your development branch of the KF_plugin repository. I'd hate to see those features go missing completely when you take off, even if I am unable to make them work myself. The KSP modding community has lost so much good stuff when people have disappeared and I don't want to see our work go that way when this is all over. Besides, I fully intend to use my work here in whatever portfolio I build when I'm trying to get employed after college. - - - Updated - - - Well, first thing I'm going to do is simply make sure that everything that can be tweaked in an form is exposed to the part configs. Editor controls are a more tricky matter and will have to come later. At this time almost everything is already available, and those that aren't are simply calculated from the parameters that are. What I'd really like to do is try and expose even the calculations themselves to the configs, but that's going to be a tricky matter of converting strings to ints/floats and such. I'm sure it could be done though.

New in the computer industry: keep your file structure safe by downgrading to an all-natural, environment-friendly, and sometimes even green desktop solution in the form of your very own stone tablet complete with a hand-made chisel and hammer combo pack. Never deal with computer viruses again! The only viruses that'll attack you are the gooey slimy kind. (warranty void if kicked, rolled, spat on, used for target practice, used to sacrifice your neighbors to a deity, dipped in water, submerged in lava, left in the weather for any more than 3 years unattended, or touched by viscous slime. Acid exposure has not been reported on, as no one has survived. Can be used as pillow or recreational copulation surface when not in use in its intended form.)

Yes, but that's at the config level. In-flight is another matter entirely. You also have to consider that KF doesn't suffer from the same "catch a rail" issues due to the advanced suspension and anti-roll systems in place, along with the smooth turning speed and the heavy turning reduction with high speeds. As for the float curves... your guess is as good as mine. We'll need lo-fi for that one.

I'm afraid it's been talked about way too many times. It's an engine limitation. We'd need to find a way to trick the engine into thinking that the wheel has lost contact with the ground for a split second to re-set the new settings, which wouldn't be something that would be easy to do without bringing on the kracken. As for functionality toggles, I'm all about adding more power to the end user and to the future modders of these things. I'll be exposing more and more as configurable options in the future if possible.

We may never truly know hat the fuzzy dice are in reality, we must simply accept that not all the strange things in this world are supposed to be known to us. It is a mystery that will endure for all of time, and beyond...

Are you meaning some sort of visualization for the colliders in the VAB/SPH? Or are you meaning being able to toggle on/off the functionality for specific parts? As far as I can tell, having the water slider active doesn't really have any negative effects for non-flying vessels, so I honestly don't see the problem with having it active at all times for any wheel/track/repulsor. I am working on a way to make sure it's only active when the craft is within a certain distance from sea-level so that one can still use these parts on flight-enabled craft that may start the flight scene already off the ground, since it seems to have trouble positioning itself correctly for in-flight initializations (thus why BDArmory missiles were spawning them in mid-air) but, beyond that issue, there seems to be no negative with it. Only one slider is active per vessel too, so multiple slider-enabled parts don't cause extra performance hits. I would like to be able to scale the size of the slider to the size of the craft, so that super-massive vessels could still make proper use of it. Right now, though considering the vessel would have to be super massive to make this an issue, in theory your vessel could be so large that the slider would no longer be able to cover the entirety of the repulsors attached to it. As for an editor visualization, I would eventually like to figure out how to create a FS-style wheel-alignment option for the KF wheels, since they tend to show up in the editor in full retracted state which makes it difficult to gauge how they will work when physics is attached. Alternatively I might be able to figure out how to force full deployed state when in the editors. Ideally I'd like them to appear in a mid-point state, or the neutral suspension that some models have defined. Essentially the water slider is vessel based still, but it is initialized by the parts instead of the entire vessel on load.

That does sound kerbal. That water slider could be a great way to simulate a lot of things relating to the water. I'm going to have to experiment with that.

Fair enough. After all, it's basically a parachute with an alternate model. You could probably get away with using just about any model you could imagine in that role as long as you recompiled the model as a parachute. For a set of textures that isn't even made for that model, though, it looks pretty nice as is.

Me neither, but then I've had my brain in the code for so long I don't even remember my last rover that actually used a track. Perhaps it's a "feature" of an older version with less sideways movement restriction or something. It does bring up the idea to have both an overdrive mode available along with an "instant emergency brake" mode for those situations where you just have to force some hydroplaning action to get that maneuver completed properly. That brings up another idea I had: Get going fast enough with those oversized wheels and you might be able to cross small bodies of water with it. Might even be able to make them float due to their potentially gas-filled interiors. I was thinking the effect could possibly be produced by making use of the water slider for more than just a repulsor module.

Now that's ingenious. Never thought to use those other modes while painting.

Once we get the giant hand... then next thing is going to be to make a giant hand that will take a bunch of wing pieces arranged to look like a giant piece of paper, fold them, and then launch the thing. I figure you could get a pretty good illusion of folding it up using a lot of IR hinges and some very careful IR Sequencer umm... sequences... yeah.

Now someone build a plane that can take off and land using this baby. I'll get the fire extinguisher for the computer you try it on, cause you know it's going to burn.

Who says we can't? We can scale anything with a config made for it.

How do you know RoverDude knows what they really are? Hmm? It's one of those grand mysteries of the universe. We may never truly know, and if quantum weirdness comes into play then, if we ever do figure it out, it may no longer work in the way we think thus making our supposed knowledge of the thing null and void.

Hey, the texturing looks awesome even as it is in that first image. Now, if those balloons could be made to not only act like parachutes, but have the ability to hold a lighter craft aloft for an extended amount of time, or lift a craft if deployed from the surface, then we'd have a serious winner.

Food? Where!? I need food... Mmmm... foooood.... - - - Updated - - - Possibly... unsure how at the moment. That's lo-fi's department. If it's purely a config option, then it's likely that you could simply tweak whatever allows that sort of movement. Any thoughts, lo-fi?

Alright, I think I understood a teeny bit of what you just said. My brain doesn't grasp these things too quickly I'm afraid. I was trying to convert that Karibou wheel this morning. I got about as far as writing a MM patch that referenced the original wheel... and then got stuck before I actually patched anything. But hey, it's progress either way, right? Yeah... it's sad. Anyway, I'll give it another go later if I feel up to it. Considering all the complexity of RoverDude's wheel model, there might not be all that much that needs to be overridden really, as long as the KF modules know what the various transform and object names are. The animation is going to be another thing all together, but considering the issues we have with the animation and the functionality of the ERS wheels (I'm unsure, but I think we may still have issues with them actually working and not simply getting stuck in a retracted state no matter what they are visually) I've actually been thinking about taking inspiration from the various mods that makes their own animation modules (such as RoverDude's plugins) and implement a KF-friendly animation module based on those. Anyway, you'll notice I made a new release and already got at least one happy report back, so things are looking up. And I'm not slowing down too soon either.

For custom colors and whatnot, feel free to take a look at what we did in Kerbal Foundries. I took CollisionFX and, over about 3/4 of a year, slowly morphed it into the "KFDustFX" module. In its current state, it's maybe about 2% CollisionFX and the other 98% is what we've (lo-fi and me) rewritten. Combined with some of the advanced wheel features of KFModuleWheel and the repuslors in KFRepulsor we have a dust emitting module that is very customizable. We use an external BiomeColors.cfg for static body/biome definitions, but also make use of a small, low-res (6x6 pixels, configurable) camera object, with a mask that blocks out the craft itself, situated above the craft which samples the current view from the ground textures and averages them out to give us a new dust color at a configurable, but defaulted to 10, frames between samples. We then have a little buffer in the dust emitter which allows the dust to slowly transition so that the entire dust plume doesn't change colors all at once. So if you need some inspiration on how you can take your current CollisionFX and make it even more awesome, feel free to browse. [Link to github] I've already been asked to make a KFDustFX variation for non-KF wheels, but I figure that would be more in line with CollisionFX, which is all yours. The only things we don't have in our implementation is any sort of collision sound effects, or any sparks of any sort (though, our screw-drive could certainly use some sparkage occasionally while moving along the terrain since it relies on a lot of friction with the ground to propel the craft).

How do you even know they are, in fact, "fuzzy dice" at all? They could be an advanced orientation control system with a low-tech gravity-direction sensor (they hang from something) with a low-tech visualization system (they hang from something). We may never know for sure.