StahnAileron

@Nertea I checked-in with KSP with the whole 1.5.x update and all. SSPX was nice and I was looking forward to the new version. (I even attempted to update an SSPX station with Redux parts in 1.4.x... Gave up after a while as my mod collection at the time wasn't complete compared to prior KSP versions.) I noticed the various dockings ports from SSPX aren't in SSPXr. Have they been completely deprecated or are they planned for a future update? As you have commented before, stock is kinda ugly, especially in light of quality mods like yours. There's also the fact the old SSPX docking port held a bit of MonoProp, so I didn't have to really do anything to supply the RCS I need to assemble a station.

Hmm... I think the pressure unit is Pascals (KPa or Pa I definitely don't recall), but I don't remember if it's for dynamic or static/absolute pressure... I THINK it dynamic pressure. (Which I think makes more sense: if it was static/absolute, that would just be the equivalent of a fixed altitude in practice.)

Just show/hide is what I would like. Not sure if anyone else would like to chime in.

@jrbudda Two things: A) BUG: The Editor collapse-to-right option for switching between compact and full mode shifts the windows to the right. It's not collapsing to the right and keeping the same position. Collapse-to-left works correctly. Seems like it thinks collapse-to-right means set new anchor point for the upper-left corner of the window to the location of the upper-right corner, then switch view. Version 1.1.5.4 of KER from your GitHub with v1.5.1 of KSP, no other mods other than MM and KSP-AVC, both latest. B) REQUEST: Would it be possible to customize the columns in the Editor window's full mode? Compact has the most pertinent information, but I like quick access to the optional info/settings from full mode. I spend a lot of time in the SPH with aircraft, so the extra options are handy.

That feature was re-enabled relatively recently. It was removed WAY back in 1.0.5 or so. Since @linuxgurugamer took control of the mod and this is a more code-centric mod, I asked him to re-implement it. It's been about a month or two since the feature update, so I'm not surprised if you never knew it was there: it actually WASN'T for a long time. (And the original implementation was just a magnitude. LGG was kind enough to add all 3 axis numbers as well.) I was going off visuals and the torque numbers for a long time as well. (Building stock-ish VTOLs without an engine management mod took a bit more tweaking. I should probably look into VTOL engine management mods anyway though. I know of a couple...)

That is precisely what I was talking about. Thank you! You are a godsend to this community!

Possibly stupid question/feature request (if you're even doing feature requests and not just maintenance): In versions of this mod from the 1.0.x-era, there used to be a mass-offset reading that gave you a direct line offset measure of the current wet CoM relative to the DCoM. Is there any chance of bringing that back with perhaps 3-axis readings? (Or at least 2 axis?) I tend to built VTOL aircraft and DCS build is has been indispensable for ensuring I get the CoMs and thrust vectors aligned. I know there are other mods that work with dynamic engine thust-limit to provide the same effect in the long-term. However, I always found them unwieldy, especially in light of how many mods I can have installed. (My screen can be full of menus...) Granted, that may have change last I bothered to test one of those mods. (Problem is the last one I looked at had WAY too many features than I needed/wanted that I couldn't hide like MechJeb.) The Torque value helps me align the thrust vector, but eyeballing the mass indicators isn't very easy at times. I believe the feature was removed because the original dev thought it wasn't used much. (For RCS use I can understand, but for VTOL engine placement without a dynamic thrust management mod, it helped me A LOT.) Otherwise, could anyone direct me to a simple mod that can dynamically adjust engine thrusts to align the thrust vector with the current CoM inflight? I know of Allista's mod, but is the "overladen" mod I hinted at above. It looks amazing, but has WAY more features in it than I need or want. I want something simple like Diazo old Vertical Velocity Mod. (Basically just a toggle.)

It's been a while since I've posted here, but with the current and upcoming 1.4.x releases, I'm guessing the codebase and modding API have stabilized. 1.4.4 shouldn't really break 1.4.3-era mods when it gets released...Right? (Maybe at most a simple re-compile?) I got out of KSP for the past year or so because of a new job and the broken mods that always follow nearly every KSP patch release. (Especially the major ones.) I'm hoping the modding API has stabilized for both the sake of the modders' and players' sanity. (DISCLOSURE: No, I do not use CKAN for anyone who wanted to say, "But keeping up-to-date with mods is easy with CKAN." No, I will not start using it. No, I will not bother trying to justify, argue, or debate my choice to not use it.)

Perhaps you can make an MM patch to swap the sounds to something else? I did something similar when I was using RealPlumes in 1.3.x because they swapped out some default engines sounds that were great for initial launch, but made no sense when I was re-activating engines at zero thrust. (They were stupidly loud and didn't match the visual action.)

And SSD would alleviate the transfer of the game data to RAM/main memory. However, KSP and the mods for it are Just-In-Time compiled on load. A faster processor would (in theory) help as well when Module Manager has to actually process the config files and compile the parts. The only other thing that might help is to get a RAM drive and enough RAM so that an install (or more) of KSP can reside on it. Problem there is cost and the fact you'll either be chewing up power keeping the drive alive or having to re-copy the content during each power cycle or reboot. (You'll be bottlenecked by the transfer speed of the interface though, like any other data transfer-related problem.) Some RAM drive have a battery back-up system. Still, RAM drive are fairly power hungry last I looked into it. As noted before, smaller textures would help since you would literally be reducing the amount of data you're transferring each time on game start-up. The question is if you're willing to live with the lower quality visuals. (This is dependent on the screen resolution you play at as well.) You don't need 4k textures when you play at 1280x720 all the time, for example. BTW, the issue with SSDs mentioned earlier is mainly on the WRITE side. READ operations are generally not a problem. However, in KSP's case, I can't be sure as I know KSP keeps quite a log going and sometimes a LOT can happen in a game session to bloat that log, especially with lots of mods. I'd get a second SSD just for KSP/games in general rather than having it alongside your OS install. (I'm using a hybrid system via Intel RST for my game drive. OS is a dedicated SSD-only drive.) At the very least, it should be more consistent performance without OS disk operations getting in the way of KSP.

As far as I know, if you have a 100% re-useable design, you can mine ore and then recover the craft for 100% cost + worth of ore (or fuel if you convert the ore). This is for pure stock. The same can be done if you use mods that add other mineable resources. The best bet might be Karbonite+. The Karborundrum(sp?) resource is worth quite a lot, though there's only 2 or 3 sources of it with the normal settings for that mod. (Low solar orbit, Eve, and Eeloo, if I recall...) Not sure about the mining rate for it since I have yet to really leave Kerbin's SoI. Otherwise, I usually crank up the fund (and science) rewards in a career game if I care more about just having contracts to give me goals to aim for. Career-mode gameplay is a half-assed after-thought.

Not a problem. I know modding is a time-consuming hobby. It's why I don't do it myself (that and I lack artistic and/or programming talent/skills at this point). The patches is the main thing. Internals I can get around with a simple brute-force methodology. (Besides, does AoA even have a stock internal view? I thought all the IVA views were predicated/reliant on ASET/RPM?) Again, if I get around to doing real, proper MM patches, I'll let you guys know. Lastly: yes, I meant SpaceDock. I read up on the Star Control reboot by Stardock relatively recently and it stuck for some reason. (Despite the fact I had visited SpaceDock not too long before those posts...)

@martinezfg11: I'm looking over the mod (v1.3.9.0 via Stardock) and giving it a once-over to suit my needs. I'm doing a more brute-force method (MM cfg that removes all BDA modules from any part), however, given my request, I may later on do a proper edit of the configs and pull out the BDA sections and place them into one (or more) separate patch file(s). Also, I notice some stats are still from the Beta-era (3400-degree MaxTemp, no SkinTemps), so I may decide to do a balance pass on that (I can't do mass and costs though; MaxTemps are simple for Atmo-only versus Space-capable parts, for the most part.) If I do any of the above (no promises...), I'll let you guys know and post the changes some place (or just send a pull request on github). Getting stuff up to par with stock 1.3.x configs is a chore...

@Wolfair corp., @martinezfg11: Is there any chance of parts with BDA-functionality having those functions split off into a BDA MM patch? As it stands with the current configs, this mod implies BDA is a required dependency instead of an optional one. None of the BDA module calls have a NEEDS to even check for BDA first, so the mod assumes BDA in installed. I haven't touched BDA for a long time. (Considering the complexity of BDA compared to its utility for me, it's just a drag on my system with all the other mods I have installed.) There's no reason to mandate the BDA modules in the part configs without declaring BDA as a dependency. I would like to ask the same for RPM/ASET support (I don't bother with IVA mode at all), but that's directly integrated to the models as far as I know, so that's probably asking a bit much. (I've just deleted interiors from mods if they start affecting my install. I actually got performance boosts from deleting interiors because KSP doesn't have to render them in the Kerbal windows.) Besides, I realize the IVA views are half the reason people use this mod.

Regarding a custom KAX resource: is there a chance of including/supporting an MM config that swaps out the KAX custom resources for more common ones from CRP for those of us that have extensive modded installs (and therefore likely to have the needed dependencies anyway)? I'd rather have a common pool of resources that the mods I use pull from (that make sense) than each one using their own set of custom resources, if possible.

Two items: I don't recall if this supported Radiators as specific category. It currently doesn't (and I don't think it ever did, but again, not sure...) Radiators take EC to use for quite some time now, if I recall correctly. Any chance of adding them to the filter list? I recall Ratzap once telling me that certain categories in the filter for Fusebox are dependent on mod version-specific dlls being present when Fusebox is compiled to actually support that mod properly. This is because some mods reference EC usage with atypical methods that Fusebox has to specifically account and look for. SCANsat in particular seems to be notorious (well, to me) for breaking support in Fusebox each time they release an update. (Ratzap basically had to recompile each time certain optional supported mods updated, like SCANsat.) I'm on 1.3.0 currently and don't see SCANsat as part of the Fusebox filters. Any ideas about SCANsat support in FB-Continued? On a side-note: Kinda wished you called it Fusebox Rewired

There's a reason they called it: ... and not just "Gemini Service Module." It's kerbalized historical referencing. If you want something a bit more faithful, look at actual historical mods like @CobaltWolf's Bluedog Design Bureau.

@keptin Given what you just said, for future reference: My understanding is that KAX is just a parts pack with a plugin-dependency in the form of FireSpitter. I'm guessing KAX will work for the foreseeable future assuming: The FireSpitter plugin is updated to support future KSP versions (and players actually update it properly...) and KSP's codebase doesn't change (once again) in how it handles models (like how I think 1.0.5 switched to convex-only colliders or something or 1.1 handled wheels/legs.) Anything else should be maintainable by the player-base if you ever drop KAX completely, no? (Like config changes.) If you do actually abandon KAX, have you considered changing the license so another modder or the KSP community can adopt it for at least maintenance and distribution, if not further development?

@Skalou, @linuxgurugamer First, a grateful thanks for the work on Atomic Age. I don't use much from it, but I abuse the crap out of the KANDL for small probes and commsats. That said, something I want to ask @Skalou regarding the KANDL: Have you looked at the shroud set-up for it? Most other engine fairings/shrouds I've seen in KSP either stick with the decoupler/separator or split and eject sideways. The KANDL's seems to be a single separate physical entity that kinda gets flung off due to collision on staging. I bring this up because in prior versions, it would get explosively ejected when staged. I wound up always having to disable the shroud. (Otherwise I'd risk damaging my vessel or shifting the orbit a bit. I've lost solar panels to this a couple of times, at least.) I just checked this version with KSP 1.3.0 and the same issue seems to persist. Though I admit, it doesn't seem as bad as before. This was tested with zero ejection force on the decoupler (to rule that out). No shroud = safe and gentle (no shifting), as expected. With shroud = forceful ejection, causing a spin and orbital shifting. This was a very small test vessel with low mass. Something about the size and mass you'd expect for use with the KANDL, if not a little lighter. This mostly a minor thing with a workaround I know about (I think I defaulted the config file to disable/hide the shroud), so it's not something I expect to be addressed quickly. Just something you might want to be aware of. (The lack of a shroud kinda kills the immersion when I go for practicality over aesthetics.)

Generally speaking, I sorta like having my power switch separate from my mode selector. I'm more likely to power cycle than mode cycle. I also think it's a little more obvious in terms of seeing what controls/options you have.

I was KINDA close, in a broad sense

Part II: If you collected them in Kerbin orbit, de-orbit them; attempt to hit them with a direct rocket launch from the surface. The lower to the ground and higher the (combined?) impact speed, the higher the score. Anyway, back about this challenge: Yeah. I read "Atari Challenge" and I thought it was designing and launching a vessel that looked like an Atari console. Or, now that I think about it more, Atari-era classic characters.

No offense, but are RATs really needed in a game that gives you an even better option: RTGs? Yes, it's not realistic, but realism was shown the door long ago. (Playability trumps realism in many cases... Or else we'd only bother playing Real Life(tm).) Granted, it's not as pretty as a RAT for aircraft design if you don't intend on using a hollow part of some sort (e.g. cargo bay) or just clipping the sucker, but it's constant power without the dependency on forward movement in an atmosphere. (And there's also the bane to many a designer: drag...) Honestly, I can't see the benefits of RATs in KSP when it has better implementations for power generation in aircraft. The only thing I can see going for this is cost (that's just one line of code in a *.cfg file) and for the sake of realism. I think it's too much effort for not enough pay-off, generally speaking. For sim enthusiasts it'd be nice, but I can't see that demographic making up a large enough portion of the player-base to warrant/justify an implementation of RATs that works (well) without some hacks. (Unless implementing them is easy; I doubt it given KSP's development history...) WARNING: The following addresses a point (Career Mode), but contains a mild rant:

Is the mobile launch pad the first step into a stock feature of off-site/-world construction using ISRU? Like the EPL mod? That would make KSP far more playable for me in the long run. I've yet to really do anything outside the Kerbin SOI. (The one thing was an attempt at a DMagic survey contract around the Sun. That game was in 1.0.5...) Exploration of the Kerbin solar system doesn't have much incentive for me without some in-game reward (other than science, of which I have disagreements with concerning how research works...)

Probably clichéd as hell, but any thoughts on the Top Gun theme as an intro leading into Danger Zone? First thing that came to mind. There may be something else more appropriate, though...