ferram4

@darcgekco: It models them as elliptical frustums based on the approximate shape of the mesh, using attach node sizes to properly handle the very blunt sections at either end. @junkie_business: There are a few errors that I see in there, particularly caused by and out-of-date ExsurgentEngineering. I don't know if that's causing problems down the road or not, but it is breaking some MJ stuff. I'm not sure what ModuleDataTransmitter belongs to, but that's breaking too. Then (what I think you're talking about) involves the game losing track of the GPU for some reason, which i've only seen happen when someone alt-tabs. If that's the case, try updating your drivers and see if that works. I've never seen anything like this happen. @a__gun: Handling animating parts properly is in the "things to do" category. I've had some issues getting the mesh detection to work properly for some of these things.

If all of those parts were amalgamated into one single part, yes. Even if they weren't wings the simple fact that they are lots of tiny little plates facing every which way would confuse FAR about what it should do. FAR is built around assumptions about the general shape of the parts, most of which can be modeled as an elliptical frustum; something like that completely violates those assumptions and thus all the calculations will be garbage. There's really not much I can do to fix things like that right now. Either have approximate aerodynamics with limitations on what you can do in real time, have accurate aerodynamics with no limits on what you can do but take hours of time processing it, or you can have stock "aerodynamics."

Well, how do you lose control? If it flips out after going subsonic, you need to either fly at a lower angle of attack (you're stalling) or shift the CoM forward / shift the aerodynamic center back, since it's becoming unstable. If you just can't get it to pull up on the final approach, you're probably bleeding off too much speed before trying to land, which means that you need to take a more aggressive descent path.

@Agathorn: FAR source code is included in the download, in the source folder. If you're going to look into working things out, try not to make any changes to most of the code, since I've been merging a lot of optimizations from a.g. into what's there. @Swifty: Did you build and test the craft during one session, then cause the issue during another session? If so, did you install any other mods between these sessions? It might be caused by some type of mod breaking something. I was not able to recreate the issue, and access is restricted to the craft you posted. I suspect that you added a mod that caused either FAR to break when you were initially designing it or you added a mod that caused it to break when you added the payload. @junkie_business: Those shouldn't cause any issues, and I'd suspect another mod. Anyway, post a copy of your output_log.txt after causing the issue again and we'll see if that points anywhere.

I know that, but perhaps it's messing up since it's at a different height than the surrounding terrain.

There's another land section one that you need to set so that the surrounding terrain is correct. I think it's the map decal tangent one.

It doesn't, but I'll see if there's an efficient and easy way for me to make some of the stuff in Flight Data available.

*shrug* I dunno yet. NathanKell might have some idea, but I don't know what's actually changed and how to fix it.

That's because previously something was breaking the clamp's connection to the ground before resetting it, which seemed to help with the reposition on load issue. Now that isn't happening anymore, so the clamps add stress to the ship.

You should try messing with the height through the reposition radial setting to see if you can fix it.

I'll be happy to help you out with the orbital decay drag, which shouldn't be too difficult, since free-molecular flow works out to be pretty simple to solve. I'll probably also pick your brain on compiling some stuff in C++, since I've never managed a project that involves two different languages at the same time and I'd like to optimize some more things in FAR.

Make sure that you're using Deadly Reentry Continued v4.3 instead of the old Deadly Reentry v2.0. If that doesn't fix your issue there's really not much that I can do, since I haven't run into this issue since many DRC updates ago.

Twitchiness using SAS is to be expected, since SAS is designed for somewhat low control authority vehicles and with FAR aerodynamic control surfaces can give you a lot of control authority (particularly in roll). If you're managing to get wobble with FAR's flight assistance, then you've got way too much in the way of control surfaces that can act on that control axis; you may want to use tweakables to reduce their maximum deflection or the axes they act on. If your plane isn't capable of holding level, odds are that you just went from subsonic flight to supersonic flight. The aerodynamic center (CoL, using a more proper term) sits a further back in supersonic flow compared to subsonic flow, so that means that you'll either need to make the plane less stable or add a lot more control authority to keep it level in supersonic flight. Generally, trying to maintain level flight around Mach 0.95 - Mach 1.1 is not really a good idea, you should go a little bit slower or just go faster.

@SnappingTurtle: I think you're correct. I'll look into fixing that. @Boamere: That gets printed to the output_log when you ALT-TAB out of the game. Your lag is probably due to too many mods or a very underpowered computer.

No, it doesn't look as insane as a Whackjob rocket. It looks like I'll need to add a few F-1s or RS-27As as liquid verniers for the first stage; it's not very controllable.

HoneyFox is correct. It's a giant tank (10m x 15m) filled with Aerozine, NTO, Hydrazine, and batteries. I worked out a config for the M-1 hydrolox engine, which is somewhat necessary to make this work. First stage has to be SRMs to get it going, I can't get enough thrust without too many liquid engines. Current design has a single giant SRM as the first stage, 13 M-1s on the second stage (which weighs as much as a Saturn V) and 3 M-1s on the third stage. I'm thinking I'm going to split the first stage into multiple SRMs for aesthetic reasons, since that giant nozzle disturbs me, and to see if I can do some parallel staging there, since that single SRM is 2000 t dry, not counting the interstage on top of it. @NathanKell: Well, it looks like Manhattan doesn't exist either, and Long Island isn't an island either. Oh well, not much that we can do about that then. Edit: Any suggestions on what I should name this thing?

Oh, I can't wait to see what the land around New York looks like with this. Does Staten Island actually exist, or have we been forgotten again?

I have been, but not in my most recent launches (ultra-heavy payloads, working on 1,000 tonne to LEO) and I have to get the most recent updates to the pack and Scripto's changes. The only issues that I can see remaining would be the second stage engine if the interstage doesn't shield it properly and aerodynamics affecting stuff in the trunk, but the latter can be fixed with an additional title specification in the FAR config (I'll look at making it standard for FAR). Oh, and I think the solar panel covers might not shield the panels, which is something to check.

@NathanKell: That sounds awesome! If you're going to take suggestions for preset launch sites, I'd suggest the planned SpaceX private launch site located in Boca Chica Village, TX. The coordinates are 25°59′29″N 97°11′1″W and it's right at the southeast corner of Texas along the gulf. I'm working out a Falcon Heavy launch of a space station module with full re-usability, and having the option to land the core downrange at The Cape rather than in Texas might help boost the payload mass a bit.

@Boamere: I have not been able to reproduce your issue using just KJR. I suspect it is another mod; uninstall them one by one until you find the issue. As KJR does not change the CoM of any parts under any circumstances, nor does it cause any exceptions during loading that could cause this issue, KJR is incapable of causing that issue. You will have to ensure that your mods are up-to-date and that you have followed all the instructions to the letter installing them / updating them. I cannot help you with this. @hippomormor: You probably have a ship with a very large number of stretchy tanks and decouplers. There was demand for super extra stiffening for stretchy tanks, and the lag in v1.7 is the result of the physics calculations necessary for that. Part of the g-force issues with the experimentals is the issues involved in starting up the simulation and the fact that DR doesn't wait a bit after loading before checking g-forces.

@darcgekco: No. That would require completely rewriting the procedural wing code on DYJ's side, since that's where it's applying the wing properties. @MR4Y: SAS is closed off to me and pretty much every other modder, so there's nothing I can do. The thing I can do is set all the default deflection limits to very low numbers (~3-4 degrees) so that when people build a plane with a stock-standard number of control surfaces for what it is they'll end up with something controllable. There's really nothing I can do for bad design though.

You have even less yaw stability than I thought. You need a vertical tail almost 3 times as large to deal with the effects of wings that big.

You have virtually no yaw stability with that. The AV-R8 isn't enough vertical tail for those wings unless you've got it on a tail boom that's as long as the rest of the plane.

There's also a possibility that he has very swept wings. The slight change in sweep angle caused by sideslip could cause enough difference in lift between the wings if the sweep angles are high enough.

@Hyomoto: I can look into possibly adding some RPM support, but I have no experience with it at all. I actually haven't gotten around to playing with it since I'm very selective in the mods that I install. I hope that Mihara's code allows for easy implementation of 3rd-party stuff. @MaverickSawyer: Well, dihedral produces a rolling tendency when the plane sideslips, which tends to help make a plane stable in roll because when the plane is rolled to one side gravity induces some amount of sideslip. Dihedral can make things less stable if it's highly pronounced compared to the amount of yaw stability a plane has, which is a common occurrence in KSP since people tend to put half-hearted vertical tails on their planes in this game. It's generally better to go with polyhedral wings for most designs, which allows you to have more control over the magnitude of dihedral effects. There's a very sweet spot of roll stability relative to yaw stability. Too much of roll stability and you get dutch rolling motions that take a long time to damp out or end up being unstable, causing lots of yawing and occasionally rolling issues. Too much yaw stability and the plane ends up having an unstable spiral mode, which basically means that the plane starts to roll one way or the other and keeps rolling that way; it causes lots of crashes for pilots unfamiliar with using instruments to fly in bad conditions, because they don't realize that they're banked 70 degrees until they crash. Generally you err on the side of making the spiral mode slightly unstable and focus on a well-behaved dutch roll mode since it's easier for the pilot to correct for a non-oscillatory motion than an oscillatory motion.