Gaalidas

Exactly! Your inferior machine is too... well... inferior... to handle the complexities of a sketch shader despite the power displayed in those other games. Actually, I have no clue... I just had to post something. I'm nuts that way.

It should be noted that the original creator of this mod really doesn't do a lot of hanging out in this forum to answer questions about this thing. As far as I am aware, this thing won't handle DDS textures, so you'll need something else for that (DDS loader and Texture Replacer work well together) and while it will make a 64bit bridge if you launch in 64 bits, the native bugs in KSP 64bit pretty much eliminate the possibility of debugging this thing for that bit level. I have also found that RAM usage is not affected very much, it's more of a performance thing and mostly noticed in the part lists for the editors if you turn off the editor loading feature and let it load only when you select the part. From my understanding of the original idea behind this mod was that it would load a tiny image for the texture, and not a checkered error texture like some have been reporting, and then load (from the disk) the full texture on demand. What is being experienced however is that, when initializing the program, RAM usage is relatively unchanged and, despite the log showing that LOD is unloading old textures, eventually it will load too much data into your RAM and make the game crash. If it was truly unloading old unused textures, you would unlikely have the same problem. Something to consider however, if you are unable to load the game without another texture manager dealing with compression and resizing and all that, then LOD will have issues with your setup. In order to run this along with something like Texture Replacer, which has a very simple "unloader" so that your RAM is not keeping copies of the textures around that it does not need to keep. It also contains a simple version of the DXT compressor for non-DXT formatted textures. While that feature can save RAM usage a bit, it also causes LOD to freak out a bit. In order to use LOD, that compression has to be disabled. In theory, you should not need that compression with LOD active but, as I have experienced, if I do not take extra steps to reduce the files manually (resizing and whatnot), LOD will still hit that RAM limit quite quickly. what this all boils down to is this: If you are trying to use this along side other compression mods, then that is likely the problem with LOD initializing itself. If you are crashing, then you need to cull your mods for unused parts and their assets, or you need more power than LOD gives you. In the end, if LOD works, it's pretty good. It isn't a magic RAM saver though, and it does not work very well with other mods that also handle textures, but can be civil with them if they don't get in the way. I barely got through to the Dev for an update to .25, getting support for little features is not going to be easy. As for SXT, I see very little in that mod that would cause any extra problems. It is very low on the RAM footprint as it is, but if Lack edits any of the textures and passes them out in the wrong format, the current KSP bug with TGA could be affecting it. This counts for any of his dummy-textures if he uses that method for texture replacement. Those dummies are still being loaded, so they all have to be valid uncorrupted image formats. That's all I can come up with.

It'd be really great if the OP title could be updated for the newest release. I've been checking the forums for a while now and only just decided to see if someone was forgetting to update the post title. Apparently I was right.

technically you could shorten the number of things MM needs to patch by eliminating from your patch the parameters that are unchanged. For example: @PART[ASET_PRC_Bumper] { %MODULE[ModuleAnimator] { %name = FSanimateGeneric %startEventGUIName = Deploy Bumper %endEventGUIName = Retract Bumper %actionGUIName = Toggle Bumper %availableInEVA = True } } In the above, I was able to remove the "animationName" parameter because it is the same for both modules. This is not really necessary for a single application but if you want to make a single patch work for multiple parts, detecting common parameters becomes necessary so you do not need to specify the specific information for each part individually. Unfortunately, in this situation, there are other necessary parameters with differing names which make any attempts to modularize the patch nearly impossible... so I guess my point really doesn't work when dealing with a change between stock and FS animators. Too bad I'd already written all this out before I realized that.

Nailed it. I amaze myself sometimes.

Simply changing the water requires editing the assets files, as it has been mentioned. I wonder if any of the shader work being done for the EVE overhaul could be applied to an update for the water system? That's all I've got as far as ideas go at this point. Just one thing you gotta make sure of when updating the assets. Save as a DDS file, which has to be vertically flipped from what you would normally use in any other format. I once used Texture Replacer to try and replace my water by extracting the assets, saving as a PNG and editing away. Because I failed to vertically flip them back to an upright orientation, my water all got reversed in-game. Same thing happened when I tried using the DDS loader on a stock part. I forgot to vertically flip it, so my part was wearing its texture upside down. Looks pretty funky.

awesome. I'd have those details by now, but my father and I decided to catch a showing of "Interstellar" this afternoon. I think I nearly fell through the floor at some point when I realized that my own theory on the relationship between black holes and the micro-singularities/exotic particles passing through our planet constantly being extensions of the same anomaly (a theory inspired by a certain part of string theory) was being represented right there on the screen. I think I'm still in shock.

Before you release everything to the masses, I'm doing some final touches on an attach/stack node redo on all the parts to eliminate odd behavior in how they attach to the parent craft (such as gaps, or attach spots that are different than it appears on the model, bad stack node orientations, and a few stack node size tweaks) I'll update with my findings later. I'm short on time at the moment. If my next test goes well, I should have all the parts aesthetically pleasing as far as attachment goes.

Well, yeah, if the "part" file is unrecognized, then it will not load the part. As for the model and texture, I am less certain. I suppose without the part file, if the model references dummy textures used in texture sharing, then it would not load the full scale textures. The models themselves (except when using static mods like KerbinSide) are relatively small. iT is possible that it still loads all the textures initially, but doesn't commit a copy towards the game if the part compiler deems it unnecessary. I just know that when I watch the loading process, it loads the models and textures before it compiles the parts, but i am unsure when it actually loads the configs themselves. If those are loaded before any of the assets, then you might be correct in that the assets are also skipped. Yeah, logically that all makes sense. I stand corrected.

The model still exists for other parts to reference, as do the textures, but the part would not load or compile. It might improve performance in the part lists, but that's about it really. The loader will skip compiling the parts because it doesn't know they are there, but the model and texture (the really big hit for performance) will still load as an unreferenced asset. Also, while the crafts might not load correctly into the flight-scene, the game will still show them in the editor list with warnings over locked parts detected. So, basically this is a load-time saver. And a slightly less complicated version of an editor-part-list pruner.

Yes, go for it! Change everything... again! yeah! I've become a little burnt out on kerbal killing... uhh I mean... science! yeah, that's it. it's taking me some time just to get to a point where I want to let it try to boot up.

Might be able to cobble some camera transforms in the form of welded cameras to those pods. Heck, you could probably jam an empty mesh with just a camera transform so as to not mess with the outside appearance.

That video has got to be based on some of our weird conversations here. Or at least inspired by the philosophy of kerbal landings where we can say that "a crash landing is still, in every practical and rational aspect, a landing. Safety is not our concern here, only the technicalities of landing a craft successfully. We'll worry about safety when someone complains about it... and the complainer can be our first test subject."

One of many. We're gonna keep you busy until you turn back to drinking just to escape us.

Might be a good second project for you once you have the rest of this stuff stable and released. We'll call it the "Kerbal Foundries Ultimate Stability Initiative (KFUSI)." That, and the "Kerbal Foundries Crawler Steering Initiative (KFCSI)."

I can confirm that launch sites on the Mun, at the very least, do work rather well without any side effects so far.

Given enough time and energy, all should be possible. Doable at this time, however? Not likely.

That's a freakish amount of parts. I accidentally made a lifter that topped 300 parts and launched once, then had to revert because the launch failed laughably and crashed myself to the desktop. It looks amazing though, and could be useful considering the oversize and overweight stuff I tend to build.

Re-enter the atmosphere at the right angle and it'll be ready for dinner by the time it lands.

I've tweaked my copy of the plugin to allow a bit more flexibility in the repulsor height to see if I can squeeze some more height out of it without side effects. I'll let you know if it works.

Yeah, I have yet to look at lo-fi's code to see if a simply addition of that parameter into the cfg would work. I'll get on that.. uhh.. eventually. I hope.

Not only is the maximum height 8 meters at the moment, I discovered that really heavy stuff tend to limit that height even further. 8m for something like that monstrosity might end up looking more like 8 in. Also, might not want to launch it stabilized at such a great height. Otherwise, no matter what happens with those repulsors, that thing is going to fall quite the distance before getting into repulsor range. There is good news however, that maximum height value can be tweaked (if you're a code-diver like me) and I doubt it would be much trouble opening that variable up to the configuration layer. It might already be available, I'm unsure what needs to be done to make that happen. I may have to do some code digging after I finish my SQL homework. If I survive my SQL homework that is. Note: the repulsors never really had a problem with TweakScale, except that nothing other than the model size and node placement was ever actually scaled.

That would sure simplify a few things I've attempted to build.

Honestly, I've never really even updated this mod since I saw it a long time ago and, other than a few specifically complicated parts not getting the shader applied properly, it pretty much works without any hand-holding or whatever. I also don't understand why it hasn't been integrated into the base program already.

That would be nuts. In a good way too.