JeBuSBrian

Why? It's already compatible with everything. All you need to do is type up your cfg changes.

Wow, okay. The scale was certainly a lot bigger than I expected. This going to be like... 15m wide? Maybe even 20m judging by that? That's a whole other ballpark.

What I mean is, why bother having to make more adapters? If that's the basic shape you want, simply aligning them with LLL or THSS from the start would save you the effort.@dizzysaurus, This isn't the place to discuss that. Go to the LLL / THSS threads.

Can I suggest that you make those larger trusses align with LLL / THSS? There's a certain commonality of shape there.

There's nothing simpler than a six-letter code to input into the forum.

I have the exact opposite situation you do. .20 essentially allowed me to double the number of mods I'm running. But, this isn't the place to beat that dead horse.As far as I know, there's no source code out there for ENBoost. If it doesn't work for KSP out of the box, there's very little chance it ever will. I can only begin to imagine how its developer optimized it for Skyrim, and I can't imagine it would work for KSP. Skyrim's world is based on cells whose contents are well-defined and fairly unchanging. This would allow for a very efficient look-ahead, to know which data needs to be loaded next into the extended memory, before being swapped into the main memory. KSP is wholly different in that regard, in that objects can be anywhere in the universe, and in constant motion.

Just use the album code. Hit the "Reply With Quote" at the bottom of my post to see how I did it.

It's a very minor pain. Not like you need to recreate it by hand.

Just use the [imgur] tag and embed the album.

I believe it creates a catalog at some point which indexes all parts by folder. If it's not in the folder when the index is made, it doesn't show up. You can delete the catalog.txt and config.xml and that should reload the whole thing the next time you start the game.

As I understand ENBoost, it would never help the lower-end machine folk. It is designed to take advantage of memory greater than the normal limit (~3.1GB RAM) as well as loading massive amounts of texture data into the GPU's own RAM. The more of each, the more effective ENBoost would be. It creates a cache in a separate process, which essentially doubles the available RAM, then swaps which items are in which process's memory dynamically. If you are on a low-end system, there's not going to be any spare system or gpu RAM for it to use.

It already is for me.

Question: Are the clouds a separate object, or are they simply baked into the ground texture?

It works as-is. I'm fairly certain the only customizations not included in the first post are the ones I made a few back, and dizzysaurus's just before that. So, you know... do it yourself.

Wow, yeah... they are all typoed like that. Good catch!

I tried these yesterday and found them finicky for engine placement, as well. Even with part clipping, it was hard to get them attached. I found it easiest to place the center engine first, then try to get the outer ones on.

There's a story there just waiting to be written.

I think the breakiningForce and breakingTorque need to be increased significantly on the engines. They're falling off before I even get them into orbit... before I even get to the upper stage, really. I'm going to test a bit with 500 or so to see if that keeps them attached. Will report findings... Yep, setting both to 500 worked to keep the engines attached during ascent. Don't know if the number could safely be lowered or not, but since it works, I'm going to leave it at that. Your mileage may vary.

I guess we're both failing pretty miserably at our goals. Have you gotten it to work after merging the folders?

...Look, I don't want to sound like an ass, but how long have you been using a computer? Because, well... this is a pretty simple concept. If you want files in Folder A to be in Folder B, you need to merge them. Yes, merge the folders.

Seriously? The GameData folder that comes with any mod will drop into the same place as the GameData folder that exists with the vanilla game. Drop it straight into the root KSP directory. This is not rocket surgery.

Kinda splitting hairs there, considering you made them both, and this is just about the only thing that uses KD, don't ya think? Anyhow, from the looks of it, KD isn't recognizing that parts now use the Part{} wrapper. It's trying to use them in the old format. So even importing parts isn't going to do much good. Though, this is me just jumping into the deep end of your code, so you'd know better than me.

This is not quite working the way it used to, since the part cfg format changes. It doesn't actually load the parts. Basically, it's kinda useless at the moment. Unless I'm missing something very basic. It scans the Parts folder which is now empty, rather than the GameData folder where everything has gone. At least, that's what the source code suggests. I'm still picking my way through that, trying to make sense of how it parses the files. Not straightforward in that regard.

Call me Mister Request... OSS Struts with the same 6-way branching tunnels as the cargo containers would round out things nicely. Also, going back to my comments on the differing lengths... I noted that while one short tank generally looks to equal 1/3 of the long tanks, if you actually put 3 of them together, they're a tad bit longer than the big one. I think this is because the outer struts match up. Problem with that is it means they're slightly too long, because each of the three matches that length. If you could chop half of each outer strut off, they should line up properly. This happens with all the parts with varying lengths.