ferram4

I think I have a possible mechanism for this. So, we're looking at ModuleGimbal PartModules, that determine how they should react based on the vessel CoM, which is set in the FlightIntegrator (for stock) or ModularFlightIntegrator (for FAR and other mods that require it) VesselModule. The code between the two for setting CoM is identical, but the results affecting gimbaling but not control surfaces, reaction wheels, or control inputs indicates a CoM error. Further, that the error requires velocities < 750 m/s indicates that a relatively high world velocity is needed. So, let's consider what happens if the VesselModule runs first: it calculates the CoM of the vessel, and then the PartModules come along to make use of the CoM calculated that frame; everything works as it should. What happens if the PartModules run first? The CoM location used by the gimbal PartModules is the CoM location from the previous frame; below 750 m/s, when Krakensbane isn't active, that can be as much as 750 m/s * 0.02s per frame = 15 m away, which could be enough to cause issues on short vehicles. It should also vary with vehicle orientation, and tests in the FAR thread seem to indicate that. Alright, so if this is the mechanism, it's an order of operations issue. Why would that happen? VesselModules and PartModules are both derived from Unity's MonoBehaviour class, which execute most of the code in the game. MonoBehaviours have each of their functions executed in the order that they were created, so if you get PartModules that exist before VesselModules, then the PartModules should run first. If this is an issue, it should actually be reproducible in stock as well; undock a short vehicle from a station (read: create a new vessel and new VesselModule, but with old parts and PartModules) and then bring it below 750 m/s and the issue should appear. If that shows the problem, then ultimately this is just an exacerbated stock issue of relying too heavily on order of operations to get things done. At the moment I'm not sure why ModularFlightintegrator is being added late though. It should be added in the same mechanism that FlightIntegrator is, so I'm a little stumped right now as to how to solve it. I should be able to get something together though.

Alright, thanks; still no idea, but we'll see. When you get a chance, can you summarize all of it in a bulletpoint format for causing it and how things react? If I manage to find a fix I wanna have all the possible variations to test simply.

Oh, you mean these guys? Temperatures below 3000 m/s: Temperatures at higher velocities velocity in m/s, stagnation temperature in K Thinking back, I'm not sure exactly how accurate these are, especially at the higher energies. The right next step would be to do an Equilibrium Gas calculation and work from there instead, but getting the Gibbs Free Energy values (or something equivalent) for ionization is... difficult.

@sumghai: I'm aware; I was involved in the latest win64 thread in General Discussions. Thanks for the heads up anyway. @GorillaZilla: Umm.... what?! Okay, wait, the actual orientation of the vehicle matters? Oh, that's bad. That's real bad. It's measuring something from a bad CoM, I think. If you're shooting it straight up to test, you should be able to get the results to reverse after going around the planet 180 degrees. Or nearly. Depends on where the coordinate system origin is located, I think. Yes, please test that rocket as well.

Alright! So that points to something related to how the stock gimbal code works. No exceptions in the log, so nothing's terminating early to cause the issue. Try this: Build a rocket with some engines in a conventional pusher arrangement, and some engines in a tractor arrangement (make sure it's well in front of the CoM), both to push the vehicle prograde. Also add a set of pusher and tractor engines for retrograde. See what happens, just for completeness; this will help exclude any CoM-related issues. So part of me wonders if this is due to something being shifted to Flight Integrator that Modular Flight Integrator doesn't include. I'll investigate the code, but I have no idea at this moment.

Alright, so here's the tests you're gonna do. You're gonna test: Whether this also affects control surfaces. Make sure you check against the normal deflection angle to be sure. Whether the control input indicators in the bottom left move as they should. If it doesn't affect the control input indicators then the error is somewhere in the stock gimbal code, which means that there is nothing I can do to fix it. You're also going to post your logs the complete logs, nothing stripped out at all, as well as a complete and exhaustive modlist with versions. No CKAN, if that's involved at all, you're on your own.

Well, for one, there's the principle of the thing: I'm not giving permission after CKAN contributors have shown that they don't consider permission necessary. For two, I want a permanent solution; I don't want a "and now it shows up 6 months later as a problem again" solution, because that's what's going on right now. I don't want to have to chase after CKAN to get them to stop screwing me over, but ultimately that's what this ends up being. I don't appreciate any idea that's going to result in me having to help the people that decided to screw me over after they decided that what I wanted didn't matter. Dunno, that's pretty damning. After all, for all those issues, none of them have affected anyone who bothered with manual installs; a good metric for this should be the number of errors multiplied by the number of CKAN users that installed FAR, and that's gonna be way above the people who installed it manually bad enough that InstallChecker couldn't figure out how things broke. Seriously, from my perspective, you're doing a lot worse than winzip.

If the buttons along the bottom of the Flight GUI aren't depressed, then the Stability Augmentation functions are off. In addition, there are no FAR systems that override yaw controls at all, so right inputs will always come through as right inputs. I don't believe that this is an issue with FAR, instead I suspect that it's something else you're using that is inverting the controls. FAR does not have any ability to invert control inputs, period.

Every time you place a part, FAR needs to update the voxel. Every time you resize something, FAR needs to update the voxel. This is not a procedural parts issue then. I'm not sure what I can do, if your install is lagging that much then it indicates that your machine is very slow at collecting garbage, because FAR doesn't produce that much with the voxelization, or else you have a lot of stuff working in the background that prevents the voxelization threads from being able to run without either interrupting KSP's main thread or trying to take priority over some other process that has been given higher priority. Not much I can do in that case, unfortunately.

@pwnedbyscope: That indicates that you didn't remove all the files in the download. Deleting the FerramAerospaceResearch folder would have reverted everything to the state it was before, including control surfaces reverting to the stock model. Only possibility is if something incredibly stupid happens with how stock handles saving/loading of vessels now, in which case that's an error with stock behavior that I can't fix. @ExEvolution: If you do get drag forces, that indicates that some other mod is forcibly updating vessel voxels too often, and that's up to them to fix. If you don't then you've found a bug somehow and I need to you to document everything you did (all of it, every stupid little button you clicked or vessel you launched, EVERYTHING; leaving anything out will make it unreproducible) along with all the logs.

@GorillaZilla: There is a simple way to disable FAR's Stability Augmentation. The solution is to turn them off. A more sure-fire way is to not turn them on, because they default to off. Yes, user error can cause bad things to happen, but it's not a gamebreaking issue that SAS won't let you turn off retrograde when you leave SAS on and in retrograde mode. The stability augmentation systems have always been in FAR, since v0.1 as a little help for flying planes. The switches for them are right along the bottom of the main flight GUI. They've always been there, and they've always defaulted to off. @cipherpunks: You using RealChute in the problem install? Because I guess that RealChute doesn't have configs for that parachute. Other than that, not much I can do, the parachute code in here is all stupid_chris's stuff. @WalterB: It should be possible to remove the checks somehow, and I know that stupid_chris was looking into how to do it for similar reasons. We'll see if anything comes of that.

...I'm having a really, really difficult time finding how any of my response was biting the head off of someone. I explained that I was confused with the asking, that I don't deal with CKAN except for the problems that it causes for me, and that CKAN's problems are best kept to CKAN channels and with CKAN's people. Not wanting anything to do with CKAN and complaining that it has caused issues is being a jerk now? And yes, the CKAN issues can be buried by kookery, just like all issues and valuable discussion. There was a good group of issues from way back of CKAN not installing MFI, then installing a version of MFI that caused problems with Deadly Reentry, which probably also involved issues being reported to that thread. Also, let me remind you: CKAN is a machine. It does the exact same thing every time. This affected everyone that used CKAN and FAR, not just the ones that reported it.

@brusura: Not sure what's going on, but I can confirm. Something's breaking very low in the aero calculations. @cipherpunks: The bacon labs parachute-docking port combo produces drag with FAR. I cannot produce any issue with it.

Well, you've been overruled then. I tried that with pjf, and got a no. And it's a matter of CKAN policy that the answer is no. I don't think you actually can extend that offer anymore, unless you can somehow change the mind of everyone involved.

Funny, they won't. As noted here, since KJR (and most of my other mods) are openly licensed, they won't stop indexing it except for if there are substantial issues. I'll get to that later... I didn't know that metadata issues weren't a CKAN problem. I'll note that for future arguments with CKAN contributors. The amount of downplaying of issues is amazing. And I was merely noting that I didn't know why you were asking. They have never cared about what I want, why would anyone start asking for permission now? Let's say that you're talking to pjf and you're trying to get a straight answer about what circumstances would actually result in them de-indexing. After much wasted time you finally get an answer of anything that isn't "immediately fixable." And then you try to get an answer of what does and doesn't qualify as "immediately fixable" and you can't get a straight answer about that. And then you get told that it wouldn't matter, because FAR is a dependency for RO, and so it would never be de-indexed because of all the people for which it works (despite the fact that all the issues are from CKAN screwing up the install, which means that all CKAN users have the issue), showing that you just wasted all your time trying to get answers and that the guy in charge missed the point completely after dodging so much. I think yelling is quite suitable there. All I did was note that I didn't understand why you wanted my permission and asked you to keep CKAN issues to CKAN. I'm not sure how that makes me a jerk.

I have no idea how acknowledging that it's a CKAN problem, by whoever works with CKAN has anything to do with causing CKAN to screw up its metadata. It's not as if I'm the one that caused CKAN to index the wrong version of a dependency that only had one public version (how, I have no idea). If he wants to update the metadata, well, CKAN policy and customs tell him he can do whatever he pleases. He never had to ask me, because CKAN established a long time ago that my permission doesn't matter. Why he wants it, I don't know; the only permission that I will give to CKAN is that they have the permission to de-index all my mods whenever they please; everything else is based on whatever other policies they have, and I won't pretend I have any say there.

...no I haven't. No one has asked about FAR metadata at all. I'm not sure how I could reject something that hasn't been asked. Go, check the FAR thread; there's nothing there about metadata. You know, something I've noticed when dealing with CKAN: every person involved does their best to try and say, "no, we're not the ones screwing up, it must be your fault modder." Even to the point of making stuff up. But let's suppose such a thing were to happen. FAR is not on CKAN by my choice. It was not added by me, nor have I ever had any input on the metadata. CKAN has always indexed my mods without ever asking for permission; I don't see why my permission is needed now, because it certainly wasn't needed before.

I'm punishing them... because I'm leaving them in the exact state they would be in if I weren't here producing mods? I think your baseline is a little off. They're not hurt at all; they just don't get benefits of those mods like users of more stable platforms do. I suppose Squad is petty because they pulled the win64 build as well, rather than just declaring it to be unsupported and letting users who aren't doing anything wrong continue using it?

I dunno why you're asking me, I have nothing to do with CKAN besides yelling at them about the problems they cause for me. Go take any of their problems to their place and please don't bring them here again.

Yes, I'm aware of heating issues. Something is very wrong with the new skin temperature system, particularly in calculating the exposed skin area. I can't figure out how Squad set it up, but for some reason that isn't changing at all or being set correctly; it's set in too many different places for me to follow exactly what's going on and if there's a way to go in with a scalpel to do the changes that I need. Hopefully I can have something to try and fix it, or just rip the entire new heating system out and replace it with something more like the old one. @Cinocal: That would be a vehicle main axis error. Not sure how only two jet engines could cause that; can you upload the craft so I can take a look?

That would be news to me, considering I can't get the hack to not crash. My tests indicate that the point is where it's always been; you try to use over 4 Gb RAM, you're getting a crash. No ifs, ands or buts. Sometimes instability before. And this is with the hack. Unfortunately, as I noted back in my history of win64 KSP builds, this was tried. Still had nearly all the users coming to my thread. The only advantage is that it's a little easier to figure out what's going on sometimes. We also both know that if a win64 issue comes up you'll blame it on the mod; it's impossible to convince people that's not the case. Win64 KSP guarantees failure is contradictory with what? That users blame the mods anyway and bury legitimate issues? Or are you trying to argue that there are issues that are on all platforms is proof that win64 is completely blameless in all ways, and that's it's never caused crashes? I don't see why we would, Linux 64 has always behaved. Just like all the win64-pushers, you ignore this because it's inconvenient. Windows users would, yes. Linux users would not, because Linux 64 doesn't crash frequently, and so isn't disabled. Why do you ignore that it's only win64 that is locked? Does it hinder your argument that it's irrational hate of x64, because all the mods that you're screaming about aren't locked on all x64 builds, only the busted (read: win64) ones? The only 64bit-specific mod development that has occurred is the development of the detection of whether the KSP process is a 64-bit process on a Windows system, i.e., "is it win64 KSP?" Perhaps you noticed that everyone downloads the same dll, regardless of OS or word size; that's because the code is identical in all those cases. C# compiles only to bytecode, which is then turned into machine code specific for that system by the Just In Time (JIT) compiler. The end result is that we can't do any win64 development for mods, because there is nothing to develop. It's exactly the same as win32, and OS, and Linux 32, and Linux 64. I would suggest that you actually get into modding and attempt to handle any of this if you don't believe me. There is jack that we can do for this problem, and the only people that do seem to think it have some idea that coding is magical, that modders are witch doctors, and that the only thing they don't get what they want is because the modder is a big meanie that won't chant the right words. It doesn't work that way.

I don't tend to venture in here, but this is relevant to me. CKAN has caused no less than 4 different kinds of installation errors for FAR, 3 in the past two months alone. The first was simply not including an option to wipe all the files in a directory, so CKAN users ended up with incomplete atmospheric data for planets. The second was that it didn't install a hard dependency. The third was that it installed the wrong version of a dependency that only had one publicly released version. The fourth was that it screwed up getting the version order correct, because 0.15.3.1 obviously comes before 0.15.3_Froude. From experience, no, it doesn't do a good job with FAR; I have no idea why it breaks things that manual installs don't so often. I have to wonder how many other mods get hit with this that no one hears about because they have smaller userbases. But I hope that that answers for the "hate." It's not hate, just wariness of an app that has proven itself to be trouble.

@gogozerg: Confirmed, and no idea what's happening there. I suspect something wacky with the new heat system and the areas that FAR calculates for heating. @FourGreenFields: Ah, integer overflows, my old friend. Fixed in the dev build by switching to longs, I'll look into putting a cap to ensure no overflows above that.

Some are compatible, some aren't; pretty much any mod that works with the heating system in some barely-connected way will need updating for sure, others might not. You'll need to update any of the ones giving compatibility warnings though, those won't automatically go away. For auto-updating mods, there is that CKAN thing that people talk about, but in my experience, it's screwed up a surprising number of mod installs, so if you want to risk it, you can try that.