Ignath

No one here is trying to get you to stop voicing your opinion...but we are also free to discuss and comment on that opinion, are we not? Also, people get hostile of opinions when they (intentionally or not) make unfounded accusations (like SQUAD was stealing FAR/NEAR/DRE). Whether that was your intention by your statement or not (judging by your second comment, it wasn't), that's how it came off to nearly everyone who responded to you. Nope, you're not...as a matter of fact, I'm sure Ferram was quite frustrated in things like new features being added before aero was fixed, which is why he MODDED it to make it better (at least until SQUAD fixed theirs). That is an opinion shared by many on this forum; as evidence by the amounts of downloads FAR has had since it's creation.

Your statement lacks all logic and common sense...SQUAD was supposed to leave out mostly accurate aerodynamics and re-entry heating from their flight/spaceflight game just because some other modders added their version as a mod before SQUAD included it in the base game?

So basically, by this line of thought, anything that any modder ever made up at any time that KSP has been available for play is no longer available for inclusion in the stock game...

That was revealed to be the dust that kicks up on takeoff/landing I believe...more accurately, that the exhaust is now affected by and can collide with objects like the ground and the launch pad (you'll notice that smoke now comes out of the underside of the launch pad when you lift off now, rather than just blowing down into the planet). Edit: I agree that the hype that builds around things in this community can border on the absurd; however I think, while they hype is promoted by SQUAD, it's entirely driven by the fan base.

Actually don't even have to exclude the Squad folder as far as I can tell. I just did a copy all of my GameData and CKAN folders from Windows onto an install on my new Mint partition without incident.

Are any parts overheating and causing the new overheat gauges to pop up? Those are known to have a memory leak that will cause the game to crash after a time. To fix, push F10 to disable the gauges.

CKAN will not touch Auto-detected mods. If you wish to have CKAN control the mods that have been auto-detected, I would suggest uninstalling any mods that have a dependency on that (I know RPM is a dependency for many mods, so be careful...ModuleManager is also a HUGE PITA to move to CKAN from Auto-detected, because so many other mods depend on it) which have been installed w/CKAN, then remove RPM manually, then refresh your CKAN and you should be able to install RPM via CKAN (and whatever other mods that depended on RPM). If you don't do this, sometimes the local CKAN metadata gets all messed up and you'll get stuck in a loop where you can't update w/out CKAN crashing or tossing exceptions. Sometimes it is even best to remove all your mods before trying something like this (certainly would be if your mod list is fairly small), just to be sure no "unintended consequences" occur.

Yeah, installers are still horrible to create and make work properly. My suggestion would be to do what Astronomer did with his Visual Pack on CKAN and split things up into Categories: Clouds DOE Config PlanetShine Config Scattering Config Auroras Parts ETC... That way, users could install only what they wanted and it should be easier to get up on CKAN (if you are interested in getting it on there Proot).

I'm so sick of hearing statements like these (not just from you Gregrox, but from many others as well; yours was just a convenient post to quote). No one here on the forums knows WHY 1.0 was "rushed" as everyone thinks it was. Did SQUAD have a merch deal in place they needed to hit the 1.0 milestone for (going to GOG and Pressing GOLD discs for the Boxed Set)? Did they have internal forces (management) at SQUAD to have it finished up? No one knows what the reason was, but the ultimate result was that SQUAD couldn't release a .95 and a .99, then 2 weeks later release 1.0; something drove them to have to release the 1.0 version when they did. SQUAD has no "responsibility" to tell us why, we don't own shares in the company nor do they owe us anything more than they've already agreed to do. Time to move past everyone's perceptions of what the 1.0 release "should have been" and move forward to what 1.1 CAN/WILL be. Perhaps it's time to let the wounds close on this battle and just move on? SQUAD knows that a very vocal minority are displeased with the way 1.0 went down...Max had a nice little reaction video on a tweet he sent out. Lets give them time to enjoy what little they can from the 1.0 release and then get back to work and make our game better, rather than berating them and beating them into the ground with every chance we get. THAT won't get us what we feel like we want, that will only dishearten the devs and perhaps we'll end up getting NOTHING (if I were SQUAD, after reading some of the entitled posts I've seen in the past week...I'd consider just telling you all to shove off).

Can you get out and push your original ship with your RCS from your Kerbals jetpack? That is pretty much the method of last resort when out of fuel.

You're right...that was ages ago. Now, there are FAR more people who play KSP, far more people who would "participate" (note this word is in quotes because their participation would be nothing more than "Hey, I'm going to play KSP 1.X before everyone else...Oh balls, it's broken. I must go rage on KSP forums") in the "testing" of the RC version and we'd end up with the same debacle we saw back in 0.14. No matter how many times it is said by QA/Experimentals team members, for some reason the key point isn't getting through: It's not about QUANTITY of testers, it's about QUALITY of testers. Right now, after the years of testing that some of these QA/Experimentals members have gone through, I don't think dumping thousands upon thousands of "green" testers is going to help anything...just bring about a bunch of bug reports and issues (some of which will already have been solved) that won't go anywhere toward improving the end-result. In fact, it's likely to cause the same issues that are showing up now, with people complaining about bugs that are missed and wondering why (now since there are so many testers) these "obvious" bugs were allowed to slip through. Correct, which is a choice of your own and not really SQUAD's fault. You can't expect that they'd want you (or anyone else) divulging all the information about their Experimentals testing can you?

Those city lights are coming out spectacular Proot! Amazing work sir!

Thanks regex for the Aero and Thermal buttons. I second all the opinions on this thread stating that there should have been a stock toggle (other than in the debug menu). Ignore away oh grumpy one

Started in .19 or .20 (can't remember anymore), but 1.0 is by far my favorite version thus far.

There is really no fix unless you want them to be more specific in labeling and change it to "surface speed". Speed records are based on surface, not orbital speed.

Pretty sure this is already on CKAN, it just needs to be updated to 1.0 to show up for a 1.0 install (or be marked as compatible in the .netkan file).

As I noticed you use some of TriggerAu's code in this, you should see what he's done with Alternate Resource Panel when it comes to swapping the stock toolbar. I've used ARP in that manner since he released it without issue; there may be a trick or two in there if you haven't investigated it already.

Tiberion I just wanted to post to again thank you for the work you and all the rest of the QA / Experimentals teams have done for KSP and all us Kerbonauts. Secondly, I want to thank you for posting a bit of the "process" behind what you guys do in QA/Experimentals. I think a major part of the "misunderstandings" that are happening in this thread and throughout the forums are due to a complete and lack of understanding of what a QA/Experimentals tester goes through and deals with throughout the final (literal) SPRINT to the finish line. Thanks for giving us some insight into the process.

And in all reality, this number may actually represent a BOOLEAN value not an actual INTEGER. For instance, 0 = True and 1 = False (or vise-versa). It may be just a "flag" to let the program know whether or not to include the part's mass on the part it's attached to or as it's own mass (thereby shifting the CoM of the vessel toward the part, instead of just adding the mass to the attached part). EDIT: Ninja'd on the boolean info

Just found this on CKAN myself and going to try it out. Nice idea!

It has already been integrated into CKAN...there is just no version up and ready for 1.0 yet. Once that is available, it will show up on CKAN.

Yep, watch for the typo I fixed...it won't work w/the typo.

This is what happened to my Val as well

Anyone who's already using Module Manager can also make a heatshield_fix.cfg that contains this: @PART[HeatShield*] { @PhysicsSignificance = 0 }

Man, I hope SQUAD reads and pays attention to this OP. Spot on with all points.