SpacedInvader

Just a simple question, how much memory does each ongoing on-rails flight take on average? Thanks. EDIT: I posted this in general discussion, I'm not sure how it ended up here...

This is wrong... on loading it should say 0/X loaded, where X = total number of part textures you have in your gamedata folder. It should also run through all of them on the "p:" line once on loading. As far as the window being necessary, I'm not sure, Faark hasn't really commented about it needing to be open or not for the mod to work.

What mod folder does the log say it's attempting to load at the time of the crash? The LOD log usually says what file it's having a fit with.

As far as I can tell, there doesn't seem to be a way to smooth them. That being said, maybe adding a new PQS noise mod with negative start and end values might do the trick. EDIT: So far I've been unable to affect them at all with any of the mods other than the one that created them and I've tried differing variations of 10 of them.

On a separate note, now that I'm getting a clear handle on how to make planetary surfaces interesting, I'd like to move back into the 10x Kerbol system. I was thinking about just using Frozenbacon's nice RSS config, but I would like to add the planet factory planets into it (scaled up 10x as well) and also make any changes necessary to bring it into 100% compatibility with the most recent version of RSS. Some help / guidance would be appreciated.

BTW Faark, I was thinking if you want to make this thing ready for release before starting further improvements, I'd suggest the following, which I'm hoping are easy modifications: 1: Give it toolbar integration so we can close the window and reopen it on demand 2: Get the info window to stay open beyond when you release the mouse 3: Have better item names than "p:", "l:", etc. Those are the most basic changes I would think you would need before you could readily move this to the release thread. It's already quite stable (I haven't had a crash since 2.2) and really just set for more improvement in memory handling and maybe compressed textures.

More pics... Although I think I can manage at least part of this tweak within the current RSS parameters, I'm really looking forward to getting the generic PQS loader so we can have 100% control over the mods.

I started with a heightmap deformity of 30Km since that's what you described as being correct for Mars. Then I exaggerated the deformity for the first PQSMod_VertexHeightNoiseVertHeightCurve2 up to 15Km and then tweaked its values some. The most important of those, however was the simplexHeightEnd which I cut in to 2500 which drew in the walls of the canyon significantly. PQSMod_VertexHeightNoiseVertHeightCurve2 { deformity = 15000 ridgedAddSeed = 1212 ridgedAddFrequency = 18 ridgedAddLacunarity = 2 ridgedAddOctaves = 4 ridgedSubSeed = 23234424 ridgedSubFrequency = 12 ridgedSubLacunarity = 2 ridgedSubOctaves = 4 simplexHeightStart = 0 simplexHeightEnd = 2500 simplexSeed = 654786 simplexOctaves = 4 simplexPersistence = 0.800000011920929 simplexFrequency = 14 modEnabled = True order = 13 The walls of the canyon look to average a little more than 10km, though I'm motoring out there right now just to be sure. An interesting effect that I edited back out, but might fit very well with deep surface features like canyons, is that if you set the heightmap offset too far in the negative, a lower, sheer walled second canyon opens up like a crack in the crust. It might be used for more interesting features. Will post pics in a min.

bump for a hopeful answer

The easy way to tell is just place yourself at the bottom of the valley and then record the altitude difference it takes to get back out. I know for a fact that scaling up by a factor of ten made the mountain in the images I linked peak over 25km. EDIT: I just spent a lot of time playing with those valleys on Duna and unless I'm mistaken about the ones you're referring to (I've yet to make it there during a game), I can say with some certainty that if you set deformity for the heightmap to 80km then the mountains on on the sides are pretty close to that number. I've also found some interesting tricks using the real time editor and hovering over a valley. I'll get some pics together and post in the next day or so when I have time. At least with Duna, I've been able to sharpen the valley walls to a decent degree and add plateauing tops to the cliffs above the valley walls, turning them from gentle valleys into something that looks more like proper (if wide) canyons.

My suggestion would be to try is without Texture Replacer at all to see if that does the trick. So far, my experience is that this doesn't love anything that alters textures at all.

I highly recommend trying the WIP Load on Demand Mod... My GameData folder is almost 5GB and I almost never get OOM crashes.

This is exactly what I did to get features back on the Mun which was great visually, but as NathanKell pointed out, means that the highest point on Duna I this case would now be 80km which is quite tall. I'm thinking that the best the we're going to be able to get out of this is better definition near canyon walls and/or around the biggest mountain ranges and even that is going to be a compromise rather than a proper solution. That being said, I'm starting to think about the possibility of negative elevations for some features like craters or canyons. If done properly, it may allow for smaller vertical deformity while also allowing deeper, more defined features.

I know that you just can't have the same landscape as you do in stock, but there was has to be a decent compromise. Think about large craters around the world, they may not look like we'll defined impact craters like the found in Arizona, but you can often see the rim in the form of a circular mountain range. I'm also thinking about the way depression features like the twin craters on the moon are displayed. In their current form, they do appear depressed, but only slightly, completely removing the impression that they were impact events at all. My thinking is the solution to this is much like you described, where certain situations are interpreted as sheer walls where others are seen as gentle slopes. I would approach this by working with the rigid altitude curve though, as I have a feeling it can be tweaked to constrain certain regions of the terrain into steeper walls rather than gentle slopes.

@Ralathon: How does this method handle large scale terrain features (canyons, mountains, etc.)? Up to this point my experiments with PQS editing have never resulted in acceptable definition in large features, instead just giving a little hint of their existence with color and minor variation on elevation. I'm really looking for a method that will output canyons and hills where they exist without having to exaggerate their vertical dimension to obscene proportions.

I'm assuming this process will work for the rest of the CB's as well?

What he said

It just occurred to me that I'd really like to try tweaking simplex frequency and persistence as both of those seem to have a significant effect on PQSMod_VertexSimplexHeightAbsolute. Unfortunately, neither of these are yet defined within the dll to be edited.

I have been noticing occasional memory leaks since moving to 0.23.5. In one instance, the leak expanded to fill all 16GB of memory on my system even though the KSP process only reported 3.1GB. Restarting the game released all of the extra memory, but I'd not seen something like that in years.

That looks like the result I got when I multiplied all of the values for the Mun by 10 originally. I think it's the result of too high a number in either the noise frequency of simplex height persistence.

Can you share that planet editor? Doing this work in real time sounds so much nicer than restarting the program over and over, even if I do have the test install as bare bones as possible and on a SSD...

After spending some time looking over the PQS mod xml's and the revisiting the libnoise documentation, I'm thinking that the issue may reside in PQSMod_VertexHeightNoiseVertHeightCurve2. I'm trying would seem that that the deformity needs to be further exaggerated to increase the variation in vertex height imparted by the noise function. I'll have to do some testing on it when I get home (I'm currently out of town), but if someone else has time, maybe they can fiddle with it a little and post results? I'm also looking forward to getting that generic loader in place as there are quite a few mods that you haven't exposed which might have interesting effects.

I appreciate that you're open to expanding the mod in the future. I also appreciate all the great work you've already done to this point. This mod for me at least is right up there with KSPI, FAR, and the other essential mods to enhance the KSP experience. I would definitely like to see those development videos, and I would like to reiterate that I'd be perfectly happy doing the work necessary for making this work with the Kerbol system. As long as I have a decent set of instructions to work with, I can completely take that burden off of you.

I do understand your original intention to follow the RO / RSS, though the reason I was surprised is because MS18C is much more generic than this first view of MS19. In its current form, RPL could easily be used for either RSS or stock, at least with a minimum of modification. That all being said, it would seem that maintaining a separate version for stock system would consist primarily of substituting the stock planet names for the real names and adding science for Minmus. If this is the case, I'd be happy to do it for myself as long as you provide the information about how to do it. As far as the science parts are concerned, it would seem that they don't offer nearly the same quantity of science points that the new experienents do, so their presence earlier in the tech tree seems to me at least like they wouldn't be that unbalancing, especially since you very quickly get into higher cost science nodes in the tech tree. You may not agree, but I'm thinking that if you were to place them lower in the tree, it would give players a little flexibility to get an extra node here or there if they included all those parts on their probes / ships, while not giving them enough science to really advance much more quickly through the tree.

Looks like there are a lot more PQS mods than the few used in the RSS config. That being said, you mention that you need to call the object (I'm guessing you mean individual CB's in this case) to find out which PQS mods it actually contains. What is the process for finding this out so that I can play with the mods for each planet? Also, is this something that will apply after implementing the generic PQS? You mentioned that the generic mod would require you to define the parts of the PQS, is this something that would have to go into the config or is that more of a dll thing?