Telemachus

Telemachus

14.7k Downloads

polling n.heading n.pitch n.roll too often screws with camera

TheTacoScott opened this issue ยท 11 comments

commented

I think it has to do with the function: updateHeadingPitchRollField

What it's doing on the back end is REAL screwing with the ship. Sometimes it just jumps the camera around, sometimes it can case issues in staging where parts of your ship blow up.

Do it with curl and a while loop, or just something like the below. Comment out EVERYTHING but pitch/roll/heading and it borks up. Everything else you can poll 100x a second and it handles it fine.

Thoughts? Where does updateHeadingPitchRollField come from? I can't seem to dig around these references and find it.

 function GetData()
      {
        var $apistring = datalink + "?";
        $apistring += "zz=p.paused";
        $apistring += "&a=r.resource[SolidFuel]&b=r.resourceMax[SolidFuel]&c=r.resource[LiquidFuel]&d=r.resourceMax[LiquidFuel]";
        $apistring += "&e=r.resource[MonoPropellant]&f=r.resourceMax[MonoPropellant]&g=r.resource[Oxidizer]&h=r.resourceMax[Oxidizer]";
        $apistring += "&i=r.resource[ElectricCharge]&j=r.resourceMax[ElectricCharge]&k=r.resource[XenonGas]&l=r.resourceMax[XenonGas]";
        $apistring += "&m=v.atmosphericDensity";
        $apistring += "&n=v.missionTime&o=t.universalTime";
        $apistring += "&p=v.rcsValue&q=v.sasValue&r=v.lightValue&s=v.brakeValue&t=v.gearValue";
        $apistring += "&u=v.altitude&v=v.heightFromTerrain&w=v.surfaceSpeed&x=v.verticalSpeed";
        $apistring += "&y=o.ApA&z=o.PeA&aa=o.timeToAp&bb=o.timeToPe&cc=o.eccentricity&dd=o.inclination&ee=v.orbitalVelocity&ff=v.angleToPrograde&gg=v.name&hh=v.body&ii=v.long&jj=v.lat";
        $apistring += "&kk=tar.distance&ll=tar.name";
        $apistring += "&mm=f.throttle";
        //$apistring += "&nn=n.heading";
        //$apistring += "&oo=n.pitch";
        //$apistring += "&pp=n.roll";




        $.get($apistring,function(data) { 
          console.log(data);
          setTimeout(function() { GetData(); } ,10);
        })
        .fail(function()
        {
          console.log("Failed Getting Data");
          setTimeout(function() { GetData(); },2000);
        });
      }

      GetData();
commented

This bug is still present in 1.0.

Is it possible to cache these values inside the plugin, and only update them every 150ms regardless of the polling rate as a quick fix?

commented

I think v.findWorldCenterOfMass(); is going to be rather expensive. It has to do mass calculations on the whole vessel and fuel mass is always changing, etc.

If I replace that with CoM = v.rootPart.transform.position; the camera thing seems to stop happening.

commented

Thanks for doing some digging on this issue! I'll try this suggestion out later.

I think I borrowed v.findWorldCenterOfMass(); from Mechjeb 2.0 a while back, but I guess it is called less than 100 times second there.

commented

I've added new API calls to my local dev build (n.pitchRoot, n.rollRoot etc.) which compute their values using v.rootPart.transform.position rather than v.findWorldCenterOfMass(); this does indeed solve the camera issues. These new calls will be in for the next release, but I want to fix #49 first, as that is as serious issue that's been around for a while.

commented

Honestly, I would rather see the change made to existing apis rather than add yet another set of pitch and roll metrics.

commented

My reasoning for adding new APIs was to avoid breaking anything, but I guess you could argue that the existing APIs are unusable for the likely use cases (polling) anyway. That said I'll swap them out!

commented

These changes have been implemented in version 1.4.30.0.

commented

Ah, I see where it comes from now. Just below the data handlers.

Is "v.findWorldCenterOfMass();" an expensive operation?
Does kerbal re-calculate that all the time to calculate pitch or does it just do it at staging? Or does it pre-compute it are "build time" for all the stages and maintain those values? If so perhaps you could hi-jack those pre-computed values rather than having telemachus re-caluclate it all the time (which I'm assuming is expensive, maybe it's not).

The rest of that function seems pretty standard 3d math foo so I can't imagine that's where the hold up is.

commented

I would need to profile the function components to determine where the hold up is. Also, I doubt that KSP precomputes the values for each stage, because that does not account for arbitrary part removal (such as after a collision).

commented

I wrote essentially a "relay" for Telemachus here: https://github.com/withorwithoutgod/ksplarp

So there is only one thing polling kerbal/telemachus and all 5-6 of my friends just poll the relay.

I'd still be interested to know if this "bug" is fixable.

commented

I do know that some others have been using RabbitMQ as a relay.