Gaalidas

In the KF plugin, after a few hundred different attempts at making it work, all we ended up with was this in the Awake() method: [COLOR=#004085]GameEvents[/COLOR].[I]onGUIApplicationLauncherReady[/I].[COLOR=#191970][B]Add[/B][/COLOR]([COLOR=#191970][B]OnGUIReady[/B][/COLOR]); [COLOR=#004085]GameEvents[/COLOR].[I]onGUIApplicationLauncherUnreadifying[/I].[COLOR=#191970][B]Add[/B][/COLOR]([COLOR=#191970][B]OnGUIUnready[/B][/COLOR]); With OnGUIReady and OnGUIUnready both being custom methods that either add the button or remove it. So far it seems relatively stable. Haven't experienced any duplicate icons for quite some time either, but then we have extensive checks for that sort of thing in other areas of the mod since we render our button in every scene I think.

Having multiple transparent pods in the same craft, or indeed within physics range of each other, is one way to get a performance drop. As long as you can't actually see the other pods from the interior of one of them, however, you won't even notice that it won't show the insides of other pods when in IVA. I'd be interested to see how you're handling their retracted states along with the transparent windows. I've yet to ever see an IVA view that animated along with the outside part to reflect a change in dimensions or size.

It's true that KF textures are noticeably larger than some other mods on the market, but not overly so. That said, I'm on a non-gaming laptop so I usually reduce any texture for any mod I download, including the assets for this one, by at least 50% before installing them. Also take note that we opted out of converting our textures to DDS ourselves due to massive quality losses in the conversion. Converting yourself either manually or using the tool available (somewhere in the tool release forum I believe) would increase the speed of loading.

"ordinary" FSwheels? I wouldn't call them ordinary. Certainly not as awesome as KF wheels though. Perhaps the word "mundane" could be more accurate. Technically, this version of DustFX will not. However, I do intend on making a separate module (perhaps releasing it as a separate mod) that would allow for other wheel systems to use these effects. The issue will be how to make it work with both the stock wheel module and all the other modded wheel modules without having to write completely different configs for each mod/part. That will be something I'll work on at a later date though. Alternatively, if those wheels could be revamped to work with KF steering and such, then all issues would already be worked out. From what I remember, suspension for those parts is pretty much non-existent, but I think you could still configure them to use KFModuleWheel/KFWheel with a suspension of zero. That's something I've wanted to look into for a while now: making the suspension optional. There's already a check in the module(s) for whether the part is simply a non-interactive wheel, or if it's a fully functional wheel (for unpowered trailers and such) and I think the same logic behind that could be used to simply default the suspension values to zero and remove their tweakables. Both options are in the works, just not a priority right now. Originally, DustFX wasn't going to be a part of KF at all, it was simply geared towards it. In it's earliest conceptions, it actually worked for anything that could collide with the ground. It probably wouldn't take that much effort to simply strip it back down to standard collisions instead of specifically KFWheel collisions.

There wasn't an actual config in any of these posts, I was just suggesting that you (as in anyone unwilling to wait for an update and feeling adventurous) look in the KF part configs for any parameters in the KFModuleWheel module that have anything to do with "retract" or whatnot, and simply remove them to let the module reset to default. This would, of course, likely mean you'd need to relaunch any vessels that are currently in the world with those parts. lo-fi: Perhaps sometime in the next few days you should grab the latest code from the main KF_plugin repository and give it a compile, then package that up with the latest configs and such from the main repository and put up a new update. I've done a number of fixes to the configs and reworked/polished a number of the features we've been working on and I think it's all ready for a release... and should be more stable than the last number of releases. Perhaps it will put some of these issues to rest that are being reported.

You've had a few of those I think, as have we all. I've updated the repository with my latest code changes. This includes a few variables renamed for my own sanity, and a few new features. Included is the debug option in the KF GUI to show the debug options, and the one option available which is to show the water slider collider. It seems to work perfectly so far, but needs more testing with multiple vessels and such. I also included my latest brand new addition to our list of modules, which I've detailed in the github commit notes. I'm eally on a roll with these things now that the really nutty stuff is over with. I still want to, eventually, dive back into the crazy world and try to get a redo of the GUI done in the GUILayout format, which might allow us to finally make the GUI window draggable. I might have to go ahead and do some testing of that after I figure out if the KFController is worth the effort. So, am I right in assuming you simply got burnt out after the crazy post-release days and had to recharge?

Indeed, I suggested a page or so back that one user remove the deploy/retract lines from the wheel configs to reset them to their default "false" state. I think one of his wheels on his rig was being retracted somehow, causing it to not function correctly. I never did hear back to see if that was fixed.

Well, I'm going to continue looking into an overall vessel-module level controller. I think it could be made to work well enough. I've been observing several other mods that use vessel modules and it seems to work rather well in certain situations. Besides, in this case the module wouldn't only be adding things to parts, but also removing them when they are not supposed to be there, thus solving some of the problems we had with the old vessel modules. It's a work in progress anyway. The end goal is for only a controller module to be added to the vessel no matter what, and that all the other dynamically added/controlled modules will be added to the vessel's parts if they are needed, from the same single module attached to the vessel instead of being checked for every part specifically. I'll be testing it all thoroughly before committing anything though. I found something, though I have yet to commit the change, where I think DustFX was actually still being applied to a part twice. Basically it was checking for the null status of the KFDustFX and then it was adding it if the module was found, and not if it wasn't. I'll try to update the repo with my findings soon. I'll take a look at the dust stuff and see if I can come up with anything usable. More than likely I'll fail, but you never know.

I can already see myself sticking a bunch of KF wheels on this baby and letting her rip.

-head explodes- Ah crud... oh well, I'll move on without it. it's an interesting idea, though it seems to me we'd end up with, basically, tracks without a track surface. We'd also need to find a way to apply the steering mechanisms to the separate parts of the single model. I won't say it's a bad idea, but it's a complicated one. Also, I really don't experiment with that sort of thing. That's all lo-fi. I do stuff in teh coding part, and I'm still hard at work on adding new things for the day when lo-fi decides to return to us and lead us all into glory... whoops, wrong story... ahem, moving on... I will say the idea of having less physics joints to deal with and wrapping a ton of wheels into a single part for those rovers that simply require an absolute ton of wheels is a nice thought. However, without a way to dynamically generate these multi-wheel constructs, I don't see it being very practical. To make it work really well, you'd need to implement something like a procedural wheel-mount frame which, depending on the length of the frame, would contain a number of wheels spaced according to the selected scale of the wheel and the base wheel part-size. You would then attach the frame to the craft via a single attach position, but for stability of the craft you would need to strut the ends of the frame to the hull as well. The technology to do this exists, even within KSP, but has never been done quite to this level. For instance, the older procedural fairing mod has a fairing base that can be scaled, which affects the base number of fairing stack nodes it has, but then can also take a modifier for how many stack nodes to include and will then re-position them based on their size and the number requested, and also by an offset position from the center of the plate. In our case, the nodes would be replaced with complete wheels and we actually wouldn't need a modifier for the offset since ours would be linear. If we could do this, however, then we would have already done it with the tracks to make the long-requested procedural tracks. We don't have procedural tracks though, due to some limitations in the game engine. These same limitations would likely limit us here as well. If you simply have a ton of separate wheels on the craft, you might have more physics joints, but you also don't have to strut anything down since they're already attached to the vessel at multiple spots and will interact from that position correctly. With the procedural frame, you'd end up with the entire set of wheels interacting only with the part in the middle of the craft where the frame is attached... much like the way Tracks are right now, which is another reason why making super-long tracks isn't really practical. My most recent dabbling relates to all the checks we have to do with our modules to control whether or not they are allowed to exist or be active. My most recent idea to get around all these necessary checks is to simply assume that, if the module is present on the part and the vessel is a valid vessel for those modules, the module is allowed to be run on that part. Then, using a vessel module for simplicity's sake, we attach a KFController module onto any craft that is loaded into the flight scene. This vessel module will first take stock of the presence of several modules on any part within the craft: KFRepulsor, KFModuleWheel, ModuleWaterSlider, and KFDustFX. all it needs is a single instance of that module on any part attached to the craft to return true on any of those. Then it takes a reading on what the vessel is currently flagged as (VesselType) and if it returns as "debris" or something like "Kerbal" or "EVA" (I forget at the moment what it returns for EVA Kerbals) then we start a routine that will systematically run through every part of the craft and look for the modules which should not exist and will then, first off, disable anything that needs to be disabled (such as the water slider itself, and the possible debug option for it's view state, which I have working perfectly now by the way) and then, upon completing that, removes the module from that part. At the same time, this new vessel module could, potentially, also keep track of the adding of certain modules to parts that require them but don't have them defined in the part configs. It's still very much a work in progress, but progress is being made. The initial work on this new module was inspired by the possibility of the water slider spawning in the air when BDArmory missiles are fired from a repulsor-enabled craft. Good to have some discussion back. I've been watching this thread get buried under several pages of posts and had almost given up even finding it again when checking these forums. I guess no news is good news, however. I'd still like to know if my suggested fixes for several people actually fixed their problems.

Hey, if you do happen to divide by zero, it wouldn't necessarily obliterate all of time and space all at once... well, technically it will happen all at once, but that single moment of time will be shattered and collapse into itself creating a sort of temporal-spacial singularity which will warp the fabric of space-time like a black hole, but reversed. In a black hole, an external viewer would observe that you would never actually reach the point of no return because of the time dilation. In this instance, there would be no outside viewer because all of time and space would be affected, and the closer to the point of impact you are, the less you will be impacted by the effect, thus being able to observe all of space and time collapsing from the furthest reaches of time and space inward toward you. So, in a matter of speaking, at the exact center of the anomalous calculation (your exact location at the time of the division) time and space would continue to pass by at the same rate as always for the entirety of the infinite duration of the space-time life-cycle, at which time (as if "infinity" were a number that could be reached) everything would cease to exist. Either that or we'll all just suddenly not exist and won't care either way. In theory anyway...

Once you've completed this baby, you're going to have to go through and cut the model up in the attempt to make it into a sort of "Delta-Glider fuselage" set, you know that right? In theory, you could cut all these parts up and still have them use a single texture set, or the same set of multiple textures, for easy re-skinning and/or texture-swapping, and end up with a basic glider model that can swap out mid-fuselage modules for the need of the end user. For instance, swapping out fuel capacity for a cargo bay, or a cargo truss, or an extended crew module, etc. Even if you simply cut out the middle part of the fuselage, gave it a shroud-type surface for when it's not occupied, and then made it able to mount a variety of these mid-section modules, it would extend its usability a ton. Just something to mull over it your head.

I'm liking that new engine model with the nozzle flexing (or whatever it's called. I imagine it almost like "breathing" the way it flexes like a human being's rib-cage when filling the lungs with air.) but I'd also like to see more completion of some of your older projects that we have yet to see be released, such as the conformed solar panels.

The truth of the matter is that KSP 1.0.4 has a bit higher of a ram requirement and the updated versions of those mods may also have a higher ram requirement. This will, during loading of KSP, cause lockups when ram usage gets over the maximum load of the game or the maximum available on your system. Load-up lockups can also occur when a major error is encountered such as exceptions from mods that run during the loading process or formatting errors in texture replacement calls commonly made when compiling a part that uses a MODEL node to swap a texture but cannot locate the required texture to apply. It should be noted that USI Kolonization, while optimized rather well, is not the most ram-friendly mod. There are a lot of large textures being used which could easily be smaller, and a lot of models loaded which do not even fit very well with the current style of the main parts. There are also some native texture issues having to do with errant cross-texture usage with other USI mods that have not been fixed. If you use all the USI mods, then those errors do not show since you already have them all installed and available. As much as I would love to help, we should probably move this topic back into the general forums or the help forums so we don't turn the KF dev thread into a "help me fix my game" thread, and save this thread for actual KF mod issues and developments. - - - Updated - - - Hah! It happens I suppose. I can't say I honestly had that happen to me, but it's one of the many dangers to becoming too reliant on cookies.

Can't help with the album, but I must say this is something I didn't know I needed, and I may just add this to my install sometime soon. Actually, I had no idea that Tab/Shift-Tab even did anything in the map view. You might look into adding a config file so one might toggle on/off any of the features you add. For instance, a user might want everything except the navball defaulting to visible.

For a power user and seasoned KSP player/modder, this sort of addon makes absolutely no sense. However I can't even begin to say how useful this would have been before I knew how all this stuff worked. If I was brand new to this stuff, I'd download this immediately.

Huh, I didn't think lo-fi bothered to clean out access permissions like that. I'm sure it was simply an oversight. If it wasn't for his little absence, I'd poke him about that. At the very least you should still have reading access to the KF_plugin repo, since I believe it's public. As far as I'm concerned, you're pretty much stuck as a permanent member of the dev team whether you like it or not. We'd still be struggling with our persistent data if you'd not stepped in. I've been having a grand time adding new persistent variables to that class and, in many cases where you'd expect a local variable to be declared and checked against, I've simply opted to re-check KFPersistenceManager.whatever_variable_I_need instead and it works flawlessly. And... that would be correct. If you aren't running the most recent version of KSP, then you're out of luck I'm afraid. The reasons for remaining in the KSP beta version are simply too few to warrant continued support, but if you go into the "change log" area of our KerbalStuff page I believe old versions of the mod are still available. That's the extent if the support I can offer. I can tell you that the problems described are actually rather common for KSP 0.90 and aren't easily narrowed down to a single mod. It should also go without saying that if you're running an old demo edition of the game there's really nothing we can do to help you. We created this for the full product, version 1.0.4. - - - Updated - - - As far as I'm aware all of those mods are available for 1.0.4 or, at the very least, have no noticeable incompatibilities from their last update. To be more specific, I run 1.0.4 along with (picking the names from your list) Toolbar, B9, BDArmory, CIT (Not the active struts, but that specific mod was discontinued I thought, or was integrated into another mod), CRP, DistantObjects, Enhanced Navball, JSI (Raster Prop Monitor & the extra utilities mod), KAS, Kerbal Joint Reinforcement, KerbinSide (though not the whole package, some of those models are down right huge and take a lot of ram), KineTech, KIS, Klockheed Martin Gimbal (both 2.0 and 3.0 I think, though that's only because I've never bothered to upgrade the parts that are still using the older plugin), MagicSmoke Infernal Robotics, mechjeb2, Kerbal Konstructs, ModuleRCSFX, NASAMission (this was rolling into the main Squad folder, so if you have a squad folder you've got NASA too), Docking Port Alignment Indicator (and its associated RPM addition), the whole gambit of NearFuture stuff (had an awesome dream last night about using that mod), Procedural Fairings, RealChute, Scansat, SmokeScreen, TAC Fuel Balancer, ToadicusTools (all hail the hypnotoad... sorry, couldn't help myself), Kerbal Alarm Clock (I don't have any alarms though, thinking about removing it), Tweakable Everything, Tweakscale, USI (and their various part packages, though not all parts due to needing to keep my ram usage low), Universal Storage, Virgin Kalactic (or is it VirginGeneric?), Waypoint Manager (I have exactly one waypoint, and I've never used it), Module Manager (a must have for pretty much everything), DDSLoader (actually, this one is no longer necessary since we have native DDS support. I forget when this was added though so you might even have it in .90, can't remember), Adjustable Landing Gear, Ambient Light Adjustment, BahamutoD parts package (which I believe includes the animation modules), Burn Together, HyperEdit, Improved Chase Camera, Kerbal Foundries (duh!), Quiztech Aero, and yes, I even run Targetron which seems to be impervious to KSP being updated. I don't use everything you use, but I also know that many of the mods I don't use have either been updated recently or don't have any issues running in KSP 1.0.4. This being said, you really have no reason to be playing in KSP 0.90 any longer unless you simply can't accept the new aerodynamics system that was rolled out by Squad. However... I also noticed you listed FAR in your list of mods, which means the stock aerodynamics does not affect you and i know for a fact that FAR is compatible with the latest version of the game, so you still have no more excuses to be using 0.90.

Just because you first encountered this problem after installing this mod does not necessarily mean this mod is the cause of the problem. Either way, without a log that clearly refers to the plugin or an assembly within the plugin, there's nothing I can do. I've never experienced this, nor have any other reports come in related this this problem. I'm afraid there's nothing more I can really say except I'm sorry you're running into problems and I hope you figure it out. I won't discount that this mod could be having an issue with another mod but, again without any logs, I can't think of what it could be.

Those two missing textures don't seem to affect anything, so I'm unsure what is going on with them. I put up an issue on the bug tracker, but I think lo-fi got a bit burnt out after our big push for a release and then the frantic fixing of critical bugs that followed. If you notice any actual missing textures in game (areas of a model that are pure white, not including the APU in which case that white area was never textured in the first place) let us know and I'll see what I can find and/or see if I can release a texture file you can stick in there for a temp fix. Otherwise, it shouldn't be an issue and you can safely ignore it. The invalid integer values are something I see in a lot of modded parts and I'm still trying, occasionally, to track them down. Sometimes it's due to a module wanting a certain parameter to be formatted as an "int" when the actual input is formatted like a "float" in the config. The most common case is when a decimal place value is defined where a single digit was expected. From my experience there is no serious impact and, if the input truly is in the wrong format, the module simply reverts to the default value. The only real danger comes from badly formatting input where there is no default value defined in the code, but in those cases you would expect the code to not even compile properly. So, in the end, unless you are experiencing an error while using the part in which the invalid integer was detected, then you can safely ignore it. If lo-fi continues to be out of communication for an extended amount of time, I may look into issuing a patch for the latest release that you could all get from here. In the end, however, I'm just a collaborative author of small portions of this mod so I really can't do any official releases to address these issues. I need to do some self-educating to get myself familiar with the Unity side of things before I can address missing textures in the correct way.

There's a "butt" joke in there that I'm trying, desperately, to resist expressing.

Alright, I have something for you to try. First off, I recreated your design (using different hull parts since I don't run that specific USI mod in my game, but the orientations default to the same vector so there should be little to no issue) and it worked flawlessly. However, there are some differences with my installation than the standard one. lo-fi experimented with retractable wheels a while back and some of those settings remain in some of the parts despite there being no animation to go along with them. So, I'd like you to try something for me and see how it goes, if you're comfortable with editing some part files. First off, go into the KF directory, then the Parts folder, and look for "WheelLarge.cfg" and open that up. Under the module named "KFModuleWheel" you'll see some parameters that go along the lines of "hasRetract" or some such. I don't have those lines in front of me and I need to leave the house like 5 minutes ago, so bear with me. Some of those parameters will be set to "True" and I want you to set anything that has to do with retracting to "False" or, alternatively, just delete that parameter from the module. Relaunch the game and relaunch the craft. (Re-attach the wheels if you can spend the time) Let me know if this changes anything. EDIT: In theory, the part might be getting stuck in a "retracted" state which would effectively make it unresponsive in much the same way you are describing. With those parameters removed or set to False, they will simply not ever have the opportunity to be retracted, which eliminates that possibility from the things we would need to investigate in order to figure out what's wrong here.

"bin sort"?

For the post that says this doesn't need reviving, that's completely nuts. The mod may well work, but it could certainly use a bit of love on the code side. There are so many ways this could be improved if someone would take the time to take it apart, rebuild it, and give it a fresh new set of features to match the modern KSP modding standards. I'd do it myself, but I could never successfully recompile the source as it is now.

You should be able to use wav files as well. Technically, anything that KSP loads up should work. I'm unsure what the inspiration was to set it up like "sound_1/moving" unless you were trying to imitate the old stock behavior for defining engine sounds and such. That does lead to the question about how one might use those internal sound effects in a mod like this, but I don't see how any of those sounds would actually fit the bill, so to speak.

It's a crazy mystery that I'm unable to solve personally. This requires the wheel-master's touch. Yes indeed, I have built things that make that thing look very tame. Imagine this: three sets of wheels on each side (six total), each set comprised of six medium wheels assembled in a 2x3 setup (similar to what your rover does, but more compact) for a grand total of 36 medium wheels. 35 of those wheels worked flawlessly, and the one wheel that didn't ended up tearing its entire 6-wheeled compartment from the rest of the rover when I attempted to force it to move. Even then, the rover was able to move rather well, except that the cockpit was hanging in an odd angle and dangerously close to the ground. I wish I'd taken pictures. I'm going to try making something, in a similar configuration to yours, next time I launch KSP and see if I can reproduce your issue.