ferram4

Well, it works. No idea why the version info is so restrictive though.

@Tortoise: Well, nothing is crashing at all in any of your logs. It's not working, but that's very different than a crash. Words mean things, please try to use them correctly. @ExiledViking: If it's bundled, it's a non-issue. If it's coming through of CKAN, if the SHA is the same it's a non-issue. If anything has modified it somewhere along the way, maybe it is. I dunno why MiniAVC would log it as an issue to begin with unless you're trying to use Kindelberger on something other than KSP 1.1.2. Everything is set to work fine with KSP 1.1.2, but KSP 1.1.1 and 1.1.0 will not work with it.

Hmm. Then I'd suggest uninstalling FAR completely and reinstalling, because this isn't something that I've been able to cause with just stock craft following the launch->revert->breaks steps.

@Tortoise: Can you reproduce the issue with a purely stock craft with no mods affecting it other than FAR and provide that craft file? It's really just launch -> return to SPH -> NREs? What about the crash you were talking about?

@Kitspace: Because that's what happens when surfaces stall, they get large pitch down moments. And the less-deflection-than-actually-happening visual is just an effect, it is deflecting as much as it should be. @Tortoise: I'm not seeing the game end in a crash in there; did you link the wrong log file? I do see FAR breaking somehow, but I need full and complete (read: causes the issue every time by only following those steps) reproduction steps to cause that as well as a full modlist.

...even now seeing people saying that NEAR was easier to use than FAR makes me laugh. It was so much easier to get into flatspins with NEAR than with FAR, but no one complained just because more difficult with less information available somehow translated into easier. That was pretty much the only change other than no UI or options. Anyway. There is a very, very easy quickfix to KSP wings that could be made that don't have to worry about overall geometry at all, which is that the wing lift curve (ignoring dynamic pressure, just handling Mach effects) as a function of Mach number is completely wrong. It should follow approximately 1/sqrt(1 - M^2) at M < 1 and 1/sqrt(M^2 - 1) at M > 1, which of course breaks noticeably near Mach 1 so some simple fairing between the curves from Mach ~0.8 to Mach ~1.3-1.4 fixes it. This is similar to what FAR does. Stock instead has a curve that decreases in silly ways that makes lift far too low at high speeds, as shown below. Note that the huge drop in lift at such low Mach numbers means that stock has to apply a very high base multiplier to get planes to fly reasonably at around Mach 0.5 - 0.7 (170 - 238 m/s) where most fighters are intended to fly. The end result is that you have multi-ton shuttles and fighters being able to float along at 30 m/s when in reality 70 - 80 m/s is the lowest speed they should be able to manage with full flaps. Before even attempting to handle any kind of shape effects, this curve needs to be fixed and the base multiplier needs to be changed; whether it's set to assume that everything is U-2 wings, shuttle wings, or some compromise doesn't matter so long as lift as a function of Mach number is right. That'll fix a lot of the "things feeling wrong" effects right away.

Reentry FX aren't controlled by FAR, those are set by the stock game based on the current velocity and air density. As for them being stronger without FAR, that makes sense since stock KSP greatly underestimates the drag for blunt reentry vehicles. All the behavior here sounds about right, and if these planets are actually Kerbin-sized with Kerbin-scale atmospheres then it should be exactly the same as reentering in the stock game.

@Tricky14: That's called, "first stock wheels are borked, never use them." I don't have any more advice there, I'm afraid. @Svm420: Not possible. FAR gets the prefab mass and then adjusts the mass change it reports so that it completely removes that. If you could bring the mass-strength slider down to 0, the wing mass should become 0. Only other option is that after creation pWings is setting the part mass from 50 kg to 100 kg and then letting FAR take over, and in that case it needs to stop doing that. Nothing I can change. @Tau137: Confirmed, tried to fix, cannot fix. The mesh and colliders for that are simply not set up in a way that allows FAR to detect that the shape is completely continuous along the vehicle, and because of that there really isn't anything I can do to fix it. When it's deployed, FAR models it correctly, but when it's folded up, FAR will provide higher drag than it should and without the colliders being lengthened and solidified (or the mesh being closed off) that'll never happen. Trying to fix it on my end would be a nightmare of edge cases and terrible things happening, so it's not in the cards. @Everyone going on about the damn Tweakscale bug: Please don't continue to report bugs that were mentioned to have been fixed in the dev build the page before. Doing that just delays development and bugfixing because I have to check to make sure that I'm not missing something that I already fixed or that you're not using the dev builds and are reporting that the bug wasn't actually fixed. It slows things down and creates confusion, so please don't. I understand that you're trying to be helpful... but you're not right now.

Yeah, that was... actually, I feel bad, that battle just didn't seem fair. I was expecting to lose, since I know that a single engine fighter can beat the Tytonid at its own game (stupidly high P/W), but I guess we'll have to see if the 3rd round battles have that. Anyway, tips. So the first are on AI settings. Most of the aiming difficulties come from the base proportional pilot factor being far too strong; it makes the AI overshoot like crazy. Dropping that helps keep the plane on target. Problem then becomes that the damping factor is so high that the plane doesn't turn, roll, or anything very well, so the next step is to drop the damping factor. I think the Tytonid has ~6.5 proportional and 1 damping set, but I don't remember exactly. Only problem that can remain at this point is that the AI might be very timid about initially turning the thing around with those settings, which can be easily fixed by building some angle of incidence into the wing or tailplane (positive for the wing, negative for the tailplane) so that it naturally produces 1g lift at some kind of speed. The next thing to look at is power to weight ratio. Higher P/W means a higher top speed, a higher speed for maximum lift turns (and a faster turn rate in degrees, but a larger turning circle), a higher sustainable climb rate and better zoom climb performance. For the most part, you increase P/W by losing unnecessary mass, which has the advantage that the plane needs less lift, which means less drag (or even smaller wings, which means even less drag) for level flight, tighter turns, better acceleration, and better airbrake performance. I think the Tytonid is only 20 kg over the 6,000 kg dry limit for heavy fighters. Since the dry limit is 2,500 kg for light fighters they should be capable of much better P/W than the heavy fighters under most circumstances. Only reason to sacrifice on P/W is if increasing it with engine power severely hinders your flight performance for some reason. The next is to look at roll performance. The AI isn't very good at truly thinking ahead, so you need very good roll performance to make it stay on target. Remember that it's easier to stay on target by pulling up or pitching down onto the target and that the rudder is only for last-minute corrections and that yawing to get on target bleeds your valuable energy in the first place. It also makes near-to-the-ground dives safer because the plane has time to roll upright for the pull-out. The Tytonid has rather, uh... impressive ailerons to make the heavy double-fuselage design capable of rolling fast. After that, the thing to do is build a bunch of aggressor craft for it to fight. Build BnZers, turnfighters, energyfighters, whatever you can to fight it. Deliberately choose designs that are different from each other to hit everything; don't use the same engines or armament. As you improve it, make the aggressors start breaking the rules in terms of thrust, weight, or armament. When you lose, watch the battles from both your craft and the opposing craft, looking at g loading, speed, turn circle, etc. to find where your design is weak. If the weakness can be rectified with no downside, do it. If it can't, see if doubling down on your strengths can improve things. If you can't beat it after that, really dissect the aggressor craft to see why it's better, and try bringing over what you learn to your design.

@pellinor: I'll try it, but my initial tests still have everything breaking. Dunno why, I'm adjusting the mass to the "new prefabMass" that TweakScale sets but it's not working. No idea why yet. Nvm, I got it working. Seems fine, and things don't break with the FAR dev build now. @Svm420: I hate ModuleMassModifier so much right now. @SpaceEnthusiast: Your initial post had me wondering if there was a bug, but if you're deploying a parachute to get this to happen, then no wonder. That's gonna jerk the rocket around pretty hard when it deploys and I wouldn't be surprised if your joint failures are because of the stock joints failing, not anything FAR does.

@pellinor: When you've got something worth testing say so and I'll try it out, then if it works we can deploy our fixes.

This is not the case. This was a risk updating between some earlier versions of FAR v0.14.x.x to other versions of v0.14.x.x. It was not a problem updating from any version of v0.14.x.x in the wild at the time to v0.15. The problem with the update to v0.15 was that FAR introduced a new dependency (ModularFlightIntegrator). CKAN's metadata did not install this properly, and CKAN did not do any checking (automated or otherwise) to ensure that the metadata it created would install everything bundled in the zip. As a result, CKAN users never got the dependency and their games broke. Once that was fixed, CKAN distributed a slightly out-of-date version of MFI that would cause any install with both FAR and DRE installed to crash. All because CKAN did not do any error checking on its auto-created metadata. Since then there haven't been any FAR updates that would fall afoul of the "CKAN not deleting entire folders" feature. Also, that feature is not capable of creating install errors should one uninstall FAR with CKAN and then reinstall it. The only source of errors within CKAN for causing FAR errors is either within the metadata or somewhere within the code itself. I don't know which.

@pellinor: I have been able to access the MassScale value from the partmodule successfully. However, when the OnRescale function runs MassScale reports 1. I can't afford the overhead of constantly checking the MassScale value to see if and when it changes, so at this point the ball's in your court.

@Svm420: That would raise the question of how it knows which one to use. The main problem is that I can't access the massScale field easily simply because the ScaleRedist doesn't expose it through the rescale functions. I could assume that mass only goes with scale^2, but then if that ever changes everything goes to hell. @nobodyhasthis2: The only issue that I know of on the CKAN github that I'd consider fitting the bill of "supporting" my position is anything related to #1607 or #1610, the former of which is very relevant and that I am aware of already, and #1610 the same but really isn't relevant considering that most CKAN errors with FAR (where I can even figure out what went wrong) seem to be related to distributing the wrong version of dependencies; I doubt that the leaving files behind issue would actually matter because FAR hasn't updated its config files in awhile due to no need to do that, and any issues that will occur won't affect FAR installs, only installs that had FAR and don't anymore. So that then leads me to the question again of what issue you're actually talking about, since it can't be either of those, because why would you try to hide the issues that I'm already aware of? Hell, why would you try to keep someone who has a serious problem with CKAN's handling of metadata in the dark about their discussions of that in the first place? Also... this thread is about FAR. Normally it sticks to FAR development and support, but discussions about how CKAN affects FAR is on-topic here.

@Svm420, @Razorfang: The problem is that FAR previously was able to simply set the mass based on the surface area and whatnot. The problem is that the requirement to switch to ModuleMass (because KSP changes) forces everything to work through mass changes only, rather than setting it directly. So I need to know the base mass. Which Tweakscale changes. Apparently my attempt to work it back by calculating Tweakscale as multiplying mass by scaleFactor^3 didn't work, so I'm not sure what the actual solution is here anymore. @MisterFister: I think you're being too generous towards him. There isn't much point in not linking the issue if it's just stuff that has been rehashed before, the only reason to not link it is because it's probably leaning more towards, "blame ferram4 for all the issues" sort of stuff. A bunch of people involved in CKAN seem to think they're going out of their way to accommodate me when they're really finding ways to avoid fixing the fundamental issues I have with CKAN. At least that's the gist I got from the few issues I found searching through the github for anything that might fit the bill. Oh, one of those issues was basically what you are asking for as a change. It was closed as being outside the scope of what CKAN is supposed to do / to avoid acknowledging CKAN's issues rather than merging it. The most likely case of it happening is if they decide to go for it after I say this to prove me wrong; which would be nice, but that would require them to be motivated by spite, and I don't think that's the case, I think they just don't care about the problems they cause and have. But basically, that's probably not gonna happen, because CKAN acknowledging that they have a history of screwing up undermines their argument for why they're useful. The main reason you're being sent on a wild goose chase is that, 1) CKAN devs and contributors would prefer modders to handle the metadata and present things as if that's the case to convince users that modders support CKAN a lot more than they do, 2) But modders don't tend to handle the metadata, because it's not what we've taken on, leading to, 3) Back and forth before CKAN contributors finally accept that it's their job to handle it.

@Svm420, @Razorfang: well, you can try the dev builds on github and see if they work. I've got no confidence in them since I don't use Tweakscale due to all the issues it has had. @Vegemeister: Me dropping support for Tweakscale will not prevent Tweakscale from scaling other mod parts. You have nothing to worry about there. @nobodyhasthis2: Well, I'm not sure what "CKAN contributions" it could be pointing towards since the extent of those is "stop causing problems" and "make sure that you can't cause problems," but fine, I'll believe that an issue that doesn't appear to exist actually exists. ...couldn't you guys just de-list it already and we can stop having this mess every time KSP or FAR updates? Or you can drop the "we won't de-list mods that allow redistribution in the license even if we cause issues for the modder" policy, fix CKAN borking FAR installs, check to make sure that all your metadata is absolutely perfectly correct before you push it for releases, and even though I still won't like CKAN I won't have to separate out the CKAN installs as "probably broken" and everything can go back to being nice. Like it was before you guys borked FAR v0.15 installs and suddenly created the "no de-listing" policy a month afterwards.

There is no such issue on Github that I can find. I'd hope that giving the impression that the most CKAN supporters can do is nothing is not what you're going for. Sure they can. The could read the first post, like you're supposed to do. And if they had, they'd have ended up in the right spot. But none of them do for some reason so I'll continue to berate them for not reading and following directions properly, especially since they often show up with problems for me to fix. @dannway: I dunno what happened to the Kerbal, I've never managed to cause that situation. I do see what's happening with the flag, that's probably something where I should make FAR just ignore it. @ThorBeorn: There are config methods that can be used here, but those result in huge increases in overhead to voxelize the part because it switches from using colliders (which are often good enough) to meshes (which in most other situations would be caught, but the combined collider bounds are nearly the same as the combined mesh bounds, so this doesn't work). I see what the author was trying to do though; by removing the collider there they could prevent people from being able to attach parts to the cockpit window. There is a tag that can be used to get the same effect on colliders; it is used on the stock cargo bay doors and on the cockpits in Lack's SXT; have the author look into that, it'll be better for both of us. @Svm420: I dunno, maybe Tweakscale is breaking something? The problem is that Tweakscale has such a history of breaking everything that it touches that it's probably hopeless for me to try and fix anything related to it. Maybe I should just drop Tweakscale support entirely.

@MisterFister: It is, however no one uses it. This means that if CKAN has one of its many "it completely borked a FAR install" situations, none of the CKAN people see it, and since CKAN users are insistent on ignoring the first-post request to place their issues there nothing has been placed there. I don't know if it's ignorance (probably most users) or if it's deliberately hiding CKAN usage until asked (there have been a few), but it doesn't make me like dealing with CKAN users.

@Svm420: I have to agree, "laziness" is uncalled for. Instead, use their own terms, like "convenience" and "less work." They mean the exact same thing, and we understand it as the exact same thing, but for some reason those words sneak it past people. It's very strange, as someone who understands the Virtue of Laziness, but what can you do? Use the synonyms they like and move on.

Sorry, but CKAN installs are not supported, since they have a history of installing FAR improperly. For example, CKAN has not installed MM 2.6.24, it has installed MM 2.6.23. I suspect that may be your problem.

@hoowuth: Make sure that you installed all the dependencies correctly as well. Remember that installing FAR is simply merging the GameData folder in the zip with the GameData folder in your KSP directory. Doing anything more complicated than that will break the installation. @aluc24: Install the mod correctly. There are no problems with FAR parachutes in KSP 1.1.2, with FAR v0.15.6.3, with MM 2.6.24 and MFI 1.1.3. If you do not have all of those installed, or are using older versions, or are on a different version of KSP, things will not work. I'd like to take this moment to remind everyone that support requests like these are almost impossible to answer because they do not include a copy of the output log, reproduction steps, any information about mods installed or what KSP version is being used. Without that information, I have to guess wildly like I've done above. Follow the "HOW TO GET SUPPORT" sticky in the Modded Support forum. Help me to help you.

This is likely caused by another mod. KJR has no influence on heat transfer or heating whatsoever, nor does it even touch code that affects heating. I'm not sure exactly what I'm supposed to do with this information.

Well, then either the forum screwed up and brought me to very old posts and I assumed they were new, or I am sufficiently sleep deprived that I hallucinated entire posts... ya know what, I'll blame the forum software, that's more likely. If it's a screwup on my part, sorry for the pings everyone. I'm just trying to stay on top of all the issues right now.

@cardgame: I've only ever seen that happen with SAS on, and that is to be expected. SAS is a terrible control system and doesn't know what to do with lots of roll authority. Turn it off and use a different control system if you need that. @Camacha: I have no idea what you're doing. I don't even know how you got FAR config data from pre-1.0 FAR versions... you don't need any config data for non-wing FAR post-1.0. Just leave it be. @Van Disaster: Deploying flaps generally doesn't move the CoL / aerodynamic center at all. However, it does tend to change the zero-lift pitching moment a lot, and there isn't much you can do to prevent that besides have sufficient pitch authority to balance it. @Noc: Well, it'll probably result in double-counting lift, because body sections already create body lift. You would likely be best served by just leaving the defaults alone and it should work out fine. @xau: I have not been able to reproduce this, I need full reproduction steps on a minimal mods KSP 1.1.2 install with the most-up-to-date FAR and a complete (no trimming) output log before I can do anything. Edit: did somthing weird happen with the forum? It looks like all the posts I replied to just disappeared...

That is what happens when you ignore what I say and insist on using the versions intended for 1.1 compatibility with older KSP versions. Don't do that; go get the older version and use that.