ferram4

Why? Don't bother, I have no interest in running a rat race against multiple pre-release versions. People can be patient. People should be patient.

As has been noted, there will not be an official KJR for KSP 1.1 until the full release version of 1.1 is out to avoid hassles. In addition, as noted in the spinoff thread and on the github PR, the code does not properly fix KJR. I would suggest that if KJR is that important to you, you go back to using 1.0.5; if not, live without it during the 1.1 pre-release. The trouble of attempting a rat race with a frequently updating pre-release build is not worth it. KJR 3.1.5 will be out when the stable version of 1.1 is out. Not sooner, not later.

The code isn't working because you haven't made the changes necessary to actually make the stiffening function. There is a lot more to fixing a mod than making sure that no errors pop up.

@tetryds: I'm not surprised there weren't any derpcannon planes, simply because testing the larger-than-20mm cannons out showed that a lot of them weren't worth it. The Vya 23mm is probably the best out of the ones there. It's got a decent RoF and excellent muzzle velocity and dispersion, so it's a very good cannon to use. I started with it before switching to the Hispanos for slightly less risk of overheat, slightly better dispersion and better RoF. The Mk 108 30mm is good if you can get in close, but its RoF is lacking compared to the other cannons and the low muzzle velocity (combined with the points system that limits how many you can have severely) means that even in close it's very easy for the plane to miss with it. The Vickers 40mm has the same problems as the 108 but worse. The even lower RoF and comparable muzzle velocity means that it's very unlikely to hit anything, you really can't carry any other weapons and still have a powerful enough engine, and now the gun is adding substantial mass to the plane design. If this were instead a NS-37 or NS-45 it would probably be viable with the higher RoF and muzzle velocity, but I still wonder. I was testing a light fighter with a Vickers at one point before I just abandoned the idea since the fighter got more kills with 2x Breda 7mm. The 75mm Panzer Quacker derpcannon is just too cumbersome and its RoF is abysmal. The muzzle velocity is good, but the unfortunate mass of the gun and mass of the ammo makes it just completely useless. I mean, I'd love to have seen a Hs 129 dogfighting in this, but the lack of other armament or underpowered engines just gets in the way.

All of my tests, including changing the shape of procedural fairings has resulted int he correct fairing shape in all situations. Remember that in any situation in which you attach only one half of the fairing FAR will not voxelize a whole fairing, because there isn't one there to voxelize. If you're somehow managing to cause an issue, you need to report it in the FAR thread with minimal mods (read: only FAR and pFairings), detailed reproduction steps that are guaranteed to work and a full copy of your output_log.txt. Missing any of those, or reporting, "this just happened" with no other information doesn't get anything fixed.

@numerobis: You're correct, as angle of attack changes, the CoP shifts. If you're treating CoL as just the lift component that goes into the CoP, it's completely and utterly useless since adding a constant torque somewhere will change the location of the CoP/CoL despite it having no effect on the stability of the craft. Otherwise you could argue that deflecting control surfaces, since it will shift the CoP/CoL will make craft unstable, but that's just not how it works. Any aerodynamic indicator needs to be applied at the location where the change in aerodynamic forces with AoA is applied, because aero stability is entirely based on how aerodynamic forces change, not their specific magnitude this second. Incidentally, that's what FAR modifies the CoL to be (a more traditional and useful Aerodynamic Center) and it works out great; I actually haven't bothered designing a plane with the other FAR graphs in awhile. Now stock models the CoL using the lift-portion-of-CoP method, so you're probably wondering why it's even useful right now. That's because (working only with pitch here for simplicity) if there is no aerodynamic torque at zero-lift, the CoP and Aerodynamic Center are at the same location. The problem occurs once you stop looking at rockets and planes with symmetrical wings with no angle of incidence on them and things get really weird. Especially since the CoP can shift outside the craft and then, well, it's pretty obviously useless. But that's correct for the CoP and that's why it's never used in stability analysis in real life, only as something of a theoretic curiosity. Aerodynamic center is the way to go.

@Lorunification: Well, then you had better be able to provide reliable reproduction steps for it. So far, no one has been able to and every time I have tried claimed reproduction steps everything behaves normally. So there's a reproduction step missing in all of these that every single person is missing. It's also pretty telling that every single example includes reproduction steps that are followed any time anyone launches anything and it still doesn't cause problems. @123nick: Funny, I've thought that water drag is probably a bit too high.I've had plenty of planes basically come to a halt almost immediately and pods stop bobbing in the water after maybe 3 or 4 oscillations. I suspect you're not using the most up-to-date version of FAR, update your install. @ss8913: I honestly don't know yet. Although on the one hand it might provide good feedback, I've got a lot of reservations about how things might go. I have no idea how CKAN might behave with this and if it will be able to differentiate between the beta 1.1 and real 1.1, which makes releasing through the standard channels somewhat concerning. I also expect that there will be the disaster of people from 1.0.5 trying to install the 1.1 build and vice versa and that will cause tons of hassles. I'm not even sure if I should push what I have to github considering the gigantic mess that was the time when FAR v0.15 was under development and people couldn't be bothered checking to make sure they had up-to-date dependencies. I'm still working out the cost-benefit analysis.

@Van Disaster: lower your default altitude. It always wants to climb back up to the default altitude and attack from there, but then it's too steep of an angle against a target that's below its default altitude and it decides to play it ultra-safe and pull out of the dive. Your AI settings would most likely be better for a BnZer, not a turnfighter like you've got. And it never gets to extend like it wants to because it's bleeding energy like it has a parachute on it in those turns. If you're gonna insist on it being a turnfighter, set up the AI for it to stick to low altitude shenanigans and work on it to make sure that it is actually capable of quickly getting right-side up and damping yaw oscillations to avoid going into the ground. Honestly, it looks like all your problems are just a case of designing for last war's AI.

Allow me to be opposed to a "not working" button for a simple reason: 99% of the reports are going to have little to no explanation of what went wrong and will be utterly useless to modders in actually figuring out what went wrong and that method will discourage people from bothering to report on the forums or github where things can be followed up. It's no different than adding a commenting system: it's another place for bug reports to show up, and modders aren't going to check them all, which interferes with getting bugs fixed, which is worse for users. Be good at hosting and finding mods and that's it; don't engage in scope creep. As for layout, frankly, until it's being used it's gonna be difficult to tell the actual problems that are gonna slip through. As for the colors, I guess it works, but I'm tired of seeing facebook/forum/blue-white color schemes everywhere.

They don't care whether they're more maneuverable or not; if they've got a speed advantage they'll try to boom-and-extend. Turnfighting is something that only planes at a speed disadvantage in an engagement will try to do, although if an ally ends up in trouble his teammates should stop boom-and-extending and immediately turn in to try and help.

They are heavily reliant on leading edge flaps that are probably deflecting quite a bit to keep the wing from stalling and the excessive amounts of power these engines have to keep things going. Also, that plane is basically nothing but wing. And heads up to anyone who's interested in the dev AI, you really, really want to grab the newly updated version from the link earlier in the thread; I managed to get some simple boom-and-extend working, along with slightly more opportunistic target selection so it will heavily influence battles how the AI fights now. Also, it cares about friendly fire. Really. No more of it killing your teammates because they gently floated in front of the guns. Now, if they rush-jump in front of them they'll still get killed, but at that point, they deserve it.

Anyone who would like to try the AI changes should grab the dll from this repo; it still might need some tweaking, but I think that it's pretty good. The AI isn't really capable of telling if it's a turnfighter or a BnZer, and in any case, the engine power boosts in the pack actually make BnZers not really all that great anyway, considering it's way too easy to prop hang and climb up to them that way, shooting as you go. It's far more valuable to be able to maintain a good amount of energy in your turns while still being maneuverable or be able to do boom-and-extend-level rather than a traditional zoom climb. One other thing you'll notice is that the guns probably seem to fire faster. The barrage code in the release has a bug that actually limits fire rate based on framerate, but that has been fixed here, so very high RoF guns can be really scary now. Part of me thinks that a highly Zero-like plane on a 20 kN Widshed w/ 4x ShVaks might end up being one of the best options with that assuming that it can get into range and has enough ammo.

Okay, the only FAR error I can see in there is one where somehow the GUI can't find the vessel that the part is attached to... very strange. There's a lot of stuff actually happening in the log, I need you to tell me everything that you did with that vessel (and I mean everything, switching your view between crafts is a thing, loading it up is a thing, going back to the space center and returning is a thing, etc.) so that I have some hope of getting actual reliable reproduction steps. While I'm thankful for the log, I also need you to tell me what mods you're using on the craft, and if possible, I need you to reproduce the issue with as few extra mods as possible. Until then, I unfortunately really can't do much besides guess at what's going on and try random code changes to fix it (and probably introduce much worse bugs in the process).

First, yes, the arrows are wrong. Parts that have no drag on them have excessively large drag arrows... for some reason. I'll have to look at what causes that. Second, it's not just drag. Very large fairings will produce much more body lift than the rest of the rocket, which at low AoA is proportional to the cross-sectional area, and take a look at that fairing: its diameter is twice that of the rest of the rocket, which means that it's gonna be making, unit-length-for-unit-length, 4x the body lift. All way ahead of the CoM. The payload is actually probably a lot draggier than the fairing, but because it has less body lift, it's more stable. Draggier things being more stable isn't that rare; reentry vehicles are far more stable than bullets are, but bullets are much lower drag. Redesign the fairing to fit a lot tighter around the payload (your payload is a smaller diameter than your rocket, why the hell is the fairing a larger diameter than the rocket?!) and everything will be fine.

Very nice! Alright, so here's an update on that asymmetric monster of mine: The FAR Tytonid's development is going along pretty well, that's the Tytonid Mk XII up there, and yes, there have been Mks from I up to XII, and there will probably be a few more. Lots of incremental changes between them, mostly related to trying to solve problems related to the asymmetric design. There's a lot of info in the spoiler on this, hopefully someone finds it useful / interesting. Well, that was longer than I expected, but yeah, I'm incrementally improving it as if it were a real war plane. Unfortunately I can't throw an engine with a better P/W in there as I increment, but given how OP they are compared to real life, I'll make do.

So, a heads up to you guys. Assuming @BahamutoD ends up accepting the PR (when it's ready) and there are no serious bugs, and yada yada qualifiers, I've got some AI modifications in store for BD pilots. Mostly I'm tired of it turning into flat turning battle with whichever plane turns better / doesn't start the evasion code winning all the time and no AI coming to the other's aid. Right now I have it set up so that the AI will attempt to do Immelmanns, split-Ses, and chandelles as needed to conserve energy or get into position to attack the opponent. In addition, the AI will also call for help from its teammates when under fire, so it won't turn into a pair of independent dogfights 10 km apart. Right now I'm working on making the evasion routine a bit smarter so that it actually tries to dodge the enemy plane's guns rather than just do something stupid and get killed or set up a really nice deflection shot for their opponent. Should certainly make the battles more interesting, but at the same time will likely result in the design-meta favoring slightly different craft than before, so you guys should know.

But L/D ratio has absolutely nothing to do with the pitch damping of an aircraft. The only thing that matters is the lift slope of the wings and tail (how much lift they make per unit AoA) and how far they are from the CoM (so the moment arm they have to work with). We're describing short-period motion here, drag can be completely neglected in the analysis of nearly pure pitching here and the L/D ratio does not matter. The frequency and damping ratio of a plane will be independent of however L/D varies at full pitch input because the a plane in short-period motion is very much like a pendulum; the frequency is based on the distribution of mass and the static stability, the damping ratio based on the distribution of lift forward and back and the static stability. The actual magnitude of the L/D ratio... just doesn't matter in short-period dynamics.

@Kitspace: Simple solution. Make the plane more statically stable, which will also have the effect of making it more dynamically stable, or put more lifting surfaces further from the CoM to increase damping that way. In general though, highly maneuverable planes are always more finicky than their less maneuverable counterparts. It's the nature of the beast. There aren't many other options, considering that the issue you're describing is basically continuously stalling -> recovering -> stalling the plane, so the only options you have are to increase the damping severely, cut back on control authority, or don't jerk on the stick like a madman. Honestly, not jerking on the stick like a madman will probably be the most productive option though. @kcs123: I... do not even have any idea what your image is supposed to show, why the peak of the L/D curve is even relevant here, and it's fairly clear that you're not optimizing for maximum maneuverability, so I don't know why you're bringing it up.

I am fully aware of the consequences in terms of following the license precisely and the negative consequences of it. However, not all the negative consequences have to be tolerated, because the terms of use for a site can forbid those. At this moment, there are no policies to handle behaviors that follow the license exactly but provide no actual benefit (and in some cases, harm) to users or modders, which is what I'm getting at, and based on the current discussion in here, it seems a lot like there won't be any at all.

As someone who is currently being screwed over by open source licenses, I think it's kind of important to understand why I even selected them: I want there to be no problem working from what's there if I decide to quit. I also don't want people who want to build off of it to be discouraged from doing so. What I don't want to deal with is someone uploading an exact copy, that copy then becoming the go-to source for the mod, that copy becoming out of date as I continue development, but still being the popular source that everyone goes to (for some reason), resulting in greater support requests for no good reason. Or for the upload having packaging errors. Or for it to include large changes, but all the info points back to my thread so I'm getting support requests for someone else's stuff. So, in terms of policy outside of what is strictly following licenses, how do you handle the above scenarios? Will there ever be any policy outside of pure licenses that SpaceDock will follow, or will the response amount to no more than, "deal with it."?

Simple; you're absolutely correct about how you expect things to behave. What you're not correct about is the orientation of the axes; Z+ is measured downwards. That's so that a positive angle of attack is measured as pitch up for the plane. Everything else comes from that.

I'll likely enter a heavy fighter as well, but I decided to be... well, interesting. Already executes the dummy without a problem and has somehow managed to out maneuver and destroy most of the light fighter designs I've tried to create to kill it. I may have to create a heavy fighter to try and kill it. At the moment I'm tweaking it and trying to balance how much fuel and ammo it should start with to have the necessary endurance.

I'd like to second this, as I've found that without the source available, I can't even add an extra link to download one of my mods; on my Kerbal Joint Reinforcement page I'd like to add a link to it on SpaceDock, but for some reason I can't; it will be set up in editing and then disappear when I try to confirm it. What is the reasoning behind keeping the source hidden?

And now, FAR v0.15.5.7 "Johnson" has been released, fixing a bug or two. Changelog has the details. FAR is also now hosted on SpaceDock, so do us all a favor and hug their server to death. Anyway, questions: @FourGreenFields: No, reference area also matters. Otherwise the drag coefficient would increase for larger planes and that would defeat the purpose of creating a dimensionless coefficient for this. @Bookstore44: Yes, I'll need to update the wiki; Xu being negative just means that the drag coefficient is dropping, it's not necessarily a bug. Also, hacking gravity causes that to make sense since you've dropped the lift requirements down to nothing, so the drag from that has also dropped. The way wings are currently modeled, the entire chord stalls at the same time, but the way the pressure distribution works out, that produces a pitch down moment about the wing's aerodynamic center. That said, if the entire wing is far enough in front all the extra drag of the wing stalling might be enough to keep the plane from pitching down. In any case, it sounds like your tail is stalling too soon and you should sweep it back / reduce its aspect ratio to help delay its stall until the main wing stalls.

@Rodhern: Follow up; found the issue, turns out that it was the little zero-crossing marks that the graph adds. When simulating a cylinder from the side, little numerical errors cause the lift, moment and L/D ratios to all hover around 0, but not quite on it, jumping above and below it every data point or so. So it's trying to add a couple hundred zero marks and that gets expensive. Added a quick sanity check to say that there are only ever gonna be 4 zero-crossings per line at most and otherwise to ignore them and it's fixed. @m4ti140: Sorry, missed this initially. Yeah, that's the long-term plan. Ideally not providing the airfoils themselves, but instead families that you can tweak the camber and thickness of as necessary. Ideal starting profiles will be the NACA 4-digit airfoils, the NACA 6A-series of airfoils, and likely supersonic diamond airfoils (which will likely not be camberable because camber in supersonic flight isn't very helpful). But first I need to get the wing overhaul working.