Jim DiGriz

possible bug in GameData/ModRocketSys/Parts/RCS/NBrcsCorner.cfg: MODULE { name = ModuleRCS thrusterTransformName = RCSthruster thrusterPower = 1 resourceName = MonoPropellant resourceFlowMode = STAGE_PRIORITY_FLOW atmosphereCurve atmosphereCurve { key = 0 240 key = 1 100 key = 4 0.001 } } Is that legal KSP ConfigNode? I'm writing an external config node PEG grammer and it choked on that, and it looks buggy to my eyes...

I think I picked this release up this morning. With DRE it appears that everything got a bit more explode-ey. With my gravity turn script I used to be able to accelerate at 49,000m to raise my Ap to 200,000m without overheating, and today at that velocity things go boom. Don't know for certain it is this FAR update that is responsible (I have lots and lots and lots of other mods), but is that expected/desired behavior of the drag tweaks? Based on what I'm seeing I imagine aerobraking also got a lot more exciting and people will need to adjust their typical periapsis upwards. I've been updating once or twice a day and DRE hasn't had a release and nothing that came by recently 'smells' like it would have caused this change, but I can dig into it more if necessary... (and i'm playing with stock sized kerbin and not with Real* mods). EDIT: it looks like my delta-V to orbit also dropped precipitously. I had tested before that clamping Max-Q didn't matter, so I was just punching it at like a launch TWR of 2.5 at full throttle and not worrying about drag -- was that a bug that just got fixed? It did seem to violate my physical intuition... EDIT2: yeah, i'm hitting max Q of almost 70 kPa and drag of almost 200 kN now. max Q looks similar to prior release, i don't recall what numbers i was getting for drag. EDIT3: mods that were updated: EditorExtensionsRedux, KerbalKonstructs, CommunityTechTree, MagicSmokeIndustries, FerramAerospaceResearch

I'm seeing 12.6Km/day decay around kerbin in a 150x150km orbit which seems a tad aggressive... AFAIK, I've not twiddled with the stock settings... I'm lucky I have the Trajectories mod installed. I started out in a 80x80 orbit and was debugging some other module and distracted, but noticed the aerobraking predictions once I got down to nearly 60k in the atmosphere at which point I broke my fingers pressing the prograde and burnburnBURN! button... EDIT: Yeah, my multipliers are all set to 1.0, and I'm not using RSS or other-sized kerbin or 24-hour days...

okay, i got a beachball finally on my way back from minmus. so 106 modes, over 10,000 module managers patches loaded and i might be seeing a crash every couple of hours. when you consider the clock really started on debugging all these mods back when the prerelease first dropped i'd consider this a lot more playable than i ever expected. i'd kind of like it to crash more, i'd probably spend more time learning how to program rust instead of playing ksp...

I played 1.1.2 earlier today and did a successful mission to land on the mun in career mode with ckan telling me that i have 106 mods enabled -- no crashing. for how stupid i'm being with all the mods i have loaded up its being remarkably stable... heading to minmus now...

That is the lack of angular momentum and inertia compensation.

OMG, that was so bad.

Software development roadmaps are like weather prediction. You don't ask weatherman for predictions of what the weather is going to look like 2 years out, and you shouldn't really ask software developers either. What makes sense is to ask what they're working on now (the 1.1 stuff they've been highly transparent about). And how far along they are in it and what they're currently working on (the devnotes are excellent and highly transparent here). Asking for anything else is practically like asking them to knowingly lie to you. Claiming that there is a "moral case" that you need to be shown their roadmap is evidence that they should never under any circumstances show you their roadmap, because you're obviously going to interpret the roadmap as a promise and not as a guess about the future that may be scrapped any time someone comes up with a better idea and/or something that seemed simple turns out to be an epic never ending yak shave. Software development does NOT look like this: It often looks more like this:

This feature probably falls right out of Principia (along with many others):

So, kOS uses "findLocalMOI", but I can't see that offered anywhere in kOS when I search the repo, there's just that one hit on that one line. Google search turns it up here: https://anatid.github.io/XML-Documentation-for-the-KSP-API/class_vessel.html That looks like its just the KSP internal API? https://anatid.github.io/XML-Documentation-for-the-KSP-API/index.html Anyway, I'd think that off of the vessel you could hang some methods something like: - MOI (just that thing presuming it really is in KSP base) - adjustedMOI (reserved; unimplemented for now) - torqueRCS (the RCS bit of updateTorque) - torqueReaction (the Reaction Wheel part) - torqueEngine (the awfully complicated bit) And maybe you could break torqueEngine up into torqueGimbal and torqueStatic, but maybe YAGNI... With those exported as streams, then you could prototype your own PID controllers that used them. torqueEngine looks like the only really ugly bit to implement as long as we don't bother with adjustedMOI -- and assuming we can get MOI out of the base game and google isn't wrong there...

So I think here is where the pitch value is getting set and the important bit here is that its trying to achieve a "target torque" based on the "control torque": https://github.com/KSP-KOS/KOS/blob/4bcdb9604f8c575e43935c2e54953ec090be2f0a/src/kOS/Binding/SteeringManager.cs#L962 The PID controller output for the target pitch torque is here: https://github.com/KSP-KOS/KOS/blob/4bcdb9604f8c575e43935c2e54953ec090be2f0a/src/kOS/Binding/SteeringManager.cs#L933 But there's also a PID controller for the pitch angular velocity: https://github.com/KSP-KOS/KOS/blob/4bcdb9604f8c575e43935c2e54953ec090be2f0a/src/kOS/Binding/SteeringManager.cs#L920 This block just calculates the angular error: https://github.com/KSP-KOS/KOS/blob/4bcdb9604f8c575e43935c2e54953ec090be2f0a/src/kOS/Binding/SteeringManager.cs#L899-L911 Then as input to the above there's this ugly-ass torque calculation method which is just Reaction Wheels + RCS + Gimballing Engines + Static Engines: https://github.com/KSP-KOS/KOS/blob/4bcdb9604f8c575e43935c2e54953ec090be2f0a/src/kOS/Binding/SteeringManager.cs#L636-L645 There's some "torque adjustment stuff" but that looks like its only enabled in debug mode: https://github.com/KSP-KOS/KOS/blob/4bcdb9604f8c575e43935c2e54953ec090be2f0a/src/kOS/Binding/SteeringManager.cs#L355 User tweakables are applied here as as pitchTorqueAdjust (0.0) and pitchTorqueFactor (1.0) https://github.com/KSP-KOS/KOS/blob/4bcdb9604f8c575e43935c2e54953ec090be2f0a/src/kOS/Binding/SteeringManager.cs#L874 And I think to start with you could simply use vessel.findLocalMOI (which I think is baked into the game?), there's a bunch of code here which seems to try to work around deficiencies in it: https://github.com/KSP-KOS/KOS/blob/4bcdb9604f8c575e43935c2e54953ec090be2f0a/src/kOS/Binding/SteeringManager.cs#L536 I think all the adjustMomentOfInertia and adjustTorque code wouldn't be necessary for a minimum viable PID tuning product... It looks like updateTorque() and specifically that awful calculation of all the torque from the engines is the worst bit. If you omit the adjustTorque/MOI code then the rest of the calculations look reasonably straightforwards, although I have to admit I have no idea why there's two different PID controllers for each axis...

Yeah I'm just drinking some coffee and surfing through the kOS code, and I don't quite grok it either. I still don't know what they're using Quaternions for, which I think might be related? I had enough QM to understand quaternions as math, but I don't understand quaternions as control theory... That PID tuning looks interesting, but I think it also needs to scale based on the torque you've got available. P at least has to get jacked up if your reaction-wheel-to-mass ratio is low. I'd think you'd also want to use moment of inertia rather than mass, although for space stations that were very long and thin, maybe not since it would tend to rip them apart...

So, does the PID in the autopilot need to autotune itself a little better? With a mainsail taking off its a bit too aggressive and when I pitch over it 10 degrees it overshoots and wobbles. Then I was having all kinds of trouble with the rocket tumbling once I cut the throttle, and what I just discovered is that jacking the PID up to 10,0,0 seems to be necessary once I don't have the mainsail gimbal and have to control via reaction wheel and some (small) control surfaces. It feels like the PID should tune itself based on how much torque (from all sources) was available and how much rocket mass you needed to turn? I suspect kOS and Mechjeb already have code that does something similar because I haven't had to think about this kind of behavior before... Feel like its a bug and not a feature, although if its a feature, it should probably be documented how to scale it yourself? It was a bit surprising, and my initial train of thought was that something was buggy with the autopilot where it stopped working once I cut the engines...

All the code that depends on TWR is commented out so at one point I was playing around with a rocket with 2.8 TWR and was using those startSpeed and startTurn calculations. But yeah you're right that's the initiation of the gravity turn and its just hardcoded. Those are the numbers that last worked for the last rocket I was playing with. I don't know why all of the Ascent Guidance autopilots use a startSpeed and don't just tip over a bit right at the start, I keep shaving that down and it doesn't seem to make a difference, but I never played with it at exactly zero. I think we're may be trying to act like real rocket launches but there's no reason in kerbal to do that? Not sure... The end_surface bit is when we stop setting our steering locked to the surface vector (AoA is zero) and when we start tracking prograde instead. We do that when Q is less than 2.5 kPa which happens when we start hitting the upper atmosphere and I think are pretty much horizontal. Of course Q is also less than 2.5 kPa at the start of the launch so we need to make sure that we're coming down off of max Q rather than climbing up to it, which is what the check is that Q is less than max Q / 2 -- on ascent Q is very unlikely to be half of the max Q that we've already seen since we don't throttle back for quite some time. And we end_surface because Q has dropped enough that drag has dropped enough that we're basically 'out' of the atmosphere and drag is low and we no longer care about drag loss, and we don't care about the possibility that we might flip over if our AoA isn't zero. I'm pretty sure that "maintaining time to Ap" is a bit of a (useful) hack -- what its trying to do is make it so that you burn a lot of fuel immediately to push that Ap out, and then by maintaining the Ap slightly ahead of you when you hit horizontal flight it minimizes your gravity losses there. It keeps you burning horizontal so that you don't pass through the Ap and start having a large deviation between your prograde and your burn (which causes losses) and you don't get too ahead of yourself and push the Ap out too far and again your burn would not be in line with your prograde which would not be horizontal. There's dV losses that come in when you don't burn horizontal and dV losses that come in when you don't burn along your prograde vector -- when your prograde vector is horizontal and you're burning along it is when you have zero dV losses. And if you want to see improvements in delta-V getting to orbit build some bigger rockets using jumbo-64s and plenty of TWR (like 2.8 or so). If you build a 1.25m rocket with a 1.4 TWR you won't see much improvement because your drag losses will be higher (bigger rockets punch through the atmosphere better -- kerbal gets this right). Also if you build upper stages without enough TWR this code doesn't do any pitching up, so you'll just fail to maintain time to Ap and crash. Upper stages for this code need a decent amount of TWR. (and the drag losses in this code are all wrong, its a long story....)

Here's my attempt at doing the GravityTurn mods approach in kOS: https://gist.github.com/lamont-granquist/e26279492ec020f711d2 I believe if you want to do the most optimized gravity turn that the problem you are trying to solve is that you want to dump as much delta-V as possible while you are horizontal to minimize the gravity drag losses. If you're too low and you burn horizontal you burn up, so you first have to reach an altitude of around 40,000-45,000m If your horizontal velocity is too low when you reach an apoapsis of around 40,000m then you won't be able to circularize and maintain your 45,000m apoapsis, so you need to have some significant horizontal delta-v there. The way that GT does this is by keeping the apoapsis around 30 seconds ahead of you. There's probably an optimal trajectory where at the apoapsis you have a horizontal velocity of around 600-800m/s at around 40,000m-ish. Ideally you would burn your fuel in a single instant (at infinite TWR) to shoot yourself into that trajectory (taking account for how much drag you'll have, which alone is a hard problem to solve -- it'd be simpler on an airless world -- although the GT module itself shows that drag is not that large of a loss with most halfway sanely constructed rockets). So the problem to solve is to burn at full throttle, and immediately tip over just enough so that when your heading is locked to your surface vector, and after drag is subtracted that you wind up on that trajectory that takes you to around 600-800m/s at 40-45k Then once you can burn horizontal, burn all your fuel to circularize (at a safe altitude without burning up), and then further burn to raise your apoapsis up to your target orbit. One problem to solve is that high altitude circularization burn at around 45k needs to be a bit more controlled so that you don't exceed certain speeds at certain altitudes (but you do punch it up to the max that you can). Instead of trying to solve the problem of steering a rocket analytically to hit that curve there's probably a way to write down function of max velocity as it depends on height (or air density which you then plug in the bodies air density as a function of height) and then write a PID controller that feathers the throttle and/or attitude to try to hit that curve. Then I think on an airless world you could actually work backwards from a desired trajectory and work out the GT starting angle that would get you there for a given TWR. http://www.amazon.com/Introduction-Space-Dynamics-Aeronautical-Engineering/dp/0486651134/ There's some math in there which is about as accessible as I've found so far.

Here's a kOS script that I worked on for awhile trying to reimplement GravityTurn in kOS: https://gist.github.com/lamont-granquist/e26279492ec020f711d2 Its a bit fugly because I was learning kOS at the same time as I was trying to write it. The computations in the readouts are still buggy. There's no code to bring up the attitude if the TWR drops too low. The codestyle is a mix of how I started writing kOS and how I wound up writing kOS so its nice and inconsistent. There's some half attempts at pulling out functions into re-usable library code that never got completed, etc... I think where I want to go with it all next would be using kRPC instead of kOS (kOS attempts to be an "in game" computer that has some limitations -- kRPC is more of an "open up an API that lets you write your own mechjeb in some other language"). It was very cool to see my ****tty little badly tuned PID controller feathering the throttle to keep the apoapsis time pinned, and it taught me what 'integral windup' is. EDIT: oh i didn't like the code in GravityTurn that guesses the initial angle and turn altitude, but i never found a better replacement, so that was left a bit hardcoded, you have to tweak that manually to find a good match for your rocket, etc...

^^^ We found him @Nothalogh

Laptop users. People on 64-bit old-windows that upgraded (Windows 10 still ships with 32-bit which you get by default if you upgrade from earlier 32-bit versions). People who just don't understand and think 64-bit costs extra and think they don't need it so don't buy it? I used to work with some system administrators who would build 32-bit virts in order to artificially constrain the memory size the software developers could use to 4GB -- I'm so glad I don't work with those idiots any more... There's people out there who still believe voodoo about 32-bit being faster than 64-bit. Anyway, it's most likely cheaper and easier to just ship a 32-bit build and write a small script to launch it when the O/S is only 32-bit, than to deal with the (admittedly small) fraction of users showing up whining about the game failing to launch on their 32-bit O/S and demanding their money back...

While I agree, they'll almost certainly ship both versions like they do in the linux builds in order to support the heathens still stuck on 32-bit hardware and operating systems. I would hope that if Squad is really committing to 64-bit that the script that wraps invoking the binary will launch 32-bit only on 32-bit and launch 64-bit by default on 64-bit hardware. Rendering the entire "pledge poll" concept a bit pointless...

I have Ubuntu already installed. Goddammit, I'm trying to get through XCOM here while I'm waiting for 1.1... Don't be telling me I can run 64-bit on OSX right now...

dual booting is a PITA. linux has right now has crap support for scaling 4k displays (particularly with mixed 4k and 2k displays on the same desktop) and i need to use some Mac apps, so my triple-boot desktop has been booted to OSX for the past 3 months...

I used to use Linux but switched my desktop to a Hackintosh for $REASONS, I had 64-bit but I lost it. Yep. All evidence points to Squad producing a usably stable 64-bit game for Windows/Mac/Linux (since Linux has been usably stable in 64-bit for years now) by going to Unity-5. A poll will change nothing.

+1 I've never used wheeled vehicles out of the VAB, but having to hit 'brakes' right after launching from the SPH is annoying gameplay.

Game mechanics? Agreed. OCD? Disagree. I didn't know that fact quite in the detail, but I was aware that I could easily stack up to 4x of the four little experiments on one side of a rocket and it didn't make any difference in flight, so I'd always known it was at least negligible...

Thanks -- just recovered 10,000 science from a mission to Ike all on a single command pod that reentered. Only needed 1 of every science experiment on the lander (although i brought 2 because symmetry). Had I think 75 science experiments in the command pod, carried none of the science instruments back with me. Hit 6 biomes on Ike in 3 landings + 3 hops. Reentry vehicle was pretty much just a Mk2 with a heatshield and a parachute (think I had a couple lights and antenna as well). Got 5 kerbals up to lvl 4 in the process. Everything collected was from within the Duna/Ike SOI, I already had all the Kerbin/Kerbol SOI science collected.