ZRM

Is there such a page? That would be very handy.

I've got custom cg shaders covered, if you want my shader and material management plugin. I was planning to release it with the Kerbin Mini Shuttle, but it can come out early. I've also got ideas relating to the details of how to implementing paging for this, but I don't have the time to implement them myself. Some of the things you need to implement for this to work, including manipulating the second PQS UV channel, would also solve the texture precision problem mentioned previously and thus allow higher texel density for detail mapping.

It will be, once I get the time, which I don't have that much of for KSP right now. This may change in a month's time.

Nice, but IMO the coastline needs to be cleaned up just a bit. The hills and mountains look okay. What's the altitude range like now? Also, in the Kerbin data I forgot to include the mod for the flattened area around the KSC. It looks a bit out of place now that it's not on the coast. I'll send its details and then you could modify it a bit, perhaps making it tighter around the KSC. It's a PQSMod_MapDecalTangent if you hadn't figured that out yet. We'll also have to deal with the Scaled Space model at some point. I'll explain how to regenerate it later.

And the title?

Hang on, so have you just got the numbers mixed up and this is the changelog for a new version coming out soon, or did you think that you had released v4 at some point and not actually done so, and this is the changelog for that version, not the one you're about to release?

What's new then in v5? And what happened to v4? The thread still says v3. I haven't downloaded any of these recent versions due to lack of spare time, so what is the total feature set right now? I think it would have been nicer, and more subtle, if the "chain of command" was lower case and not bold. Then this could have been continued for quite a while.

I've still got to figure out what's making it non-functional at your end. 6th December is exactly a month away. I want to get this done and released as soon as I can.

I don't have much time to work on it right now as I'm at university. No WIP thread yet, but there probably will be one in a little under a month when I have the time to resume work on this. The binary files are for the scaled space meshes - the simplified meshes that you see from high orbit. The actual body instances with their terrain generation configurations (used for higher detail near the surface) and other features are cloned directly from existing planets/moons. They then have their properties altered to come up with new terrain and new texturing for the new bodies. There are particular limitations in this approach. Anyway, this is Mr Shifty and Kragrathea's thread, so I don't want to get into the details and derail the thread, but as an example, Sentar is a modified version of Jool.

No. I am not using this mod, and I'm not associated with Kragrathea. It's my own mod I have been working on when I've had the time on and off since 0.21.

It's possible, but not with this mod as it currently is. I've been working on a mod that should allow anyone to make their own custom planets and moons completely from scratch (which is clearly not the case here - all of Krag's new planets and moons are modified versions of existing bodies in the Kerbol system), but it's not so far along in development.

No is the probable answer to that. Just the analogues are in place (e.g. Jool -> Jupiter etc.). I'm the one working on actually making new planets and I haven't had much time to continue my development of my technique yet.

Great! Any luck with the terrain? Has the stock Kerbin PQSMod configuration data I sent you helped? Are there any particular things that I've missed out that you want? Also, is 10m x timewarp too much? A year in just over 3 seconds is very fast, and it's not like anyone is going to be flying Voyager beyond the solar system, right? Maybe 5m x at the most? How about a configurable list of time warp values? Regarding tangents, could you not use Unity to make the curve in the animation editor, then write a script to dump all of the values to a file? You would need to do something similar for pressure curves as well. And last but not least, have you tried any of the hacks for axial tilt? Sorry to bombard you with queries.

I'm not sure that this is entirely the right sub-forum. A mod may want to move it. In short, you need to look up orbital mechanics. Watch a few videos, read a few articles, and you should eventually get the hang of it. I can explain the gist of it and how it fits into KSP below, with lots of links you can look up on Wikipedia (though I recommend searching for beginners' tutorials for these subjects as well). There's no real way to avoid the physics, as it is physics, though hopefully the perceived complexity can be reduced. Ignoring general relativity, the motion of bodies in space, such as planets, moons, stars, spacecraft etc. can be described by Newton's law of gravitation. This is where the force between any two point masses (or spherical bodies, which is a good enough approximation in most cases for real objects) of mass m and M is F = (G x M x m)/(r^2) where F is the force you apply to both bodies in the direction of the other body, G is the gravitational constant, m is the mass of one body, M is the mass of the other, and r is the distance between their centres of mass. Here is another visualisation from Wikipedia with different names for the variables (note that F = F1 = F2): To calculate the motion of a spacecraft, you therefore have to integrate this force over time between the spacecraft and every other body in the universe. In general this is impossible to solve analytically, even if the universe only contained 3 objects. KSP simplifies this a lot by only considering one body other than the spacecraft - this is known as the 2 body problem. In this setting the evolution of the motion of the spacecraft over time due to Newton's law can be solved exactly. You can simplify this further because since the planet/moon etc. is normally much more massive than the spacecraft, the tiny forces involved will not affect it much, so you only need to consider the forces on the spacecraft. The result is that it will always follow what is known as a conic trajectory, relative to the body, with the body at one of the foci. This trajectory, known as an orbit, forms the shape of either a circle, an ellipse, a parabola or a hyperbola, as pictured below: The body is at the point F, and the spacecraft follows one of the coloured lines. A circular orbit is shown in grey, an elliptical one in red, a parabolic one in green and a hyperbolic one in blue. KSP takes advantage of this exact solution by using it instead of calculating the forces on the spacecraft, which allows you to predict the motion of the spacecraft into the far future with little to no extra computation. This is why KSP's calculations are so robust. The downside, of course, is that the result is only absolutely correct for a system with only one major body. It can approximate more heavily populated systems (like in KSP) by limiting the active range of the gravitational pull of bodies depending on the strength of their gravity compared to their surroundings. This active range forms a region known as the Sphere of Influence (SoI). This provides a means for determining which single body to choose as the other body in the 2-body problem with the spacecraft, as you have no doubt experienced when crossing into the Mun's SoI, for example. What is (approximately) happening is the game is always checking which body has the most effect on the motion of the spacecraft, and it switches to whichever that is as necessary.

I think Nathan's dealt with that. Don't think it's released yet though.