SpacedInvader

Beginning with 6, RSS started converting planet textures as part of its default configuration and has started eating a little more memory as a result. Even more so if you're using my planet replacement pack, and probably even more again once Nathan finishes texture caching so we can control scaled space meshes without an hour of processing on load. That all being said, there aren't any mods that we've identified as being specifically incompatible, except maybe that you need the latest dev build of Mechjeb, so I don't think that's going to be an issue for you. My best recommendation is to run with aggressive ATM and then also Faark's LOD mod, which, when combined, should give you plenty of memory overhead to have parts packs in addition to RSS and all of its supporting mods.

Look for the RSS mod bundler, won't give you just one download, but should make things less complicated I like it, especially the Mars one which I may use, either as is or as a starting point, instead of making a new one from scratch, with your permission of course. Here is a teaser of my Moon map: I'm still in the process of identifying about 10 features to turn into unique biomes so it's not quite done yet.

Thanks for the input so far.. Now I've got my Moon map working in game, but it's stuck on the old Mun biome names. Is there a way to rename or omit the old names so I can use all of my own new names? Doesn't seem like anyone has mentioned this up until now (and yes, I searched)... EDIT: Nevermind... stupid formatting error was stupid... I included the ExactMatchThreshold value for each entry instead of just one for the whole file, fixing that fixed the incorrectly displayed names.

Or that... I'm thinking we should put "Post your output_log.txt with any request for help" in big, bold, red lettering on the OP....

Out of curiosity, how much does increasing the number of biomes increase memory usage, if at all? I'm working on a fairly complex biome map for the RSS Moon, and I'm having to fight to get myself under 60 biomes...

Sounds like you're missing a bracket or a dependency file somewhere in your config.

I've yet to have any troubles with stretchy tanks with LOD... I usually rapid-fire 'T' to get to the texture I want, sometimes needing to cycle a couple of times because I'm doing it too fast, and I still don't get crashes from this...

Nice!... I'm looking forward to it

Did you try searching the thread for an answer before asking this? There is a fix for this exact problem literally 7 posts above yours...

I'm really loving this mod, its nice to have system enforced delays between launches since I know I'd never have to willpower to do it myself. Right now I'm wondering if concurrent building is going to be implemented in the near future because I'd like to be able to set my times to something realistic like a few weeks / months, but also allow for 3-4 vehicles to be building at the same time to balance things out.

This is mostly true, the issue with LOD usually comes when entering the VAB or SPH for some reason. I think part of it is that the command pod section is one of the most texture heavy pages, which is why it might help to have it not load on first entry.

Is there a way to configure this so that nothing is shown / selected on first entering the VAB / SPH? I'm using this in combination with Faark's Load On Demand mod, which only loads textures when they are called and I feel like this would be a good way to further increase memory savings. Basically, I want to enter the editor with nothing selected and then default back to nothing selected when I unselect any group.

I know Mechjeb will show, but in career mode with RPL, you have to wait a while to get that information... didn't know Engineer also showed it. EDIT: I guess it does... and here I was using protractor, engineer, and mechjeb...

Ahh... ok, so the days are not going to match up, only the angles. Time to redownload protractor again I guess.

Wait... so stock KSP launch planners work fine for the inner planets of RSS? Why does that seem like a stretch to me? Does this mean that the other planner will also work?

I've actually been playing with this a little more... Apparently, as its configured, there are actually three chutes: one that has a drogue and a main, and then a separate drogue, which is the one that never gets cut. By not arming it, or by cutting it immediately after it deploys, you get around the problem. I should also mention that it seems that some of the parts defined in those configs are not being generated into the parts list. The one that I know for sure is the Mercury pitch/yaw RCS thrusters. Also the Big-G service module has the connection nodes placed so that there are two above it and none below it.

The best way to check how you're doing on memory is to open your Windows Task Manager and leave it on the processes tab sorted by memory. This should end up with KSP at the top and give you a real time value for total memory used by the process. If you're not on windows, I'm pretty sure there are similar programs to monitor memory usage online somewhere.

Ok, so I've been slowly working on biome maps for the Moon, Mars, and Venus, with the Moon going to be coming out first. I've run into a slight problem with the Moon, however which is that I've been somewhat stuck trying to find a balance between a good selection of the features to identify as biomes, a good coverage of the whole surface, and not having too many biomes. There are literally thousands of combinations and options, though there are certain items I know for sure I want on the list as unique items (Mare Tranquillitatis, for example), so that means I've got to draw the line somewhere. Anyway, the three questions I'm going to put here are: 1: How many biomes is too many biomes? 2: Which features do you all want to see as individual biomes? 3: Which major features are going to be ok to merge into something more general? EDIT: So now I've got a longer short list... all craters and "water features" that are over 200km in diameter, plus the poles, the South Pole Aitken Basin, Lunar highlands, Lunar midlands / lowlands (this is the "oceanic" areas, but its hard to call them the lowlands when the lowest areas are actually in the South Pole Aitken Basin), and then associated craters for each zone. All in all, it looks like nearly 60 biomes, which I'm thinking might be a few too many...

I know I'm quoting something quite old here, but I've got a question that doesn't seem to have been addressed at all, namely, what exactly does the search threshold value do? From reading, I get the impression that if you set it to zero, you get a return of the exact biome you're currently sitting over but what changes if you adjust this number to some other value? Is there a possibility this could get rid of random biomes showing up where they aren't supposed to?

Double post is double... I can't speak to the SOI issue, though I would say that RSS is a finicky beast when you start messing around with things that were very carefully calculated. As for the 180km thing, that's working as intended... The outer most atmosphere begins at 180km, so you're restricted to physical time warp from there on down... EDIT: I'd also like to ask people with the underground bug, are you running .23.5? The more I see your posts, the more I'm reminded of the issues I got when trying to run the 10x Kerbol config from .23 on the v6-pre release of RSS, which is intended to work with .23.5...

Wasn't a dig... I used to love that game...

Found an interesting bug in the Mercury parachute pack. If you just deploy them, everything goes fine, but if you arm them instead, you can't use time acceleration when under a km up. For some reason if you time accelerate down low like this, the chutes will explode and send you shooting straight into the ground. This is much like the April fools prank that stupid_chris played, but not exactly. I've narrowed it down to the secondary chute not getting properly cut for some reason, leading to some strange logic.

Suddenly this game is looking a lot like FS98...

The easy way to find the right date to leave is it use Mechjeb's maneuver planner to automate the date selection. Might night be absolute best efficiency, but at least it's better than just blasting out into interplanetary space and hoping...

I actually used to put a navigation satellite like that up before I found the stock KSP launch planners. This plus Mechjeb will at least give me a decent quick and dirty window planner, but I really hope you math wiz types will get the planetary starting points figured out soon so I can use the real planning software to find most efficient travel windows and such. Is it even worth putting in the effort to create a navigation spreadsheet before the planetary starting locations are fixed? I have to say that I'm starting to get concerns that using inclinations to fake axial tilt like this is going to end up being more trouble than its worth...