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?

I think your edit explains what I have been observing. Even though it seems that air density falls off faster in RSS (I think? Based on this image, I would guess lots of the noise would be lost by 20km), it's still the higher frequencies that get lost first, and those are the frequencies that aren't really present. Thanks for explaining!

Good point. Guess I was aiming for fewer mods if possible, but doesn't seem like this is one of those times where "merges" makes sense. My bad!

Just curious, how does this mod determine how much to muffle sound? I play with the RO/RP-0 suite of mods, and I feel that the onset of muffling is rather sudden, noticeably starting at maybe 30,000m altitude, at which point the atmospheric pressure is very low. Sound more or less completely fades out by 50,000m. Is this just another of those unintuitive things I should expect from realistic physics?

Yep, it's a [known bug](https://github.com/malahx/QuickMods/issues/33). Looks like some of the mods have been fixed, but QuickGoto is not one of them, unfortunately

Awesome! If you have any hints, I may be able to take a look I was thinking it'd be done manually. I didn't want to warp outside of the editor since warping is realllyyyyy slow on my machine, and because it gives the KCT delays a bit more meaning compared to just warping through them, without having to spend way too much time in the editor designing things.

Just curious, how difficult do you think it would be to add the ability to have time pass at different rates in the editor, a la time warp?

Sorry, should have specified. All Y'all adds a button in the right-click menu to extend/retract all solar panels/landing gear/etc all at once, even if they are part of a different symmetry group. It's certainly possible that I missed the functionality in Part Commander, though.

Is it possible to sync settings for mods? I'm experimenting with an install with Filter Extensions installed, and I would like it to not hide parts that have been researched but not purchased. Every time I change the setting, though, it eventually changes back to the default (hide parts that haven't been purchased).

How difficult would it be to implement something similar to what All Y'all does?

You used TweakScale on engines that much? Then again, it's been quite a while since I last used it... As a first approximation, if you're alright with REALLY bad-looking models, it should be somewhat easier to make proc engines as a clone of PP SRBs. Replace the motor casing with plumbing/combustion parts, change the tweakables (I'm guessing this is much harder than it seems), change the pricing code, maybe change the nozzle scaling code, and you have something that might work. I just thought of one thing: no engine (that I know of) needs to know about any other engine, so the mechanism for looking for existing engines and seeing if the one being worked on may not exist. I'm not really familiar with the codebase, though, so it's quite possible it does exist. This isn't an issue if you're ok with forcing players to produce derivations by cloning an existing part, and not recognizing "Oh, you built this part before, so the price is reduced x%".