ferram4

@jrandom: I think it's the result of a bug that was in my turbojet nerfing (it didn't do exactly what I wanted originally) being fixed combined with the stock ignition threshold capability being fixed.

@ninjaweasel: What I meant by "the payload isn't magically protected by aerodynamics" was assuming that you were a newbie figuring that attaching a payload fairing was the solution to all problems; I've had to deal with a few of those. I think I see what's going on here; you're relying on the boosters for some manner of stability and it provides just enough to make the rocket work in the lower atmosphere. I have an odd suggestion, but it might work if you're having trouble: put the entire upper stage with payload in the fairing, but attach the first stage to the top of the payload (might need a redesign though) and fly the payload + upper stage up backwards; this puts the heavy engine and fuel in the very front of the vehicle. Put a large probe core on the main stage so you can aim prograde and try that. It sounds wonky, but if it works, you've got an awesome launch vehicle. Other than that, more fins, and obligatory asking if you're running v0.12.5.2, since v0.12.5.1 and 0.12.5.0 had strange surface area calculation issues.

Are you trying to keep the rocket aimed prograde and actually do a gravity turn or are you trying to do the "go up 10km, pitch over like a maniac" ascent that everyone here incorrectly calls a gravity turn? Is your rocket built vertically? Large, highly parallelized rockets tend to have control issues since as the fuel tanks empty they force the center of mass to move backwards, but keeping larger upper stages in a more vertical serial-staged design results in the CoM moving forward as the first stage drains. Are you trying to launch a light, fluffy payload that takes up a lot of space in a payload fairing? It's not like a payload fairing is magically protected from aerodynamics; if you're doing something like that it's the equivalent of putting a few wings on the front of your rocket. Post pictures of your vehicle; without more information no one can guess whether your failure is due to design or piloting. And start small; if you need a payload fairing your fist launch with FAR (which should be a mk1 pod with enough fuel to de-orbit, just like when you started), you're doing it wrong.

Hey, I just found some stuff in ModuleGimbal that might be useful for people dealing with the extra gimballing range of real engines. ModuleGimbal has a responseSpeed value and a useResponseSpeed that can be set for each engine, getting around the really over-the-top sudden jerking that happens when sudden control inputs happen. ModuleManager code follows: @PART [*]:HAS[@MODULE[ModuleGimbal],!RESOURCE[SolidFuel]] { @MODULE[ModuleGimbal] { %gimbalResponseSpeed = 15 %useGimbalResponseSpeed = true } } This will update any part with a ModuleGimbal to have a decent response speed, with the exception of SRBs, since doing that apparently breaks saved StretchySRBs. I'm not sure what units responseSpeed is in, but I think it's degrees per second; 10 is about the lowest you can go before SAS starts getting bad at dealing with the controls, and anything below about 5 makes manual control impossibly sluggish as well.

Really, it's just that the atmosphere cuts off whenever the air pressure is 1e-6 times whatever sea level pressure is. So with Venus settings, that means that it cuts off at 0. So basically, you'll go from vacuum instantly to being in Earth's atmosphere at ~70km. At full orbital velocity. And it just gets denser from there, with no low-level braking above that. Even with FAR, lifting off of Venus would be like Eve in stock KSP. Except your rocket will have to be aerodynamically stable through all of that. The Goddard Problem might actually be relevant in that case.

Hovering over the button creates a tooltip that lists the engines that use that mix. It's actually cool, it gives you an idea of what engines you can mix-and-match and not end up with leftover fuel.

Lots of mass on either side of the docking port, combined with decently high thrust, combined with the fact that it looks like in most of those places you've put lots of other smaller parts next to the docking port means that it's basically set up to wobble as much as possible. There's only so much that can be done. That said, it looks like I was right about stretchy tanks being skipped. I'll look into getting a fix out after my testing confirms no odd side-effects.

Ah, I see what the problem is; you're using multiple tanks on the first stage when you don't need to and the wobble is being caused between the smallest ones. There's some weird thing in KSP's physics, that I don't know if it's caused by PhysX itself or Unity's implementation of it where joint forces seem to be scaled down to the lowest mass object's size. You'll notice that most of the flexing in stock KSP occurs at decouplers, which are the lightest objects in stock KSP. So the same thing is probably happening here. The only solution I've been able to find is struts. Hell, the "decoupler stiffening" is simply adding strut-like joints. Edit: I think I found the issue. KJR's mass threshold is culling out the stretchy tanks because they're too light when dry. This would explain why it primarily happens in RSS. I'll look into fixing this and hope it won't break anything.

That's really weird. Can you provide an output_log.txt? I honestly don't have any idea what could be causing that one to be honest. The only guesses I can come up with are that battery power ends up preventing the game from handling an exception properly or that it leads to some type of deadlock somewhere... in which case I don't know what I can do about that, since FAR doesn't actually run multiple threads or anything like that. See if there's some kind of "maximum performance, screw the battery" mode that you can throw it into and try launching something with FAR. Maybe FAR's heavy use of floating point math causes problems when the computer is trying to save power. Anyway, I'm speculating about that. For now, upgrade to 0.12.5.2 before you try to aerobrake at Duna. I've seen some issues in that version where craft end up with stupidly high reference areas and end up slowing down to 10 m/s in the upper atmosphere and losing that thing would be funny, but still kind of bad. "Hullo! I'm Scott Manley, and my mission to Duna was just eaten by an aerodynamics glitch."

@NVM: Know about it; I'm trying to find a way to fix it that doesn't involve updating the control surface "positions" every physics frame, which would add some performance hit that I'd prefer wasn't there. @somnambulist: I added it. The minor error is that he says that negative Cms are necessary for the vehicle to be stable, but really it's a negative Cm slope that's necessary for that, but it's still better than nothing.

You do have an option to bypass the block under the most restrictive proposal being discussed; recompile the source and fix the bugs. If all it did was provide a stern the warning is users will ignore it since they will either hear from others or learn through experience that the "ignore incompatibility" button is actually the "make it work" button, and then we'll be back to where we are currently, with users suffering compatibility issues and the resultant complaints. Except there won't be any noise of the form, "ModuleManager eats your all parts; delete the dll or else!" which was the essence of a PSA someone tried to get started on reddit shortly after 0.23 released. There won't be any "FAR causes <issue that isn't caused by FAR> in 0.23," with me getting bug reports that aren't even my fault. There will be fewer effects of ignorant "common knowledge" that X is the solution to a problem, where X is actually a bad idea that simply replaces the visible issue with a more subtle one. That background noise of well-meaning but incorrect mod support is really the key thing to reduce, since it reduces issues in the long term. Sure, people will ask how to circumvent the compatibility check, but that blends in with the demands to update the mod anyway. I actually don't see how this is a bad thing. When a mod goes unsupported it's only a matter of time before it causes game-breaking issues and it's better that it be closed down before that happens. Even when a mod is "functional" from a user's perspective there can be a lot of errors quietly occurring; exceptions are thrown, the game and the mod fight over things, the mod conflicts with other mods, but if there's no overt issues users declare that it's still fully functional, even though it's not. If there are users that think that a mod should be maintained, but the original author isn't interested anymore, they should look into maintaining it themselves. If they don't have the skills, learn them. I didn't know C# until I started coding KSP plugins. Leaving a plugin in a semi-working state is worse than it disappearing; it becomes a complication in bugfixing any other mod, since of all the mods this person is running, there's this one random plugin that's from 0.18 that is probably causing weird interactions, but given the poor quality of most bug reports quantifying those interactions is a pain. Ultimately though, how a modder implements the compatibility check is up to them. There are some that might just have the game yell at you and then let you continue. There are others that will disable the mod because they know that it will break horribly.

I can see it being an issue with the engine stiffnesses... basically, since KJR calculates joint stiffness based on the part's model, if you connect an upper stage with an engine much smaller than the tanks of the upper stage and the lower stage the engine-decoupler connection can be quite weak. I've noticed some wobbling myself, but I have been busy engaging in wretched excess in RSS, so I figured it was understandable. I'll do some more testing, but I think part of the issue might be that decouplers are being overzealous in deleting joints when they shouldn't; an understandable situation given the early joint issues the mod had.

Okay, so Launch Clamps are breaking something then. I will investigate and look to see if I can fix the issue. That said, the issue looks like it happens at decouplers, so I have a hunch what's going on there. I'll see if I can find the problem.

I thought it was common to provide a link to the forum thread in the Readme? At least that's what I've always done. As for helping users, protecting them from the ever-present threat of KSP updates screwing up their mods seems like helping them out. Every single time a KSP update has broken FAR the game-breaking bug was caught in the compiler. Every single time. At that point, a dll being redistributed doesn't bother me so much, because it would require the compiling user to fix the bugs. The alternative is that they reference the old KSP libraries to build the dll, at which point it'll quickly become apparent that the dll is broken and every single one of us can say, "This is why the version compatibility check is there; to prevent this. We tried to stop you from running into this, but you've insisted on bringing this issue on yourself." A config file change, or an in-game work-around would have to be coded in by us as an "intended" way to "fix" the issue; it seems harder to justify, "Sucks for you, you shouldn't have done that." What's the point of adding a button if they're not ever supposed to press it? The only way that I could support an in-game work-around is if it requires the user to type out something ridiculous and over the top, like the below, in full: I fully realize the above is heavy-handed, nasty and a pain to type out, but I get the feeling that the heavy hand might be necessary for the users I'm envisioning complaining about the compatibility issues if I ever decide to allow a non-compiling solution to the issue. A "simple" work-around I would be too likely to lead to people ignoring the message and complaining because "the mod didn't work," like all the people who asked for a confirmation dialogue for "End Flight," not realizing it was already there because they automatically went to click "Yes" and that their brain filtered that out. That said, I probably wouldn't implement that particular wording; it's just too mean and nasty.

Oh, that gold part between the Merlin 1D vac and the second stage is a separate part? That would cause the issue; make sure that there are struts from the second stage to the first stage (or to the interstage fairing) to stiffen that up then. It might also be part of the stability issue; make sure that the interstage fairing actually has the word "fairing" in the title so that FAR picks up that it should shield the parts inside it from aerodynamic forces.

Get rid of the landing legs on the upper stage. Seriously, those are going to make the thing less stable and are probably part of the issue.

I'm not aware of any odd behaviors with landing gear from B9; I haven't heard any complaints about it, so I don't think it does.

Majiir's code allows the mod author to implement whatever kind of version-checking procedure they want. I was talking about my psuedocode in the original version, which references the minor version. I see that you have not had the issue of maintaining a mod that broke horribly during a KSP update. I'm still getting bug reports for versions of FAR from KSP 0.22 not working in KSP 0.23; I've had some reports of people trying to use 0.23-compatible version of FAR in 0.22. When did a plugin checking its running environment's version become Digital Rights Management? That actually makes DRM sound somewhat reasonable, I might have to rethink my attitude on it being pure evil if version checking == DRM. Sure, I can see it as a compliment, but it's essentially phrased as a demand, and it ignores the consequences... "I want to play your mod so badly that you should have to deal with more bug reports and compatibility issues so I can play with it." The first one is pretty much what I already do. The second strikes me as a really nasty way to handle it, and since I'm dealing with an aerodynamics overhaul (and the associates changes in playstyle that come with it), I don't want a harsh support attitude to discourage users having trouble from asking for tips. Especially since I'd prefer to not to risk becoming nasty when I've heard the same gameplay question the 100th time, from a well-intentioned user. The third might work, but useful information can be hidden when the thread disappears. For Majiir's stuff, perhaps. For mine, it's mostly copylefted. So all it takes is recompiling to update the compatibility and fixing any compiler errors, and people are free to redistribute FAR, KJR, KIDS, etc. as they see fit. None of this discussion has included restricting the source; it has simply focused on making sure that the plugin is confirmed to have no compiler errors stable by recompiling it using the appropriate (hopefully) references, with a small change to the source to make compatibility work. I think that you're seeing licensing issues here where there ultimately, are none.

The main issue with oblique wings is aeroelastic effects due to the differences in sweep. The spaceplane torquing in space sounds weird. Did any of the parts have drag / lift values in the right-click menu? If not, then I'm going to assume I can simply giggle at the result without having to bugfix.

Maybe Greys will want to do something like that, but that system just strikes me as unnecessarily complicated, and it doesn't shut off your mod if it doesn't come from an "approved" source or some other nonsense like DRM causes. It simply identifies whether you're trying to run a mod with a version of KSP that it was not compiled for, and if so, adds an additional (IMO unnecessary) server check to see if the mod is compatible in that particular KSP version, since it wasn't intended to work with that version. Since Firefox disables plugins when they might not work after an update, that means that that function is DRM, not simply a hassle-saving feature for supporting plugins, correct? At least according to your definition.

I'm assuming that users will be treat replacing the plugin's library with greater weight than changing a value in a config, in the same way that I assume that users will consider a HighLogic-skinned window to be more official than a standard Unity-skinned window. Perhaps it's not the best assumption, but replacing a file of a type they know nothing about should seem more significant than changing a value in a text file.

True, but here's the thing: by implementing a config bypass, I'm implicitly sanctioning a "fix" by changing the version number, and people will pick up on that. The dll-recompile doesn't have that issue. Did you not read the code example in the OP? Where it checks the minor version number, which would allow a plugin compiled for 0.23.0 to still function in 0.23.1? Or are you simply not recognizing that KSP is major version 0, minor version 23? And last I checked Actions On The Fly spammed null reference exceptions all over the place. You might argue that this is an example of how this scheme would be bad, but considering the issues I'm aware of with Actions OTF, this is actually a situation where this would be necessary. If the code is hitting an exception and stopping execution prematurely, how do you know that there aren't strange effects causing things to break? The point of this is to prevent issues like that from occurring. Even if there are no visible errant behavior, exceptions should not be allowed to continue existing in the code. What happens when some 3rd party posts a config in a folder structure with the proper pathline and they say it "fixes" the compatibility issue and a user installs this and runs into issues without ever seeing the "setting this to X will void support" message? Am I just supposed to tell them, "tough luck, you shouldn't have done that?" It just asks for problems when ignorant but well-meaning users attempt to "help" other users. Ah, so you do see the point. The idea is to prevent computer-illiterate users from running into possible issues and then dropping it in our laps. Tough, but I don't see how that has any bearing over whether this changes whether the lockout makes sense. It's not like plugins are created by modders to add to some great collective good of the community where we all live in a nice, happy utopian vision of rockets and happiness; most of us probably do it for our own selfish reasons. For example, I release my plugins (with the exception of KIDS) so I have more... data points about how it handles. For the intelligent user, correct. For the foolish user, the modder just gave them a way around the compatibility check; WHY DOESN'T IT WORK?! ARGGHHH! The problem is they likely will not be warned; they will obtain the "fixed" config second-hand, or they will gloss over the warning as irrelevant. They'll read somewhere to "ignore the warning, it's full of it," and believe that. The key is that someone with coding knowledge take responsibility for the code working, and if it can be handled through a config change that cannot be guaranteed.

Mostly the first one, with the suggestion of the second. For example, ModuleManager will likely still run even if FAR is disabled; since FAR needs the wing aero parameters applied by ModuleManager, it will break the stock wings completely. Okay then, just making sure. This seems like the kind of system that can easily break everything if implemented wrong. You make good points, but IMO the options you want simply allow the existing problem to continue, or worse, for an unsuspecting user to get a 3rd party config that "fixes" the compatibility check problem, but leads them into the actual compatibility problems, and then they get angry because they don't get support due to the changes to their config file. It adds the possibility for modder-mod users relations to go really, really far south just after an update, particularly for something like MJ or RemoteTech, which need quite a few changes to maintain compatibility every update.

@Majiir: That looks really cool Majiir. Only thing I'd suggest is that the window's title say, "Incompatible Mods Detected" and mention in the pop up that there may be side-effects of leaving the code available. Other than that, I'm not sure exactly how I would implement that code into a mod; would I simply copy the compatibility checker code over into the FAR source, add my disabling code to it, and it would work (in the final release)? @draeath: Then they can use MonoDevelop instead; ultimately, trying to force a plugin to run with a possibly incompatible version of the underlying software falls more into "software development" than simple user stuff. And I'd rather not set the bar so low that it can be circumvented using a change to a config somewhere, since that defeats the purpose of this. I can see exactly how your config option will play out: Some people will disable the check, and that will be fine. Others will download a "special" config from someone else that "makes <MODNAME> work in KSP <VERSION>"" without knowing what it does. Then they get issues, they complain and then get super, super pissed when the modder doesn't provide support for them, after all, they didn't change anything. No one will blame the 3rd party source of the config, they'll blame me. For giving them the option to disable the check.

You do realize that all you need to compile code for a KSP mod is Visual Studio, have the project reference Assembly-CSharp.dll and UnityEngine.dll in KSP_Data/Managed, and compile the dll, right? All you need is a C# compiler, which isn't hard to find.