Gaalidas

Awesome. Sure, stock functionality exists for highlighting parts, but it's rather subtle and tends to not be capable of highlighting parts through other parts. I wasn't even aware this needed an update though. I have been somewhat lacking in my editor activity lately. I'm also one of those on a laptop mostly, and the only feature of KSP that will slow me down more than AA is the shadow system. Heck, I'd play with an abnormal part count and still be more comfortable than with AA, or shadows if I'm really feeling the need to suffer, enabled.

Bribery might work... In fact, I'll take any bribes you want to give. I can't actually do anything... but I'll gladly accept. By the way, lo-fi, time to edit your signature again. The new year is here, so your break is over. Get back to work you lazy animal!

So, I was thinking about this and came up with a thought. Yes, only one thought. My brain is really busy these days and that's all I could afford. ... Oh, right, I should probably tell you what the thought was, shouldn't I? Right then... I was thinking that having options to increase/decrease the gravity factor in addition to the "like this body's gravity" settings would be useful, along with a readout of the current gravity factor being applied to the craft. Perhaps put the change rate at 0.25, thus allowing for quarter-gravity changes. Then, all you'd need is a reset function to disable the gravity modification and reset the device to the default for the current body.

Technically, that craft file link is a photobucket album... might want to check that one.

Hrmm... I wonder if the old release has an issue that we inadvertently fixed in the more recent dev releases. Hovering tanks sounds awesome. If that's the sacrifice I gotta make, then that's what's gotta happen. Good bye cruel world... lock and load!

Hey, could you make it more st... *gets his head bashed in by an angry mob with pitchforks and torches*

On the up side, using the DDS converter and the DDS Loader mod, I have not had to use this mod at all so far. I still miss the performance upgrade this mod provided, but at least KSP is usable with the alternative setup.

I can see all sorts of uses for this kind of thing. It does need some sort of side door, or underside door, with a ramp or a stairway of some sort for easy embarking/disembarking. I'm already thinking about the ways we could adapt it to use Kerbal Foundries tracks (or repulsors) to make the ultimate in stylish off-world rovers.

They've actually been there for a long time (at least, by my perspective, since I bought KSP when it was just moving out of version .18) but sometimes the most obvious things can go completely unnoticed. For instance, when I was having trouble with action groups in my early days, I'd discovered the on/off settings but not the toggles. For many parts, especially modded ones, the toggle was labeled as simply "toggle" but not what it was toggling. So, in the action group setup you could have as many as six different items simply labeled as "toggle" with no other identifier. It wasn't until I started searching teh forums for the answer when finally my brain caught up with me and I discovered that the toggle was related to the actions they were displayed under and it all became clear. Before that, I thought there was something wrong with the hot keys themselves and had attempted to fix the issue by editing the KSP configuration files manually to make them into "toggle" keys. Needless to say, I failed because that wasn't even applicable to my problem.

I was wondering about the no-file thing. I'd also be very curious if anyone else is experiencing the node positioning issues I was having? If not, then me digging through the code for the culprit may turn into a lesson in futility.

Sounds like it's a case of having to not only change the symmetry, but also the model and animation to match. Looks interesting. Are the back-sides also functional? The way they retract, you couldn't just put another set on the other side or they'd clip through each other.

I agree with BigFatStupidHead (awesome name by the way)... Gaalidas has a good point. Hold on... that's me isn't it... I do so hate it when that happens.

I wouldn't say "never" on the topic of making a compatibility addition to the mod in the future for those who prefer that sort of thing, but it's definitely not worth the extra effort to make your mod completely dependent on that form of install. It reminds me of my days modding Oblivion (and Skyrim after that) where we had a few different mod installers out in the world. The nice thing about that was that a mod could be distributed with the specific file type used by those mod managers but, since it was only a zip file with a different extension, it could be opened by any of the current mod installers and managers without issue. the only issue was if the install had scripting for things that had options, such as texture resolution or optional features. One nice feature of those managers was that the scripting and settings for each mod were read from a simple xml or txt file within the archive, so releasing a mod as a simple archived file meant for manual installation could simply package a little extra file in the root of the archive and all of a sudden it was fully compatible with all the other managers while still maintaining the ease of installation for the experienced power user. I'm sure eventually this community will set some form of standard for making the different mod managers compatible with each other, but until that happens it's better to just wait and see what happens.

As I read the title, I was just thinking that it had to be something like "cost for resources" is greater than "cost of part" which results in "I'm sending up an empty tank, and being payed to do it!" Either way, sounds awesome. It's like how I live with my parents while going to college and actually make a bit of extra money on the deal with Financial Aid where they try and compensate me for living costs, and I have none.

Ultra details are a nice thought but, like you've described, it would take a while longer to make everything work together properly and construction of the vehicle would take forever. I know for a fact that KSP does not handle ultra detail very well, and not all users can handle huge part counts either. The main block for that kind of detail is the minimum node size which, at node size 0, is still too large for some of the really small creations we have tried to put into the game. Also, since part connection strength has a lot to do with the node size, if you were to attempt to make a new node size that is smaller than the minimum, you would begin to create nodes that would possibly fall apart as soon as the engine fired up. Option two is much more reasonable.

I've been hearing reports that CKAN just creates an extra level of complexity which means twice as many things that can go horribly wrong with a sensitive mod installation. I even stopped using an older mod manager because it couldn't handle two mods adding files to the same base mod directory without deleting the previous mod that used that directory. On top of that, with my tendency to "fix" some of the configurations in mods that I install, which could cause buggy stuff to happen, could cause such managers to report that the mod is no longer installed correctly, or that I have an outdated version of the mod. For these reasons, I really hate those update notification mods and mod installer programs. That's why my archive unpacker batch file automatically searches for and removes all "*.version" and/or AVC-related dlls it finds.

I just saw the first version of those things for the first time today, and I can't believe I missed them. The new ones are looking nice too.

I'm still a bit scared of the new editor controls. I like all the power we have at our disposal, but I'd finally become very used to how the old editor worked with Editor Extensions and all that, so now I'll be hitting the wrong hot keys constantly.

You could perhaps make use of some of those plugins that attempt to track time passage for the use of using up or generating resources for vessels that are currently unloaded by the engine. In fact, I remember that in the past there have been parts which would expand/retract and others that simply had a visual indicator to show their current filled status. If a system like that could be implemented where the resource represents the time it takes for the specific part to get fully scratched up according to this mod, and the visual indicator is the overlay applied in similar fashion to the shader modifying process of KerbPaint, then you might be able to get the desired effect. So, basically, the part would have a resource (call it "space-time sandpaper") and a module that slowly drains this resource based on the current conditions defined in a config node that corresponds to either a planetary body or empty space, and even different regions on planets with biomes could be defined. For certain percentages of this resource drain, the shader would apply a different mask which would produce these scratches/dust layers that again could be defined by the configuration, in an image likely. Upon re-loading that craft and using it another module, which only runs when the vessel is active, will slowly (more slowly that the drain, likely) regenerate this resource which would cause the resource-tracking module to reverse the state of the mask, stopping just short of a full recovery until either the craft is manually cleaned/repaired (maybe an EVA kerbal could perform these actions) or the biome/configured body was changed which would cause rapid recovery of this resource, followed by a subtle switch to the new mask. So, in the end, not exactly simple, but also not exactly impossible. Again, however, making a mask work for all the supported parts without having to re-mask every textured part individually for each configured environment could be the near-impossible part. You'd need to be extremely subtle with the scratches/dust so that you could apply the mask to the entire craft without making it appear awkward. Also, you'd need to make sure you aren't blocking transparency, emissive maps, or any other effects that the base game makes use of. One of the issues with KerbPaint is that you have to use different shaders depending on what shaders the part already makes use of or you'll get some odd results. For parts with multiple objects that are skinned individually, you needed to tell the plugin to do a forced override which, if the mask was not perfectly aligned and colored, could make certain areas on the part look completely off. The downside of such an openly-expandable environment such as we have with KSP is that we lack any standards that can be enforced when making new parts which would allow us to create add-ons such as this without having to worry about incompatibilities. This would be simple in many other platforms, but with Unity and KSP it could easily drive you utterly insane.

It's amazing what you can accomplish with something that's only half busted. I lost half of my wheels on a 32-wheel rig I created a few months ago and still managed to go a fair ways on Kerbin itself. Yeah, so I did crash eventually, since the whole front of the long-hulled rover was hanging by a thread and the ground sorta decided to rise up and smack me in the face... but I was kinda asking for it anyway running at top speed with less than a bottle of glue holding that thing together. EDIT: Lo-fi, you... err... little man... err... thing! Okay I didn't think too hard on that one. Anyway... when you did your last few updates to the github, you reversed every optimization and addition I made to any of your code, even if you didn't actually change anything in that file. This is one of those moments when, in my younger days of trying to manage Ultima Online servers and honing my isometric building skills (I was pretty awesome, if I'm allowed to claim that myself.), where my friend at the time would do something that just irritated me and the only thing I could think of to say at that moment was... and I quote myself (scary isn't it?).. "U Suk!" Anyway, good to have you back in action, can't wait to see what else you irritate me wit.... I mean, what new and exciting things you come out with. That was a close one...

Sounds like a new way of branding a resource generator. Don't get me wrong, I sorta like it... but it does feel like just a rebranding some something we have already.

Ah, well, that was a long time ago and I forgot all about returning here to report on my findings. Logs are rather unhelpful, since there's not a lot of messages being passed to it about the specific actions taken by NodeHelper. Anyway, it turns out that NodeHelper was giving me some errant coordinates. I basically had to take the original position of the node reported by NodeHelper and calculate the difference with the new node coordinates (per-axis, and multiplied by -1 if the change was in the negative direction) and then apply that final difference to the original node position in the original part configuration. Only then did the node appear, once I reloaded all the data, in the correct position. I'm not completely convinced it was completely the fault of NodeHelper, otherwise I would have expected more people to report on the issue. I suspect that, which the parts themselves were not being scaled by any amount by TweakScale, the simple fact that TS was managing node positions, based on scale, could have affected their reported positions when NodeHelper recalled them. I also want to mention that a lot of stock parts were having issues with their node positions, and their scales as well (it might have been scale, rather than the nodes, but the parts I'm working on are not being scaled improperly so I suspect that node positioning was also buggy) so this could have been a problem with the base program. The issue with the node orientation, from what I can gather, is not necessarily a breaking issue. the orientations are supposed to be numeric, ranging between -1 and 1. setting one of the coordinates to 1.25, as NodeHelper was so helpful in doing automatically when parsing the part data for the first time that play session, would result in nothing more than a little error when KSP tried to read the data. Either way, it would still orient to the closest valid numeric range... in this case 1. Still annoying, however, and in need of investigation. Note, however, I have yet to do a lot of testing in the new KSP version (0.90) due to all the plugin updating madness going on still as I type. NodeHelper is still an invaluable tool, but it has some quirks that need to be taken into account when using it alongside other plugins that modify node positions.

Wow... that's all I've got for that one. Just when you think you've seen it all... yeah... EDIT: I actually watched the video on that website a few minutes ago. That's some hilarious stuff.

The animation for the decoupler would be guesswork if you can't find documentation, but the functionality might be able to be derived from Baha's animated engines plugin. In that, he has settings that allow for an engine to not activate until it's fully extended. If the desire here is to have an animation play out before the decouple process is activated, then that might be a good place to start. I have not even heard about this decoupler system before, so that's as far as I can go.

No, getting rid of Vista is always a good thing. Still, it could be Windows 8... okay, forgive me, but I really dislike Windows 8... to be fair, it probably isn't the operating system. I say "probably" because now that I've said that, it probably will turn out to be the operating system and I'll have to rethink the problem. My guess is that it will fix itself over a little time, but I have yet to look at the link myself. It's possible that something went wrong on the server side and we might have to wait for an official update. I suspect it will correct itself in time, though.