SpacedInvader

Doesn't setting their sizes so large prevent any of the normal sized (even for RO) docking ports from fitting correctly? My thinking is that they should be rescaled to 1.6 like the pods to match up. This all being said, I'm currently debating with myself whether or not I really want RO. I do much enjoy the added realism, but the size change often means that parts are just not going to work with the new system until someone goes through and spends the time to make them all fit correctly simply because 99% of all parts packs are built for the stock system. This is only compounded with complex packs like FusTek or Chaka Monkey which don't scale well. Even with a small to large adapter like we're talking about, you could end up with a 4m diameter pod docking to a 2.5m diameter space station part, which is just as unrealistic as if it was all 2.5m. EDIT: On this note, how hard would it be to build a version of this mod that has the tweaks to everything except the part sizes?

This is because the center of lift / mass for the pod are not in alignment so you can . The red arrow there is showing you where it wants to turn under thrust. I would shrink the size of your COM ball to see if there is a turn circle there, and if there isn't, just move / add weight 90° CCW (or is it CW? It's been so long since highschool physics...) from the arrow until it's gone.

I would definitely like that, whichever you would prefer. This has brought up something else that I think this mod actually really needs, namely an adapter or two to allow standard sized docking ports to be fitted to RO sized docking port spaces, or maybe even a "dual purpose" docking ring that fits 2m and 1.25m. The issue here is that there are just too many parts packs that have not, and probably will not for some time, be resized to the RO standard, but would still be nice to be able to fit in game without ugly empty spaces. Just a thought.

Has anyone been able to get the FusTek station parts to work correctly when resizing? The config included with RO has the parts named wrong, but when I correct the names, I start getting lots of z-fighting and the tapered ends are gone. Plus crashes...

So in the last week or so I found an interesting little chart showing how different tank and engine combinations work together (pressurized vs. non-pressurized and pressure-fed vs. non-pressure fed). I found this very useful for picking out an engine at the time, but now I can't find it again for the life of me. I wonder if someone knows where I can find it or perhaps could repost something similar here. Thanks.

Mac is OpenGL, which is unlikely to be supported any time soon.

I guess I didn't get that this is what you were looking for... I'll have a chance to do that when I get home from work tonight and we can compare notes. I'll also get the debug version and get you some logs which might help identify where all that extra memory is going.

So I've got a fairly frustrating issue that keeps cropping up. I can't tell if the problem resides with Real Fuels, Engine Igniter, or with the parts themselves, so I figured I'd put it here. Anyway, here's what's happening: Certain engines that require pressurized fuel tanks will *sometimes* claim that they are not connected to pressurized tanks, and thus show that they have no fuel, even if they are clearly attached to a pressurized service module full of the correct fuel types. Reverting to the editor and removing / adding the engine again will often correct the issue, but not always, and this issue doesn't always crop up on the first activation of the engine, so reverting isn't always an option as the mission may have been going on for some time. Has anyone else experienced this, and if so, have you been able to correct it? I have considered removing engine igniter, but I'm not convinced that this is the source of the issue as it still only happens with certain pressure fed engines and not others, leading me to believe that there may be a combination of factors leading to this issue rather than a single culprit....

No, I've not been just deleting files willy-nilly... Any deleting I do is either full mod removal for testing, or trimming parts for memory savings. The issue is that with 80 mods to test, it would take days of free time just loading and reloading the game to figure out which ones are the greatest draw on memory in a stock config, which is something I probably won't get around to for a while. I think a much better approach in this case is for all of us who are getting similar results for memory usage should see what mods we have in common and then spend time testing those. Since I've not been able to find a way to just export a list, here is a screencap of my GameData folder:

Is there a program or mod that allows you to easily generate a mod list? I do have 80ish mods and I'm not really that interested in writing them all out... Does LOD handle MBM files at all? I've noticed several of my largest part mods are mostly MBM and removing them from the game can free up hundreds of MB of memory still, even with LOD + ATM installed, so I'm wondering if this might be where all the extra memory is being eaten up? I think this is the next question we need to solve. This mod has allowed most of us to install way more mods than would previously have been possible by cutting out most of the texture memory (I know for a fact that I don't even get to the main menu without it with my current setup), but now we're left with the question of where all that memory is still being used. It's pretty clear that its something that we all have in common, or at least in similar, as a load of 2.8 - 3.0 GB with an increase moving into play mode seems very common.

Hmm... Now I'm kinda wondering where all of your memory is going if I've got twice the textures you've got and you're getting the same memory usage that I'm getting.

Looks a lot like you're missing the Earth height map. Bad install maybe?

You're confirming the possible additive memory, or the large-ish increase in memory going from VAB to pad? Sorry, just want to be sure of what you're saying here. Also, my persistent save is much smaller at about 1.4MB.

are as expected v3 required about ~60-80mb in total. Measuring it is kinda complicated, since everything can have an impact. For example an focused app during SC=>LaunchPad had 40-150mb more memory committed. But stuff like that is in the nature of multi-threaded applications. I cannot reproduce such a significant increase in memory usage. I will spend time looking through my gamedata folder to see if any mods have left similarly named files like that sitting around. That being said, I'm a little confused by your numbers. It looks to me like you're getting the same 400-600 MB jump in memory usage that I am experiencing, except you're getting it for both V2 and V3, where I am only getting it with V3. Perhaps the issue is that I was getting better usage stats with the previous version through some quirk of my install? EDIT: Is it possible that the extra texture memory might be at least slightly additive when you have more textures? I've been testing (unscientifically) what happens when I reduce the overall number of textures and the results seem to show that being the case, at least to a small degree. I had about 2200 textures, which would have me load into the VAB at the aforementioned 3.3GB, then I tried removing a few hundred textures, which resulted in the same ship loading at about 3.15GB without losing any of its textures.

Aren't the hinged doors historically accurate?

I thought I did because the one on my computer was dated a day after the on in your thread, but I guess that fixed it. Thanks for the help. I see btw what you mean about the FASA being scaled better. The SLA from OLDD, while way cooler, leaves a gap around the base of the SM rather than fitting snug.

Glad I could help, even if it was by fumbling around. Now a new question however... It seems that the FASA Saturn is configured only for modular fuel tanks and not real fuels. Is this the case, or am I doing something wrong again? EDIT: Seems that both are giving me this trouble. When I try to enter the fuel dialog in the action group mode, I'm greeted with the message "This fuel tank cannot hold resources"

Ok, so I got the OLDD version to work, turns out I was trying to attach the top node of the LEM deployment device to the the bottom of the SPS (a la proc fairings interstage) which left no room at all in between for the LEM. As for FASA, I have the newest version, and I have the configs you linked a page or two back, but for the life of me, I can't find the SLA anywhere. EDIT: I have the walls, just not the base. EDIT2: Nevermind, I found it, was just filtering it out by only looking for FASA in partcatalog...

Not going to jump straight into calling this one an error, but with your configs installed, the node position for the LEM deployment device is such that the plate is only a few inches from the bottom of the engine bell. This holds true for both OLDD and FASA. Is there some trick I'm missing?

I wouldn't say that ATM is obsolete now.... These two mods work extremely well together, and working together, I consider them to be must have add-ons. With this and ATM in aggressive mode, I'm able to run with a 3.2GB GameData folder, and with this newest version, do it at about 90%-95% stability. Without these mods, I wouldn't even get halfway through the loading screen, or I'd have to cut out at least half of the mods I use and then trim them for parts on top of that. As a result, I recommend this mod to pretty much everyone who I interact with on the forums. I may have made some comments about memory usage, but I'm only trying to give what little input I can to help Faark get to the most optimal configuration. As for the glitches, I'd say they will be gone soon enough. And anyway, as you said, this is a default part of pretty much every other game, so the fact that Faark has produced this almost single handedly raises KSP to a level with many other games that have had much more money thrown into their development.

Ok, this may be a stupid-ish question, but are the OLDD and FASA versions of this both necessary for building an Apollo mission, or are they mutually exclusive?

Well that could be part of my problem. Part of my mission profile is to leave a stage with comms relay equipment in high orbit (2500km) so that's where I'm starting my descent from. I guess it shouldn't surprise me that I've got to have more DV when falling from that much higher of an altitude.

Unfortunately, I've got 80ish mods installed, so it could be LOD interacting with any one of them. That being said, there is a clear increase of 500MB in working memory (no clue about commit just yet) while in play mode with a complex craft from the previous version to this. I'm definitely getting much better results than with v2.2 as each added part only increases memory by a few MB, allowing me to comfortably work on my ships without the constant fear of crashing, but I have concerns that in game crashes while in play mode are going to become more common... I've already had one, just didn't think to grab the logs because I wanted to get back to where I was ASAP. That being said, would a non-crash log help at all in this situation, perhaps a before and after of going from VAB to pad? As for the changes you've made, I'm not unhappy with them at all, I was just throwing out some ideas as well as voicing my personal opinion that I'd rather have a game that takes longer to load, but never crashes than a game that loads faster, yet rides closer to the edge on memory usage, leaving the potential open for more crashes. I'd still by far rather work with your newest version than the older version, as I was able to build and test rockets all night and the only crash I experienced was during play during atmospheric entry, so reloading brought me almost back to the same place. With the previous version, I could easily expect a crash every 5-30 minutes in the VAB, leading to multiple long reloads (80 mods takes about 5min from desktop to loaded save and I've got KSP on a SSD) before I ever got to space.

@RedAV8R: Found a typo in the Apollo CSM config. You had the heatshield pointing to a part named Apollo_CM_HeatShield when it should be FASAApollo_CM_HeatShield, resulting in the mod not being applied to that particular part. EDIT: As for the realism stuff, there really isn't that much to it. All you need is the 9 mods listed under required in the OP. Everything else is optional, but when you really boil it down, there are those 9, some parts packs, RPL, RT2, and TACLS. Most of those authors have worked together, so its really just a matter of downloading the various mods and then you're done...

Ofc not? I'm guessing that means of course not, but of course not what? Sorry...