Agathorn

They are given in altitude. Damn. I was hoping for a linear value. I was going to mod MCE to add a "body scalar" value that could be applied in realtime. The idea was that each body could have a scalar value applied to it, so you could set each individually. But if a simple scalar won't work then that throws that idea out the window.

What is the scale difference on the modified planets in RSS now? I'm just going to write a script to change the mission configs.

Yeah that is my suspicion after looking over the configs last night. I've posted in his thread. Hopefully we cab get a scale value to set!

It looks like distances in this mod don't scale to what a planet actually is, so it doesn't appear to work properly with RSS. Is there a config that I can add a scale value to, or would I seriously have to manually edit every mission?

Hey man, glad to see this still running! Coming back to KSP and RO after 4 or 5 months away, and picking this back up. I'm also curious about Mission Controller and i'm wondering what is needed to implement it? I saw you mention it as upcoming but not yet implemented. I'm just curious what needs to be done to implement it?

So I see that RO has a MM override to modify Mission Controller (MCE) for prices, but what about distances? For example the new ARM missions that specify an orbit target? With RO/RSS those orbits would be in the atmosphere

Thanks! I'll get started on the process

Hey guys. Been away form KSP and RO for a long time, busy with other things. Want to jump back in and start up with it all again. Is the front post still up to date with setting it all up, or is there anything else I need to be aware of? Last time I messed with this all seems to be about February So it has been a while.

A great example is RemoteTech2: https://github.com/Cilph/RemoteTech2/tree/master/src/RemoteTech2/API Basically just make one class with public methods to access all the information you want to expose. It is then very easy to dynamically hook into it from another AddOn.

@ferram4: Would you be willing to add these functions to FARControlSys to allow kOS to access some fo the FAR flight data? Right now you have pretty much everything locked down behind private declarations so I can't really grab anything externally. I was trying to do as much as I could without having to ask you to change/add code, but with everything being private I can't even dynamically link to what I need. Or if instead of adding these, if you could add a proper API for accessing data that would be useful to everyone that would be cool as well. public Double kOSGetMachSpeed() { return Double.Parse(mach); } public Double kOSGetEAS() { float densityRatio = (FARAeroUtil.GetCurrentDensity(vessel.mainBody, (float)vessel.altitude) * invKerbinSLDensity); return (vessel.srf_velocity.magnitude * Mathf.Sqrt(densityRatio)); } public Double kOSGetAtmosphericDensity() { return (FARAeroUtil.GetCurrentDensity(vessel.mainBody, (float)vessel.altitude)); } public Double kOSGetRelativeAtmosphericDensity() { return (FARAeroUtil.GetCurrentDensity(vessel.mainBody, (float)vessel.altitude) * invKerbinSLDensity); } public Double kOSGetTerminalVelocity() { return termVel; } public Double kOSGetOxygenIntake() { return intakeDeficit; } public Double kOSGetLift() { return Cl; } public Double kOSGetDrag() { return Cd; } public Double kOSGetDynamicPressure() { return q; }

You math people. Makes my head hurt.

There is a very good chance that KSP doesn't update the physics as often on the non-active craft.

Try time:seconds

Thanks! /10.

#4 I think kOS definitely should have more flow control. Something akin to sys.exit(); to terminate a program at that point. As well as continue; and break; equivalent statements. That said while I think it shoudl have them, I don' tknow how easy or insane it would be to try and implement them. They seem so obvious that I have to wonder if there is a good reason they were not included originally.

#5 and #6 are already on my realism list. The rest, well I just woke up so i'll need to read it again when i'm awake

BTW if you go with the current thrust method, make sure you also modify the calls so it doesn't multiply by current throttle.

Easy for you to say. You don't have craft with nothing but vectored thrust for maneuvering In all seriousness if you are happy with the steering changes go for it. Unfortunately without roll working I still can't verify proper steering on my rockets

I'm still trying to figure out how to make it work for engines using vector thrust for ROLL which some plugins do. EDIT: To clarify i'm trying to find a way to do it cleanly. I can get it to work by brute force by detecting if one of the known mods that provide roll vectoring is installed, but that seems like a crap way to do ti.

I always prefer readable code over super efficient code. In my defense C# isn't my language, nor am I that familiar with the KSP API yet, so I was trying to change as little of the original code as possible EDIT: I do think it should use current thrust instead of max thrust though. Since the steering doesn't adjust thrust at all, what does max thrust have to do with anything? Seems that the actual current thrust is all that really matters.

So i'm still testing things, but this seems to be a better method of determing steering torque from engines: public static double GetThrustTorque(Part p, Vessel vessel) { var centerOfMass = vessel.CoM; if (p.State == PartStates.ACTIVE) { UnityEngine.Debug.Log("kOS: Checking thrust on ACTIVE part:" + p.name + " - " + p.stagingIcon); ModuleEngines engine = p.Modules.OfType<ModuleEngines>().FirstOrDefault(); if (engine != null && engine.isOperational) { float thrust = engine.CalculateThrust(); ModuleGimbal gimbal = p.Modules.OfType<ModuleGimbal>().FirstOrDefault(); if (gimbal != null && !gimbal.gimbalLock) { UnityEngine.Debug.Log("kOS: DEBUG return gimbal data on engine with THRUST: " + thrust + " and GIMBAL: " + gimbal.gimbalRange); return Math.Sin(Math.Abs(gimbal.gimbalRange) * Math.PI / 180) * thrust * (p.Rigidbody.worldCenterOfMass - centerOfMass).magnitude; } } } return 0; } 1) It actually detects the engines. That's a bonus. 2) It uses the engine's current thrust rather than its max thrust. Since steering and throttle are separate in kOS, calculating steering from max thrust seems pointless since only the current thrust matters/

Actually it is worse than I thought. I put some debug code into the steering helper to see what values it was determining. [LOG 19:04:22.758] kOS: DEBUG Steering torque = [0, 0, 0] [LOG 19:04:22.759] kOS: DEBUG Steering inertia = [Infinity, -Infinity, -Infinity] [LOG 19:04:22.759] kOS: DEBUG Steering precision = 0.5 [LOG 19:04:22.760] kOS: DEBUG Steering driveLimit = 1 EDIT: Think I found my specific problem. The function that detects thrust vectoring isn't detecting my engines. So it returns 0, and I have no other control surfaces.

Doesn't KSP physically unload a craft that is that far away? Not sure how kOS would keep running, though I admit i'm learning this as I go, so i'm not that familiar with the KSP API or its capabilities yet. I was going to try using the Never Unload mod or whatever it is called.

I still get horrible steering with that build, if I remove my steering changes. The problem as I found it, is that since my rocket has NO reaction wheels, the kOS code that determines how much available toque I have returns a very small number. This number is in turn used by the steering system to determine maximum control deflection, so it barely moves the controls, which results in basically no steering at all for my rocket. I'm betting that @masTerTorch is using reaction wheels, which seems to be the case the code was designed for. So my steering changes were causing oversteer for them, yet the changes I had made caused perfect steering for my craft with no reaction wheels. Need to figure out how to make it work for both ways.

That IS a beauty! Care to share?