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.

Oh, it's not stopping any releases. There are other things Nathan is working on.

Yes. Unfortunately it looks right now like the only options for getting axial tilt to behave correctly are all different degrees of what you might call hacks. There is a possibility that the underlying issue will be fixed for 0.23, after recent contact with the devs, as it is a relatively minor internal problem, but we can't work around it from the outside. Axial tilt is quite sizeable on nearly every major body in the solar system, so it is crucial for a half-way decent implementation.

He's working on that.

I think NathanKell said his next update is going to include automatic solar panel compensation, so if you do edit powerCurve settings, make sure to keep a backup.

Saturn is actually one of the planets I'd like to try to make first once I have the time to fully try out my approach to making planets (December at the earliest), mainly because it doesn't have a terrain, and that once I get terrain working I can put that to use on its moons. Plus it would be fun to implement rings. I'm going to try full scale first and deal with any problems that come out of that. The answer to your question: I think the possibility is there, but as with all things in this game there may be unexpected problems along the way. For example we have recently discovered that there's a large hurdle in the way of implementing axial tilt, which may be insurmountable without hacking the game.

Ok. 0.3.0.6 is the latest. I will look into this bug and other problems when I get the time. Thanks for the heads up.

10M x timewarp, nice. Wasn't there a mod for that around at some point, I vaguely recall?

Nope. You could re-enter at interplanetary velocities and the only thing that will stop you is the ground, unless you have DRE (which will burn you) or FAR (which will probably break you up).

It could be that it's because the pressure model is wrong right now. Default Kerbin (and currently rescaled Kerbin) use a simple exponential pressure scale, known as the legacy pressure implementation. Planets can switch to using the newer system that allows you to specify pressure as a function of altitude using a curve. Nathan said he's going to try and make a curve to fit the standard atmosphere model and use that instead.

A custom PQSMod should handle paging nicely for close range detail, and for long range either you can change the scaled space proximity settings to use PQS from further away or make the scaled space model have a higher effective resolution by splitting it into chunks and using a different texture per chunk. You could integrate that with a simple LOD scheme on the scaled space object. By the way, you may be surprised to learn that several of the bodies in the Kerbol system (especially some of the moons) do in fact have their surfaces defined by a combination of low-res height maps and procedural methods like Perlin noise, simplex noise and multifractals. This also applies to the surface colouration. Some only use heightmaps for specific features like a few mountains. So if you increase their maximum tesselation resolutions you should get better detail on most terrain for free. The reason Kearth looks so bad from orbit right now is because you haven't changed the ranges at which scaled space fades in (via the ScaledSpaceFader component and the appropriate settings in PQS), so the simple textured model is used when really the PQS terrain should be used. The problem with KSP really is how old all of its tech is, especially Unity, which if it weren't for some things looks like it came straight from 2004. On a relevant note I'm actually implementing a voxel-based scene representation for my final project for my degree right now. With a bit of work it should extend nicely to planetary scales, though that's outside the scope of the current project. For the Kerbin Mini Shuttle I wrote a plugin that lets you load custom shaders and redefine materials for parts and internals. The shaders are all written in Cg, but the build of Unity used by KSP uses an oldish Cg version, and it only renders under DX9 on Windows and OpenGL 3.x on other platforms, so don't expect anything like tesselation or compute shaders any time soon. The plugin also works as a manager for shader resources. I will release it once the whole KMS project is ready. BTW I also started work on a mod designed to allow parts to attach via multiple points to different objects based on proximity to their attachment nodes, so that you can make things in the VAB like 3 point connections on the Space Shuttle, or space stations with loops. This may be something Ferram would be interested in implementing. I'd just like to say that if you have any problems getting Kerbin to switch to the newer atmosphere system it's not that big of a deal because I should be able to get the Earth to use the new system when I manage to create planets from scratch (eventually). Those are his current plans, as well as implementing my idea for axial tilt. He's currently working on getting the changes he makes to be defined via config files.