StahnAileron

The biggest difference is using outer stages to feed inner stages. With just two side boosters, the Falcon Heavy on the outside would look like normal onion staging, but internally, it wouldn't if it cross-feed the fuel from those boosters into the main booster. They'd empty and be dropped sooner while the main booster would continue on with a full tank. Onion staging would have the strap-ons drop later and the main having only a partial tank afterwards. Onion vs asparagus is just as much about how the fuel flows as the apparent staging.

I sometimes just want to give up on MM *sigh* Do you have a link to recent documentation? I've been using the wiki docs on its github page. I think those are pretty old and a bit rough. But as they're on the MM github page, they're official, so I use them, even if they do seem a bit sparse to me. Is there any other source of info/docs, or is that it?

Technically, you could let the EngineLight MM cfg run, then run a second, custom MM cfg that checks for engines that use whatever air as a propellant and remove the EngineLight module. Personally, I prefer avoiding that and have no qualms about modding the included MM cfg if it's a simple(ish) edit I'm doing. It's a roundabout way to get the results I want. Plus it may have some effect on KSP start up since MM needs to parse and apply all those changes. If you have enough parts, it eventually adds up. At one point, my MM changes totaled about 4k on start-up. I added a few more mods after that and updated others. It suddenly bloated up to around 8k. Eventually, I started cleaning out optional MM cfg I don't use/care for and got rid of a couple of mods I was having issues with/didn't care enough for. Got it back down to around 5k changes, which is more in line with what I was expecting. Couldn;t tell if it loaded any better since I've gotten into a habit of playing a game of Freecell or two while KSP loads. (Or otherwise doing something else while I wait.) Still, I do understand wanting to keep a custom MM cfg you don't have to worry about overwriting by accident during updates. The best thing would be to have the mod adopt the changes we discussed. Otherwise you'd have to make a reverse cfg that deletes the module on air-breathers after the fact. Personally, I just edited the mod's config.

With EngineLight, yeah, given it's current limitations according to @dtrauma. On the flip side, I think they already do have different effects under stock. I believe the Panther afterburner mode has emissive lighting (it actually has visible exhaust) versus none in its dry mode (there's nothing to see). I admit, it might only be really evident if you looking for it in daylight or are paying attention at night. I haven't used the Whiplash anytime recently, so I can't comment on it. ...Or this is an effect from me using RealPlume, though I'm pretty sure I didn't have it installed the last time I checked the Panther. I could be wrong though... (The effects were nice, but I disliked how it change the audio for certain engines when you toggle them off/on.)

Crap... Now I realize my problem. I forget I'm trying to exclude them via negation. My logic was backwards. I was thinking, "Match any of these first, then exclude them (i.e. NOT {A OR B OR C})" rather then, "Include things that don't have these (i.e. {NOT A} AND {NOT B} AND {NOT C}). I completely forgot that with the syntax MM uses and allows, I need to use a Boolean equivalent of my thoughts rather than use it directly. Thanks for catching that. I feel stupid now... BTW, for that (correct!) change you mention: perhaps it's best to also add a :FINAL instead of changing the order so it runs after any changes other mods do first if the mods already have EngineLight support built-in. It's a general change (PART[*]), so I usually make those run last. It ensures built-in mod support is done first and the generic change doesn't overwrite it/append to it. EDIT: On second thought... After browsing the config again, I realize the stock-specific changes just EDIT the changes applied by the generic. EVERY part would need a :FINAL or a complete implementation (rather than just edits) if I wanted to make the patch file run last after other mods... I'm starting to dislike how this config was made (especially with all the FORs instead of NEEDS...) I mean it does make sense, but only in a narrow cases (stock-only or the mod names come after EngineLight alphabetically). Once you add other mods, you could run into problems, technically. @jlcarneiro Technically it wouldn't matter for those two since the changes in modes are just statistical (fuel consumption, ISP, thrust curves) and not what fuels they consume (it's still air and LF.)

Ahaha! I'm stupid. The reason why they don't work is because I used a close curly brace "}" in them here instead of a square close bracket "]" near the end. And since I copied-pasted the first to make the second, it would invalidate both. The first version works in my install of KSP, so I was wondering why it didn't work for you. So yeah, dumb typo. Sorry for that. You could also do a NOT function (!) in the initial filter to never mod those parts to begin with: HAS[!manufacturer[NAME]]. And I'm really starting to think the FOR[EngineLight] should be a NEEDS[EngineLight] instead...

To date, I mainly dispose of stages via sub-orbital trajectories, recover it, somehow re-purpose it, or just use an SSTO. I wish KSP had a persistent/permanent vessel system so recovering, refurbishing, and reusing stages/vessels felt a bit more compelling. (KCT is the closest thing...) I did clean up a launch I did once that left stuff in stable orbits. It was just Tracking Station Self-Destructs though. Too lazy to do it manually via rendezvous. (Plus I had one piece in a pretty elliptic orbit as it was discarded in the middle of a Munar transfer burn.)

If I recall, I do believe at one point there was talk in the original thread about possibly making the RCS jets use EC for balancing. I actually favor that for the simplicity and the fact that many jets/air-breathing engines include an alternator for EC generation. In theory you could only use those RCS jets extensive with engines running (EC generation) and/or lots of batteries. The idea was initially floated for the same reason @Daniel Prates outlined. (Makes no sense for IntakeAir to be the only input.) I know RoverDude's Electric Ducted Fans have RCS jets that use EC and IntakeAtm. Doing the same for the QuizTech RCS jets would allow you to use them in any atmosphere (they currently use IntakeAir, which may or may not restrict them to Kerbin and Laythe; they don't check for oxygen, so I can't say for sure) and prevent you from having to bother with a new module. The only other option I can think of would be to make them use another resource (BleedAir?) and patch jet engines to produce that like they do EC (scaled to throttle/thrust). However, patching engines to generate a new resource for one part is overkill, IMHO. *Quick Google Search Later* Ahaha! Seems I was the one to even bring all that up originally:

I'm just adding to the above really, but for overview, the (corrected) exception list should look for: IntakeAir (Typical LF Jets) IntakeAtm (Non-oxygen jets & many fans) FanIntakeAir (Other fans) In the end, I'm guessing it'd be: @PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[!PROPELLANT[IntakeAir]|!PROPELLANT[IntakeAtm]|!PROPELLANT[FanIntakeAir]}]:FOR[EngineLight] Dunno, if the !PROPELLANT[] can take Boolean expressions. If it can, then you could shrink it to: @PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[!PROPELLANT[IntakeAir|IntakeAtm|FanIntakeAir]}]:FOR[EngineLight] BTW, are all the FORs necessary? I can't tell if you're trying to tell KSP all the changes are meant to be part of a mod called EngineLight (which is what FOR actually does and MM assumes via a mod's main folder name or dll name) or if you're trying to make sure the configs take place only if EngineLight is installed/loaded first (which FOR sounds like it does), but that's actually NEEDS. At least, this is my understanding of how FOR and NEEDS work for MM from the references I read.

Anyone know why this mod is packed-in with IFS and the IFS version coming with what looks like a RealFuels or MFT set of configs? (None of the fuel switch settings have LF/O.) I was wondering why this was in my 1.2x install suddenly when I knew I never grabbed it for 1.2. (I had it for my 1.0.5 install, which is why I recognized it.) BTW, @Enceos what would I need to do/set in the configs to make a set of MM configs that create copies of the tanks in different sizes? I don't use TweakScale and prefer to not have it installed. (I don't like rescaling parts dynamically and I didn't have good experiences with it. KSP handles in-game scaling unreliably, IMHO. I only tolerated TweakScale for Infernal Robotics' Model Rework packs.) I'm thinking of making an MM config that check to see if TweakScale is installed and if not, it spits out a small collection of parts instead of relying on TweakScale support. If TweakScale is installed, it just uses the default settings you already have. I'm KINDA familiar with MM syntax (beginner and rusty now), but I need to know what I would have to look for and set to get the right sizes without liquiding off KSP. (I.e. Scale vs rescale number, etc.)

I know I'm late, but... Current KSP is know to have some sort of terrain issue. (One aspect is exemplified by the T3 and T2 runways not being aligned properly and showing seams.) As far as I know, all of Kerbin has that issue to some degree. (Plenty of mentions of rover suddenly flipping out at particular locations, IIRC.) I imagine this is related. I've had vessels sitting on the ground but look like they're floating like half a meter above it and what not. It seems like an inherent collision detection versus visual rendering problem in KSP itself due to the changes from 1.1.x to 1.2.x.

Out of curiosity, is this a persistent setting that you need to change via menu all the time or something you can toggle at will via keyboard (e.g. one of the Function keys)? I don't do screenshots much, but I do like playing with lighting as-is for the most part. So I think it would be nice if the feature was toggle-able on-demand via hotkey or optionally only kicks in when F2/F1 is pressed. Or something along those lines. I just wouldn't like having to go into the options menu each time I need to take a screenshot for whatever reason and then go back to reset the setting. I know streamers and the like will probably always have the setting on and tuned for their needs (the audience), but there's something cool about floating through the blackness of space with just the vessel's light (if any) to brightness the darkness. (I spent so much time flying in the dark back in 1.0.5 in a modded VTOL doing various survey missions. I dedicated quite a bit of time getting the lights on my vessel to look right and nice.)

@AndyMt Any chance of adding a throttle control option to this mod that a player can use after a manual launch? I have a shuttle design and notice GravityTurn's autopilot didn't handle it all that well on initial launch. (I'm guessing the offset thrust was throwing the autopilot for a loop.) I can manually launch the shuttle fine using GravityTurn-like procedures (i.e. a gravity turn via throttle control rather than direct heading changes and maintaining a particular Time-to-Apoapsis.) GTc as it is now is all or nothing at launch and can't be engaged mid-flight. I just want something to control the throttle for me during ascent that I can toggle. It could be as simple as "maintain current time to apoapsis". No regard for target Apoapsis, auto-circularization, piloting, etc. I just want something to control the throttle so I don't need to tap the throttle controls all the time. If not, I can live with it. I don't use GTc as much as I thought I would since I know the basic procedure it uses. (I prefer the throttle-control method over MJ's brute-force method, though you do need something like KER's Time-to-Apo read out unless one is comfortable playing in map mode and chasing the Apo point around with the mouse...)

Honestly, I'm STILL waiting on a kerbal mod that swaps out the Kerbal models with chibi/SD versions of anime characters. I wouldn't mind going to space with the character from the likes of Stratos 4 or Rocket Girls. Though as far as I know, the kerbal models are hard-coded and can't be modded out for different models. Last I recall, even the dev of TextureReplacer hated dealing with the in-game kerbal models. (There was the time when the genders had models that were handled completely differently in-game or something.) I'd be hyped about the strut thing, but I still use KJR for cleaner designs. The terrain/runway fix is the main thing for me. Otherwise any real issues I have with KSP tend to be mod-related. I recently got reminded how an improperly configured SmokeScreen setting could destroy FPS (I was messing around with the particle limit...) I also recently ran into an Out of Memory situation. KSP literally ate up all the free RAM I had on my system. First time that's happened since I started using the x64 versions (dating back to the 0.90 workaround.) Might have something to do with the current edition of GravityTurn as I was using it extensively during that session, plus lots of reverts (testing an Apollo-style system at the time.) Luckily it crashed on my while I was still in atmosphere, so my save when I restarted KSP was at launch. (Yay for no stranded Kerbals, though it was a sandbox game anyway.) If they squeeze in more bug fixes, performance fixes, quality of life improvements, I'm fine. I may not be hyped about it, but *shrug* I never cared for software updates like they're done these days to begin with. I'm more used to the old, 90's-era PC software (gamebreaking or extreme unbalancing bugs only; added content via paid expansion packs) or console (what you bought is what you get and nothing else) styles. Still, I won't complain if it's free. (Despite some of my complaints about KSP being a "game" versus just a simulator... But that's something else.)

Does anyone else have any problems with the HVR-ONE Ultra-Heavy Lift Fan and it's lift generation? If I place them as lift fans (vertical thrust), the lift generated according to the Aero Overlay (F12) is parallel to my craft and perpendicular to the lift: The lift fans are off and I have 2 Whiplashes for forward flight. (This was just an incomplete test craft.) I plummet to the ground readily due to apparent lack of lift... Or excessive drag in the form of lift in the wrong direction depending on how you look at it. The same aircraft but with the lift fans upright (thrust to aft) - again with the fans themselves off - and just the Whiplashes providing forward thrust can fly just fine if a bit slow-ish. Lift vector arrow off the fans mimic the OPT lifting bodies I'm using, indicating I'm creating "proper" lift. Am I using these wrong? I imagine not from the name and the fact these fans have the wing section toggle.

Is there any reasonable way to change the sounds Real Plume uses? While the new audio is awesome for initial launching, it's very LOUD in the cold of space when I'm switching certain engines on again after having switched them off previously. I basically want stock sounds for the LFO (or non-SRB-type, I guess) engines because toggling the LFO engines back on seems VERY out of place when I'm in orbit with the throttle at zero and along comes this thunderous roar out of nowhere. I'm specifically referring to the Vector and Dart in this case (I've been testing shuttle designs lately). I imagine some other engines will have the same issue for me since Real Plume uses pre-defined configs as a baseline.

So another test confirms my lifting body issue. I did a re-entry with F12 the whole way. The moment AoA is high enough to generate a bit of body lift causes a positive feedback loop. My shuttle flips and becomes uncontrollable until I hit the lower atmo and well below subsonic speeds. I either need to keep AoA reasonable until I hit speeds/atmo density where my wings can generate enough lift to readily shift prograde path (thereby preventing too much body lift in the first place), or redesign the shuttle to somehow always have more lifting-surface lift that possible boby-lift, uh, lift. UPDATE: Workaround for my problem... I shifted the main wings back a bit and added a wing extension under the main engines with additional control surfaces (pitch). This afforded me some leeway to add forward canards for even more pitch control. I now have a bigger tolerance before starting to flip and better able to counteract it. MUCH easier to fly now. I can even get out of dives better and safer. I still need to make sure I don't just yank on the pitch controls though. I have absurd lift though. Coming from 100km to 30km for re-entry and I'll start climbing again around 40km. (I set SAS to prograde on hitting the atmosphere than switch to hold attitude.) Not a terrible problem to have at this point. My test run with this current design landed easily enough in the desert. Album with a handful of pics: http://imgur.com/a/U9YoW

Good Day All, I don't mean to take this thread on a tangent, but it's the inspiration for what I'm attempting to do: build a working Shuttle System. (I won't be entering the challenge.) I built a shuttle (actually, a couple; explanation upcoming) that launches quite well. I spent time tweaking it for the major stages of launch: initial launch, SRB burnout > SSME-only phase, orbital insertion. In a nutshell, it flew as intended. I just needed to control pitch-over, AoA, and flipping over before dumping the ET. For the most part, it was far more stable during launch than I originally thought I could get it. Note I mentioned stable launching. Recovery is a whole other matter for some reason. I seem to be facing either trans-/supersonic instability (does stock aero do this?) or I'm facing some horrible body lift issues with the MK3 design I'm using while at high speeds. The CoL is a good distance behind the CoM and DCoM (per RCSBuildAid). However, I did notice during a few re-entry tests with F12 on that the MK3 bodies were generating a lot of body lift. Re-entry is usually fine if I keep a reasonable AoA, but if I hit a critical angle of some sort, it flips and either flies backwards or becomes uncontrollable. Nothing I do helps (if anything, making it worse) until I hit lower speeds. Typically this is under 200m/s or so. I've tried to replicate this, but I apparently need to go stupidly fast in relatively thin atmosphere for this to kick in. (Thin enough that natural CoL won't affect changes in prograde fast enough, but still thick enough that my control surfaces still work and create body lift on the MK3 parts.) Have any of you had to design around/take into account body lift issues with shuttle designs? I'm more used to Mk2 designs where the "body" lift is already accounted for in the SPH (since MK2 bodies are treated as wings.) I think the body lift at high speeds is screwing me over whenever I try to do any maneuvers at those speeds for my MK3 design. (Honestly, this is the first time I've bothered this much with a MK3 design.) The CoL is about a small MK3 fuel tank behind the CoM. My re-entry tests have been with mostly full tanks coming back down. I'm suspecting the body lift is enough to shift the CoL ahead of the CoM. (Relevant parts ahead of the CoM are just a large MK3 Cargo Bay, a small MK3 Cargo Bay, and the MK3 cockpit. Not much, really.) F12 showed those parts generating some absurd body lift during a few of my tests, IIRC. I'll post pics of the design if you think it might help... Or you're just curious what kind of design I made. I have a modded install. I started with a mostly stock design. The exceptions were the ET (FuelTankPlus parts to mimic the actual STS ET) and separation motors (from BlueDogDesign). It's got more modded as I iterated the design: more FTP tanks and a switch to OPT wings. (The switch in wings was to test my instability problems... That, plus extra fuel and lift.) I only have the most recent design though. I wasn't saving versions, unfortunately.

At that point, much like how mods are a community thing, mod localization would have to be a community project/endeavor. Assuming mod localization is made simple to implement (for things like a part pack, perhaps an alternative description block with a language identifier of some sort, like EN, ES, DE, FR, RU, CN, JP, etc. so the game knows which block to use based on the localization setting), it a matter of getting people to translate the text. SQUAD crowd-sourced via community volunteers. Modders can do the same, assuming any given mod has a big and diverse enough userbase to facilitate that. (Or some very generous general community members.) "Plug-in"-based mods will probably either need to roll-in their own support for localization (built into the mod), or some how hook into the system KSP will be using. (Dunno if the localization support in KSP will have an API or anything for plug-in mods to use.) From there, it's probably just a matter of pulling UI text and such into their own language config files and once again asking for volunteers to translate any part that need it. If the localization system can be taken advantaged of easily, popular mods will quickly get localizations. Of course, this assumes KSP's localization system gets exposed to modders for use (I don't recall reading this; someone chime in if you know) and in the case of plug-in mods, the dev(s) decide to support it. Localization is relatively easy these days thanks to the Internet. It's getting the infrastructure in place to do it well and correctly that's the hard part. (And probably making it robust so you don't screw yourself over later on somehow.)

This is a LITTLE off-topic, but I despise the ever increasing costs of hiring Kerbals as a limitation for crew count. It becomes more practical to rescue Kerbals after about a dozen hires or so. I don't do rescues (I'm not a fan of rendezvous missions, though I might do things like that now that I'm much more comfortable with orbital maneuvers), but do rescued Kerbals start at Level 0 as well? If so, maybe rescued Kerbals could have chances of higher ranks as time passes. No money for rescued Kerbals makes sense if you get to keep them. Adding possible higher ranked kerbals as a reward would sweeten the deal... Unless they overhaul the whole crew hiring and management process. I'd prefer salaries, but you'd have to prioritize which kerbals get paid first so you can keep using them if you ever get into a financial pinch. Maybe a per-kerbal, per-launch fee? With higher ranked kerbals costing more to use on a mission? Dunno, just throwing ideas out as a substitute for the escalating hiring costs.

In the case of sequential launches of the same launcher, would it plausible/possible to have an auto-rename function of the vessel once GTC turns itself off? It already keeps a history of launches, so I would think it could just append a number (or maybe whatever text the user types into a text field?) to the vessel name once the launch is "successful" (defined as reaching space, which is about when GTC turns itself off, IIRC). The numbering sequence would increment based on "successful" launches. (So if you revert often before hitting space, like during testing, you won't hit huge numbers later on.) Stock "renames"/appends discarded/decoupled parts already. I wonder if that could be used to rename an existing vessel. (Granted, I'm sure that's different since decoupling is generating another vessel and undocking is just restoring a saved vessel name.) This would make profiling a little more hands-off if the player wants AND it helps make "unique" names for vessels of the same class if a player forgets to rename a vessel in the editor/right before launch. Again, dunno if any of this is possible since I'm not sure how KSP handles vessel renaming and if mods have access to functionality. Also, for saving/loading custom launch profiles, would it be possible to add an option of NOT saving a launch to history for future tweaking and/or an option to save to a different (new) profile than the one that was loaded? Reasons: Do Not Save: I could be using a known profile that works well enough for a one-off launch, but that launch could adversely affect future launches using that profile. (Think using a launcher out of spec for just one thing because you don't feel like making a dedicated launcher for it.) Save to New: I have a new line of dedicated launchers and want to use another profile as a starting point because the design is similar (or an improved version.)

Well, better than nothing. If I decide to try this out in my install, I'll let you know. All my important actions go into groups 1-10 anyway, since those have hotkeys by default. (Lesser used or one-off actions I dump into higher AGX groups for activation via mouse. I'm too lazy to map the extra groups to key combos ) If AGX and DAG work for groups 1-10, that's enough for me.

Perhaps a dumb question, but what's the functionality/compatibility of this mod with ActionGroupsExtended? Does it work properly with AGX and/or support the extra actions group? Stock AGs seems to map one-to-one with AGX for groups 1-10. (Well, last I tried, which was a LONG time ago: 1.0.5-era. Uninstalling AGX still left the proper settings in stock, IIRC.) I don't touch KSP much lately, but I'm thinking of getting back into it more, especially now that someone picked up Adjustable Landing Gear. (ALG is perhaps the one part mod I refuse to play KSP without.) I dabbled in KSP a bit now and then since 1.2.x came out (I skipped 1.1.x entirely), but haven't done anything extensive since I was waiting for mods to update. I'm considering this mod to make life a bit more convenient in the SPH/VAB/Editor.

Thanks for the quick reply. Not much of that is aero-oriented, unfortunately. I do find REKT's OTAV intriguing. It (and Contares' grid fins) is along the lines of what I'd expect. But sadly, no actual wings. Still, I might look into REKT for its OTAV.

@linuxgurugamer You wouldn't happen to know if there are any other mods that use your RetractableLiftingSurface plugin other than this mod, would you? I know the first time I saw the idea in SXT, I liked it. Then I found out you were making a plugin so the idea was fully fleshed out. (i.e. Lift wasn't generated when folded.) It's an appealing thing and less cumbersome than something made with IR (though perhaps not as flexible since this sorta needs purpose-made parts to make sense.) Also, thanks for taking over so many mods and keeping them updated and relevant for new KSP versions. Somewhere between 1.0.5 and 1.1, many mods just got dropped or neglected. So, again, thanks for your time and efforts!