StahnAileron

Precisely. If only I could find one from a retailer I trust for cheap-ish. (Newegg and Amazon only have it via third-party and I dread the likes of Ebay...) They were like 500USD when I bought my 4771 (which was why I got the 4771 over the 4790k). Now it's almost the same price as what I paid for my 4771.

Yeah, but that's a different socket: LGA2011v3. Most consumers won't be touch X-series processors. They're meant for workstations/enthusiasts and are base on the enterprise-grade (Xeon) processors. His 4440 and my 4771 are consumer-grade (LGA1150). So a 49xx CPU would need a MB swap for either of us. If I had to change my MB for a CPU upgrade, I'd just go for something newer anyway.

If he can find a deal on a high-end 4000-series, it would keep costs down since he wouldn't have to swap out the MB. 5000-series in LGA1150 packaging are practically non-existent. (Two models, neither of which are truly high-end.) I looked at i7-4790k's and the pricing is still pretty crap-ish. MSRP is about $350USD new. Still, I think it would last one a while unless Intel ups the ante with Ryzen out in the wild now. If he (or I) could find a good one used or on clearance... Other thing to hope for is for KSP 1.3 to have some more optimizations for the physics along with all the localization and bug fixes.

KSP's code isn't that multi-threadable: throwing more cores/threads at the problem won't help. I need raw single-thread processing. (It's the physics as I understand it.) Don't wanna swap MBs: That's both a CPU and RAM update. My current system is circa 2014/2015. Switching to AMD is a new MB and DDR4. I'm on Intel with DDR3. Side-note: Intel is still considered the top-end for single-threaded performance. Ryzen is (hopefully) giving them competition in the multi-core segment. I'm hoping prices come down from Intel because of that. (Won't really help me unless I do a system update anyway though: 4000-series CPUs were end-of-life a while ago.)

It would also depend on the licensing. Recall that SQUAD requires all mods to declare a license of some sort. But let's be real: the code is written by a KSP player. Said player is likely part of this community. It's not like SQUAD can't just ASK for a license and/or terms. Or just hire the modder like they've done before on a contract basis and have them work on that aspect of the game directly. Modder gets paid for work and SQUAD gets new integrated code. Of course this assumes SQUAD is even interested in integrating a feature made possible by a mod. Things are also a little different when you work with a plugin (which has to go through an API) and the core game code itself (far more direct processing).

One of 2 ways: Look at the graphs in the Performance Tab and if one of them is maxed out while KSP is actively running. In the Processes Tab, look for KSP and see of the Processor Percentage is always hitting 100% / # of CPU threads/Core (For you, should be 25%). Also, you can turn down all the graphics settings and see if KSP runs any better or not in a high part-count scenario. If no, then probably CPU-limited. The Debug Menu has an FPS graph you can check. Lastly, crank down the Physics Delta setting: @0.03, it will try to keep the game running at 33.2FPS or so. I have a [email protected] and an HD7990. Graphics isn't a real concern for me; it's the physics. (I recently bumped up to 32GB RAM because of mods; also run with DX11, which apparently is worth my GPU's RAM-size in memory savings... So I sorta have RAM overkill now...) Honestly, I probably want a CPU upgrade (DZ87KLT MB). Would need to find a K-series CPU though.

It's not that he needs it, it's more that he wants it there to shift the Center of Lift forward. A tight CoL (well main CoL; KSP sucks with showing detailed info due to lots of abstraction...) and CoM make aircraft more maneuverable, which is his goal. Unorthodox look, sure, but not all to different from Burt Rutan designs. Smaller carnard would LOOK nicer, but probably wouldn't give him the lift and therefore effects he's looking for. @Numerlor Glad that helped you. The swinging part is more pilot skill: landing level and not touching yaw or roll on touch down. I've screwed up landing by doing something stupid like trying to steer on touchdown because I'm a little misaligned. (It's better to just roll off the side of the runway...) On the other hand, you could just max out the dampener and spring settings on the gears. I find the stock gears are a bit "mushy" for their size. You have to balance the width as well: Narrow is easier landing/touchdown but more unstable (more likely to tip/roll over); wider is more stable handling on the ground, but you have to touchdown on-point and level or risk slamming down a side which can ruin your landing. (Again, you shouldn't be too far away from the CoM.) Personally, I'd probably place the gears about as wide as the intakes and no wider. (At most, as wide as the airbrakes.) It's a fairly light design for the lift you have, so you don't need gears that wide apart at all. (I guess a general rule of thumb could be the gears should be within the center third of the plane's width...?)

Your biggest landing issue is the fact your landing gear is so far from the Center of Mass of the vessel. The wheels at like a pivot/fulcrum when you land. If it's that far away from the CoM, the weight makes the vessel act like a giant lever, slamming the front down. (I'm guessing this is what your hard and bouncy landing probably look like.) Best thing to do is get the gears just behind the CoM (maybe just a little further than where you have the Center of Lift). Doing this will let the wheels take the brunt of the weight of the craft without torqueing so much on landing. At that point, you just need to adjust the springs and dampeners. Also, there is no such thing as "too low" a stall speed. The slower you can fly, the more lift the design has to work with. The more lift you can work with, the softer the landing can be. But yeah, first thing up: move those rear gears forward more. They're way too far back for comfortable landing. In Real Life, most aircraft have their main (weight-bearing) gears near the center of mass for a reason. (The nose-wheel is just for balancing and ground steering, really.) If you have problem with ground clearance (you're hitting the ground with the end of the plane), use bigger/taller gears. (The taller the gears, the further behind the CoM you should place them so they don't wind up ahead of the CoM on ground contact due to your Angle of Attack.) By the way, moving those rear gears forward will also make it easier to take-off...

I kinda imagine a slider that goes from zero to the max # of seats on the craft like the Engine slider... Though I'm not sure how easy it would be to add up all the seats from parts on the fly in the editor. TAC-LS if I recall adds EC usage for Kerbals as well (Environmental Controls), so it wouldn't just be one LS mod that needs support like that. (Unless this has changed in the newest version; memory is from my 1.0.5 days.)

Oh, then just use the GravityTurn mod WITH MJ: It has MJ integration for the final circularization burn at apoapsis. Totally automated other than the pre-launch set-up (which the current version tries to guess for you automatically now; override if you wish). Or something goes wrong... I'd be a little worried about that final stage though: it seems to be carrying a good portion of the launch dV. (I personally seem to prefer about 2000-2500m/s dV in my lower stages before a low-TWR orbital upper takes over for my launch profiles. A proper GT is under low TWR thrust at that point anyway.) TWR isn't TOO much of an issue so much as what the dV spread across those TWRs is. I generally feel a little uncomfortable unless my lowers can get me above about 40km (with a good trajectory) before my upper takes over. So yeah: Give the GT Mod a try. (See @DStaal's post for the link.) I found it far better/efficient than MJ's Ascent Guidance. (MJ's more brute force, GT is more finesse. I suppose the former is more Kerbal-ly.)

For the kind of TWR profile you have, I think it'd be better if you do a proper gravity turn (like the mod linked earlier) rather than using Mechjeb. I've been recently using high TWR rockets. I can't can get them to orbit manually using the same methodology that the GravityTurn mod uses: Throttle-limiting to maintain a time-to-apoapsis. MechJeb attempts to get you into a gravity-turn-like profile. In other words: GravityTurn controls the throttle, letting gravity naturally "pull down" your trajectory as needed. You just need to keep pointed pro-grade. (If you ever need to adjust pitch manually beyond the pitch-over, you did it wrong or your TWR is too low. I've done both...) MechJeb keeps the engine at 100%. You need to keep TWR reasonable for MechJeb to work well in my experience. Otherwise you need to tune MJ's profile to match the TWRs you have. GravityTurn itself has issues with unorthodox, high TWR, and/or non-throttling (SRB-heavy) designs. After watching and learning from GT, I can do the equivalent myself just about as well. (Just not quite as consistently.) I've been using high TWR designs lately mostly because I'm an impatient stand-up guy. Still, I can usually get into a 75km - 100km orbit using 3400m/s dV or less regularly. I've done this with a High-TWR Lower and Low-TWR Upper stage design. (I had to be a bit more aggressive with the lower stage's climb, I think, to make sure I had enough vertical speed for the low-TWR upper to have enough time to add on horizontal velocity.) GT tries to guess the pitch-over profile for you. Everything else is pretty straight forward. It can be guesswork, so I just fly manual gravity-turns now. I can usually get a feel for when and how hard I need to pitch over for a design. With MechJeb, since it keeps the throttle at 100%, you get a much steeper climb in the middle section if the TWR is too high. It won't adjust the throttle until you high your target predicted apoapsis height. (MJ is Full/Off only for engines.) Judging from that video you posted, that sees to be the problem you have. I've had the same problem as well with some of my designs and MJ. (Back in 1.0.5... I've long since stopped using MJ for ascent control; MJ was too much abstract guesswork for me in tuning the profile for each launch.) Try flying the rocket manually and keeping the time to apoapsis somewhere between 40-60 secs by adjusting the throttle on-the-fly. How quickly and aggressively you pitch over is dependent on your TWR. With >2 TWR, you can be fairly aggressive. The low TWR on the last stage may require you to have a steeper climb depending on when you ditch the stages.

Feature Request: Time to Charge from Empty - Part of the main FuseBox window. Basically battery life in reverse. So if you're making excess power, this will display ("Full in Y time"). If you're in a deficit, the normal life-time will display ("Zero in X time"). This will go hand-in-hand with... Orbital Period - Part of the Darkness Time window. Knowing the both the Dark and Orbital time along with the above will let a player tune solar power panel requirements JUST right if they want. (I have a orbital period of A with B dark time. I need a max full charging time of A-B.) Not very important (I dunno how many players would tune a vessel to that level of precision), but I figure it might be handy, non-intrusive info to have. (One "toggles" automatically while the other adds an extra line to a sub-window with 5 lines.) I play with ScanSAT and RemoteTech, so I think it could be useful when designing purposed-made, tuned satellites for a particular body. Obviously, not urgent to implement. Dunno if the coding would be any worse or not. It looks straight forward enough (but I know something that looks easy may not be in the end.) Something for KSP 1.3 I suppose.

I don't blame you. Those are some complex models you made for them with all the mesh switching available. I love the Octos, as they're the most versatile. I WANT to use the Hexes, but not much goes with them aesthetically. (I wish they has fuel switching like the Octos. Speaking of which...) I know this is definitely asking a lot from you, but any plans/thoughts on adding fuel switching options to the rest of the trusses? I frequently find myself wanting the 2 smallest Octos to have fuel in them (I wanted to use them as the main body for landers/satellite/probes). I know I can make them hollow, bit no mod out there has parts that fit just right in them and/or doesn't look right. (The closest I can get is FTP's short tanks, but they don't fit right without some adjusting; wind up with overlapping frames since both of you use the same semi-standardized heights/lengths.) I'm not really expecting you to do this considering the model complexity. (You had some patience and tenacity there. ) I'm just curious.

I've been designing space stations as of late. One thing I try to do with them is give them proper self-illumination so I can actually see them at night. (I have plenty of mods and one of them make night-time in space pretty dark...) My first station is over 200 parts and counting (still missing a few nodes.) I think about 20% of the part count is just lights and RCS ports. I just realized the lights and RCS are physics-less. Does that affect the physics processing KSP does since the mass and drag are just added to the parent part? I'd like to think it makes it a little easier, but this is KSP: I can't assume the best case scenario regarding how it does things. I'm asking because the surface lights from B9 aren't physics-less. I like their looks, so I tend to spam them a bit on my designs (spaceplanes especially.) I'm thinking of using them on my next station, a small-medium fuel depot. This one is a bit more practical at about 75 parts for better loading and processing. But I realize about 18 parts are already just lights. So does PhysicsSignificance help with physics processing & frame-rates to any degree or is it purely based on part count? (The >200-part station is now chugging along at about half real-time now.) It if leans towards part count, I'll probably redesign the fuel depot to use Stack Inline Lights for lighting. (And/or saying screw it and launch it as one vessel rather than building it modularly; those docking ports add up...) EDIT: Then could you clarify the MET color indications? Could a yellow indicator be cause by an overworked GPU? For the record, I'm on an i7-4771 @ 3.5GHz w/ 16GB RAM & an AMD HD7990. My game runs slowly (less than real-time) but is playable (not choppy at all) with the >200-part station. I just took at look at the station with the Debug Menu's Performance graph. Says I'm running at 21FPS, but movement and camera control is quite smooth and even (other than the stutter from GCing every few minutes.) I'm guessing the 21FPS is more physics frames processed than visual frames rendered/displayed? 21 Physics FPS seems to jive with the approximately half real-time rate I was guessing at. Oh, this was with nearly max graphics settings other than Texture Quality (Half) and ground scatters (Off) and with forced DX11 in this case (trying to save on RAM; had Out of Memory crashes as of late from editing the station). I think my Physics Delta in the settings is 0.04... EDIT2: Huh... I just my Physics Delta. I was at 0.05 for 21FPS. I tried it out with extreme settings and got: 33.2FPS @ 0.03 (consistent and smooth) ~10FPS @ 0.12 (choppy & stutters between 8-11FPS) I never did quite understand how Physics Delta worked. I did notice that the frame rates I wound up at equal 1/Physics Delta though. Is that setting effectively a "minimum frame rate" setting or something?

It's not magic. ALG was eventually picked up by KF when BahamutoD left KSP modding due to real life. I believe they were given access to the original assets to make the wheels. You have to completely re-rig the models themselves to make them work in KSP. Pretty much anyone touching wheels/legs in KSP either had to do a lot of work to get to work in 1.1.x and up (Necrobones' LET mod comes to mind), just flat out gave up (K.A.X.), or have postponed any updates (I'm not sure what M2X will do about the MK2 landing legs it used to have.) You'd need a modeler to get the modle in order before you can do anything with plug-ins (as far as I know, KF/KSPWheel is not a drop-in replacement for anything. And even if it were the Unity4 to 5 update broke everything about wheels, so you need a re-rig regardless.) And the ALG from KF is a LITTLE quirky. (Mirroring is a little odd in regards to directions of the wheel motors: one of them apparently needs to be inverted. And the mounts backwards by default compared to what I'm used to from the original ALG.) Still, I'm glad to have them back. Stock gears are kinda fugly. (Though I do kinda miss the old stock small gear.)

Update on my station - About 80-85% done: More with the updated album: http://imgur.com/a/q34k0 Yay for modular construction: I'm dropping 2 nodes (one of two labs and a docking port extension) as this sucker is over 200 parts already (excluding the shuttle that happens to be there in the above shot...) I'm now running at about half real-time with the station loaded and it takes a bit to actually load once in physics range (about 30s it feels like.) But this thread reminded me, so I'll still be added (at least) three more nodes (Science experiments, "advance" comms, and at least one dedicated engine node for moving the station if I felt like it....) EDIT: @SQUAD @Badie See spoiler-

...I'm an idiot. I completely forgot about the patches you included. I guess I could just rig the patch to duplicate the engines so I can pick either type in the editor. Looking forward to your next release. NF Solar and Spacecraft are looking s-e-x-y there. I think of all the modders around, I like your modeling and texture work the best overall. Your efforts and dedication are much appreciated! Your Octo parts from NFC made me want to seriously build a space station for once, especially now that KSP can handle high part counts far better. Though I'm still crashing my game due to low RAM. I've been considering moving to 32GB from my current 16GB, but it means replacing all my RAM modules... BTW, small little thing if/when you get to NFConstruction: the red & blue wire on the 5m-3.75m truss adapter are reversed compared to the trusses themselves. Is this intentional? (Looks like the wires crossover at the junction.) EDIT: So I went and checked... Where is this LFO patch for the NFSpacecraft orbital engines? I have v0.6.3 and I don't see an "extras" folder like you normally have in your other mods (and originally mentioned). ... Never mind. Found it on Github. (v0.6.4?)

Here is my WIP station. First real station I've attempted: Made mainly with @Nertea parts. (I love his work.) I have plans for a pure fuel depot later one after I get this complete or get tired of it. (I have 10 more pieces to add...)

I know what you mean. In actuality, my inspiration came from an odd mix of Universal Storage System's Alkaline Fuel Cell part (gaseous H2 + O2 > H2O + EC) and NFE's capacitors (denser EC storage with limits on charge/discharge rates.) USS didn't conform to stock resources. If anything, I could see someone making an NF-compatibility for USS (H2 > LH2, O2 > Oxidizer; dunno about the water.) Anyway, I just kinda wanted a closed-cycle Fuel Cell loop of some sort for high-density energy storage. I'd used NFE's capacitors, but I sorta want a more hands-off system. My experience with the capacitors date back to 1.0.5, though. I should probably try them out in 1.2.x now before commenting too much. I just recall not being able to leave capacitors to charge/discharge on their own and that they weren't rated-limited like fuel cells can be (i.e. Fuel Cells can output only as much as needed; capacitors were all-or-nothing). If you could take a capacitor and use two ModuleFuelCell modules to let you convert StoredCharge and EC back and forth automatically... (I'm not sure what ModuleFuelCell is allowed to convert in terms of resources.)

I wish I knew about this beforehand (like 12-16 hours ago from this posting...) It would've made my efforts SO much easier. @Alshain If you interested, you can look at my MM cfg: It's fairing-related stuff I made independently of your CFGs. Same things, but with annotations and 2 extra features: Max Section Lengths and making sure all nodes are technically hidden (though perhaps unneeded?). Explanations are in the cfg if you care to take a look.

Dammit! I wish I know about that like 12 hours ago! It would've made making my own fairing mm cfg a cinch! (Of which I already pushed out as an all-in-one patch with notes. ) *sigh* I need to search better...

You know how we now have a mode selection for reaction wheels (Full, SAS, Pilot)? Could we get something similar for RCS controls that can cycle through functionality (Full, Translation, Rotation) and be Action Group'ed? Generally speaking, thanks to the power of Reaction Wheels in KSP, I use RCS mainly for translation (docking and fine orbital adjustments) and rarely for attitude/rotation control. (For the latter, it'd have to be one heavy craft with relatively weak RW power, I'm in a rush to change attitude for some reason, I need supplemental control because my control surface aren't as effective in the current situation, or I'm controlling a VTOL.) I'm actually trying to build my first ever space station and I find it tedious to turn RCS on/off depending if I need translation or rotation. Yes, I know I can set the individual degree of control, but I'm not doing that for three degrees across 2 dozen or so RCS ports because my dumbass forgot to do that in the editor. (Even doing it in the editor could be tedious since I can't just click on one button to swap modes - it's four: one to show the open option to do so and one each for roll, yaw & pitch.) It's just a quality-of-life thing. Nothing urgent, but if RWs got something similar, why not RCS as well? (Kinda wonder if RCS should also get the Full-/SAS-/Pilot-control option as well since RCS is sorta tied to SAS in a way, like RWs.) In the meantime, I need to make a MM cfg that sets RCS ports to only translation mode by default...

No idea. I imagine it'd be up to a SQUAD dev to look at a mod's code to see how the functionality is implemented. Other features from plug-in based mods have been incorporated before, so there's a possibility. How easily is another matter.

Just to let you know, if you use Atmosphere Autopilot, it fixes one problem with the SAS system in stock: it unlinks the axes from each other. My biggest gripe about the stock SAS is that with it engaged, ANY player input overrides ALL the SAS commands. So SAS can be holding pitch for you. Your craft can be rolled a bit and you want to level out. You inputting roll-only commands for some reason turns off the current SAS hold-pitch inputs. So now you're rolling manually while pitching down unless you input some pitch as well. You may or may not have to add yaw input as well. It's an absurd system that made fine-tuning attitude nearly impossible without mods to compensate (Pilot Assistant being the primary one I used until I found AA; using both now.) Anyway, isolating the axes for SAS goes a way to solving the wobble-after-input problem. (It's be only one axis you need to fight, not possibly all three.) Another thing that may help is limiting max control surface deflection (or deflection speed?) based on dynamic pressure. (Dynamic Deflection does the former.) I would still find the method mentioned here useful as well. It does sound kinda dumb using only an absolute zero-point (no trim control) rather than a relative zero-point (trim-based SAS). As I mentioned, all the axes are "linked": SAS is all or nothing in stock. Either it has full control of your craft or you are in control. So trying to correct just one axis manually (say, yaw) makes SAS disengage completely until there is no more user input. This means if it was holding pitch, it's not anymore. Second, it's use of control surfaces is also all-or-nothing for the most part. SAS is basically coded to change attitude as quickly as possible, screw efficiency, from what I've experienced. As such, it's pretty aggressive and coarse with adjustments. This can be havoc on controls depending on control surface area, atmospheric density, and speed. Fine Control mode mitigates this a little bit, but it depends on how fine you want your deflection rates to be. (A example situation could be landing a plane: you may want pretty fine controls during the terminal stage just a little before touch-down.) I'm fine with stock SAS in space (for the most part...), but in atmosphere could use some work. On the other hand, mods have more or less corrected that, both in atmosphere (AA, PA, DD) and in space (MechJeb).

I've actually been contemplating a part that uses H2/O2 (gaseous forms) to make water and EC and then being able to convert that water back into H2/O2 with more EC. Basically FuelCell meets NFE's Capacitors meets Resource Converter. LH2/LOX could work, but the converter side would need to suck down more power than the FuelCell side produces and pump out a bit of heat you'd need to reject to simulate the cryogenic process. I was thinking of just doing an MM config using assets from stock for myself, but I don't know what numbers would be reasonable/balanced to use for the conversions. Especially since it's non-stock resources. Anyway... @Nertea I see you're starting to deprecate parts from your packs for newer ones you're creating to replace them. Any chance of legacy packs ("Legacy Packs - Unsupported"), either from you yourself or from someone else? (Kinda like how the OPT mod was split up when the dev was finally able to come back.) I really like your parts in general. (I already miss the low-profile LFO engine from NFSpacecraft.) Your assets are under ARR licensing, so I have to ask. (Otherwise, I need to start collecting older versions of your mods for my personal use, before parts are gone gone.)