SpacedInvader

Ok, this would explain why the surface of the CB tends to "evaporate" as you descend to land. The static mesh is giving way to the dynamic terrain. I'm guessing this happens in stock as well, but because the static mesh is 100% match to the dynamic, you don't see the switch, or at least not as easily. That being said, the heightmap does affect the PQS dynamic output, so I guess my desire to try and increase it's resolution somehow still stands. I will also go back to messing with the PQS modifiers to see if I can come up with something less drastic (75km is pretty big), but also with much more definition so landing and exploring is much more challenging and fun.

Not sure why it froze the parts on loading, but your approach also works. Personally I added the old ones back and turned the tech.cfg into a .bak file to remove the limits entirely, but it cuts out some difficulty, which is why I didn't mention the second option.

This is not the fault of RPL, but rather changes made by NathanKell to the newest release of Stretchy Tanks. He's deprecating the variety of different diameter tanks in favor of the single super-stretchy tank. He's left the old parts in the mod, but unfortunately, you need to unlock a lot of techs to get the super-stretchy to work at larger scales. To get the old tanks back in the VAB, you just need to change the "-1" on the category line of their configs to read "propulsion". http://forum.kerbalspaceprogram.com/threads/64118-0-23-Real-Fuels-v5-3-21-14?p=897356&viewfull=1#post897356

I'm really loving your tech tree and science rebalancing effort here, but I'm a little confused why robotics (something that's been around for decades) is sitting in the tech tree above hover lasers, tractor beams, and death rays (the realm of sci-fi)... My thinking is that this should be one of the more basic tech items and would probably be much more appropriately placed in concurrent development with KAS. Is there any specific reason you've set things up this way?

So the PQS uses the heightmap for each planet model to generate its terrain, but the planet models in scaled space don't have heightmaps? Now I'm just a little confused... To answer your question though, I want low / landed terrain to look better as high orbit seems to look ok for the most part. My whole endeavor so far is to create terrain that is closer to stock / real life when on or close to the surface (i.e. stuff to run into that poses a threat to navigation). Isn't it within the realm of possibility for Kerbin (or earth for that matter) to have small asteroid satellites in orbit?

Where is all that memory going then? Mostly textures even when they are being selectively loaded? I may have to load up a copy of KSP will no mods and all of the stock parts deleted to see just how much memory the engine by itself occupies...

I think in our specific instance, we're hoping to create a better height map for the scaled space Kerbol system so that the stock (albeit larger) planets will look better in scaled space without having to go to vertical extremes like I did in my earlier testing.

What causes the terrain vibration / jitter issue? I've noticed that even in stock, Mechjeb reports some millimeters per second ground speed while landed and nothing seems to stay exactly where you put it for very long, instead slowly moving along the surface.

I've personally only played with PQS settings, but if it is possible to improve the resolution of the terrain map, that would go a long way towards improving the look of the terrain without having to make it overly exaggerated in the vertical.

I'm also curious right now about RSS / RO / everything else that goes with these compatibility with .23.5. The whole asteroid thing really seems interesting, but I want all my realism to stay unbroken while trying to use it...

This may be a stupid question, but does the Active texture management plugin count as compressed textures for this, or is there any potential that they are compatible? I'm interested because ATM would allow the use of non-part texture heavy mods like clouds and city lights and planet factory. It also might reduce the incidence of OOM crashes when entering / exiting the VAB a lot. EDIT: Nevermind, tried it and answered my own question. Will send the logs.

@frozenbacon: Please tell me this is compatible with v6?

I'm already seeing incremental improvements on the previous version. I can't wait for one that compresses textures as well (or at least that can handle compressed textures), but even in current form, I'm running at around 2.9GB with almost 60 mods and with very little trouble.

Something new to test I'm starting to wonder if its at all possible to force KSP to offload other unused resources (e.g. part models) in the same way you can with textures?

Haven't updated to .23.5 just yet, but is there any reason this wouldn't work with the new version?

Ok, so I'm not sure whats happened, but this prank may have corrupted all Realchutes in my save file. I went back to running the pre-prank version when I thought it was just a bug, but now any time I try to use a realchute cone, my rocket will get to an altitude of about 4k on liftoff and then every last junction will instantly fail, usually accompanied by a massive increase in the speed of the camera moving away from Kerbin (reached the orbit of the moon in about 10 seconds), but with no ship living to focus on. What may have gone wrong and is there any way to fix this? EDIT: This behavior doesn't happen when using stock chutes or chutes from other mods.

Suddenly I feel quite gullible

So I've been using this mod for a little while now, but have started using it in conjunction with the realism overhaul mod (and it's pile of extra mods, though not RSS) and have found some strange behavior (at least with the newest version). When the chutes inflate at around 700m, the pod flips over and missiles towards the ground at extreme velocity (reentry effects play even) as if the chute is adding massive thrust rather than drag, killing itself and everything on board. I've tried adjusting settings for the chutes, but nothing has affected the outcome. I've done some searching in this thread, but I can't find any mention of a similar problem. Is this something that has been noted anywhere by anyone, or am I the only one experiencing this? EDIT: I reverted back to 1.0.3 and the crashes immediately stopped

Mun { PQSMod_VertexHeightMap { heightMapDeformity = 75000 //7500 } PQSMod_VertexSimplexHeight // doubles { deformity = 1200 // 400 persistence = 0.8 //0.5 frequency = 12 // 12 //octaves = 10 // 8 // A DOUBLE } PQSMod_VertexHeightNoiseVertHeight // floats { deformity = 4000 // 400 frequency = 12 // 12 //octaves = 7 // 6 // INT } PQSMod_VoronoiCraters { KEYvoronoiSeed = 462 deformation = 2000 //200 //voronoiFrequency = 100 //50 } } I agree that 75km is pretty high. Even that mountain in my testing pics was higher than 20km, but based on visual assessment, if you want to carry the look over from stock, that seems about right. In addition, I'd point out that abnormal proportions are not unheard of beyond earth (e.g. olympus mons). That being said, I'll have to go back and see if I can find a better balance between how tall everything is and how it feels when going there. After all, I'd personally prefer 75km mountains to landing in a planetary wide flat plain. The problem, of course, is that the height map we're using doesn't account for the larger scale, so you can't really get steep slopes spaced around flatter areas without lots of smoothing. As for SimplexHeight, there was a setting I tried there (can't remember exactly what right now) that made the ground look like a cactus, with endless needle sharp spikes sticking out. I'll have to do some more testing in the next day or two, but it may have been setting persistence too high. The old cfg is what I was trying, which I'm guessing probably isn't compatible with the new release. Unless jsimmons decides to update his config to the new release, I may have to make one for myself. I'm guessing it's as simple as converting the orbital body locations to those from the original game, just at a 10x scale? Can you tell me where the original planet files are located so I can work with those numbers?

Thanks, I'll give it a try.

Ok, so in case anyone cares, here are the pics of what I did last night. All pics were taken from about the same point on the Mun, so hopefully the comparison is easy to make. Also, I think I might have overcooked the PQSMod_VertexSimplexHeight persistence a little, leading to an overly bumpy appearance in my tweaked version, but the size is so large that the on ground effect is quite small. I should also mention that v6 did nothing to cure the ground jitters for me, so I'm hoping there is more work being done on this. I'm curious now if there is a way to simply put a capsule / probe onto a planet's surface without having to motor it all the way out there. My poor mechjeb2 pod was killed about 10 times trying to poke around like this, and I can only imagine how much of a pain it would be to try and test this out on a planet like Duna or Eeloo if my probes died every other loading of the game and I've got to motor all the way back out there again...

Sorry for double quoting this, I just wanted to make sure the relevant post was in with my findings. So I guessed, perhaps in error, that the commented out values were the original ones that were modified to create the current real solar system config. Based on that info, and the fact that Kerbin is supposedly about 1/10th the size of earth (at least from the information dropped around this thread), I went ahead and simply increased the heightMapDeformity to 75000. My thinking here was that the reason the object is so flattened is because its trying to implement the same vertical height map over a 10x larger horizontal space, resulting in very gradual, flattened terrain. Anyway, initial testing shows that this made the Munar surface look much like it does at stock system size. Right now I'm putting a lander in the same place in the stock game, RSS without my modification, and then RSS with my modification so I can share some pics of the end result. What I would really like to find is some good documentation of what each part of the PQS block does so I could further tweak it's application, does such a thing exist? On a slightly different topic, now that I've upgraded to v6, my 10x Kerbol system doesn't seem to be quite compatible anymore, with the land around KSC now being below sea level and KSC floating in the air above it. I'm not sure what else might be wrong, but I'm pretty sure this isn't the only departure from the config I want to be using. How might I go about making the old config work with the new RSS? Lastly, I would also like to use the Planet Factory planets in their default configuration with the larger system, how can I make this work? Thanks. EDIT: I would also like to know what I would need to do to let multiple copies of KSP exist on the same system without interfering with each other. I'm not planning on running more than one at a time, but I would like one to play and one to mess around with tweaking things like this without having to try and remember which mods were where and with what configuration settings. Thanks again.

So, out of curiosity, how do you want to handle crash reports? I don't want to just start sending you crash logs for fear that you're going to get inundated...

Perhaps it's on their list, but they have such a long dev list that they just haven't gotten around to it yet.