Gaalidas

I'd like to note that we haven't actually released the KF wheel update as soon as I thought we were going to when I made my previous post... so if you've also removed the old module names from the exclusion list then you've actually messed up other people who are still using the old release. Sorry about that. I was under the impression that we were within 2 days of a new release, but now it's looking like lo-fi is taking some time off while the 0.90 and holiday season debris clears before making a new release. It's well worth the wait though, I assure you. You know, I don't actually have any issue with the grass producing sparks. Okay, so it's not exactly what you'd see in the real world all the time but considering that the ground is likely very rocky and quite solid considering all the abuse we put it though and it still looks perfect, sparks kinda make sense there. I think it's all fake grass anyway. The KSC would be a complete and utter mess of a bog by now if it were real. My theory is that all the grassy terrain on Kerbin is actually a false surface that hides Kerbin's subterranean population. Rather than try to house them all in true subterranean dwellings, the administration of population control (of which the KSC is a major member of, if you consider all the kerbals being removed from the over-population statistics on the hourly basis in horrible aircraft and spacecraft related experiments) decided to encase the entire surface of the planet (at least the habitable parts) in an artificial sphere made to resemble an untouched and perfect planetary surface. This could also explain how such alrge parts can be built and assembled at the KSC without any perceivable assembly plants and other production systems in place to prepare the materials. The solution is that the entire production system is actually underground... which means that the part of the VAB that we can see is really the very tip of a huge building where only the very top is poking through the shroud. I cannot prove any of this though... so I'll just have to shoot any one of you who disagrees with me. It's nothing personal honest... EDIT: after looking at the updated MM patch you made, I see that you just updated the repulsor module check, and have left out the updates to the KF module names for the time being. Good! Had me worried for a while there.

If deleting a mod like "ActiveTextureManagement" fixed it, then it's probably an issue with the configuration for that mod in the way it's handling that texture. Deleting the other mod is only a partial fix really. But, I don't use that mod personally... so I can't say if there's more to it than just a config error. That sounds seriously awesome. I assume this means you're going to be building a large static object meant to look like the side of a hill or something, since I don't believe we can manipulate the standard surface of the planet to create a "hole" where we can build underground. Still, if you can blend it in really nice it could be awesome.

That's a bit of an issue then I suppose... anyone else having podless pods?

So, on the note of those "count: 0" messages of the ambiguous manner... I wonder if it would be better to just disable that message for the release version of the plugin, or make the verbosity of those messages configurable somehow. Personally, I've downloaded your source and gone through to disable all of those messages (and it takes some searching I must say) and recompiled a local copy for myself. They may be mostly harmless, but they're also annoying.

The problems with pParts are totally different than any problems that exist anywhere. I could never get that mod to work right no matter what. pWings on the other hand, with a few tiny hotfixes back when the current version was released to keep me from stalling on the load screen, is much more stable. Heck, I don't even make planes but I still consider this a must-have. I'm not sure why to be honest... So, this mod doesn't use KSPAPIExtensions? What's wrong? They not extensive enough for you? Everyone else is using it.. all the cool kids anyway. You know you want to... give in... end your pain... I'm really creepy aren't I?

Not that bizarre. Physics warp causes all sorta of weird issues. It's really best to steer clear whenever possible. I hadn't heard about the KK issues. However, since they added KSC upgrades and such, I'm sure that the method to adding static structures has changed dramatically, and plugin authors will need to be aware of what could be expanded in the structures there so as to not get in the way. I did recompile the KF plugin last night to make sure there were no issues. Sure enough, the only issues are a few warnings about functions that don't return anything, and those are only warnings anyway. No problems detected on that front.

The config in the distribution got messed up in the "free" area. The "free" scaletype should look something like this: SCALETYPE { name = free freeScale = true minScale = 25 maxScale = 400 defaultScale = 100 suffix = % }

Several of the other plugins used in B9 are generating exception errors in the logs and such, in a very consistent manner as many other mods which relied on code that has been changed in the KSP API. Small things, such as animation based on air speed and whatnot might fail.

Firespitter was, supposedly, hotfixed. I was just thinking I should disable steam auto-update the other night when going to bed. Woke up to an updated KSP install. Otherwise, have any issues been detected with the parts/plugin under 0.90?

So far no word on the issue I opened up. I attempted to recompile and/or fix some issues, but eventually I had to give up. I just don't have the expertise.

I swear I was thinking I should disable steam auto-update and when I woke up the next morning I discovered it had done it while I was asleep. Too late.

I actually disabled TS on all my engines and reset my mass exponent to 2 I believe. My issue is that the effects do not scale correctly with the engine, and visual appeal is more important to me than flexibility in engine size.

While TS has been updated, certain plugins that come with it are not initializing correctly. I'm currently researching whether or not they're even used anymore.

So, KJR has been updated so you know, not that I've tested it yet. I run too many mods that all need to function with KSP in its current version in order to be able to load the game and still be able to do anything with it. Physics warp always screws with everything. It's not only multiplying time, but also the physics simulation with it. That's why physics warping a plane in the atmosphere, while throttled up, which is not properly strutted or whatnot will essentially create what we call "unplanned rapid dis-assembly" in which your craft tears itself apart and proceeds to go boom, or otherwise fly off in separate directions. This could also mean that the repulsors cannot keep up with physics (in this case the physical phenomenon known as gravity) running at hyper speed pulling the craft down toward the ground. Similar effects can be seen with wheels that have especially weak suspensions, or aircraft that experience what I mentioned earlier. Another way of looking at it is that the planet really sucks. It sucks hard on just about anything it can reach. Everyone knows that planets really hate it when you defy their suckage, so they suck especially hard on those that try to escape. Get your mind out of the gutter you sicko, this is real science here... You can view physics warp as basically taking the suckage engines and running them on a little bit of high-speed. It really sucks. Now you can go back to your gutter... you sicko.

I was thinking yesterday that what we need now is for that plugin to respond to gimbal controls so that, under plugins like KM_Gimbal, they can be automatically adjusted so that the center of thrust is lined up with the center of mass like we can with gimbals on regular engines.

I over did it with the popcorn and soda. Still, it was an awesome event... and final chapter. So... woohoo... update 0.90 is upon us. Now the long wait while all the mods catch up.

Well, crud. I was afraid of that. Time to go open an issue on the dev page.

Actually, I cloned directly in Github for windows, then directed unity to that and it worked pretty well. Had to redirect the part tools, which were thankfully already set up in that project, and it seems to be doing well. I don't have any idea what I'm looking at, so I do a lot of "don't same the bleeping changes that I don't remember even doing!" and hoping for the best. Unity will be my worst learning curve situation this holiday season, if I choose to tackle it at all. I almost prefer to load the MU files in a text editor to get the information I need. Anyway, I realized when I woke up that I had talked about doing things "tomorrow" when, if fact due to my inability to get to sleep last night, it was tomorrow already. So, worry not, I have no intention of waiting another 24 hours to do anything else. Though, it should be mentioned that later today I'm going to a marathon showing of the previous two Hobbit movies followed by a showing of the new movie 2 days before non-marathon viewers get to see it. I'm gonna be sick of Middle-Earth by the end of the night (it's a 9-hour event). So, I'll be out of commission by noon-ish.

A note about the AGs. I just did some testing and, while I am unsure due to some extreme subtlety on the changed in ride-height with tracks, I am somewhat unconvinced that the ride-height AGs are auto-applying their new settings or not. That was, after all, the goal. The repulsors seem to auto-evaluate their right-height with each physics update (I think, I won't pretend to understand it fully) but the wheels need an extra push to me them update. I'll test again with actual wheels tomorrow to be sure. On the up side, I'm not getting those huge leaps anymore. As for that old rover body, I'd be interested in seeing how hard it would be to implement something like the node activation/deactivation that exists on the ERS rover system for giving an option to attach wheels in an optimal configuration via stack nodes. I'll do a little research on that. I'm still a little scared of Unity. I have it installed, but all those part tools have yet to be made easy to install as a single package for the recent updates to them, and I've actually never successfully loaded any real assets into it... ever...

I love the inline landing legs. That's an excellent method that probably would have made the stuff ASET was working on for Konquest a lot easier. I'd like to see just a little thin disk you could stick to other parts that would implement just the landing leg portion of the setup.

That's what we're here for. Someone's got to be able to tell you when you're being a dummy.

Very well, I'll give the code one more look-over to see if they really are redundant still and then publish the changes. I can't understand all of your changes to the AG stuff, but I like it better than my various attempts over the last 24 hours. I actually managed to break everything but the TweakScale context menu entries for all of your parts in my attempts to modify how the AGs worked. I was just about to have another go at it when I accidentally launched Github and saw your change. Love the new texture on the long track, too. Now I don't feel so... weird... when testing it. I hate it when parts are given that default white instead of a real texture. even a 2x2 texture with no alpha and pure white is preferable to no texture at all. At least then it could be made Paintable using that plugin. The next thing I'd like to tackle for these wheels and such are the redundant/unused textures that are still being published with them. With ram at a premium in KSP, we need to eliminate anything which might be loaded, whether they're kept loaded or not, to reduce load times and ram usage. Fortunately I've learned how to read the MU file format rather well in notepad++ to look for the referenced textures and clean things up. I think the only real culprits are a few wheels with an extra texture that looks the same as the one referenced, and a few tracks with an extra texture that looks like a tread-mark or something that also isn't used from what I can tell. I've also done some work on a few normals that were lacking and darkened/sharpened a few things that I thought could use it. The really large wheel set in particular has had a little update that reduces the blinding brightness of the suspension and attach bars so that they look metallic instead of glowing fluorescent (dependent on video brightness settings, I suppose.) I'm no texture artist, but I dabble.

If that's the case, then I can remove any changes to that variable being applied to the KFWheel module. That simplifies things even further. In fact, before reading this message I synced up my github copy and noticed you'd made a few adjustments. I'm getting ready to test another tweak to my action group expansion. I've probably broken them further, but I've been so lucky with TS lately, I'm feeling like it might have a shot at actually working right out of the box. Glad to hear you're happy with the TS scales available. I admit, I did not test every part to see if those values worked, I merely gave it a reasonable guess and tested a few of the parts to see what would happen. I then got lazy and said "here goes nothing" with my github update. Also, don't feel bad you've barely been keeping up with me. I barely keep up with myself sometimes. I look back at my forum posts and think to myself "Did I really type that? What was I thinking?!"

Ahh crud, you've gone and done it again. Lo-fi, you're going to become developer of the century in a week at this rate.

I think the lack of autoscale, which many people mistake as a bug when in fact it's a feature that wasn't made into a toggle like it should have been, is the only real benefit of it. As for why my fix works, I have no clue either. But, it does work and it actually allows me some extra flexibility in how I define the scales and their correction values. Otherwise, I was severely limited due to how lo-fi has bundled his various ways of handling tracks/wheels/whatever in the same modules rather than making dedicated modules for each one. it sounds wonderful when making the plugin efficient and making the configs easy to write for different styles of locomotion, but for modifying things from other plugins it's a nightmare. I'm just glad that TweakScale was developed with enough flexibility to allow the scaled values to be defined in a plethora of different ways. It makes the learning curve really steep, but in the end it's worth it. It's a bit like the English language. There are so many different ways to say the exact same thing with you take into account accents from all around the world (half of them in the USA alone) and the different spellings between USA and British, and even Canadian ways of doing things... well, you get the picture. It's a nightmare to learn, but once you get to a certain point in that learning curve you begin to realize it's incredibly difficult to break the language (so to speak) and you can get away with almost anything and still be understood. Then begins the long and arduous task of learning all those various ways to say things in an attempt to master it. The difference here is that I probably won't die of old age before mastering the different ways to define scales in TweakScale.