StahnAileron

There's a whole discussion about it on the first page.

The problem is the micromanagement in the long run, as @Gargamel notes. You can fudge the numbers for time warp on rails as @mattinoz notes. ("Decrease orbit semi-axis by X meters per orbit/day/hour/etc." Other parameters as wanted, like scaling loss with altitude.) If there was an orbital decay function, it would have to automate station keeping, making engines/RCS and fuel(s) mandatory on any long-term orbital craft. (Space stations, comm sats, survey sats, etc.) With enough things in orbit, you'll be spending (read: wasting) a lot of time with station upkeep without automation. ("Spend Y fuel to prevent X loss of altitude per Z interval.") Of course, this in turn leads to management of refueling all of those craft in the long-term as well. For that, you would have to have a system for automating that as well if you wish to cut down on the tedium. As KSP is not yet a true game (in my eyes, anyway) and is just a sandbox simulator (Career mode doesn't count and you know it), that's not gonna happen (any time soon, at any rate; maybe in KSP 2). If you could record launch profiles you've done manually, like refueling/-supplying a space station, and could set the game to use said profile in an automated fashion, then orbital decay could be a thing. However, for the sake of simplicity and gameplay, the lack of orbital decay is the right choice to appeal to the masses. For those who want more realism - *points to Mod Section of forum* - You should find a mod that suits your tastes. (I do believe there is a profile recording mod as well to help automate regular, repeat launches.) Remember, if you want something in stock, it has to appeal or offer value to (close to) EVERYONE, not just you personally or a small niche of players.

No problem. For all you know, it could have been a simple syntax error or typo. I've had to troubleshoot my MM configs before. Usually, it's me mucking up the match parameters somehow.

Uh... Guess you didn't know, but the setting for clamshell versus confetti fairings is part of the module config for a part. You can do the same thing with a MM config to set that option, no need for a DLL plugin (well, other than MM.) // This MM Config sets some defaults for your fairings so you don't have to all the time. // The FINAL is there because I make all my personalized MM configs run last after all the mod configs. // I figure it makes sure I catch all changes and mod parts that use/apply/edit the same settings I'm modifying. // Probably safe to remove if you wish. @PART[*]:HAS[@MODULE[ModuleProceduralFairing]]:FINAL { @MODULE[ModuleProceduralFairing] { %nArcs = 2 // Number of fairing sides. In-game Editor Tweakable Limits: 2-6 %ejectionForce = 1000 // Self-explanatory. In-game Editor Tweakable Limits: 0-1000 %useClamshell = True // Self-explanatory: True/False // The next setting controls the max length of each section. // I'm applying a multiplier here to the part's stat. // If you want a hard number, delete the *. // Not a normal tweakable, so I don't know the limits. @xSectionHeightMax *= 3 } @MODULE[ModuleStructuralNode],* // Needs indexing wildcard here since each node is using an instance of this module. { %visibilityState = False // Visibility of the Truss(?): True/False (Related to "showMesh" below; change in tandem.) } @MODULE[ModuleStructuralNodeToggle] { %showMesh = False // Visibility of the Truss: True/False (Related to "visibilityState" above; change in tandem.) %showNodes = False // Visibility of Nodes: True/False } }

Ah, right. I forgot about that fact. Been taking that for granted as a given since it's part of the reason you would want to use Trajectories. It's actually Angle of Attack. (Attack is relative to prograde. Attitude would be relative to horizon.) If you're using this in a later version of KSP than the version it was built/tested against officially, something may have broke despite it still "working" superficially. If I recall, the orbit line system in KSP got revamped in 1.4.x while Trajectories is technically only 1.3.x compatible. (Assuming the thread title is accurate.) You can always take a look at the log file to see if Trajectories/KSP is complaining about anything. I usually deal with SSTO spaceplane designs, so I just need to be "close enough" with the prediction and I'm usually Prograde anyway (AoA notwithstanding). The last time I seriously tried anything with KSP was back in 1.2.x apparently. (I dabbled a little with 1.3, but got sick of having to wait on and update mods.) I haven't touched Trajectories with 1.5.x yet due to how out of date it is. (Side-note: SQUAD's idea of quarterly updates is, IMHO, a terrible idea. Though KSP development, in general, has been a cluster*bleep*. But I'll shut up now.)

Those are on purpose to disable those features. I think it was noted in the readme.txt file or something. I remember looking it up to be sure myself.

Correct: Trajectories only accounts for the CURRENT configuration of your craft. There's no option to make predictions for a later stage with a different set-up. (ANY mod that takes staging into account for predictions can get VERY complex. Just ask the MJ or KER devs.) The only thing you can do is launch the craft, cheat it into orbit, do a de-orbit burn, get it to the configuration you need it in, and test the re-entry. (TL;DR: Do a live test.) For atmospheric bodies, Trajectories lets you set a AoA for the duration of re-entry based on I think the stock cut-off altitudes for situation transitions (i.e. Flying High vs Flying Low.) Or close enough to it. I think there's a third slider for REALLY close to the ground. The slider is quite rough, though. It's more like preset angles instead of a fine-grain adjustment slider. In any case, setting/leaving it at zero with defaults assumes you're point directing prograde. Values other than zero is attitude relative to prograde. I think there is a setting to change this to horizon-relative, however. Of course, the orientation of your command part plays a role since that dictates the orientation of your craft relative to prograde.

Then you'll have to tell me exactly what you want accomplished because that patch changes only ONE sound. (Launch something with a KS-25 engine and toggle the engine on and off a few times with JUST RealPlume, my patch, and all necessary dependencies installed. The activation sound should be the quieter stock sound.) This release of the mod is still technically still for KSP v1.4.x. (See title.) Minor updates to KSP have been less likely to break mods, it seems.

Having your own personal folder for mod patches is fine. Well, I'd have to verify that you are in fact saving the file as a CFG and not some other file type by accident. You know what...: https://www.dropbox.com/s/qcst62p1avgmhqz/RealPlumeAudio.cfg?dl=0 Try that link and download. That's the actual file I'm using and as far as I can tell, it works... I think. Honestly, I've been working with jets lately (usually), so I haven't actually been paying much attention to rocket engines and the sounds they make. Lastly, if you could tell me just exactly what it is you want to do again in detail, maybe I'll be help you a bit more (or realize what I have been trying to do doesn't apply to your end goal...)

Anywhere inside the GameData folder should be enough. I did make this for KSP 1.2.x, so some stuff may have changed or it isn't affecting the particular thing you're trying to do. All this patch does is replace the activation sound for engines with the original stock sound. The activation sound was the loudest sound clip used by RealPlume (back then in KSP 1.2.x anyway). Oh, and just to be sure: You did make sure the file extension on it is CFG and not TXT, right? If you're on Windows, it defaults to not displaying the file extension. And NotePad, if you used it, appends .TXT to new files by default unless you tell it to save as ALL FILES first. You may also want to make sure it's not labeled as FILENAME.CFG.TXT as well. I apologize if you are already aware of the above, but I know Windows has many idiosyncrasies most users aren't aware of until they have trouble and ask someone for help.

It only accounts for drag and lift (you can specify AoA) while coasting for predictions. It'll update the prediction in real-time while thrust is engaged. (And the prediction is just what the path will be like if you STOP thrusting at that point. Remember, these are coasting predictions.) It's meant for mainly atmospheric (re-)entry. The normal orbit lines are sufficient for airless worlds. Lastly, I don't think there is any mod that accounts for thrust over time rather than instantaneous point thrust. The closest thing is/was a mod that broke down a long burn into multiple smaller, shorter burns. (I think MechJeb or PreciseNode did that. Don't quote me on that.)

Yes. That's a setting within SmokeScreen you can change while in the game. (Particle limit so you don't overload your graphics card.) For individual engines? Not in-game without affecting other engines. HOWEVER, if it's what I think you're thinking of, you CAN replace a particularly loud sound with a stock sound via MM patch. In fact: // Purpose: This MM CFG changes the engage/staging/activation sound for RealPlume. // Commetary: The sound is impressive for launches, but out of place for designs // that rely on different sets of engines that a player turns on/off // as needed with the throttle at zero. // They can be VERY loud in the dead of space... // Part needs a Plume definition and not have SolidFuel. // SRBs are one-shot alway-on; a loud activation sound is befitting. // Dunno if I should include a check to exclude Jets; do any jets use RealPlumes? @PART[*]:HAS[@PLUME[*],!RESOURCE[SolidFuel]]:NEEDS[RealPlume]:FINAL { @EFFECTS { @engage { @AUDIO { @clip = sound_vent_medium // Stock audio clip often used as the stock engage sound. } } } } Copy and paste the above into a plain text file. Save it as a *.cfg file in the GameData directory (pick whatever filename makes sense for you.) The patch has an explanation of what it changes (because coding notes so I know what the code does years after the fact...) If you have other concerns with the audio, ask and someone might be able to help you.

Literal balance request: is there any chance we can get a CoMOffset on the XJ-48k Vector engine? They mass 2100 kilos. Two of them on the backend of a Mk2 plane shifts the CoM really far back, making it practically a requirement to either front-load the plane somehow or make it a delta-wing design. (Or anything else to get the CoL behind the D/CoM in a reasonable way.) If yes, I'm currently booting up KSP to test a setting. I'm thinking something in the 2-3 range for offset will work. Will get back with a suggested value later. EDIT: So I tried out an offset of 2.7. Seems like a bit much: it puts the DCOM in front of the WCOM by a decent margin on the design I used for testing. Considering the total mass on the front end is less then the rear, this is overdoing it. I'm guessing a value between 2.0 - 2.4 would be better. (Maybe 2.1 to match the mass? )

That used to be the case. At least according to the demo video I saw showcasing a landing on Minmus, I think. I didn't get to use it much as intended like that though. (Especially in conjunction with Vertical Velocity Control.) I wound using it to build hypersonic MK2 VTOL survey planes. There was something oddly satisfying about just flying around Kerbin for a while, landing and hopping site-to-site doing surface science, tehn flying back to a base for landing and recovery. (I used to have Kerbin-Side installed.) And of course there was getting the CoM vs DCOM and thrust balanced JUST right. And just as a shout out, @linuxgurugamer is keeping it possible for me to do that again now and hopefully into the future. (He's taken over many of the utility mods I used to design and control my VTOLs.) Not a problem. I noticed the issue last week as well, but didn't want to say anything as I have a couple of mods that have auto-piloting functions. I wanted to make sure I wasn't doing something dumb. On the flip-side, it got me to ask @SuicidalInsanity to add an attitude/reaction control thruster ((i.e. air-breathing RCS) to his MK2Expansion mod for easier atmospheric VTOL control. He was kind enough to whip up a cfg file for one using a part already available in his mod.

Does this support Blizzy's Toolbar? I'm pretty sure it did back in 1.2.x. In 1.5.1 with the latest ToolBar and dependencies, it's stuck in the stock toolbar. Blizzy's doesn't have the option to display it. BTW, it is possible to add a limiter to throttle change speed to help with jet engine response? I know most of the problem is dealing with the spool up/down of jets. Maybe a "Jet Mode" toggle that limits the rate of change in throttle and putting a clamp/limit of max vertical acceleration would help. At the very least, I think it would make it more obvious that player has to be more careful when using jets only. (Of course, this is assuming you'll even consider developing this further rather than just maintaining functionality.)