SpacedInvader

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?

So now I'm suddenly wondering how you were able to get such definition when NathanKell just said you wouldn't be able to do better than 22° from one cell to the next. Is that a "detail" heightmap rather than a planet wide heightmap?

I'd already seen that video, I was thinking there was another where he went into much greater detail. Is there any real documentation for the various PQS components describing what each does exactly and how to use them? Also, you talk about them as if you have access to them for modification, can you tell me where they reside and how I can get access to them?

Is this with RSS installed, or is that on a stock sized planet?

Any chance you can link that video? I've been wanting some kind of guide and/or proper documentation for PQS ever since this whole process began and just haven't been able to find anything of the sort. As for the first option, I'm suddenly reminded of some projects I did when I used to play Trainz. Because that game used UTM for its coordinate system, you could only get so much east-west distance before the distortion would become too great. The solution was to break up the coverage into multiple smaller maps which would be played in sequence going from one side of the route to the other. With that in mind, I'm wondering if it's possible to opt for different size and resolution combinations so that I could find one that would allow for full planetary coverage at a reasonable resolution with multiple heightmaps without placing too much of a burden on the system. EDIT: I also want to mention that I don't think the heightmap is mismade, but rather that manipulating the heightmap might allow a jury rigged way around it the limitations of the system.

I have noticed memory use spikes at each page turn within the VAB, almost as if LOD is allowing the game to load all of the textures for items on that page before purging them down to the placeholder textures. I'm also curious if there has been any more confirmations that the new version of ATM coexists well with LOD? I may have been a little too quick to report that 400mb savings in my earlier post because it didn't even occur to me that this was in a new save without any debris or ongoing flights, which is probably the source of much of that extra memory. There is still an improvement in the amount of memory used and in the way it handles it. I would also like to point out that even small savings can add up quite quickly. If a planet texture takes up 40mb, but then you're able to get rid of 10 of them until they are actually seen, you're saving 400mb. Also, wouldn't intercepting planet textures work in the same way as part textures?

How would you recommend getting around this problem then? I spent the better part of two hours attempting to apply PQS settings to Minmus and couldn't get the terrain to be anything better than slightly not flat. I understand that we're just not going to get the same kind of terrain that exists in stock thanks to the stretching (of which I was already aware), but I certainty want something better than slightly not flat. My thinking is that a one way around this would be to apply a transformation to the height map histogram to enhance the difference and rate of change between levels. In theory this would increase the slopes enough to break up the terrain some.

Bump for a little help since no one replied

@NathanKell: So it just occurred to me that it's unlikely that you're going to develop height maps for the stock planets to be used in the scaled system. Seeing as how I would like to keep the stock system (probably with planet factory planets as well), it looks like I should start thinking about making some of my own. The question is, how should I go about doing this? What tools will I need and where can I get the stock planet height information to work with?

I was actually using the rescaled Kerbol system rather than the Sol system. I may eventually move to the proper Solar system version of the mod, but for the time being Iike the alien quality of the Kerbol system. That being said, when I left off with RSS, I was about ready for to launch a Duna / Mars lander, so I had already reached the limits of the RSS terrain. My understanding from talking with NathanKell is that we're going to need to wait until he gets Krag's general PQS loader up and running and then give each planet a height map before many of the planets will get decent terrain.

@MedievalNerd: It really looks like it's developed a lot since MS18. I've noticed however, that you've moved the stock science parts pretty far up until the tech tree. While I'm guessing that this means you've really fleshed out your science experiments, I am concerned that this will force anyone using this mod into a single scientific path rather than allowing for departures based on personal preference. I would suggest keeping science parts lower in the tech tree so that they could be used in conjunction with your experiment mechanic. I've also noticed that you are tightly intertwining RPL with RSS by highlighting specific planetary probes in the tech tree. While I can't be sure of your intentions, this does have me concerned that you will also carry this theme over to the experiment progression, completely removing that option for those of us who, for one reason or another, don't use the full blown RSS (even when it's up and running with terrain on all of the planets, I will be using a rescaled Kerbol rather than Sol). If this is where you want to take this mod, that is your choice, but I would request that you either provide instructions to write / modify the experiments so they work with stock planet names or provide a second version designed to work without the Sol system and it's planet names.

I have been using everything except for RSS. My understanding is that if you're using the RftS engine definition package, it will cover the Bobcat engines, though I'm not really sure about the RCS pack as I think that is more the realm of Real Fuels and I know there are not definitions for the B9 thrusters, so there is a hit/miss element here. That all being said, I've always believed that RPL and RSS/RO were pretty much designed to go hand in hand, so using all of the associated mods for both would be best practice. The only reason I'm not using RSS is because I am going to hold off until every planet has interesting terrain to land on when you get there. I would also point out that most of the additional supported and required mods crossover, with only a few on each side not being mentioned by the other.

Looking for a little help here. I'm trying to use KESA in my newly updated install of 0.23.5 using 2.0.1. When I was still on 0.23 and running 1.5.7 (I only just found out that wasn't an official update), everything seemed to work just fine, but after the update, now the entire program hangs when trying to load WarpPlugin (the KSP Interstellar Mod which KESA affects) and the only way to get the game to load is to comment out the following code from KESA: @PART[FNRefinery]:Final { @MODULE[FNModuleResourceExtraction[*]]:HAS[#resourceName[LqdWater]] { @resourceName = Water } @RESOURCE[LqdWater] { @name = Water } } I've tried various permutations of this block, but no matter what I do, as long as the program tries to execute the code, the loading hangs on WarpPlugin. I'm really hoping someone here with a lot more experience working with Module Manager and KSP can chime in and explain where this is going wrong and if/how there is a way to fix it. Thanks.

No crashes as of yet. Crash I experienced with the previous version were almost always resulting from part heavy vehicles rebuilding multiple times (return to VAB mostly) which that version just didn't handle very well. I've kind of trained myself not to do that, but I guess I could go back to old habits for the sake of testing

This is definitely sensible as memory issues are system and install dependent, so eventually it would be nice to be able to tweak this mod to suit our current needs. I would also like to report that this newest version seems to be saving me an additional 400MB.

Forget what was originally here... I was on a wild goose chase... Still wanting to use KESA, but I'm having the same issues as Der_Failer and S4qFBxkFFg and the above edit isn't fixing my issues.

Tried searching for a solution here, but found nothing. Just updated to 0.23.5 with everything I'm running being valid against the mod compatibility list and with all necessary new updates in place. I did all of this with a fresh, updated install of KSP. Anyway, now when I try to run KSP, it freezes on loading the WarpPlugin and refuses to continue loading. What could be going wrong here? EDIT: Game loads just fine with WarpPlugin folder deleted.

Well at least you know people like to use your stuff... Speaking of updates, are you planning up updating RftS to include the new engines so they can be used with RF?

Holding pattern initiated

The point though, is that if you don't look at it, it doesn't necessarily need to be loaded, so maybe if we could have them load on demand like parts, it would save memory until you decide to look at them. In this way, if you're only in visible range of Kerbin, Mun, and Minmus, then you don't have to waste resources sitting on the textures for Eve, Moho, Jool, etc. Just like the parts in the VAB, I'd happily accept a few seconds of fuzzy planetary textures to save a few hundred MB of memory.

Any chance of getting a download mirror? I'm getting a 509 (i.e. your stuff is too popular) error for your dropbox download link.

Yay for more testing! I've got to say though, for being super alpha, this mod has completely changed my game experience... It's nice to be able to have a large amount of mods installed without having to prune them of extra parts and not have to worry about crashing on load. Is it possible to expand this to work on planet textures as well? Many planets don't get loaded at all in the average day of play, and it's been mentioned in the RSS thread that the textures for the planets are quite large in some cases, so this may be an area where some memory savings can be found. It also might significantly decrease the impact of running KSP with the planet factory mod enabled, allowing for even more places to explore and exploit within the limited memory budget of KSP. I would also like to request, if you're willing, for you to start putting up a changelog from version to version so we can see whats being changed with each iteration.