ferram4

As long as you're connecting parts with very high mass ratios (greater than ~15:1) there will always be a fair bit of wobbling. There is no way around this at all, it is a limitation of the physics engine.

Try the dev version of FAR from the girhub repo. That should fix the issue.

The root issue is that that is a decoupler, and KJR stiffens decouplers heavily due to the fact that they are where most of the wobble occurs. This is intended, or else that mount would likely flop all over the place under high thrust.

This is the inherent problem in KSP corrupting real-life terminology. Go yell at Squad about that, will ya? Anyway, yes, they will help. Perhaps not to the same extent as in real life (they might be more or less effective than they should be, depending on the design), but they do help. This assumes that a significant portion of your drag is due to lift though.

@Kitspace: Based on a maximum force that any part can sustain in a direction based on its orientation, using a bunch of things specified in config files and the part's size. @Gaiiden: Probably because it's not shielded for whatever reason. If the other parts are, but not that one, then it's probably got its origin outside the area that gets shielded and you'll need to adjust.

No. Inconsistency in physics is the one thing that annoys me more than anything else, and I'm not going to encourage it.

It's win64 KSP, which is highly unstable under high memory usage. Switch to win32 KSP and things should run fine.

Configs for part mods are the responsibility of the part modders, not me. In any case, since all the space shuttle mods have always been designed specifically to work with stock aerodynamics, I seriously doubt that you will be able to get them to work with FAR, since the changes in aerodynamics may be enough to make them unstable. Also, there is a search function. Google is also your friend. In fact, you probably would have found your answer in less time if you had started by searching.

Yeah, it's unstable in a straight-on orientation but stable in that sideways orientation, likely because of part masses being balanced for magical KSP-land rather than as the real thing would be balanced, which should be stable. Nothing I can change, it's not my problem, it's the stage's mass distribution.

If it's quite easy to add new destructible buildings, this could actually be lots of fun for multiplayer; you could play a nice game of Global Thermonuclear War against another player, with destructible cities, missile silos, air bases, etc. It would actually make for an interesting game mode for multiplayer (for once). Let's give three cheers for Squad, finally embracing the militaristic attitudes that started spaceflight and getting us closer to a competitive, aggressive, and violent KSP experience! After all, why else would they add something like this?

Well, no. And context-less NRE's are absolutely useless as far as bug reports go. How about you start at the beginning by following the steps outlined here.

It's win64 causing the issues, not any specific mod. Switching over to win32 will fix them.

The calculations shouldn't be that bad; that implies that errors were being thrown to the log by something else. I should know, I'm playing entirely on a laptop, and I don't get the slowdowns. For some reason, Unity's logging code is amazingly slow.

If it's locking up on the load screen, then that's not NEAR for certain, and it's not a dependency issue. It means that there's a broken part config / asset somewhere, which normally indicates an improper installation of one of the mods. And yes, all art assets need to be loaded into memory at game launch. All plugin-only mods will only use small amounts of dynamically allocated memory in-game, and are rarely the cause of memory issues.

@iamzac: Only going to be done for rotor or helicopter. VTOL engines are otherwise just jet engines, and they should keep the nerf that they have had. KIDS will not do its stuff by default for FAR. Re-balancing rocket engines is not within FAR's scope. @forsaken1111: FAR modifies drag parameters. Jet engines are balanced to counter drag parameters. Ergo, modifying jet engines is within scope, though I would prefer to simply break them completely and require the use of AJE instead. Jet engines only had the properties they had because Squad doesn't know what they're doing with respect to aerodynamics or engine performance. @dzikakulka: That's just the drag from the engine itself. The sudden contraction and all the messy garbage for the nozzle makes it pretty draggy; that's supposed to happen.

And yet the name tells me nothing about what's in it at all. At least my glory seeking mod name talks about aerodynamics. Not really, you could name it something descriptive. No, it's just that incompatibility issues only occur in code, and unless you're going to go into the mods and change their code specifically for your pack to fix the conflict, you can't do anything. The problem is that there is nothing a packer can do to fix incompatibilities while still being just a packer, and the incompatibilities that happen are few and far between. That's like saying that when you're caught between a rock and a hard place your inability to move right or left is in conflict; that's not the case. It's simpyl that both solutions to the support problem have serious downsides as a simple fact that you're redistributing another person's work. If you do provide support, mod developers and users have to rely on you to know what you're doing. The problem is you can't, simply because you didn't make or maintain the code in the mods you're distributing. So you would be a blind person leading the blind, and we'll have to try and deal with the result of users breaking things following your advice, or other users repeating your statements and causing the same problems, and then (when you finally get around to forwarding any bug reports) we have to hope that you actually got all the information necessary. All of this requires that you're at least a mod developer to start with so you know the problems that you can run into. If you don't provide support, then our support workload and frustration is directly tied to whatever you distribute. If you make silent changes to the mods in the name of compatibility, but that causes issues, then we have to deal with the consequences of that. If you don't update on time, we're getting support requests for issues that might have already been fixed because users are getting old builds with whatever bugs might be in them, and we have to pick up the mess. It's not contradictory to say both problems have their issues, especially since they're the direct results of redistributing someone else's work. Both options are terrible. There's no way around that. It's just how modpacks are. The first point, no, unless you're also redistributing those mods as a pack. The second point, no, until you make a mistake and start spreading inaccurate information, which will happen, and yes, has happened, and yes, we will have to deal with it. This was how we got people repeating that "ModuleManager conflicts with X!" (when it doesn't) and advocating for deleting it, breaking tons of mods in the process. You are assuming that users know how the mods work; a very large majority (including yourself, based on your other posts elsewhere) don't, and that's where the really nasty problems start. Ah. So you are going to dismiss all of my support-based concerns because it does not fit what you desire. And I should trust you to willingly cave once you cause these issues later, why? Or... there are all the support issues that you have completely dismissed because they don't fit your narrative. If you really think that the only substantial argument is download counts, then you're in for a rude awakening when you find yourself in the middle of a support nightmare. I am ok with that, but I worry given how quickly you've dismissed support concerns that you will continue to keep it alive, regardless of how much damage it causes. There is nothing there, primarily because the only two "essentials" I actually use change the game physics.

It would be logical to name it something that makes sense. "Essentials" doesn't actually make much sense, especially considering that I play with almost none of the mods on your list, and many of them don't really fill essential holes in the game. As for throwing your name on it, well, it looks like you're trying to bill yourself as the great packer of everything essential for KSP modding. There's not much way around it when you're not developing any of the mods in the pack yourself; you just look like you're trying to get recognition for you based on someone else's work. Perhaps you should consider making it "The Assorted Tools" pack or something like that, a name far more descriptive of what it actually is. Good! You should do that before you release any packs though. You should experience what happens when someone who doesn't completely understand your code tries to provide support, and provides it badly. You should experience the effort you need to put in to correct inaccurate "common knowledge" that crops up when people out-of-the-know start trying to help with mod support and perceived incompatibilities. You should experience the joy of trying to stop a rash of people from deleting a required dependency because someone said, "this fixes it!" when it didn't. You should work on your mods and release them so that you can see all the trouble that someone like you will cause when you provide inaccurate support info. And make no mistake: you will provide inaccurate support info. You can't know any of these mods better than their respective authors, and so you will inevitably make more mistakes in support than they will. And both the users and mod developers will have to deal with the consequences of that. And if all of my worries come to fruition, what then? Will you close up shop? When the problems inevitably occur, and we come to you talking about the issues that you have caused, will you accept that they are legitimate and concede, or will you continue to deny that they exist? Why go through with the forwarding at all? What benefit do any mod developers get from needing to have bug reports forwarded to them rather than given to them directly? What benefit is there to users and mod developers when you're sitting there as the middleman in between us? Why do we need you, when we've gotten on so well without you? I don't see what I would want in one, because I don't see the point of a modpack. Ever. So I guess the answer would be nothing, then.

Well, I must say that's impressive. At low speeds you have managed the almost-unthinkable job of making your plane statically stable in pitch, but dynamically unstable. Good job, that takes work! Okay, the airframe looks decent, though I'd probably say that the slope of your moment coefficient (in the static analysis) is a little steep, which probably makes pitching difficult. To fix that, you might benefit from moving the horizontal tail forward a bit, reducing its size, increasing the size of the elevator on that (not sure how you'd do that, but it will help) or build some negative angle of incidence into it to make it easier, since I doubt you're looking to dogfight with this guy. The yawing and rolling are probably due to some minor asymmetry somewhere on the design. The usual suspect is the vertical tail not quite being straight; general solution there is to mount it somewhere where it is straight, get Part Angle Display and use that to guarantee that it's straight, or go for two vertical tails which should balance out. Even if it looks straight, sometimes it's not. It might also be smart to drain the wings and run the fuel from the fuselage, since that will shift your CoM back a bit.

So you didn't read the first statement of my last post. My attitude on that can be seen quite clearly there, that there is a market, but not for your main stated purpose / benefit, that of fixing incompatibilities. Because there are rarely any incompatibilities, and more importantly, when there are, you can't do anything to fix them. So you're not doing anything beyond what the average involved user of a mod does then. So in the case of the rare incompatibility, you're seriously considering just letting it silently disappear so that mod developers aren't aware of the issue, and thus can't fix it? You're actively harming mod compatibility then. This, at least, is an example. Thank you. This, however, is guessing. If you can only provide one guaranteed example out of all the hundreds of mods we have, then incompatibilities are very much not a problem and your pack and claimed services are completely unnecessary. Hint: if there are conflicts, there aren't work-arounds. And in the process, instead of bringing up the issue to the mod developers directly so that they can address it, you're hiding the results away somewhere else. Why? What benefit does doing this provide? It's not incompatibilities! It's old bugs in each constituent mod itself, separate from any others. Those are the issues I worry about, issues that you are not seeming to comprehend. Once again, what value are you providing with this? You have consistently ignored the fact that incompatibilities are not a serious issue and continue to state they are, as if you stating this again and again will make it true. It will not. There are not enough compatibilities to justify your efforts (as shown by the fact that you could only provide one incompatibility out of the hundreds of mods we have here) and of the one that you have provided as an example, you have not explained how your efforts alleviate that issue any better than we have done before you arrived. I would suggest that rather than trying to gain your fame on the backs of others while providing no value in return that you attempt to create your own mod. That will provide value to the community, and will also make you far more aware of the issues involved in creating and supporting a mod int he first place. If you choose to go forward with a mod pack from that point on, you will actually have some appreciation for the problems that can and will result from that, and you will be better equipped to serve the users and modders that you intend to support. Based on your statements in other threads, it's clear that you lack experience in developing and supporting mods, and a mod packer should not be a job undertaken by an inexperienced novice. Supporting a single mod can often be challenging; supporting the dozen or so mods that you intend to pack (as you will inevitably have to do) will burn you out, frustrate your users, and frustrate the modders who will have to pick up the slack / correct any mistakes that you make as a result of your inexperience. I know you won't take my advice, since you seem to be stubbornly refusing to acknowledge even the slightest knowledge about modding incompatibilities from people who know about them, but creating a mod (particularly a plugin) and supporting it will put you in a much better position to serve users than you are currently.

ThorBeorn: That feature was removed after experiments showed it interfered with other aspects of FAR. It will not be coming back in any form. @peachoftree: Noted, fixed with link to support guide. @planes: At a given AoA, lift coefficient increases due to compressibility effects; drag coefficient remains steady until reaching the transonic regime, where it spikes up before coming back down on the other side of Mach 1 where there are fewer separation effects. This is common stuff taught in pretty much every aerodynamics textbook that covers compressible flow. Perhaps you neglected to read the part that mentioned, "at a given angle of attack" indicating that it was not considering how much lift necessary to keep a plane in the air. Also, all of the details you are thinking of are already accounted for. @Kirspace: That's a dev version that is not ready for full release.

I did not argue that there was no market desire for modpacks. I stated that there was no market desire for modpacks for the purpose of removing incompatibilities, which is your stated main benefit of doing this. There may be a desire for that, but there is no reason to support out-of-date versions. Ever. More importantly, you shouldn't bring anything up to a modder about fixing an old version of their mod; they have likely already made fixes and have no desire to try and support the zombie version that you are going to distribute. And which incompatibilities might these be? Do you have examples? If it were actually a problem requiring support by a third party, surely you would have enough examples to justify it; why have you not provided any like I asked? So basically, in the end, for all the talk about dealing with incompatibilities, you provide no way to resolve them yourself; you simply shift any discussion of any (rare, I must reiterate) incompatibilities to another thread where they will not be seen by mod developer so that they can be fixed. What value does this add? This is not a benefit. This is more users suffering issues, which is a bad thing. You think it's a lot of work now?! Take my advice: abandon your project now. You will be overwhelmed trying to provide support if you think that throwing a few mods together is a lot of work. You should probably get rid of your name from the pack then. From where I'm sitting, it looks a lot like your trying to get recognition and glory based on other people's work, while providing almost no value of your own. So, the answer I get from these is, "not updating the mods isn't a problem, because even though users will run into issues that have already been fixed and that they wouldn't have to deal with if I just updated it like I should have, they can still download the updated version from the mod author's thread, after complaining to them / me about issues that were already fixed." This is the problem that I'm talking about. You've just told me that you will cause the problem that I'm worried about, as if it doesn't end up being a problem! Modders are going to get support requests for versions that are out-of-date and should be gone, but will continue being distributed due to you leaving that version up in your download. Thank you for confirming that my concerns are valid though, you're the first mod packer to do so, and so honestly. This is the only comforting about this. However, I'd urge you to pick something closer to a few weeks (since 3 months is less than the time between KSP updates, and mods update every few weeks normally), otherwise you will cause issues. What value are you providing to this, beyond a zip and assurances that things work (the latter of which we can already provide, simply by the nature of KSP plugins)? The only "value" that I expect you will provide is to encourage more modders to deny support to users on the basis of outdated versions and due to any changes that you might make to their mods.

Really? If that's the case, there should be a very large list of mod incompatibilities that you can cite to justify this statement. I'm certainly not aware of any large-scale incompatibilities between mods that could justify any of this, and if there are any, it would be nicer to have those stated so that they can be addressed by the mod developers rather than sitting on them and delaying resolving those issues. So, what incompatibilities are there currently? This assumes that a mod developer gains value from having more users; this is not necessarily a valid assumption. The most useful users of a mod are those who are deeply interested in the feature the mod provides and are willing to provide lots of constructive feedback as well as help other users having difficulty using those features. Those useful users will be involved already, simply because they are already interested in the feature; a mod pack will only bring in people who are less interested in the mod's features, and many of them will not provide useful feedback or will simply make nasty, unreasonable demands. These are not the kinds of users that help a modder, and their only use in any other situation would be that their money is just as green as the passionate user. The problem is that we don't get paid per user, so there is no benefit at all to the type of lazy users that you are seeking to bring in. Well, then since you haven't bothered to search for the recent threads that explain why there are issues, let me do you the favor of reiterating (some) of the many problems: If you don't update your pack exactly when a constituent mod updates, you will continue to distribute code that does lacks up-to-date bugfixes. If you don't provide support for each of the constituent mods, each of those mod's authors will have to work to support your pack, regardless of what version of the mod you are distributing. If you happen to leave, your download rots, and then months after you're gone we will be dealing with issues from the last versions you packed because people are still downloading that old archive. Even while you're there, people are less willing to download a pack frequently than they are to download various mods frequently; people will be unwilling to update because not enough has changed in the pack, and then we're back to old versions again. These are all issues that become far, far worse if a modpack becomes popular, pushing the mods themselves out of the spotlight. We have been lucky (so far) in that none of the attempts have succeeded, but if you continue with this, you will need to address each of these problems satisfactorily (along with the others that I have forgotten at this moment), and no one has ever provided a good explanation of how they would solve them. Most of the time, would-be packers ignore the issues entirely or else dismiss them as far-fetched, which, I must admit, does not fill me with any confidence regarding modpacks at all.

It's a stock bug, since KSP 0.24.2. Not much you can do, besides get above 750 m/s (where the bug doesn't manifest) or add lots of separatrons. Hope 0.25 fixes it.

This thread's premise is wrong; you're doing the equivalent of asking, "what foods will make your stomach full?" rather than asking the correct question, "how much food does it take to make your stomach full?" The equivalent answer here is that if you get memory usage above 4 Gb of RAM, win64 KSP will become unstable. It doesn't matter what mods, just so long as they take up that much RAM. I know what you're trying to do. You're trying to figure out why win64 KSP is so unstable with lots of mods. The answer is, win64 KSP is the problem. The mods are fine, but KSP simply is not capable of handling that much memory usage. I'd urge you to abandon this thread and ask a moderator to close it before it fills up with misinformation and makes mod authors' lives more difficult.

This is intended behavior, brought on by very high reentry velocities. You're trying to land something that has very little drag for its mass, so it's not slowing down much. Eventually, that's too much for the parts and they start getting ripped apart. Either lower the density of the vehicle, increase the drag a lot, or do a powered reentry.