MrOnak

Hmmm I might check that, thanks a lot . In the meantime I got the fuel-consumption based script to run reliably though. "Reliably" meaning it runs without error on 4 different staging setups (single->single, double->single, four->double->single, asparagus) running each setup a couple of times, even with alterating throttle settings. In case anyone is interested: // fuel flow test bed declare parameter ffMaxStages, ffThres. set tickSize to 0.1. set throttleVal to 1. lock throttle to throttleVal. stage. set currLF to ship:liquidfuel. set lastLF to currLF. set ffStaged to 0. set ffStageT to 0. set currFF to 0. set lastFF to 0. set lastFFChk to 0. set now to time:seconds. until 0 { set now to time:seconds. set currLF to ship:liquidfuel. set currFF to ((lastLF-currLF)/throttleVal)/(now-lastFFChk). if currFF<lastFF*ffThres AND now-1>ffStageT AND ffStaged<ffMaxStages { // current fuel flow below threshold AND // last time we staged is more than a second away AND // we're still going through configured amount of stages stage. set ffStageT to now. set ffStaged to ffStaged+1. print "staging!" at (0, 3). } else { print " " at (0, 3). } log currLF + " " + lastLF + " " + throttleVal + " " + now + " " + lastFFChk + " " + currFF + " " + lastFF + " " + ffStaged + " " + ffMaxStages + " " + ffThres to fflog. print "liquid fuel: " + round(currLF, 1) + " L " at (0, 0). print "fuel flow: " + round(currFF, 1) + " L/s " at (0, 1). print "last flow : " + round(lastFF, 1) + " L/s " at(25, 1). set lastFF to currFF. set lastLF to currLF. set lastFFChk to now. wait tickSize. } Call with run fuelflow2(2, 0.7). if you have two stages to separate and you consider 70% fuel consumption as compared to earlier a safe indication for a stage being burned out.

Erm... yeah... the 5000 byte space on the small probe comp . Sorry for the confusion hehehe

Heureka! Turns out it was a bug on my end, happening because my currentLiquidFuel variable was locked to ship:liquidfuel. That caused the value to change between the currentFuelFlow calculation on top of the loop and the assignment to lastLiquidFuel at the end of the loop, introducing deviations if one cycle took much longer than the previous one. New code still doesn't work but thats a time-resolution problem which should be easy enough to fix - after watching the match Changes markeed in bold-underline. set throttleVal to 1. lock throttle to throttleVal. [B][U]set [/U][/B]currentLiquidFuel to ship:liquidfuel. set lastLiquidFuel to currentLiquidFuel. set currentFuelFlow to 0. set lastFuelFlow to 0. set lastCheck to 0. until 0 { set now to time:seconds. [B][U]set currentLiquidFuel to ship:liquidfuel.[/U][/B] set currentFuelFlow to ((lastLiquidFuel - currentLiquidFuel) / throttleVal) / (now-lastCheck). //.... do stuff set lastFuelFlow to currentFuelFlow. set lastLiquidFuel to currentLiquidFuel. set lastCheck to now. wait 0.1. }

Oh I totally agree on the controller part . Being fault tolerant is what makes writing kOS scripts fun most of the time.

Sure, that's the workaround. I put this up in order to find out whether anyone else experienced these kind of glitches. kOS having the limited amount of memory that it has, I try to avoid workarounds wherever possible cause they eat up space and are yet-another source for bugs.

I've been banging a head against several brick walls for a few hours now, trying to get a reliable automatic staging script to work but I'm not getting anywhere because of what I think is incorrect numbers from KSP itself. Has anyone else noticed this? My basic code is like this: set throttleVal to 1. lock throttle to throttleVal. lock currentLiquidFuel to ship:liquidfuel. set lastLiquidFuel to currentLiquidFuel. set currentFuelFlow to 0. set lastFuelFlow to 0. set lastCheck to 0. until 0 { set now to time:seconds. set currentFuelFlow to ((lastLiquidFuel - currentLiquidFuel) / throttleVal) / (now-lastCheck). //.... do stuff set lastFuelFlow to currentFuelFlow. set lastLiquidFuel to currentLiquidFuel. set lastCheck to now. wait 0.1. } To my understanding currentFuelFlow should give me a reliable fuel flow, taking into account changes in throttle and fluctuations in loop duration. The number should be quite stable as long as all engines have fuel. It is not. Well it is most of the time but there are short and sudden fluctuations (around double the fuel flow for one or two cycles, then back to the average) every now and then. The idea of the script is to stage when the fuel flow suddenly drops by more than a certain threshold but as long as I experience these glitches that is impossible since it will stage immediately after one of the glitches. Note that the throttleVal doesn't change at the moment so it could be taken out but this is in preparation of ascend scenarios where the throttleVal will change.

I can't really help with the analysis (as I mentioned before, I tested myself into a corner as well) but I can only recommend putting your rover into a stationary position and write a script that constantly outputs heading, pitch, roll, and whatever else you need without actually moving any of the IR parts while you fast-forward time. I noticed that most of my calculations would go haywire twice per Kerbin day due to the rotating reference frame of the planet. If I remember correctly this especially affected the compass heading but this is from memory, I might be wrong.

I'd like to second this one. Any chance it will happen eventually? Thanks

Thats awesome thanks, I'm afk this weekend but I'll sure check it out on Monday thanks!

Woah! That is extremely impressive. I've been trying to hold a specific heading or angle of bank with my plane autopilot for a while now - but failed - could you share the kOS script code somewhere? I think your script has to handle partially the same vector math but I can't figure mine out, the rotating frame of reference is constantly messing with my head :-(.Shameless plug: Thanks a ton

Argh no please, not one more language to write stuff in

[MrOnak sniggers in the background]

OH MY GOD I thank you SO much for that bwaaaahahaha

Heheheh yeah kOS has other things that are moar important. One can dream though. I'll keep nagging you every few months, promised hehe

Getting rid of the free floating console would be great IF and only IF RPM is installed AND you're in a manned capsule. You'd still need the floating console we have now for unmanned probes. But yeah when in IVA I like to hit F2 and fly with only what's there so having the console as a whole on one of the monitors would be great. The Kerbal Space Industries MFD mod on top of RPM already has integration for SCANSat, VesselView and Mechjeb so I guess it might be quite feasible actually to adapt the kOS console to that. Not sure about the original RPM mod as I hardly used the interface from there.

Pretty pleeease But seriously, I know you guys are busy finishing for the next release, no rush

Thanks for the clarification erendrake. Have you thought about a RasterPropMonitor integration for kOS? That would be really really immersive

Oops yes you're right, its 30kN for the Rockomax, sorry for that. That won't change the delta-V calculations however, but it puts the TWR of the Rockomax on Minmus to 173 instead of 298. Thanks for pointing that out. I put one thruster because one is enough for Minmus but yes you can put more and get off Mun easily. Not sure fuel would be enough for Tylo but well, small tweaks. I see two key factors why RCS might be considered "better" here: The RCS Thrusters are lightweight compared to the Rockomax. Also, the RCS lander simply has a better rate of fuel to total weight: The empty LFO craftis 80kg heavier than the empry RCS craft. Those 80kg are pure delta-V .

I had a bit of time and came up with a more realistic comparison: Both probes have roughly the same starting weight. Yet, the RCS probe has ~25% more delta-V but with drastically reduced TWR. Nonetheless when all you need is changing orbits, 1kN thrust is enough on such a lightweight. On Minmus the fully fuelled Rockomax 48 powered probe has an insane TWR of 173 (fixed, thanks cantab!), the RCS one still has a TWR of 5.9 which is more than enough. Its amazing what you can get away with when you built ultralight.

The problem is mass. Four of the RCS thrusters give you 4kN of thrust. You're not going anywhere with that if you add much to the RCS "engine". But a small satellite around Kerbin/Mun/Minmus or even a Minmus Lander Probe is totally possible with RCS only.

Won't it come down to luck whether the "stepping" in which KSP moves your crafts matches the position of the other target? I've certainly flown straight thru various objects at high speeds. And no I don't mean timewarp.

On the topic of utilizing the list parts feature... is it possible to access the tweakable values of the parts? I.e. the thrust limiter setting of engines, or deployment altitude / pressure of parachutes? That'd be really really helpful

True, but after I put a satellite in geostationary orbit from LKO with half a RCS tank I just did the math: - One Oscar-B tank and the Rockomax 48-7s gives you ~1512 m/s delta-V for 0.178 tons of mass. That's in vacuum. - One FL-R10 RCS fuel tank and four RV-105 thrusters give you 4105 m/s delta-V for 0.25 tons of mass. So... once you're in LKO with something very light I'd argue that RCS gets you further than the Rockomax 48. Disclaimer: Doing delta-V calculations with only one cup of coffee in my system isn't my forte. Here's my napkin: Oscar-B Fuel Tank mass 0.078675 (wet) 0.015 (dry) Rockomax 48-7S mass 0.1 thrust 30 Isp 350 ---------------------------- wet weight 0.178675 dry weight 0.115 dV ln(0.178675/0.115)*350*9.81 = 1512.9250270144 FL-R10 RCS Fuel Tank mass 0.25 (wet) 0.05 (dry) RV-105 RCS Thruster Block mass 0 thrust 4*1 ISP 260 ---------------------------- wet weight 0.25 dry weight 0.05 dV ln(0.25/0.05)*260*9.81 = 4105.0323394544

@Blipman17: I do this: lock steering to UP + R(0, -1 * altitude / 1000, 0). Now I just realized that using * instead of + would actually give me more flexibility but this thing turns your rocket 1 degree east for every 1000 meters of altitude. It's a bit brutal but you can achieve orbit quite easily with this when you know when to start applying this lock steering and when to unlock again.

oh god, RCS thrusters are massless as well? Bah... *makes mental note*. This is getting ridiculous.