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.)

Chiming in here: In 1.5.1, HLAR seems to be very erratic compared to the last time I used it extensively back in KSP 1.2.x. (I skipped 1.3.x and 1.4.x). The log file doesn't seem to have anything from HLAR mentioned other than loading it. I tried HLAR in a test install with just KSP 1.5.1, Toolbar & ToolbarController, Vertical Velocity Control, AGExt, and ClickTroughBlocker (all latest according to MiniAVC) with a stock-part craft. As soon as HLAR is engaged, you can see the control indicators going nuts, even when the craft perfectly still and vertical. In the air, the craft kinda wobbles like how a spinning top does when it's winding down. Eventually, the feedback wobble causes the craft to just tip over into an unrecoverable state (too much tilt with too much horizontal velocity) and crashes it. Further testing shows that I can get HLAR to not wobble. However, it takes some effort to do so and when it does happen, it actually stops attempting to kill any horizontal velocity. It'll just attempt to get back to full vertical and just stay that way. While getting back to the vertical, it's SAS control is extremely jerky. (It's much more like a person tapping the controls than a program adjusting it.) Even with Precise Control engaged, the inputs are noticeable jerky, though not as bad with Coarse Control. Ah... Found something odd. Using Vertical Velocity Control to control my throttle, I noticed that HLAR reacts to whether or not the vertical velocity is positive or negative. With a negative vertical velocity, it tilts against the horizontal drift. Still jerky, but it seems to do what it's supposed to. With positive velocity, for some reason it tilts INTO the drift. If I hover and Ping-Pong back and forth between negative & positive velocity, I get the erratic behavior I noted before. (I'm guessing exactly zero vertical velocity is throwing it for a loop and hence why the controls go nuts.) Also, didn't this mod have a "fly to point and hover" function? (Right-click button, then left-click on terrain. Turns the button red.) This doesn't seem to be working much, if at all. And apparently getting it to lock into straight vertical with no attempt at canceling horizontal velocities is as simple as right-clicking on the button and keeping HLAR's settings window open. The moment the window is closed, it'll start tilting the craft again. I think that's everything I discovered so far. If I find anything else (it's really late and I should be in bed), I'll post more. (If it isn't obvious, I typed this up during testing. I apologize for the lack of conciseness.)

Oh, thanks for the (unexpected) offer! Guess we'll wait and see.

LoL. That would explain the NaN errors I sometimes saw in my full mod install.

@SuicidalInsanity Much appreciated! On a side note: B9PS is proving to be VERY versatile and feature rich. I'm seeing it in a lot mods now, especially some very prominent ones.

I was starting to suspect that as well after I was done with my testing (to make sure it was reproducible and I was just doing something dumb.) In the mean time, I guess I can either not use GPO on those parts (thankfully, it defaults to -OFF-), leave the fuel out, or use some of the parts from the MK2X mod. I'm partial to the QuizTech part since it has built-in intakes and the model animation is really nice (and makes it blatantly clear if I have those engines engaged or not even at zero throttle.) Thanks for taking the time to look at this!

@hab136 Could you take a look at this post?: In short, there seems to be a conflict between GPO and at least a couple of parts from QuizTech. Details are in that post.

Sorry about that. It was late and I was starting to go brain-dead. I got around to testing this with a trimmed down install. It's seems to be a conflict between QTAS and GPOSpeedFuelPump. Bug triggers when I attempt to engage the "Balance" function of GPO-SFP on a QuizTech engine that has fuel. (Tested with K-FAN and the Twin Afterburning Jet.) KSP 1.5.1 QTAS 1.3.13 GPO 1.8.16 MM 3.1.0 Log: https://www.dropbox.com/s/4w2361d0gex2oj6/KSP.log?dl=0 The CTD on revert-to-editor when the camera gets screwy is a little harder to reproduce consistently. If it does revert to the editor, universe rendering gets screwed until I restart KSP. Didn't get a Collider NaN calculation error with this set-up either. (I assume that's the result of another mod going nuts after GPO bugs out the game in my full install.) Anything else you need? (Should I post this in the GPO thread as well? I didn't have any noticeable problems engaging GPO on a couple of stock fuel tanks.)

@SuicidalInsanity Is there any chance of getting a config for an IntakeAtm version of the switchable RCS blister for atmospheric VTOLs? I'm trying out KSP once more and noticed the newness in quite a number of mods. (Especially those that have adopted B9PS *looking at Nertea's stuff*). For some stupid reason I like trying to make MK2 VTOLs. I realized some (true) RCS parts for atmospheric VTOLs would be handy. (QuizTech has one, but it's not very practical for the design/uses I have in mind.) Decently powerful air thrusters (read: RCS) would make it easier to stabilize a VTOL into position for landing rather than relying purely on attitude control.

Is anyone else having a problem with the K-FAN causing an exception/NaN problem on launch and then a CTD when trying to revert to the editor? It looks like something's wrong with the model. (Or I have a very weird mod conflict... But it's just that part so far.) If you want logs and a mod list, I'll supply them. I just don't feel like it now because it takes forever to load up an instance of KSP for me. Actually, I got smart and copied over a new instance of KSP with just QTAS for testing later. Still lazy though. (It's a bit late and I found another part in the MK2X mod to suit my needs for now.) I'll eventually get back to this, however.

Ooh~! Nice! Will they have (optional?) textures that'll blend in with the SSPXr look? (Mainly that DP Sr size one in the second image.)