m4ti140

Well, guess what you can build now

If I may suggest something - if you're going to do the split-rudder airbrake, split the vertical stabilizer and the two halves of the rudder into 3 separate parts, so that it can be easily made FAR compatible.

IMO they should just make KSP2, but with a custom made engine and more exploration content

@neistridlar Thank you sir, you are a legend. I'm gonna leave a link to your post here, in case someone else is looking for it.

So... I made a Concorde replica to check out the droop snoot cockpit in its natural habitat, and noticed a couple issues in process: 1. Toggling droop snoot summons Kraken. He's fairly lenient in its wrath but definitely there: firstly, any post processing graphical mods that I have (scatterer, EVE) skip a frame exactly three times in roughly one second intervals. Secondly, the IVA spazzes out during transition, teleporting above and rotating backwards, and remains like this until I switch to exterior and back to interior. 2 . The 2m passenger door parts produce ungodly amounts of drag. Not by themselves mind you, they themselves receive proper drag forces. However the game behaves as if they just weren't there, applying end-of-fuselage drag to both parts neigboring it. I measured the aero forces on individual parts and the surounding fuselage sections behave as if they were facing the airstream, not the interior of the door section. Until I removed all 3 door sections replacing them with an additional passenger section and a fuel tank, I couldn't break Mach .9 on reheat. Removing two of them allowed me to barely cross the sound barrier and after removing all I could suddenly do Mach 2.5 on half throttle... If this is caused by the same bug in the stock game that originally caused the 5m fairing to act like a parachute and the interstage fairings to produce more drag than if the sections were unshielded, then it should be reported to Squad, cause it's pretty game breaking. If it isn't, then maybe the drag cubes are actually too small, causing the game to treat those sections like discontinuities in the fuselage.

Is Cormorant Aeronology allowed?

The links for KK docks and launchpoints are dead (404 on DB)

Are you using the MH launchsite selection system, or is it still the old KK one? Will it conflict if I have MH installed? EDIT: Nevermind, I can see you do now.

May I ask how? Can it be done through configs, or is a custom plugin needed?

I have no idea what you're talking about, but I'm pretty sure I'm not doing this.

Am I the only one for whom the loading tends to hang at "DialogPlain.fnt" for a few minutes with this mod installed?

@Kurbalizer It's "deSSert". Don't forget what game you are playing Also the Dessert Runway IMO should be put into a separate config file that is only used when MH is installed

KSP version: 1.4.3 64bit (win10) non-steam Issue: As of this version all Direct Input devices (like literally every single joystick/hotas on the market) have horrendous input lag, which gets worse with low fps. At stable 60fps it's around 0.2-0.5s, but at low FPS and high CPU load (with high part counts and/or graphics mods) it grows to as high as 1s and above, making analog input absolutely useless. Both keyboard input and xinput devices (x360 pad) are unaffected, the reaction is instantaneous regardless of FPS. Log: https://1drv.ms/t/s!ArMDWm49dN3Cgb0No1fRmIdnvzYd4Q Specs: MSI GE62 6QC: i7-6700HQ @2.6-3.3GHz, HD Graphics 530/GTX 960M (Optimus), 16GB RAM, Samsung 960 Evo 250GB SSD/1TB HDD, https://1drv.ms/t/s!ArMDWm49dN3Cgb0No1fRmIdnvzYd4Q Fresh install

I did more testing, the phantom forces were indeed due to IR

Some of this stuff looks almost essential, hard to believe no one thought about this until now. This is going to change EVA gameplay a lot.

@Pak Just a small suggestion: Could you remove the space from the root folder name (and related paths in cfg files)? It screws badly with Module Manager.

I actually checked that when the issue happened, and there was no autostrut connected directly to the arm. Here's the entire log, up to the point Kraken devoured the Universe, in case the issue is with IR after all and it unfixed some bug with landing gear that Squad has already taken care of in stock: https://1drv.ms/u/s!ArMDWm49dN3Cgb0I5QvDLMMj6Mvt1A There are tons of the following lines spammed before the NullRef spam at the end, this is where the game implodes: [ERR 20:23:17.371] Infinity or NaN floating point numbers appear when calculating the transform matrix for a Collider. Scene hierarchy path "GearSmall/model/Squad/Parts/Wheel/LandingGear/GearMedium(Clone)/Medium/prong/WheelRetract/WheelRetractCollider" and this one: [ERR 20:23:30.151] Infinity or NaN floating point numbers appear when calculating the transform matrix for a Collider. Scene hierarchy path "mk3CargoBayL/model/Squad/Parts/Utility/mk3CargoBay/long(Clone)/BayDoor1/ColDoor 1" Not entirely sure if it's a stock bug at this point, gonna test later without the arm again, though I'm certain I didn't see the bug before I started playing with IR

Hello, I noticed there are some significant phantom forces present when using servo locks. I'm currently running an STS-88 recreation and I start the flight with all servos locked in the RMS for transport (the RMS is built exactly like the real thing, with the same joint types). After orbit insertion I noticed growing phantom forces that eventually caused my craft to accelerate, raising its orbit at a high rate (apoapsis rising by >100m/s at some point), and slowly begin spinning towards the port(~0.1 rpm/s), where the arm was installed. Unlocking all servos reduced the severity of the phantom forces by orders of magnitude, although some residual forces were still present. I am using persistent rotation, but disabling it didn't solve the issue (though it might have caused it, I don't know). Note that I was in a 45 deg inclined orbit, in case that matters. Here's my craft file and log. The craft requires Cormorant Aeronology and Tweakscale in addition to IR, and might require Kerbalism, as it was created with it installed. https://1drv.ms/u/s!ArMDWm49dN3Cgb0KQvGWolTYMYmHSQ EDIT: This might have not been directly related after all, I've just got a NaN error pointing to a landing gear collider and krakened the hell out...

One other thing I'd like to point out: area ruling is not that important for airliners that cruise below Mach 0.7, as wave drag is still minimal, but it is for faster (0.75-.85) ones, these use supercritical airfoils in wings too, and use anti-shock bodies to preserve area ruling in wing section. In fact dedicated anti-shock body parts (preferably tweakscale compatible), separate from both wings and control surfaces are something I would love to see in an airliner mod, as those are perfectly functional and do serve their purpose with FAR, allowing the player to fine tune area ruling. So yeah, you want fuselage parts to be area ruled (smooth changes of total cross-section, as in with empennage cross-section included) and for the wings it doesn't really matter that much - giving them supercritical airfoils would look cool nice and add realism, but it might be a pain to model and it doesn't matter from gameplay point of view, as neither stock nor FAR cares about actual airfoil geometry when dealing with wings.

Then GDJ's post makes no sense to me, because that's a supercritical airfoil, this is not how you design trailing end of a fuselage, you just maintain area ruling while smoothly reducing total cross-section towards the end (rather than suddenly cutting it off into free airstream, you only do that in aircraft with a tail nozzle)

That's a supercritical wing airfoil, it's cambered. Empennage airfoils are symmetric, even the supercritical ones. @neistridlar I can do some testing once FAR is out (or at least in beta) for 1.4+. As for actual effectiveness of modelling an actual transonic airfoil, I have my doubts: FAR doesn't care about the airfoil for lift and induced drag computations, and for form/wave drag the feature size is too small to detect here, unless you set your voxelization resolution crazy high (which will slow down the game). Also I'm not sure if FAR doesn't calculate wave drag within the lifting surface module for wings, in which case, again, the actual part geometry won't matter. If the actual airfoil used for computations was somehow taken from the geometry, all stock wings would be useless. For the same reason, if and when Ferram releases overhauled wing system with ability to use custom airfoils, it will probably remain decoupled.

While you're still at this stage: Please, PLEASE, for the love of Krakensbane, do not integrate control surfaces into lifting surfaces they're part of, keep static surfaces and control surfaces as separate parts, integrating them makes them almost impossible to use with FAR. Thanks.

@Drew Kerman Basically what @li7in6 said, the trim in most real aircraft works exactly the same as in game: the neutral position is shifted, but it doesn't change the range of the control surface. In airliners, the entire stabilizer assembly changes its angle of incidence to trim, which allows the elevator range to be retained. I suppose that's what you mean by "AoA tweakable", but to get this out of the way, because I''m not sure if you understand what AoA is based on your post: Angle of Attack is not a property of the wing, it's not included in FAR configs at all and it can't bee controlled by FAR. AoA is the physical angle between the airflow velocity vector in far field and the longest chord of the lifting surface. You can't change the AoA of a part with a tweakable slider, the AoA depends on your aircraft's pitch and in order to change it without changing pitch you have to physically rotate the wing part along its span relative to the rest of the aircraft(in which case it's better to refer to it as Angle of Incidence not Angle of Attack). So to do what you're trying to do (i.e., if I understand correctly, an airliner style all-moving elevator trim) you have to use Infernal Robotics. The way I do it when I make airliners in KSP is to simply attach the horizontal stabilizers to the tail through rotatrons and then offset the rotatrons inside the fuselage so they don't stick out, and offset the stabilizers away from them to align them with the fuselage. Finally I invert one of the rotatrons (otherwise they're going to rotate in opposite directions when you trim), set the range to something reasonable for an airliner (e.g. for 737 it's 17 degrees from full nose down to full nose up), put them both in a single group and assign the group to keys I want to use for trim (the RCS translation keys are good for this purpose, since you're not going to use them anyway in an airliner). It's also a good idea to limit the speed to something realistic, like 0.2-0.3 deg/s. You can also use kOS to automatically trim when you deflect the stick beyond a certain value without any keystrokes, as kOS features direct support for IR - tested and it works marvellously.

Hmm... I've got the same graphics card and an i7 on my laptop, and I get pretty good performance with EVE+Scatterer. The current stable release of EVE uses CPU to handle volumetric clouds, I wonder if you would get better framerates with Blackrack's EVE build/without EVE. Also the Optimus setups use regular system RAM when they run out of VRAM, shouldn't matter here but the thing is you can make those laptops handle higher texture resolutions by expanding regular RAM. Bottom line is, a 960M is more than capable of handling Scatterer alone (won't be as smooth as stock, but stable). Things get messy when EVE is involved. I'm clinically blind then, didn't realize that tint was just the galaxy in the background getting tinted.

I don't use DOE. Also I'm pretty sure Scatterer used to handle the night sky as well in the past, before new Unity broke things. Now it seems to simply disable itself, as otherwise the skybox is invisible.