[1.0.x] [V1.9f] Kerbal Foundries wheels, anti-grav repulsors and tracks

[shooty]

Howdy folks. Hope everyone is well.

I was setting up a new install and noticed two textures are called but are not present.

RepulsorSurfaceDiffuse

SurfaceTrackSurface

I had both files from earlier releases but I just wanted to let you guys know for the next time you pack up a release.

I also get [ERR] Invalid integer value on all the repulsors. I'm still using ksp 1.02 if that matters....

[LOG 10:15:18.359] PartLoader: Compiling Part 'KerbalFoundries/Parts/Repulsor/KF_Repulsor'

[ERR 10:15:18.375] Invalid integer value

[LOG 10:15:18.421] PartLoader: Compiling Part 'KerbalFoundries/Parts/RepulsorGimbal/KF_RepulsorGimbal'

[ERR 10:15:18.437] Invalid integer value

[LOG 10:15:18.484] PartLoader: Compiling Part 'KerbalFoundries/Parts/RepulsorSurface/KF_RepulsorSurface'

[ERR 10:15:18.500] Invalid integer value

I dont know the implications of an Invalid integer value, but I was wondering if it was actually a problem.

As always, my thanks for the neat toys.

Edited August 28, 2015 by shooty
speellin and gramour ;)

[Gaalidas]

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.

[saqib126]

Help!

I`m having a problem when with this mod whenever I try to enter the tracking station,vab, or sph. The game resets the camera and doesn`t do anything, it just says vehicle assembly building or other building depending on what you click. You can`t move the camera but still can interact with interface, like choosing to recover a vessel or exiting the game. I`d appreciate if anyone knows how to fix this.

Here is some info, though this problem only appeared after adding kerbal foundary: Here is some info!

Version of KSP .90 (i use this because a lot of good mods are here like b9) Windows 64-bit, using 32-bit ksp (I thought 64-bit ksp was discontinued).

List of mods, Toolbar, USI Tools, Active Texture Management (aggressive edition, 64x),Asteroid Reclying Technologies, B9 Aerospace, BDArmory, CIT Active Struts, Civillian Population, Coherent Contracts, Community Resource Pack, Community Techtree, Contract Configurator, Advanced Progression Contract Pack, Scansat Contract Pack, Remote Tech Contract Pack, Improved Contract Window, Interstellar, Crowd Sourced Science, Deadly Rentry Continued, DistantObject, DMagicOrbitalScience, Enhanced Navball, EVA Transfer, Extraplanetary Launchpads, ExtraPlanetary Launchpads-->Regolith Adaption, FAR, KAX, JSI, KAS, Kerbal Engineer Redux, Kerbal JointReinforcement, Kerbal Stats, KerbinSide, KineTech Animation, KIS, Klockhead Martin Gimbal, KSI, KSPX, KWRocketry, MagicSmoke Industries,MechJeb2, Kerbal Konstructs, ModuleRCSFX, NASAmission, Navyfish Docking Port Alignment Indicator, Near Future Constuction, Near Future Electrical, Near Future Props, Near Future Propulsion, Near Future Solar, Near Future Spacecraft, ORS Resource Pack, Procedural Airships, Procedural Fairings, Procedural Parts, RealChute, Regolith, Remote Tech, Scansat, Science Alert, Ship Manifest, SmokeScreen, TAC Fuel Balancer, TAC Life Support, Todicuss Tools, Kerbal Alarm Clock, Tweakable Everything, Tweakscale, USI, FTT, USI ExplorePack, USI Karbonite, USI KArbonite +, USI Kolonization, USI Survival Pack(previously D.E.R.P.), Universal Storage, Virgin Kalactic, Vanguard parachutes, Waypoint Manager, module manager 2.6.0, and DDSLoader, and Adjustable Landing Gear, Ambient Light Adjustment, Bahamuto Dynamics Parts Pack, BahamutoD Animation Modules, Burn Toghtether, Davon Thruster Control Systems, HyperEdit, Improved Chase Camera, Kerbal Flight Data, Kerbal Flight Indicators, Kerbal Foundries Wheels and Repulsors, Quiztech Aero Parts Pack, and lastly, Targetron.

[Gaalidas]

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.

[saqib126]

How can i get the logs?

[Tarheel1999]

How can i get the logs?

Look here: http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST%29

And if you really are running .90, it seems unlikely that posting your logs is going to help. I doubt that lo-fi, Gaalidas, or Aqua are providing support for older versions.

Edited August 29, 2015 by Tarheel1999

[*Aqua*]

Somehow I don't have access to the KerbalFoundries repo anymore. I guess lo-fi assumed I'm not interested in helping to develop KF anymore. I didn't do much in the last weeks because of real life.

[NoMrBond]

Guys, I'm taking a break. See you in a while!

Have a good rest and good luck with the relaxation!

[Gaalidas]

Somehow I don't have access to the KerbalFoundries repo anymore. I guess lo-fi assumed I'm not interested in helping to develop KF anymore. I didn't do much in the last weeks because of real life.

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.

Look here: http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST%29

And if you really are running .90, it seems unlikely that posting your logs is going to help. I doubt that lo-fi, Gaalidas, or Aqua are providing support for older versions.

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 - - -

Help!

I`m having a problem when with this mod whenever I try to enter the tracking station,vab, or sph. The game resets the camera and doesn`t do anything, it just says vehicle assembly building or other building depending on what you click. You can`t move the camera but still can interact with interface, like choosing to recover a vessel or exiting the game. I`d appreciate if anyone knows how to fix this.

Here is some info, though this problem only appeared after adding kerbal foundary: Here is some info!

Version of KSP .90 (i use this because a lot of good mods are here like b9) Windows 64-bit, using 32-bit ksp (I thought 64-bit ksp was discontinued).

List of mods, Toolbar, USI Tools, Active Texture Management (aggressive edition, 64x),Asteroid Reclying Technologies, B9 Aerospace, BDArmory, CIT Active Struts, Civillian Population, Coherent Contracts, Community Resource Pack, Community Techtree, Contract Configurator, Advanced Progression Contract Pack, Scansat Contract Pack, Remote Tech Contract Pack, Improved Contract Window, Interstellar, Crowd Sourced Science, Deadly Rentry Continued, DistantObject, DMagicOrbitalScience, Enhanced Navball, EVA Transfer, Extraplanetary Launchpads, ExtraPlanetary Launchpads-->Regolith Adaption, FAR, KAX, JSI, KAS, Kerbal Engineer Redux, Kerbal JointReinforcement, Kerbal Stats, KerbinSide, KineTech Animation, KIS, Klockhead Martin Gimbal, KSI, KSPX, KWRocketry, MagicSmoke Industries,MechJeb2, Kerbal Konstructs, ModuleRCSFX, NASAmission, Navyfish Docking Port Alignment Indicator, Near Future Constuction, Near Future Electrical, Near Future Props, Near Future Propulsion, Near Future Solar, Near Future Spacecraft, ORS Resource Pack, Procedural Airships, Procedural Fairings, Procedural Parts, RealChute, Regolith, Remote Tech, Scansat, Science Alert, Ship Manifest, SmokeScreen, TAC Fuel Balancer, TAC Life Support, Todicuss Tools, Kerbal Alarm Clock, Tweakable Everything, Tweakscale, USI, FTT, USI ExplorePack, USI Karbonite, USI KArbonite +, USI Kolonization, USI Survival Pack(previously D.E.R.P.), Universal Storage, Virgin Kalactic, Vanguard parachutes, Waypoint Manager, module manager 2.6.0, and DDSLoader, and Adjustable Landing Gear, Ambient Light Adjustment, Bahamuto Dynamics Parts Pack, BahamutoD Animation Modules, Burn Toghtether, Davon Thruster Control Systems, HyperEdit, Improved Chase Camera, Kerbal Flight Data, Kerbal Flight Indicators, Kerbal Foundries Wheels and Repulsors, Quiztech Aero Parts Pack, and lastly, Targetron.

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.

Edited August 29, 2015 by Gaalidas

[saqib126]

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.

So, i can just upgrade to 1.0.4 ksp then?

- - - Updated - - -

Also how to I post the log files here, or do I have to go to dropbox?(A couple of forums i`ve found have this feature)

A chunk of the mods I manually downloaded are back in .90 (as CKAN didn't work with them for no reason. I don`t remember which they are)

- - - Updated - - -

I boot up ksp 1.0.4 and get this message(along with a barrage of about 4 plz go back to .90 requests)

These mods incompatible with 1.0.4 ksp

aaa_toolbar

Crossfeed enabler

deadly reentry

far

kas

kerbal join reinforcement

kis

kspapiextensions

launchpad

mechjev2

procedural parts

realchute

scale

Incompatible with unity 4.6f1

realchute

It appears that the game has stopped loading at" QuiztechAero/Parts/FuelTank/Mk2_Quart_Tank/Mk2QuarterTank"

- - - Updated - - -

also dds support is not in .90, that was what I learned after successfully troubleshooting kerbinside`s completely nonexistent(thanks to that problem) texturing.

Edited August 29, 2015 by saqib126

[*Aqua*]

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.

Glad, I could help you guy!

I just discovered that the Github cookie's life time came to an end. That's the reason why I couldn't access the repo anymore. *sigh*

I hate me sometimes for not noticing trivial things like that.

So, i can just upgrade to 1.0.4 ksp then?

You should do that. I'm pretty sure that almost all mod authors don't care about KSP <1.0 anymore. I will be increasingly difficult to get current mods running in an old version of KSP.

Also how to I post the log files here, or do I have to go to dropbox?(A couple of forums i`ve found have this feature)

There are a number of sites why stores text files for free and without needing an account, i. e. http://pastebin.com/.

Most of these sites have a size limit, you may have to split up your log files into smaller file before uploading them.

I boot up ksp 1.0.4 and get this message(along with a barrage of about 4 plz go back to .90 requests)

These mods incompatible with 1.0.4 ksp

aaa_toolbar

Crossfeed enabler

deadly reentry

far

kas

kerbal join reinforcement

kis

kspapiextensions

launchpad

mechjev2

procedural parts

realchute

scale

Incompatible with unity 4.6f1

realchute

I'm pretty sure that all of them got an update for KSP 1.0.x. Please refer to their forum threads to get the latest mod version and ask for help if they don't work.

It appears that the game has stopped loading at" QuiztechAero/Parts/FuelTank/Mk2_Quart_Tank/Mk2QuarterTank"

You should visit this thread, post your log files there and ask for help.

[saqib126]

Updated all of those mods and more, and fixed the loading getting stuck at quiztechaero, but now its stuck on usi kolonization, posted on that thread now,hopefully they can help me fix it.(if you decide you with to help, here is a link: http://forum.kerbalspaceprogram.com/threads/79588-1-0-4-USI-Kolonization-Systems-%28MKS-OKS%29-%280-31-6%29-2015-07-29?p=2167557#post2167557 my post is at bottom of that page.)

Thanks for your help!

Edited August 30, 2015 by saqib126

[Gaalidas]

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 - - -

Glad, I could help you guy!

I just discovered that the Github cookie's life time came to an end. That's the reason why I couldn't access the repo anymore. *sigh*

I hate me sometimes for not noticing trivial things like that.

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.

[riocrokite]

hey Gaalidays, what are you up to these days concerning new stuff in KF?

Have you done any tests regarding how multiple wheels affect performance (i.e. compared to stock wheels)? I'm thinking about doing something like 2 or 3 wheels - wheel to decrease number of parts and increase performance. Case if we have several vehicles together and each of them has 8 wheels (because of heavy load etc), total number of wheels might very quickly skyrocket and thus affect performance. If we had 2 wheels in one part i.e. we could cut total number of wheels by half and thus increase performance.

[lo-fi]

Before poor Gaalidas' head explodes... How is grouping wheels into one part going to perform any better than as separate parts? This doesn't make a lot of sense you still need the same amount of wheel colliders and the plugin has to do the same work either way. Granted you'd save a few physics joints, but that's the only benefit..

[Gaalidas]

-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.

Edited September 1, 2015 by Gaalidas

[lo-fi]

I came to the conclusion that vessel modules are more hassle than they're worth for this application, which is why I switched back to adding PartModules as components (not as PartModules, so they don't appear in persistence and mess with the indexing) because it's far more robust. It works, and I'd advise against messing with it. Here Be Dragons. Far safer to have a module added to a vessel if it's needed than have it added to every vessel (almost everything implements Vessel) and disabled if not. Procedural is not going to happen for wheels, same as it won't for tracks - it's just too difficult to be worth tackling for complex parts.

Performance wise, it occurred to me that the dust can certainly be improved. Switching the biome colour checking and averaging into the camera module (or call it a dust controller) would unload the emissions routines in KFDustFX hugely. A track, for example, will check and average colour for every single wheel hit, when really doing so once per frame for the whole vessel (or at very least for each part) would be sufficient and take far less CPU cycles. It's going to be a while until I get back to actually doing anything, but there are my musings for what it's worth...

[Gaalidas]

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.

Edited September 2, 2015 by Gaalidas

[Tiberius]

I'm have a bug to report. I was using the mod fine, as it was intended, but then I noticed there was a "deploy" feature for wheels. Perhaps it is unrelated, but after attempting to load a rover with the wheels un-deployed, all of the wheels are now broke. Most work as intended, but never deploy. They are stuck in the un-deployed animation. This happens on the tiniest double rover wheels and the next size up single wheel. No combination of deploying or reloading the scene will fix the problem. The wheels are seen folded up, suspended a few inches over the ground as they drive along. They also don't show the rotation or steering animations. Your mod worked fine at first, and without changing or installing anything else, a few days later started displaying this behavior.

Thanks for any help or tips your might have! I'm really looking forward to using these wheels!

[lo-fi]

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.

Yeah, that's exactly what I thought. And, indeed, what was wrong with the buggy initial 1.9 releases....

I'm have a bug to report. I was using the mod fine, as it was intended, but then I noticed there was a "deploy" feature for wheels. Perhaps it is unrelated, but after attempting to load a rover with the wheels un-deployed, all of the wheels are now broke. Most work as intended, but never deploy. They are stuck in the un-deployed animation. This happens on the tiniest double rover wheels and the next size up single wheel. No combination of deploying or reloading the scene will fix the problem. The wheels are seen folded up, suspended a few inches over the ground as they drive along. They also don't show the rotation or steering animations. Your mod worked fine at first, and without changing or installing anything else, a few days later started displaying this behavior.

Thanks for any help or tips your might have! I'm really looking forward to using these wheels!

The deploy function shouldn't even be there in the release version! Sorry about that. That should at least be an easy fix, though.

[Gaalidas]

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.

[lo-fi]

events that get disabled had been renamed and thus causing an NRE. Nothing obvious there... I don't remember setting it to true in any of the configs, but maybe I had a moment of madness sometime

[Gaalidas]

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?

Edited September 2, 2015 by Gaalidas

[*Aqua*]

So, am I right in assuming you simply got burnt out after the crazy post-release days and had to recharge?

I think the same. The weeks before the 1.9 release lo-fi did a lot of stuff! I even thought he put all of his free time into KF. (Which is insane because you burn out pretty fast!)

[lo-fi]

Yeah, it was a hell of a lot of effort. The vessel module debacle and the persistence lag bug were sort of the last straw. Beyond that, I realised I was fixing or tweaking stuff I really didn't care about, so it was time to take a break! I'll maybe pick it back up over winter, depending what else I've got on and how the mood takes me.

Everything will no doubt fall apart when 1.1 drops, but not a lot I can do about that until that happens and I'm in a position to do so.