ferram4

TL;DR: Licenses should assume that everyone in the community is going to exploit them as much as possible. The previous paradigm that worked for the smaller community in the past should be replaced with a more legalistic and (inevitably) restrictive one do account for the lesser respect accorded to modders and their works as the community grows. IMO, given that we're arguing for exploiting licenses to their very limits, the mod licensing guide in this forum needs to change to give All Rights Reserved a much more prominent place and only barely mention more permissive licenses. I'd also say that we should advise everyone to go as restrictive as they possibly can just to make sure that they don't accidentally forfeit a right that they wished to reserve for themselves. It's the only way to be sure that there are no misunderstandings: restrict EVERYTHING.

Yes, FAR can get messed up trying to deal with wings made of multiple parts. This is why you should use pWings instead, which it will handle correctly. At the same time, a lot of those CoL seem so odd for the Sp+ parts that I suspect that they aren't set up correctly for FAR. It looks like there are a lot of inconsistent and wrong numbers there.

FAR doesn't change the control law that SAS uses. SAS also overrides any and all of FAR's off-by-default control systems. If you are having issues in space, it is completely impossible for FAR alone to be the culprit.

Either it's a g-force issue, or something is interfering with FAR. FAR does not apply forces in vacuum, and so things should not break off in vacuum unless a 3rd party plugin reaches in and calls FAR's methods improperly. And at that point, there's nothing that I can do, because it's not my code.

@YauS: A mod list is not reproduction steps. I need to know what you did in game. What parts you combined. How they were attached. Order they were attached. Etc. You're doing the equivalent of answering "how do I make fudge?" with "butter, condensed milk, chocolate and sugar" with no context for what to do with them. @ChrisWill: The flight help stuff is disabled by default; unless you clicked one of the buttons in the Flight GUI to enable them, they are always off, and then you can always turn them off if you choose. If SAS is causing you to flip out in space, then it is not a FAR issue; FAR applies no forces in a vacuum, and so there will be no effect on vehicle dynamics.

@kafuka: Known issue, try downloading the GameData folder from the GitHub repo to fix it. @YauS: I still require reproduction steps. I have tried all manner of attempting to cause the issue, and I cannot; you will need to tell me exactly what you did before I can diagnose the issue.

I mean, in the sense that if engines and tanks had anything near realistic Isps, masses, and thrusts that most of the rockets people build for getting to a 100 km parking orbit on Kerbin would be more than capable of getting to a 150 km parking orbit around Eve. The fact is that engines have 1/2 - 1/3 the TWR of their real-life counterparts while fuel tanks have nearly 10 times the dry mass of their real life counterparts. This works out to seriously increase the amount of mass needed for a given dV. This is necessary, or else you would have people complaining that something slightly larger than the Soyuz 3rd stage can put a Soyuz in orbit around Kerbin (considering that stage alone has ~3 km/s but much lower Isp than KSP engines, that's not hard to see happening). Our rockets are artificially larger in order to fit expectations. Oh, it's also good to see someone else who doesn't see an aerodynamic overhaul as a given. I thought I was the only one who expected it to be dropped.

Well, isn't the point of a license to compel people into following exactly what you want? That's pretty much what a weapon is supposed to do, once you go a step further than, "make things difficult / painful for you." Gah, one of the few times I don't use my beloved semi-colons! What I meant was, you were probably right, we should have more restrictive licenses if we're going with something like that, and that (based on what most authors seem to expect) we should probably just go All Rights Reserved to cover everything. Sure. But there would be less confusion. Granted, everything would appear a lot less open and permissive than it currently is, and there would be almost no change in how things go, but the clarity and lack of ambiguity and lack of doubt that it would cause for most forkers / mod packers would likely outweigh the general reduction in the, "you can do this," atmosphere. After all, you've been the one arguing for clarity here, and that will have inevitable consequences in how open the modding community is perceived to be, regardless of how it is in actuality.

Ah, I see. Your argument is that we should not at all expect the courtesy of asking from anyone who might want to do anything with our stuff, and should thus explicitly tell everyone to keep their hands off. Sounds good, I think that everyone who expects such a courtesy and is able to change their licenses to be more restrictive should look into going into a no-redistribution, no-derivative type of license. Everyone's been talking about how the community has gotten more hostile lately or some such kind of complaints, so I think it's logical to start treating everyone as if we need to constantly aim legal weapons at them to get what we want. You're completely right, most of the stuff here should be licensed All Rights Reserved, probably. It would be better for everyone, IMO.

Ok, so the argument is wasted time. Then consider this: What if they implemented an aerodynamic model that caused the dV to orbit to change drastically? We know that'll happen, regardless of if they go for a realistic (low drag loss) model or if they go for a lol-stock model, because either one will end up considering how to make the rockets pilot-able, and in the process the drag forces will be set to something different than what they are currently. Once that happens, suddenly the balance of the system is out of whack, because all of the engines and tanks are balanced around 4.5 km/s dV to orbit. At that point, wouldn't it be easier and faster to simply scale up the planets to place the dV-to-orbit at the same point as it was prior to an aerodynamics overhaul? The only other options are to nerf Isp or dry mass to reduce the dV for a given rocket size (which then has the negative effect of encouraging more staging in an atmosphere, and with a more realistic drag model staging can seriously upset the stability of a rocket, meaning it would be much harder for new players). So, if the game gets an aerodynamic overhaul, and that overhaul will almost certainly change the dV to orbit, then it will be faster to rescale planets, which can be done with a single item to change rather than changing a bunch of parts.

Good, then with us seemingly on the same page, I can make my point a little clearer: If someone with a permissive license asks for you to not redistribute / fork their project (as a courtesy) and you do so anyway, then you should not expect them to provide the courtesy of support to your users, or you, if you find yourself out of your depth. A lack of courtesy will beget a lack of courtesy, and that is something you should think about.

@juanml82: Width of payloads is not an issue. I have a rocket that will put 5000 tonnes in orbit in RSS, and it's got a 36m payload fairing; I can stuff a Saturn V and a few other rockets in there and you'd still have room to spare. It's not like there are really many limits with this guy. @Vanamonde: So then let's try going the other way then; why not scale down the universe even further? After all, if increasing the size of the universe will simply end up with the same experience for the player, why not make it smaller and we can then dispense with the problems of timewarp entirely? There are gameplay differences in the flight profiles of rockets when you change the scales of the planets. Those are the things we want; the timewarp change is simply an adjustment to deal with the fact that space is huge, just like it is in the stock game. It's not like timewarp exists for its own sake.

You really don't want to advocate for treating mods with only the letter of their licenses, because that logic can be used against you. Nearly every open-source license includes a clause that basically says, "You have no right to support," and that anything you do get is merely a courtesy. By your standard, pretty much all of us don't agree with our own licenses, but I'm sure you're not going to argue that we should tell anyone having trouble with our mods to stuff it and get lost. Fact is, we're allowed to tell you to scram based on our licenses (and we would if we followed them to the letter), just as you're allowed to redistribute / fork / whatever regardless of our feelings on it once the license is set.

Node sizes don't affect stiffness when KJR is installed, because relying on part modders to set the correct node sizes in the wake of 0.23.5 proved unwise; many mods still don't set nodes to the correct size, causing lots of fun issues. Instead, KJR changes joint strength with the size of the mesh based on a plane that is normal to the "forward" direction of the attach node. There's not much that can be done to fix wobble now though; the newer PartJoint system seems much more protective of the properties of joints, so I can't change things as much as I would like or even be sure that what I'm changing is having an effect. Further, struts (which previously held everything rock solid) were given a ton of play post-0.23.5, so they're no longer as useful.

Windows 64 bit is the problem. It is horribly unstable once memory usage gets to a certain point. Either remove memory-heavy mod (doesn't matter which) or go back to 32 bit. There are no other options.

Wait, that pic is from in-game with a new shader? So... when do we get it and how sad will my GPU be?

@YauS: I need the full output_log.txt and full reproduction steps. Just attempting to use the Stability Deriv GUI with B9 parts does not cause the issue. @tetryds: Will investigate; it should be a fairly quick fix. @dweorg: Fairing stuff is a known issue; use launch clamps. Otherwise, keep your TWR down, you're overspeeding. @Rabada: Use the smallest fins you can get away with. If you can keep it stable without fins, that's more efficient.

Lemme turn this around: You're playing a game involving (rather) realistic gravity and physics that are used in quick approximations of realistic physical systems in our models of our real life universe using the same principles to explore the solar system that we use in real life. Yes, the devs are including fictional aliens as the main characters and including lots of fanciful planets, but even still, not only would going total-fantasy turn a lot of gamers off and make it into nothing more than another stereotypical science fantasy game; there's no justifiable basis for throwing realism out, and again... physics like our universe. You can scream out, "N-body shouldn't be included, it's too realistic!" when you're building rockets that follow realistic physics and not look a bit silly.

And yet all of these are not issues with the Unity engine itself; they are issues stemming from how computers are set up in general. The original Deep Space Kraken was the result of floating point errors, and there's no way around those, and any game with very large relative changes in velocities will have to deal with that. N-body is not precluded in any way due to the engine; hell, if you wanted, you could simply run the forces of gravity through the same physics engine used for the parts and everything should work out, though the lack of symplecticity would result in some energy gain over time. However, that's a problem with the algorithms being used, not the engine itself, and you can easily code around that. Don't believe me? It's not like there's a mod in development to add it or anything. This idea that modeling something realistic is impossible in Unity is one of the greatest cop-outs this community has. I don't know where it started or why people keep repeating it. It's the worst attempt to defend non-realistic gameplay, because your argument falls apart completely the very second someone proves that it can be done, especially because it implicitly assumes that the only reason for not doing it is because you can't do it. You know, I'd bet money that if FAR didn't exist, everyone would say the same thing to excuse the stock aerodynamics system. There are reasons to argue against realism on the basis that it is unfun, but don't sit there and say that such things can't be done as the reasoning. Most of what you're talking about can already be done in sims like Orbiter and X-plane, and they already had to tackle the same challenges that KSP would in implementing those levels of features. Code is code; it doesn't decide to melt if you combine it with a certain engine.

Well, then in that case, it's up to you to ensure that your users are aware that they pester you about the problem, especially since you're actively considering bundling older (read: unsupported) versions of mods. No modder is going to be happy with you if they discover that their threads are getting clogged with already-fixed issues because you bundled that version rather than the one with the fix, nor are they going to be happy with you if they're asked to support something you implemented. It's up to you then to make sure that users only pester you about your stuff. In general, I've never been a fan of people packaging my work (though the license allows it if they want to go ahead in spite of that), simply because there's no benefit for me in it. All I get is more support requests and have to deal with older versions out in the wild for longer. You do realize that by creating a modpack, you'll be actively discouraging people from updating regularly for bugfixes, right? No one is going to download an entire pack again and again because one mod updated; they'll either download the independent version (which may conflict hard with whatever changes you've made for your pack) or they'll just not bother. In either case, users will enjoy playing less and it will be more work for all of us to support it.

If you're gonna be rearranging things to reduce the number of folders in GameData, I'm gonna tell you something you don't want to hear: you're going to have to modify every part.cfg and fork every plugin in order to make the necessary changes to the hard-coded directory structure they expect. There's no way around it without the game breaking. But besides that, once you're in the realm of changing things to make them fit, you're not bundling someone else's mods. You're creating your own versions and distributing those. Baiscally, that means that now you are responsible for all the support requests that come out of this. If you change something in NEAR to "balance" things or to "maintain compatibility" and someone comes to me complaining about it, I'm going to have no clue what they're talking about, and I see no reason for me to support anything that someone else changed. Think about it: someone still has installation issues? Your problem. Someone has uninstallation issues? Your problem. Someone has odd things happening with a part pack you modified? Now, it's your problem. Someone gets odd behavior out of a plugin you modified? Now, it's your problem. You will be stuck attempting to support a gigantic number of mods with codebases that you will likely not understand. And given that we won't know what you changed, nor do we want to deal with whatever you've changed, you won't be able to send users to us for support. This is just going to result in everyone being more ticked off when things go wrong. I think you underestimate the issues and overestimate the benefit of doing this.

@bartekku99: win64 KSP is highly unstable due to what appear to be memory issues within the game itself that I have no control over. If you can reproduce the issue in a 32 bit version or in the more-stable Linux 64 bit version I'll take a look though. If you manage to reproduce it in one of those versions, then I'll need that mod list with version numbers for the mods and a copy of your output_log.txt. If you can't reproduce it in 32 bit, then I'm going to assume it's just another manifestation of the current 64 bit instabilities.

I'd argue that KSP's rockets don't use an LH2 + LOX mix based on not only the wrong mixture ratio, but also the large density of LF. It's probably something closer to kerosene + LOX in density (in actuality, it's slightly denser than kerosene), though the lack of boiloff makes me somewhat partial to a mixture of either UDMH, Aerozine 50, or UH 25 as LF with NTO as O, since there is no boiloff at all. Kerosene, UDMH, Aerozine 50 and UH 25 are not the kind of things you use for nukes because the molecules are so heavy (which reduces exhaust velocity). Of course, lighter molecules also means lower desnsity. As long as the NTRs with the current stats run on LF with the current density of LF, they will have the performance of running on pure LH2 but using fuel with the density of kerosene, which basically means there are never any drawbacks to using them.

Odds are that it's plane design, not the mod being wrong. It is almost always plane design. Of course, the exact cause is basically impossible to determine without a picture of the plane, the velocities that you're flying at at each altitude, and how the CoM moves as fuel burns. It could also just be running out of air for the engines leading to uneven thrust causing a spin.

@CattyNebulart: Then that means that you're going fast enough that aerodynamic forces are strong enough to break you up even in stock. Yes, logs would help: Upload your entire output log (NOT ksp.log) to dropbox or something. Windows: KSP_win\KSP_Data\output_log.txt Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log Aka Files>~/Library/Logs>Unity>Player.log Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log Then I'll need a complete modlist, with version numbers. @jmanidb: Yes, and it would be great! Command pod orientation would never forced to be blunt end first, so you can reenter at any orientation you like. The only reason that orientation is forced is by drag not being applied at the CoM, and in stock, that's accomplished by parachutes (even not deployed) having higher drag than capsules. You'd never have to worry about where you attached wings, because after all, with the center of pressure forced to be at the center of mass perpetually, there's no way to build an unstable plane! Of course, there's also no way to build a stable plane either, so you'll be sideslipping and pitching out of control with no way to right things, but hey, aerodynamic forces applied to CoM means only neutral stability, not actual static stability! Oh, and funny thing about applying all the aerodynamic forces to the center of mass: without distributed forces, there is no aerodynamic damping. Now, that basically means that there is absolutely no chance that this aerodynamic system could ever stop a plane from tumbling! Of course, you could instead argue that wings remain magical special things that apply forces at their own location (for no apparent reason to the player) solely because that results in the outcome you want, but then you're setting up inconsistent physics to get a desired outcome. Inconsistent physics is bad game design and is confusing for players. Yes, this applies to stock aerodynamics (the bad game design comment), and I submit all of the players confused by why their spaceplanes-on-top-of-booster-rockets are unstable as proof that it confuses people; they have not considered that aerodynamic forces might be applied somewhere that would make the vehicle unstable because they were taught otherwise. TL;DR: Your system makes everything worse. If turned into something like stock, it maintains the privileged physics nature of wings that confuses new users. This is a bad idea.