[1.2] Real Solar System v12.0 Dec 8

[ferram4]

The Mun visibility issue Visari was talking about is caused by the game shifting from the scaled space model of the Mun (which looks very rocky and uneven) to the PQS terrain Mun (which has been changed to be a lot flatter). Basically, rocky Mun fades away and is replaced by perfectly spherical gray blob. Solutions I can think of are either trying to rebuild the scaled space model from PQS (if that is even what's done) or scale up the Mun PQS height values so that the hills have the same scale with respect to the radius.

Re: wobble plugin: I have a simple version working, similar to the old KIS Connect that essentially makes all the parts flex as if they were automatically connected with struts, but I'm not satisfied with this. It looks like the main source of the problem is the physics dT value and the number of solver iterations used; decreasing dT and increasing the iterations should fix the issue, but that will make lagging worse. I'll continue working on it and see what can be done.

[NathanKell]

@ferram: ah, right--I grab the maxradius and minradius offsets from original planet radius and use them to calculate new min and max radius based off the new radius, rather than getting them as multipliers. That's so Kerbin's mountains remain the same height ASL (although probably it should get a factor of about 1.3x, going from Kerbin's highest point to Mt. Everest). I just automatically did the same for the Mun. I can switch to scaling for now to fix it.

Best wishes on that plugin! You mean decrease dT below the minimum offered in settings, I presume?

[NathanKell]

Oh, ferram, one other thing, regarding the jump from Q of 30 to Q of 0 when leaving the atmosphere. I tried with atmo height of 135km, but after extensive testing, it looks like CelestialBody.maxAtmosphereAltitude is just for show; static pressure seems determined only by scale height (and SL pressure), and the clamping is when the exponential calculation drops below approx 0.000001, not when altitude above sea level is > maxAtmosphereAltitude. The only way to fix it would be to increase pressure at sea level above 1 atmosphere and then decrease CelestialBody.atmosphereMultiplier, but that would throw off the exponential curve since it looks like pressure ASL is multiplied in _before_ the exponent is applied rather than after (i.e. it's (p*e)^(-alt/scale) ).

Or we could switch to the new atmosphere method? That operates off a floatcurve with arbitrary altitude and pressure values and tangent support.

[asmi]

Re: wobble plugin: I have a simple version working, similar to the old KIS Connect that essentially makes all the parts flex as if they were automatically connected with struts, but I'm not satisfied with this. It looks like the main source of the problem is the physics dT value and the number of solver iterations used; decreasing dT and increasing the iterations should fix the issue, but that will make lagging worse. I'll continue working on it and see what can be done.

What would really help is turning all rigidbodies into cinematic mode, and running separate physics simulation using Bullet with double-precision - it seems to be way more stable when it comes to fixed joints. Another solution would be to replace default joint with a bunch of one-degree-of-freedom joints (essentially springs) positioned around contact plane.

[ferram4]

@NathanKell: Try out the floatcurve method and see how it works; ideally, this means that the density can actually head towards zero at the limit rather than having that awkward step in density. I think that maxAtmosphereAltitude is just a float that's used to determine when to start looking to apply the stock drag model.

@asmi: Unfortunately, I'm not well-versed in simulating rigid bodies connected with springs; I'm an aero guy really. The problem is that "fixing" a particular degree of freedom doesn't seem to do much, since the physics simulation has trouble keeping them constrained to be right next to each-other. Keep in mind that struts already try to do that, and they don't stop all flexing.

I've just started looking at Bullet, I don't know if I'd be able to properly insert it into the game though. I don't know how heavily built-in PhysX is, especially with respect to the orbital maths.

[Camacha]

Now, regarding RemoteTech. Before I said it was incompatible. Well, I finally looked through the code and found Kerbin's radius was hardcoded. So I fixed that. I now offer a build of good ol' RemoteTech 1 optimized for this mod, to hold us over until Cilph releases RT2.

Here's a copy of my fork. It has my previous changes as described in the RT thread: the new antenna range calculation, the new GUI info, the ability to use multiple antennae (though each additional antenna beyond the first contributes only 1/4 its range), and support for a Range Multiplier so you can play with this mod.

If you want stock RT, set those two new things to off in the Settings.cfg file, and set Range Mult to 1.0

(In RemoteTech/Plugins/PluginData/RemoteTech/Settings.cfg)

Extract your archive to KSP/GameData/

https://www.dropbox.com/s/16928ut2x37kih8/MyRemoteTech.zip

Is this still incompatible with kOS?

[asmi]

@asmi: Unfortunately, I'm not well-versed in simulating rigid bodies connected with springs; I'm an aero guy really. The problem is that "fixing" a particular degree of freedom doesn't seem to do much, since the physics simulation has trouble keeping them constrained to be right next to each-other. Keep in mind that struts already try to do that, and they don't stop all flexing.

Existing strut uses Unity's ConfigurableJoint with all degrees locked, I'd instead go with limited degrees as latter allows specifying movement limits, damping and so forth. Check this out: http://docs.unity3d.com/Documentation/ScriptReference/ConfigurableJoint.html part which says "<something>Drive". In order for that to work, the joint needs to have corresponding degree of freedom Limited, not locked. ConfigurableJoin is a textbox 6-way joint with 3 rotational degrees of freedom, and 3 linear.

I've just started looking at Bullet, I don't know if I'd be able to properly insert it into the game though. I don't know how heavily built-in PhysX is, especially with respect to the orbital maths.

Orbital mechanics is completely custom component that is independent of PhysX except for passing position and velocity fixes from and to active vessel. This all is explaned in abovementioned video from Unite. Any serious modder IMHO should watch it as it gives insight into how game actually works under the hood.

Edited October 26, 2013 by asmi

[ferram4]

I haven't been able to find the happy medium for ConfigurableJoint settings, at least with "Limited." Either the rocket can't support its own weight or the forces are too great for the timestep and the rocket tears itself apart. Funny, but not very playable. Very frustrating, since I haven't been able to find a video tutorial explaining how all the parameters interact exactly.

The orbital mechanics shouldn't be a problem then. But I just thought of something that might completely prevent implementing Bullet Physics (at least as a mod): engines and wings apply forces to their rigidbodies to achieve their function. I don't think there's a way to read off the total force applied to a rigid body, so engines won't do anything if the engine part rigidbodies are made kinematic. The only way to make it work is to do serious complicated hijacking of the forces before they are applied to the objects, so I think Bullet Physics should wait until other Unity options have been exhausted.

[asmi]

OK guys, good news - I know how to bring ground under KSC back (and that fixes "hard to click-buildings-issue"):

NathanKell

Insert the following code before you cycle through PQS objects and calling RebuildSphere():

                    var mapDecals = FindObjectsOfType(typeof(PQSMod_MapDecalTangent)).OfType<PQSMod_MapDecalTangent>();
                    foreach (var mapDecal in mapDecals)
                    {
                        mapDecal.position *= KerbinToEarthCoefficientF;
                        mapDecal.radius *= KerbinToEarthCoefficientD;
                    }

Coefficients are defines, as you'd expect, like this:

        private const float KerbinToEarthCoefficientF = 6371000.0f / 600000.0f;
        private const double KerbinToEarthCoefficientD = 6371000.0 / 600000.0;

But because scaling things up also scales distances, KSC is now way off-shore. Maybe we should consider moving it closer to the shore.

Edited October 26, 2013 by asmi

[asmi]

The orbital mechanics shouldn't be a problem then. But I just thought of something that might completely prevent implementing Bullet Physics (at least as a mod): engines and wings apply forces to their rigidbodies to achieve their function. I don't think there's a way to read off the total force applied to a rigid body, so engines won't do anything if the engine part rigidbodies are made kinematic. The only way to make it work is to do serious complicated hijacking of the forces before they are applied to the objects, so I think Bullet Physics should wait until other Unity options have been exhausted.

We can mod ModuleEngines and put our own module instead of default one - that shouldn't be that big of a deal. Infact I already have plans to implement engine groups mod that would allow independent throttling for engines, and replacing default module with my own is the way I was thinking to do it.

[ferram4]

Awesome! Only thing I'd say is to add a check to the code to make sure that there aren't any "MapDecalTangents" that aren't on Kerbin, since that could cause problems down the road.

I guess there's no compelling reason to stick with PhysX other than the fun of trying to implement Bullet Physics. Really, what I want to see is differences in how the two handle objects of different masses that are constrained to each other, since that is the big problem in joint wobble currently.

Edited October 26, 2013 by ferram4

[Sax Man Aeronautics]

-snip-

Will you release the new update, and are you going to do the other planets or Kerbol later on?

[asmi]

As for terrain smoothness issue - that's totally expected given the scaling. However since the terrain is procedurally-generated, there should be a way to increase heightmap resolution so the generator would produce higher-frequency details. I'm gonna look into that tomorrow as it's too late over here...

[Visari]

I've rounded up a few screenshots showcasing the Mün surface bug: http://imgur.com/a/DJMFB

additionally, could this be the same bug on kerbin? (note the horizon) http://i.imgur.com/PqidHez.jpg

[asmi]

Awesome! Only thing I'd say is to add a check to the code to make sure that there aren't any "MapDecalTangents" that aren't on Kerbin, since that could cause problems down the road.

There are three - KSC, KSC2 and IslandAirport. I figured I'd kill three birds with one stone, but yes, for the sake of avoiding surprises down the road, let's do only KSC for now.

[asmi]

Speaking of which, here is how I sniffed all of that (maybe it'll be useful to you guys):

        private static string FormatComponentName(Component component)
        {
            var str = component.GetType().Name;
            if (component is PQ)
            {
                //special case for PQs as they represent terrain patches
                var pq = (PQ) component;
                str += string.Format("({0}/{1})", pq.subdivision, pq.sphereRoot.maxLevel);
            }
            return str;
        }

        private static void DisplayObjectProperties(GameObject currObj, StringBuilder sb)
        {
            var comps = currObj.GetComponents<Component>();
            var compList = string.Empty;
            compList = string.Join(", ", comps.Select(FormatComponentName).ToArray());
            var parents = string.Empty;
            var curr = currObj.transform.parent;
            while (curr != null && curr.gameObject != null)
            {
                parents += string.Format(" <- {0}({1})", curr.gameObject.name, curr.gameObject.tag);
                curr = curr.gameObject.transform.parent;
            }
            sb.AppendFormat("{0}, tag {1}, name {2}, {3}, {4}, {5}, {6}\r\n", currObj.name, currObj.tag, currObj.transform.name, parents, compList,
                            currObj.transform.position, currObj.transform.localPosition);
        }
//and then whereever you need add this code:

                foreach (GameObject go in FindObjectsOfType(typeof(GameObject)))
                {
                    var sb = new StringBuilder();
                    print(string.Format("GameObject name = {0}", go.name));
                    DisplayObjectProperties(go, sb);
                    print(sb.ToString());
                }

I guess there's no compelling reason to stick with PhysX other than the fun of trying to implement Bullet Physics. Really, what I want to see is differences in how the two handle objects of different masses that are constrained to each other, since that is the big problem in joint wobble currently.

That is a big problem for any physical engine, but Bullet tend to do better due to increased precision and so reduced rounding errors.

P.S. Do all of that really belongs to release thread? This is clearly DEV content...

Will you release the new update, and are you going to do the other planets or Kerbol later on?

I'm gonna leave it up to NathanKell to release it since he is playing the prime violin over here...

Oh guys - I just thought of something - since now we know how to move KSC just about anywhere, why don't we implement such an option? I'd love to move it to real KSC's and/or Baikonur's latitudes as it represents a major challenge on it's own.

Edited October 26, 2013 by asmi

[mushroomman]

Yeah, I was just going to suggest that you could move the KSC, If you're going full-realism-orbithadababy-NASA stuff then yeah, I would say you should you move the KSC to somewhere other than the equator.

[pina_coladas]

All I ask is that you leave the option of having KSC at the equator. Extra plane change fiddling is one extra detail that people might not feel like dealing with when adjusting to the new mechanics. Having the choice between equator, real KSC and Baikonur latitudes would be great. Maybe there could be a configuration where the Mun has 0 inclination too, for old time's sake...

[NathanKell]

asmi, super! I was looking at PQSCity, but that's for the buildings, not the terrain.

I'll edit and compile and release.

Also, I too support the option for moving KSC to 28d or 46d lattitude (although in the latter case, you'd have to launch to 51.6 )

[FanaticalFighter]

OK, this is my first post, so if I miss some Kerbal custom, cut me some slack

This mod is amazing. First time in ages that getting even a small probe to orbit is hard

[NathanKell]

Ok, I have updated to v2. Included asmi's fix; disabled Mun scaledspace rescaling (see if that fixes the Mun?); only change each planet once (I think the changes stick); fixed Minmus.

Yeah, that should do it.

Edited October 26, 2013 by NathanKell

[Reddragon]

We have a problem here.

On the first picture I orbited the Mun at an altitude of 82000m. On the second one I was orbiting at 32000. I don't know yet if it is only hyperedit or not.

Edited October 26, 2013 by Reddragon

[MedievalNerd]

We have a problem here.

On the first 2 picture I orbited the Mun at an altitude of 82000m. On the last one I was orbiting at 32000. I don't know yet if it is only hyperedit or not.

Doh, trippy but unwanted definitely.

Did you try with a rocket with infinite fuel? Maybe if you get there 'manually' you won't have that funky stuff going on.

[Reddragon]

Doh, trippy but unwanted definitely.

Did you try with a rocket with infinite fuel? Maybe if you get there 'manually' you won't have that funky stuff going on.

I didn't think about that scince I never use IF but that's a good idea. I make a try for it. The best in this mod is that even going to the Mun is challenging now. Changing the Mun's orbital declination requires a better planning than before and speaking about that:

I guess this is something what is called old but gold.

Btw. the bug seems to be visual. The rescaled surface only appears once I'm very close to it.

This happened:

My perigee disappeared after retrograde burn

It seemed that I'm still pretty far from the Mun and suddenly

But the collision worked well.

Edited October 26, 2013 by Reddragon

[Zander]

@NathanKell: I see you are making minimus into a captured comet with a weird inclination. And thats a great idea. But as I said earlier can you please put it farther out than the moon. I really think the earth single moon relationship has played a huge part in human space history and it should be maintained with no other bodies in a position to interfere with it. Right now people can get gravity boosts or even use minimus as a half way point to getting to the moon but this is unrealistic. I know its your mod so you get to make the final call but I highly recommend moving it out past the moon.

2nd: After reading this I have become a little disappointed in you guys. I find it sad that the first thing people start demanding is faster time warp to go with the larger solar system. A real life mission control staff member has to wait 6 months for the rover to reach mars.. And we cant even wait 5 minutes more??? Common people that's part of the fun. The risk that if you build something wrong and it smashes into duna then you have to wait all over again. That creates tension and anticipation. Those things are what make this game fun. Go make a cup of coffee, sit back relax and just wait the 5 minutes.. you will enjoy the result far more than if you instantly time warp yourself over there and have no incentive to put care into and double check your rocket designs and do testing like real space programs do. We don't need to add more time warp.

Edited October 26, 2013 by Zander