giucam

Is it me or the attitude control in 0.6 is much worse than 0.5? I can't keep my simple rocket going up straight, while in 0.5 it worked perfectly.

Ops, somehow i missed that post, sorry. /me hides

Having read on the Pioneer plaques yesterday, those six dots could actually be (rotated horizontally) the string ||--||, which is the binary number 110011, which is 51 in decimal. That's probably the distance between the pyramid and the body, we now need the unit of measure.

It seems i managed to fix the bug (or maybe workaround it, i don\'t know yet). Vector3d rad = QuaternionD.AngleAxis (isa_RAM_Longitude, Vector3d.down) * QuaternionD.AngleAxis (isa_RAM_Latitude, Vector3d.forward) * Vector3d.right; isa_RAM_Elevation = Math.Round(vessel.mainBody.pqsController.GetSurfaceHeight(rad) - vessel.mainBody.pqsController.radius, 1); I\'m now testing it yet but from the first few orbits it seems to work right.

You\'re right, it screws up. Anyway, maybe i\'m too used of working in open source projects, but i think the best way to deal with these problems is to make them public, so that many people can look at it, rather than keeping them private.

Today I found the time to have a look at it and it seems i managed to make it not rely on the mesh intersection. Vector3d rad = isa_Position - vessel.mainBody.position; isa_RAM_Elevation = Math.Round(vessel.mainBody.pqsController.GetSurfaceHeight(rad) - vessel.mainBody.Radius, 1); Replacing the existing 'isa_RAM_Elevation = ...' with those two lines makes it read the height from the height map. I\'m orbiting Kerbin from a 100km high orbit and it seems to spit out reliable data. The only issue is that the mapgen tool doesn\'t work for height < 0, that is when the craft is above an ocean. @Innsewerants Can we have the source of mapgen too?

I didn\'t talk about orbits, i don\'t know. I was just saying that time warping isn\'t a problem. I\'ll think about it anyway.

@RC1062 Actually the engine internally is 3D, i just live on the z=0 plane. @millitron I don\'t know really well how the engine i\'m using works internally, but afaik it handles big distances pretty well. I\'ve being simulated the Earth with the Moon around the Sun in a 1:1 scale and warping up to 20x and an year keeps taking 365 days. EDIT: i forgot, 1 sec is 1 day in my simulation.

I don\'t see why time warping would be a problem with an N-body system. I mean, i\'ve been doing a little 2D simulator (before finding out kerbal ) with N-body physics and i can warp without problems. (the actual physics engine isn\'t mine, http://www.ifa.hawaii.edu/faculty/barnes/treecode/treeguide.html). If the elapsed time since the last frame is, say, 50ms, at 1x i advance the engine for those 50ms. If i want a speed of 2x i advance it for 100ms, 10x 500ms. Obviously computing more time requires more cpu time, so if i warp to 1000x the actual speed will be maybe 900x, but i don\'t think that\'s a problem. What matters is that the accuracy of the physics doesn\'t change with the warp speed, because the engine internally advances with steps of few ms. EDIT: now that i think about it i was wrong: the engine warp speed is not affected by the cpu time it takes, even if it is 100000000x. If the cpu is not fast enough it will just have fewer fps.