ferram4

In addition to FAR and KJR stuff, I've got a few other in-game projects going, particularly in Real Solar System. One involves recreating the Molniya launch vehicle used for Soviet Molniya satellites and light lunar and interplanetary probes: And the frosty white sections actually are the LOX tanks; the fuel is distributed through the whole thing properly (I might have gone overboard on the recreation). Another involves sending 5000 tonnes of payload to LEO (so that's ~1.78 Saturn Vs) to see if I can. The Eotena, aka, "Whackjob's got nothing on this": It weighs more than a Nimitz at launch and sort of acts as a test subject for most of the KJR tweaks that I've been working on.

See, it's things like that that make actually publishing and supporting something like this worthwhile. I'm curious, what school is it that has professors that think that my mod is actually decent? Also, this is probably asking too much, but do any of them happen to have any connections in the aerospace industry? I've been trying to get an aero engineer job and haven't had much luck due to a lack of connections and networking; I figure them having some experience with my little project can't hurt, right?

10 or 15 degrees would cause lots of funky rolling motion at any speed; dihedral or anhedral is rarely more than 3-4 degrees in real life. Seriously, just put together a plane in KSP using wing parts in the configuration you're talking about and see how badly it flies. This hacky approach you're insisting on doing is not going to result in anything fun to fly. That said, if you are going to just do a curved wing like you're talking about the poor qualities you'll get out of it will be realistic, and FAR (and actually, the stock "aerodynamics" as well) will prove why curved wings like that aren't done in real life.

That would cause really, really funky things to happen in flight. With separate horizontal and vertical sections 2 degrees of sideslip at low speeds won't cause a lot of rolling; using a single angled section will cause lots of rolling. And that's with 5 seconds of thinking about it; there will be more issues, especially once you get into the supersonic stuff. Aerodynamics can't be added together like that, and there are a lot more complications than you think from doing things that way. This is a bad idea.

The best would be cuts at both points, since FAR is only able to simulate a wing for a part that is a flat plane; any other set up will have either the vertical fins doing nothing or the regular wings doing nothing. However he decides to do it, make sure that the part-forward vector is oriented perpendicular to the wing and that the part origin is at the center of the wing root, or FAR won't handle the aerodynamics correctly at all.

My main problem with the Mod Nexus is the fact that it has a mod manager; unlike most people here I really don't think that a mod manager is a good idea: It hides the mod "installation" from the user, which makes them less likely to have any idea of what to do if something happens to go wrong; they don't know what changed and what to delete or copy over to fix it, and it makes the mod "installation" out to be more complicated than the simple copying-over-of-folders that it is. It also means one more thing for modders to support. We already have to support our own mods, other people's mods (since bugs are mis-attributed when multiple mods are in use), and KSP itself (since some stock bugs are exacerbated by mod behavior). A mod manager of any kind will simply be one more thing that we have to support, since everyone will blame the mod author for a botched installation, not the author of a mod manager; it's even worse since Nexus has a 3rd party mod manager not even intended for KSP alone, which means there are likely to be more issues with it. If some type of issue comes up, I'll need to change my mod to get around whatever edge case in the manager it's hitting, even if it's otherwise perfect. Depending on how the mod manager handles dependencies (are they bundled with the mod download, or is the manager supposed to find and download all the dependencies?) users who don't want anything to do with the mod manager for security reasons or because their favorite mods have issues with it can end up having a much harder time dealing with the installation of mods that involve any kind of dependency. It basically pressures users into using software that they don't want to because the distribution standard punishes anyone who doesn't use the mod manager. And finally, it lowers the barrier to entry below the already stupidly low bar that it's currently at. Currently a mod user has to have a minimal understanding of how to navigate directories and move files around, which is pretty much Using a Computer 101. What happens when we have to deal with users who can't do that? Users who report bugs, but can't even be lead to the output_log.txt, or that treat programming more as some kind of magic voodoo that we just make happen rather than carefully figuring out how to make the computer do exactly what we want. It'll just give all of us more support trouble to deal with and there's no incentive on our end; it's not like any of us get paid by the download. Back on topic, I think that most of what Trueborn put down is good, but I'd ask that we get free control over what type of tags we set in the mod metadata. I'd like to be able to label FAR with "aerodynamics," "lift" and "drag" to help lead people who are looking for that type of mod to it.

No. It looks at the boundaries of the fairing parts and determines what is "inside" them once, and then waits until the vessel part list changes (indicating staging or breaking, which could cause the payload fairing to come off) for fairing parts. The issue is that the particular code module that runs in this case only updates whenever the vessel part list changes, which doesn't happen with this weird fairing opening and closing thing.

Because of the way the code is set up, either it's going to always shield the payload, regardless of whether it's open or closed or it's going to never shield the payload regardless of whether it's open or closed. There's no easy way for me to detect whether the fairing / cargo bay is open or closed with that system, so if I did attempt to make it work everyone would complain about how much it would make the game lag. So basically, if it does or doesn't, it's still going to not work correctly.

@GavinZac: That's probably not supposed to happen, but you'll get issues if you try to combine high g-forces with lots of little parts (SAS modules) squished between heavier parts (fuel tanks) there's really not much I can do there besides tell you that you need to place struts to send the force around the smaller parts rather than through them. @IonMage: What happens if you use no clamps? Does it still fail? If it doesn't then the issue is due to a stock bug with launch clamps that I've got a work-around in the works for. The 2nd vehicle where you're putting a tiny part in between two larger parts will cause issues for you since breakForces are partly based on the size of the part in KJR, and putting a much smaller part there will encourage more breakage. @Aedile: I don't know what you're talking about; I just flew almost all of the FAR example craft near Mach 1 at full pitch up and only had the g-forces peak around 6 or so on most of them, with higher g's only occurring from losing control. I'll need to know which craft was causing the issue, what you did exactly to cause it, and everything that was happening in game at the time. I also want to know what kind of framerate you're getting when this happens.

The only way that I can think of that would work is for me to create a new PartModule that exists only to feed in the proper parameters, which will hurt performance if it continues to exist or it will cause weird things to happen on reload if it deletes itself. Another option is to recode of the way that the FARBasicDragModel PartModule works so that the values can be fed in there, but I think that would also require me to work out a new KSPField thing to allow it to be easily loaded, and I don't know what that entails (and my only attempt with that went nowhere), and besides that it means more memory usage for each part since it's going to have to store the list of exempt attach nodes rather than working off of a global list. There are a lot of bad things that can happen with the recode that would be necessary for setting things up that way.

Hey frizzank, would you mind making a changing the nosecone and fairing attach node names to "connect" rather than "attach?" It turns out that most of the fairing mods (KW, AIES, pFairings) use that id for their fairing nodes, and the next version of FAR is going to have the ability to flag a particular type of attach node id as something to be ignored for blunt body drag calculations; re-naming the nodes will help prevent me from having to add another exemption and increasing the risk of false positives with other mods attach nodes. If you've got a good justification for leaving them as "attach," I'll just add another exemption, but at this moment I think it would be simpler for everyone if the change is on your end.

FAR is not compatible with PlanetFactory CE packs if and only if the pack maker is lazy and doesn't bother to set the flightGlobalsIndex (which is supposed to be a unique value) to a unique value for each planet. In that case, FAR isn't able to specify unique atmospheric properties for each planet and breaks. There is simply nothing that I can do to add compatibility in that situation short of removing unique atmospheric properties for each planet, and I'm unwilling to scrap an entire feature because a few modders are unwilling to do things the correct way. Simply put, the incompatibility is on the planet pack maker's side, not mine. That said, Alternis doesn't function the way PlanetFactory CE does, and so there is no way for FAR to conflict with that.

What does the connection look like? (read: post a picture of the problem craft) Does it move at all prior to breaking? How much mass is this connection trying to hold? Have you attached tons of struts every which way with reckless abandon (that can cause stress to be concentrated at weird points)? Without more information I can't help, since I know for a fact that 5-meter stretchy tanks hold for me.

There's two presets there that will do what you want, you just have to decide if you want a crazy nerf to efficiency in atmo only or if you want a more modest nerf everywhere. I think you might change your mind on it being cheaty once you try to launch something larger though. The difficulty curve scales up a lot more harshly with FAR aerodynamics than in stock.

The reason that the jets are 16 times as efficient as they should be (not 15) is that the jet engine burns 1 unit of fuel for every 15 units of intake air, both of which have the same density in this setup. Isp for jet engines is defined based on mass flow of fuel. The ModuleEngines and ModuleEnginesFX code defines Isp based on total mass flow through the engine. So due to the difference in the definition of Isp used in real life (which was also used for specifying the jet's Isps) and the definition of Isp used by the ModuleEngines code, the code is burning 1/16 the amount of fuel it should be burning, since it's counting the mass flow of air in the calculations even though that's supposed to be taken for granted. The error is due to the fact that the Isp numbers reported by the jet engines(stock at least) are bogus. They run off of a different definition of Isp than that used to rate air-breathing jet engines, and that's why the engines are more efficient than they should be.

That just controls whether the given thrust value is what the engine makes in vacuum or at sea level. For example, a vacuum rated engine that makes 60 kN of thrust will make 60 kN in vacuum and less in the atmosphere. One that is atmo-rated for 60 kN will make 60 kN on the pad and more in vacuum. The multipliers are still the same, it's just how the thrust is set. The cutoff is set based on the original Isp, not the adjusted Isp. Real adjusted is a sort of hacky way around that where the Isps are slightly higher to account for the fact that the dry masses of engines and fuel tanks is higher than it should be. If you use real adjusted you don't need to make any more changes to get realistic-ish behavior; if you use real raw then you need to make those mass changes.

Well, there's also a well-known and well-publicized typo in the FAR config that prevents the turbojet from ever running out of thrust. So basically until you adjust that (the fix is fairly easy to search for) you're working with utterly broken and cheaty turbojets. This sort of thing has come up enough that I'm tempted to push the not-ready FAR v0.13 out the door just to get the fix out there so I can stop hearing about how FAR lets people do such crazy things with their jets and spaceplanes.

If it's hollow and stuff is supposed to go inside it, make sure that it has "fairing" or "shroud" somewhere in its title. Make sure there is only one attach node at the center of the base, and make sure that the part's radius / 1.25 is the same as the size of that attach node. It should work fine to start with; FAR automatically detects the shape and applies the proper drag to parts unless a modder tries something clever, i.e. their parts are set up distinctly differently than the stock parts in terms of where the origin is relative to the model, where attach nodes are placed, what sizes the attach nodes have, etc.

I'll chime in and agree with what Blizzy has suggested for each mod, especially the no commenting bit. Creating another place for support requests to appear is a pain, since for FAR I already need to check the FAR release thread, the Addon Support forum and r/KSP and r/KerbalAcademy, and then the Spaceport comment section if I remember (normally I don't, and normally comments don't appear there). Having the option to comment there will just frustrate everyone (users don't get timely support, modders have another place to look).

You're using the stock-alike config, right? You are looking for stock-like performance, correct?

Check the second post of this very thread. Pick one of the configs. Tada, all the engines work.

No, you don't need to. Besides, you should be running RealFuels if you're messing with RSS, which KIDS currently doesn't support.

If you truly want to make flying with FAR a pain, make sure to attach the fuel tanks sideways. I sideways fuel tank makes a ton more drag than one oriented into the flow. If you're feeling lazy, you can attach a bunch of sideways tanks at the bottom to make your rocket stable. If you're feeling enterprising, attach a bunch of sideways fuel tanks at the top to make it less stable. What kind of payload do you expect to send to LEO to make this work?

@Aedile: I've got a fix in the works for the adapter, since that shouldn't be happening. I just need to test the numbers a bit. @thorfinn: It's for all unattached nodes, forward and backward (not on sides though); they just use different values for front and back. The attach node drag on the back can be reduced by going into the config.xml and setting incompressibleRearDrag to 0.01 and additionalSonicRearDrag to 0.2, and then that will be at realistic levels.

Derp, I screwed up and left out the Kodiak Launch Complex on that list. I'll fix it.