awang

Hey @linuxgurugamer, I created some PRs to add functionality that will be useful for RP-0 players once the new release drops. Could you take a look? Thanks!

This is more or less intentional; from what I understand, Principia's flight planner is explicitly *not* intended to help you execute your burn. This isn't because the devs hate players; from what I understand it's more that stock systems are insufficient for dealing with n-body physics, and there just hasn't been enough time to implement functionality that does work with n-body physics. I've never run into anything like this, to be honest, so I can't really comment on it. Other people already addressed how Principia indicates burn duration, so I won't comment on that. The overwriting and stuck timer/delta-v countdown parts are intentional, since the guidance corrections and timer/delta-v countdown that stock shows are only correct if you assume instantaneous burns. Principia's flight planner takes burn duration into account when calculating maneuver trajectories, so the numbers shown by KSP would be wrong. I believe it's technically possible for Principia to re-implement the functionality to get a correct time/delta-v countdown, as well as guidance corrections, but it's quite complex/time-consuming, so it hasn't been done yet. Isn't stock also affected by something similar to this? If you have multiple maneuver nodes lined up, and the execution of the first one isn't totally accurate, you're going to have to go back and tweak/recreate the remaining nodes to get a proper update to your trajectory (or at least that's what I remember from the last time I used stock maneuver nodes). I think it's more a matter of there not having been enough time to implement functionality equivalent to stock, due to n-body physics making equivalent functionality much more difficult/complex to implement. Consider the amount of effort required to calculate orbital trajectories with KSP's physics model (relatively simple closed-form equations) vs real life n-body physics (have to use numerical integration). Now extend that to every other part of flight planning/maneuver execution. Well, "Show on Navball" sort of does that, by showing the right burn vector with a countdown to the right time... As for not using maneuver nodes, it's because stock maneuver nodes (or at least what you'd expect from them) don't work too well with n-body physics. MechJeb at least partially works with Principia (or at least has in the past for me), since it reads the maneuver direction from the navball. You'll still have to start/stop the engines at the right time, though, since I don't believe any current mods expect nodes to take burn time into account.

I suspect you're looking for sharedBaseLengthLimits in WingProcedural.cs. You'll need to recompile the .dll, and I'm not sure if changing the max size will break anything else. If you get things lined up right, it looks perfectly fine in my opinion. I never had issues with multi-part wings falling apart, either, but maybe I'm not pushing my planes as hard as you are.

Looks like the 1.3 update might have broken the "Show wing data" toggle in the right-click menu in the editor? When I click "Show wing data", the text changes to "Hide wing data", but nothing appears in the right-click menu, and I get the following stack trace in KSP.log: At least as far as I can tell, it seems that the NRE is thrown when trying to show the corresponding fields in lines 2646 - 2653 in WingProcedural.cs, since the KSPField attribute was removed from the corresponding fields in commit 1ba21237ed43ea5653de6f1e1cb66326e4b07259 (along with some code updating the values for those fields). Was "Show wing data" supposed to be removed completely?

Ah, this makes sense. Gave it a try. Flew with stock SAS for about 30 seconds, then switched to AA. AA took about another 30-40ish seconds of spiraling all over the place until it figured out how to regain control. Seems I'll stick with stock SAS for the powered part of the flight, and switch to AA for the landing. The X-1 has control when detaching, so no worries there. I do have to switch momentarily to the B-29 to pitch it down more so I don't get a collision, but that's maybe a second or two of control at most.

Ah, that would explain that behavior. Is there a way to mitigate this? Fly using stock SAS for a while, then switch to AA? Or maybe "reset" AA somehow (if there even is such a functionality) to try to get it to "forget" it was flying a very different craft a few seconds earlier (if that even makes sense)? Something else? Luckily, I'm not too worried about having AA active on both craft, since the B-29 doesn't seem to be nearly as twitchy/unstable as the X-1 after separation. The B-29 really only needs to get to the ground and land, too, while I'd prefer the X-1 be more controllable since there's less margin for reaching altitude/speed records.

Just curious, does dramatically altering the way a plane flies (e.g. detaching something big) affect how well AA controls things? I have a X-1-based recreation that is launched from a B-29-based launcher, and while the B-29 + X-1 flies fine, when I drop the B-29 AA tends to send the X-1 into a spiral. Is this expected?

Thanks for the quick response! I cloned your repo and built the no-mute-by-density branch, but unfortunately it seems that there might be some weird interaction between this and Audio Muffler Redux, since I hear no engine sounds at all, even when directly behind the rocket. I think Sonic Realism is partially working, since I can hear what sounds like white noise (wind noise from Chatterer, maybe?), and that sound appears to change with the angle I'm looking at the rocket. Combining with Audio Muffler Redux sounds like an interesting idea, but at that rate it sounds like you're more or less recreating Atmospheric Sound Enhancement. Wonder what it would take to revive the latter... Edit: After taking a closer listen, I don't think I can hear any difference when changing camera angle

How does FMRS detect when a stage has separated? I have a 4-stage rocket (booster, upper, trans-lunar injection, lunar capture), and FMRS doesn't seem to be detecting the separation of the lunar stages from the upper. It seems to detect the separation of the other stages (as well as fairings) just fine. The booster and upper stages are connected using flat interstage decouplers from Procedural Fairings, with one turned upside down to provide detachable interstage fairings for the upper stage. The upper stage has a payload fairing base from Proc Fairings, with the engine bell of the TLI stage sitting directly on the upper surface of the fairing base. The TLI stage and lunar injection stages are separated using a stack decoupler from Proc Parts. The proc fairings have decouplers built-in due to Procedural Fairings For Everything being installed. Any idea what I might be missing? Update: Of course, right after I post this FMRS decides to start picking up the newly disconnect upper stage. Don't know if it's going to start picking it up consistently now, but unfortunately it means I won't be able to consistently reproduce the issue.

Does this mod mute all frequencies equally as atmospheric density decreases? I'm currently using Audio Muffler Redux, which mutes higher frequencies first and mutes progressively lower frequencies as the air grows thinner. I'd like to install this for the sonic boom effect, but installing two mods that both take care of muffling due to atmospheric density sounds like a recipe for trouble.

Ah, that certainly helps. Thanks!

Does Haystack have some kind of "un-targeting" functionality built-in? It's nice to be able to target a planet without going to the map view, but I'm probably blind and missing a way to undo that...

I like how your commit messages get progressively less and less coherent

@linuxgurugamer I'm seeing a binary blob called "Plugins" in the 1.3.1 download. It seems to be a copy of the FilterExtensions dll. Is this intended?

I'm playing with the RSS/RO/RP-0 set of mods, built from master/dev branches, along with ScrapYard built from master. I get a ton of errors in the VAB when building a vessel with the procedural avionics part that RP-0 provides: This happens when the only part of the vessel is the proc avionics core. Is this a ScrapYard error? Or does the bug lay elsewhere?