SpacedInvader

I read it as "fix it for me or I'm out of here", but either way, reading a few pages of posts and having a little appreciation go a long way here.

Perhaps you should read the thread a little before delivering an ultimatum to the developer of a great mod...

I'm really looking forward to seeing that loader up and running as at this point, this issue is the only thing keeping me from using RSS in my main install. It may be a little picky, but even with all of the difficulty mods in place (RSS, RO, Igniter, RT2, etc., etc.) I was already going for Mun / Minmus landings after only a few days of gameplay and, while the challenge of designing something viable to get there and back is great, I really want something worth seeing to be there when I land. On a separate note, while watching Felipe talk about the Krakens in that video, it occurred to me that the jitter he was describing looked very similar to what you see while landed on a planet. Based on the solution, I'm starting to wonder if scaling up the CB's for RSS might have extended the distance from the scene origin, resulting in the jitter?

So I'm going to jump straight in and ask what I'd need to do to this to modify your release to work in the stock Kerbol system? I use everything in the RO / RPL list right now except for RSS because I haven't been able to tweak all of the planetary surfaces into something I'd want to visit just yet. The fact that you've relocated the RT2 base indicates that I'd probably have to do more than just delete the RSS folder out. On the other hand, will RPL work with .23.5 as is assuming I'm able to collect all of the other parts together? EDIT: Maybe a better question is what exactly changed between .23 and .23.5 as it relates to mods? What types of things could I expect to be broken and what could I expect to keep working?

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.