ferram4

@qromodynmc: As far as the low rudder usage goes, that's primarily because the controller currently uses the rudder to reduce plane sideslip. It's fairly necessary given that high sideslip can cause planes to stall out very quickly, but WT adds some cheaty anti-stall behavior to their flight models to hide that in any mode where mouseaim is available. Also, pushing the rudder usage higher and reducing the roll rate would create the "nose rises rather than the plane turning" issue that plagues quite a few WT planes at higher speeds, which is something we really want to avoid. The controller will allow pitch-down, but it dislikes doing that, just like WT's mouse aim in RB. For most dogfighting conditions the controller is only going to pull a max of ~3 negative g before it tries to roll the plane instead. Considering that most planes are far better at pulling up than pushing down, this result in much better flight performance. If you absolutely need to pitch down, WASD will still override the controls, just like in WT.

Far, far more important than what mods you're using is reliable and complete reproduction steps. If those involve doing some complicated thing, then you might have found an actual bug and I'd like to know. If they don't, then you probably have an install error.

No it will not. In addition, 3.1.4 is aimed at v1.0.4/v1.0.5. I have no idea why CKAN is engaging in these shenanigans right now, and there's nothing I can do about it.

That sounds exactly like what Blackrack was complaining about. Try the dev build.

@blackrack, @SkyKaptn: If you guys want to try, I'd suggest grabbing the dev build and seeing if that fixes the issue. It might be a day or two before that gets released as a bugfix so I have some time to test and confirm that it works as well as get another issue squared away.

That bug was fixed quite a few FAR versions ago.

Well, then I don't know what the issue is. Without you personally making changes in-game, the Custom*.cfg files are the exact same as their non-custom equivalents. I have been unable to reproduce the issue.

There are no config files that need to be generated and then reloaded for anything to function correctly. I notice from your mod list that you are missing both ModuleManager and ModularFlightIntegrator; this will horribly break FAR. I suspect that is your issue.

https://github.com/ferram4/Ferram-Aerospace-Research/wiki/Deriving-FAR-values-for-a-wing-using-Blender-2.7 b_2 is the length from the wing root (where it attaches) to the wingtip, perpendicular to the wing root. MAC is the average of the wing root chord and wingtip chord. TaperRatio is the wingtip chord / wing root chord. MidChordSweep is the angle between the span line (same as measured for b_2) and a line drawn from the midpoint of the wing root chord to the midpoint of the wingtip chord in degrees. e is calculated internally by FAR, don't worry about it. nonSideAttach is for differentiating control surface parts intended to be attached to the back of wings from regular wing parts. Only set it to 1 for those types of control surfaces. maxDeflect is the total number of degrees that a control surface can deflect by default; this defaults to 20, don't set it higher than 40, and you don't even need to worry about it because it is tweakable. ctrlSurfFrac is the fraction of the surface that is a control surface for wing parts that are part unmoving wing, part control surface. Varies from 0 to 1. Best way to get these values is to open the models in blender and measure them.

1. that functionality was added by FAR. 2. That functionality is still implemented in FAR. Check to make sure that FAR was installed correctly. If that isn't showing up, it is likely that (for some reason) FAR did not install correctly, whether it be the mod itself or its dependencies.

@blackrack: I can't reproduce any high CPU usage issues; for me it hovers around 30-40% in flight and 15-25% in the space center view, and I'm using an i5-2540m on a laptop. Are you using a new save file with a new settings.cfg and physics.cfg in the KSP directory, or did you copy any of that over from the previous KSP version?

Previous version was 0.15.5.7. This is 0.15.6.

Whoops; knew I missed something. And now the contractually obligated error somewhere has been fixed. Thanks.

@lude: that means that you installed it incorrectly. I don't know what went wrong, but what did go wrong is that FAR did not load up properly at all if FARControllableSurface modules were not applied to stock surfaces. @ss8913: As I've said many times, CKAN is not my problem. If they're being incompetent or slow like they normally are, that's their job to deal with. This is what happens when you rely on unnecessary middlemen.

Alright, so FAR v0.15.6, "Jones" is officially out, with compatibility for KSP 1.1 and all that stuff. Today's codename is named after R.T. Jones, one of NACA / NASA's foremost aerodynamicists, famous for his work on swept, delta and oblique wing theory and research. In particular, he was one of (if not the first) to develop and promote swept wings within the U.S. for high speed flight, although it took the defeat of Germany and the capture of classified German aerodynamics research data at the end of WWII for his ideas to be fully accepted. Leading almost immediately to changes in the design of Boeing's new long-range bomber design, which quickly swapped its straight wings for swept ones, creating the B-47 Stratojet that is sadly somewhat overshadowed by the B-52 nowadays. Anyways, there aren't that many visible changes, only lots of under-the-hood ones for 1.1 compatibility. Oh, and win64 is no longer locked. Changelog does have the details.

And KJR v3.1.5 is now officially out, with 1.1 compatibility and all that good news. Win64 is also no longer locked on, but that isn't noted in the changelog because apparently there is some law of the universe that says that I need to forget to add something important to the changelog. Anyway, have fun.

I don't think the Tytonid pilots pulled enough aileron rolls. I am disappointed in them. I like how the only loss I took was Jeb panic-evading into the ground, I suppose I'll have to look into making that less likely to happen. I mean, it's realistic and is even a common occurrence in War Thunder, but it's frustrating when it happens. Also, nice editing with the music. It worked very well.

With FAR the CoL is shown as close to directly behind the CoM as possible. The vertical component of the CoL indicator has never had any meaning for forward flight, so FAR removed it to make it easier to get the rest of the meaning out of it.

There is one other case where it will drop throttle, and that's when it's already pretty screwed with another plane very close behind it and the only thing that it can hope to do is force and overshoot. If the plane is in that situation it's pretty dead no matter what unless its wingman comes in to save it. A lot of the favoring of turnfighters here is because the engines are still quite a bit more powerful than they should be. Thrust doesn't quite fall off fast enough with increasing speed, and the thrust on the runway is somewhere around 1.5x-2x what the very best WWII engines could put out... running on settings with either water or MW50 injection that the engines really aren't happy about maintaining for too much time.

For the supercharger settings there are only two curves, one which is a single-stage supercharger that has a crit alt around ~4.5km, and one which is a two-stage supercharger with crit alts around 1.5km and 6km and a crossover near 2km (I think). The main difference is that the single-stage will reach a lower altitude before its power starts to drop off, while the two-stage can reach a higher altitude before it finally completely runs out of breath, but it pays for it with a lower-altitude loss in power. And as for the plane designs and AI settings, you people are insane with your high settings. Seriously, your designs are all so much better than they're performing because they can't keep their guns on target. Which I suppose gives realistic hit numbers but not for the right reasons.

Note: First paragraph is on a somewhat different subject and tone than the rest of it, JSYK. @Matuchkin: I'll start off by suggesting that the next time you post you spend a little time thinking about how your analogy functions, considering the last ones you made made no sense. Any of us taking our "Apple" and going home with it doesn't destroy the Apple, remember, we still have it. We still keep the source code, the art, the whatever and we can still do whatever we want with it. Your enjoyment is not our lives, nor our goals, nor is us modders holding on to the rights to our IP something you have to save us from. I have to admit that of the many arguments I've heard against restrictive licensing and in favor of some form of permissive licensing, your last one has been the least coherent and probably most insulting of all of them I've heard. ------------------------------------------------------------------------------------- But anyway, on to more productive discussions. So, since you don't seem to understand why a modder would want a restrictive license and the consequences of it, I'll try to explain it to you. It all comes down to one, simple fact: All Rights Reserved results in the least support work for the modder that chooses it. Choosing an open license means that you will risk hostile forks, version and build lockers being removed, and distribution through methods that are not guaranteed to provide valid installs. And for many of these situations, support requests will not come back to the forker or to the distributor (even when they're at fault); they will come back to you. Then those support requests result in valid support requests being buried, hindering tracking down info for bugfixing and just causing general frustration. And frankly, you don't gain all that much by using an open license; your users might gain a lot, but you aren't your users. Note that none of these problems will ever show up if you use a restrictive license. Now, interesting fact: if there weren't hostile forks or CKAN taking the "lol, license says we can, we don't care about your support load and fart in your general direction" approach to this, there would be no compelling workload-related reason to take a restrictive license over a permissive one. What's the point of defending against something that'll never happen? Well, that's how things used to be, but not anymore. Endgame for this though is that there are more restrictively licensed mods, which all fall into the risk that they will be lost to time. Why wouldn't a modder take the effort to get someone to maintain it? Well, it takes effort, and not bothering is easier, same reason they picked ARR in the first place. If you don't plan on coming back, there's no reason to even bother. If you do, now there are considerations about how to handle it: If you re-license openly, when you come back you'll have the fun of forks and CKAN shenanigans to deal with. If you simply give modification and redistribution powers to one person, but not the power to change the license or redistribute license rights, then if they decide to quit it's pretty much as bad as if you didn't bother, so why bother? If you give them the power to change the license or redistribute license rights, then you get the risk of an open license. Lots of consideration, lots of effort, defeats the purpose of ARR most of the time, not worth it for someone who's lost interest and is burnt out. So you want to find a way to encourage permissive licenses, and the best way to do that is to first remove the incentives for restrictive licenses. You want to discourage people from engaging in hostile forks. You want to discourage people from removing version and build locks. You want to discourage people from using the terms of the license to do anything that might make more work for a modder. ------------------------------------------------------------------------------------- All of these problems with open licenses have a common thread besides the license though. All of them, each and every one, is argued by the forker, or the unlocker, or the distributor, that their motivation is to help users. To help the "Community." But ultimately, with no concern about whether their actions harm modders. This is where all of this comes from, this strange Cult of the Community where any modder interest is sacrificed to users regardless of the long term consequences (for both modders and users alike). This is where the risk of more restrictive licenses comes from, because that is the only way to have a hope at preventing that. And funny thing Matuchkin... this thread is basically that; sacrifice modder IP to the users for the sake of the "Community." If not by force, then at least by providing enough social pressure and hassle until they finally do. And none of us are falling for it. If you want to actually help, rather than make things worse, I'd suggest that you drop your current savior ideas and instead look to try and change those that provide downsides for the open source licenses you want.

The modders that have pulled 1.0.5 releases have brought trouble on themselves and the ones that have updated for 1.1 and proudly announce it have brought trouble on themselves, butmodders like me haven't. I shouldn't get hell because some other modders were quick to declare a pre-release stable. And beyond that, why are we giving users a pass?! You're people that are capable of making decisions and getting blame just like modders are. Let's face it, if the community (whatever the hell that means) was capable of remembering that it's a pre-release, acting like patient adults, and generally acting like the testers they always said they wanted to be leading up to the pre-release, there wouldn't be any issue. But instead everyone has acted like 1.1 isn't a pre-release. Unfortunately, the builds haven't had enough gamebreaking issues to remind everyone that it's a pre-release they should be testing, not a game they should be modding for giggles. The funny thing is that we learned all of this before when experimentals became private many, many, many KSP versions ago.

@emerald: TBH, I'm actually in agreement with 5thHorseman here. If you had released under a different name, everything would have been fine, because now it's obviously not official KJR. If you had kept the name, but not messed with the .version file, I'd probably raise my eyebrow and still point out the code failures, but issues beyond this short bit of time would be non-existent; people's AVC versions would still report it as 3.1.4, once 3.1.5 is out everything would be fine. By changing the .version to report 3.2.0, anyone who downloaded the .version file by through copying the entire directory (as I suspect they would) will not hear about any KJR updates until I release 3.2.1, and that requires the farce of 3.1.4 -> 3.2.1 when I'd rather my versioning system make sense. Which I suppose could be blamed on me for being overly strict, but engaging in version shenanigans like that is something that shouldn't be necessary and causes confusion when it does happen. If you still want to engage in modding and creating your own stuff, go ahead, you've at least got the competence for coding. If you want to update other mods whose authors aren't around anymore and that the license allows, go ahead, just be sure you know more about how the code works and try to keep the "brands" separate in case the original author comes back. The only thing you've really done wrong here is unintentionally causing the potential for longer-term issues, and that's really the only extent of my problem with you. Otherwise, go ahead and have fun with modding.

I personally don't have so much of a problem with forking mods against the modder's wishes in theory. KJR is GPL, this is allowed. However, I do have problems with practice and implementation, considering that the decisions made risk making modding (at least in the short-to-mid-term) much more of a hassle and show that those involved didn't think things through completely. Releasing a compatibility fork without ensuring that all the behavior is functional. Emerald's fork did not fix all of the code, so basically it defeats the purpose of a compatibility release because it wasn't actually fully compatible. Updating the .version file for the fork. That is only supposed to be done for official releases, and interferes with the ability to effectively use AVC to inform people of mod updates. Considering that the fork doesn't fix all the issues, that basically guarantees that I get unnecessary support requests unless I drop AVC support or move to engaging in versioning wars with anyone who decides to fork, accounting for all dev releases and all kinds of silliness. Anyone maintaining a modlist for dev builds of mods for a pre-release build of KSP. What benefit does this provide, besides ensuring that modders are discouraged from pushing in-dev code to avoid the most impatient uses rushing in to play with something that isn't even certain to function? Keeping links to two versions of a mod in the modlist, even after being told of the negative consequences (basically, reasons 1 and 2) for linking the fork. If the fork had simply completely fixed all the behaviors, I'd have no problem with it, because it means no risk of bug reports. If it didn't update the .version file, I'd have no problem with it, because there'd be no risk someone who installed it wouldn't get the memo that a new KJR was out. If the modlist was limited to only official full-release mods, I'd have no problem with it, considering that that's the way it's always been and it's limited to stuff that modders are confident are fine and not risk a hassle for uploading in-dev stuff to Github. I'll be honest, I'm just not surprised by any of this. I had kind of figured that everyone would take that attitude that the pre-release was really just "release, but sooner!! :D"; the reactions to build 1196 breaking lots of things with the fix to joints (TL;DR: joints pre-1196 were unbreakable, post-1196 they are breakable) kind of proved that. I see the benefit it's given to Squad, but all the same I kinda wish that it wasn't around. The KSP community just isn't mature and patient enough for a public experimental.

And likely in the process break tons of things out of ignorance of how FAR works, as is common when people rush to release "fixes" of open source mods because they're impatient. You know, for a bunch of people looking at the source code, you're all really terrible at reading the branches that are there. Maybe one of them is relevant to what you're after. Maybe it works when you grab all the other updated dependencies. Maybe it doesn't, and I'm just trolling. Who knows? All I know is there's no support for it and you're on your own for putting it together.