Sandworm

I like this mod. It is a great device for parking missions. My only criticism is that the freezer is just too big. We need a freezer for two or three kerbals, not ten. Generally speaking those of us using life support mods lean toward the realism side of ksp. But I cannot think of any quazi-realistic mission scenarios requiring ten crew members. I think a 2.5m but half-sized part for three crew would see much more use.

Do not pick a distro based on rumors of guesses. If you are considering linux for KSP then use the officially supported distros. Any linux beginner should start with ubuntu. Don't mess around with anything else until you figure things out. Don't use liveCDs. Don't use LiveUSB sticks. Don't attempt dual-booting. Do a proper install of standard ubuntu, update everything, then install KSP. And have a look around the forums. This is not the first thread on this topic.

For multiple reasons, it's a simulation. For instance many of KSP's "game" shortcomings have been replaced with more realistic physics. Take the ISP inversion. For years engines maintained constant thrust, with fuel flow changing with atmo pressure. Many called that a compromise for "game" over simulation to make launches more consistent in different atmospheres. In reality it seems that whomever wrote the original code simply did not understand ISP. So now with 1.0 it has been "fixed" and replaced with more realistic physics. If KSP was only a "game" there would be no reason to fix such errors, or at least not replace them with more realistic physics. Therefore KSP is something more than a game. "It's only a game" is the battle cry for those who once said "It's still alpha". Virtually any argument can be dismissed with "It's a game" because it places the whims of the devs above any and all other opinions. It means that the devs can do no wrong because KSP has no basis in the real world whatsoever. Such arguments boarder on fanboyism. I have some respect for the Devs, not total adoration, but enough to deffer to them on how to define KSP. And they have for years stated repeatedly and consistently that KSP is no mere game, that "simulation" really is its defining trait.

The scale is not based on fun or game, at least not now. It is an artifact of very early days, days before time warp, and is now bounded by technical issues. Making Kerbin bigger would solve or at least facilitate solutions to all number of physics issues, from aero to ISP and reentry. But KSP faces texture limits. There is only so much that you can do when a planet is coloured by a single massive texture. Look to any number of the RSS/Kopernicus threads to see what I mean. KSP is already on the low end in terms of texture quality, and on the VERY low end in terms of terrain. They cannot push down much further without drawing the ire of reviewers. Given KSPs "load everything 24/7" approach, going with more detailed planet textures would mean a larger ram footprint... not an option. So, no. Squad hasn't sat down and decided that a planet of exactly this size would create the most fun. They have stuck with a very early decision made in a very different stage of development and have either refused or been unable to revisit the issue.

Insults and anger do have a place in debate. They are modifiers. There are times when public outcry, and I mean really vicious anger, can cause an organization to move on an issue they would otherwise ignore. These days when it is to easy to close debate through heavy handed moderation, even DMCA takedowns, such anger seems needed to sway organizations. Look at Steam's recent foray into paid mods. Had people calmly disagreed with steam via polite criticism through steam-approved media, Valve would not have reacted. But sent thousands of screaming-mad kids in every corner of the internet, that moves even Valve. A few personal insults here and there can be part of valid debate. Insult is often the only valid criticism of platitudes. I've seen Squad's various developers described as "open" and "in touch with their community". Many believe they are in fact not. That is a valid view. But any statement that a person is "closed" or "out of touch" comes across as a personal attack. It is a very personal attack. That doesn't make it inappropriate or unhelpful. The distinction is that insult must always come in response to platitudes. If someone describes themselves in some positive light, or allows themselves to be described as such, only then they may be attacked through opposite description.

How about a reminder that we are all customers who have purchased a product? As such, vocal public debate allows other potential customers to better judge future purchases. To ask customers not to speak unless they are "experts" on software development or coding defeats that public good. There are many things wrong with KSP that go beyond speculation and opinion. Equally, public criticism Squad's behavior as a developer aids in decision making re this and any potential future products. For instance: The released post-1.0 product has a readily documented memory leak, a leak that leads directly to crashes on many/most machines. You don't need to be an expert on software to understand why that is an objectively bad thing. Squad has not acknowledged the issue. And after looking at their past patterns and talking to members of the early access team, no patch seems to be in the works. We will probably have to wait a couple months for any fix. Whether from lay or expert, those are valid criticisms of a team and its product.

Well, I wouldn't say that the 64bit windows release was ever really supported. Available yes, but never considered reliable or stable imho. The advantages of linux are many. I've been running the 64bit linux releases for years. They are very very stable well beyond the 4gb ram limitations of the win32 releases. My regular game runs at 4.2gb in ram. With 1.0.2's memory leaks I've seen that go as high as 10gb without issues. Lunix does exist. But anyone managing to get KSP running on lunix might deserve a nobel prize in physics. http://en.wikipedia.org/wiki/LUnix

I just started a new save using SKY. Here are some notes for anyone else. Slight change to launch location orientation so that equatorial launches are to the right, similar to stock. (in ...GameData/KSCSwitcher/LaunchSites.cfg) PQSCity { KEYname = KSC latitude = -6.5918 longitude = 118.5425 repositionRadiusOffset = 154 repositionToSphereSurface = false lodvisibleRangeMult = 6 reorientFinalAngle = 150 // New - Reorientate to launch to the right. } RemoteTech settings for new launch location. (in ...GameData/RemoteTech/RemoteTech_Settings.cfg) STATION { Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc488 Name = Mission Control // Latitude = -0.131331503391266 // stock KSC // Longitude = -74.594841003418 // stock KSC Latitude = -6.5918 // new - south site Longitude = 118.5425 // new - south site Height = 75 Body = 1 MarkColor = 0.996078,0,0,1 Antennas { ANTENNA { Omni = 7.5E+07 } } }

If Kerbin was subject to real physics, it wouldn't have much of an atmo to speak of. Whether it ended at 20 or 100km, it would be so thin as not to make any difference to rockets.

Love KW and have been waiting for this for weeks.... but what's with the heat generation? I know Squad added it as a gameplay mechanic, but the KW engines are blowing up on me within minutes. Climbing to orbit on larger-scale solar systems requires more than a minute or two on each stage. I just cranked down all of KW's heat generation by 90% (by dropping a zero on each).

I too am confused about this. I've been following Kopernicus and it seems to be at the point of usefullness, effectively released for 1.0.2 in all but name. A 3.7x version already exists. At the moment I'm not playing KSP much because the stock planets are just too easy. I was waiting for 64k, but if it isn't comming then perhaps we can take configs for 3.7 version and double all the numbers. Thr 3.7 version: http://forum.kerbalspaceprogram.com/threads/109753-1-0-2-SKY-Scale-up-Kerbalism-for-You-Includes-a-2nd-Gas-Giant-v1-5-beta

The memory leaks. They are hands down the worst bug I've seen from KSP. It's worse than the linux mousewheel bug because we may be stuck with it for months. Squad is tweeting out vacation picks while their just released product contains a documented memory leak. That is shocking.

Taking that on requires a degree of humility Squad currently lacks. There are some very serious issues with KSP. Fearing the fanboys, reviewers are just starting to mention them. I am glad that RPS stepped out of the norm to admit some of KSP's fundamental flaws. I honestly think that a few truly critical reviews are needed to shock squad out of its bubble. We players are also all in a bubble. If you have played KSP for months/years you have developed blinders to all the little bugs and ad-hoc planning. The lack of info, the horrid frame rates, the texture and modeling errors ... we take it all in stride without complaint. Just look at how quickly we all adapted to the memory leaks. They probably aren't even on squad's radar anymore. KSP needs objective outside reviewers to see what we cannot.

The fact that unity 5 is 64bit does not mean that it can be used to create stable 64-bit windows games. Unity was pumping out stable 64-but linux builds before 5. Unity5 will certainly be better, but don't assume that it will fix all the issues.

Before this thread gets locked/moved for discussing [redacted] ... http://www.eurogamer.net/articles/2013-04-10-kerbal-space-program-dev-explains-update-plans-after-fan-fury-at-paid-for-expansion

Don't loose sleep. I just tried some rockets without command pod and am seeing gimble control on the two smaller engines, just not the animation. (fyi anyone reading this, in 1.0.2 I'm not seeing gimble on the launch pad. You have to launch first). But the FG-120 is still a beast. I just cannot get it to fly with FAR. My standard 64k 3-stack rockets using three FG-120s cannot get anywhere near mach1 without a boatload of stabilizers. The 120 just doesn't want to steer. The FG-120 seems to be the issue.

Question: Do HGR engines actually gimble? I'm having problems with HGR and the new FAR. Rocket designs that I've use for a very long time under FAR and RSS are now completely unstable. But they are stable when using non-HGR engines of similar size. I'm not exactly new to KSP, FAR or HGR. I know what should and does fly. So I tried upping the gimble ranges but saw no difference whatsoever, even with silly ranges like 15 or 40. Then I noticed the exaust plumes of HGR engines don't move like other engines. The don't seem to move ... full stop. I've reinstalled eveything and am currently poking around in the cfgs to no end. Am I alone in noticing this?

Considering all it contains is this... "Root Entry modify timestamp : Fri May 8 22:16:11 2015" I don't think it is needed.

That is a temporary issue. If they really dislike this then they can edit their save files to relock the node, or cut down on science points to compensate. Mods such as this should not adjust permanent features to avoid very temporary annoyances.

Cool. I've never used filter extensions. All additions are welcome. I'm going to be crazy busy with work for the next few days, but after that I will look into the new heat system and adding CTT support.

A mildly interesting bug was noticed in the release thread. New rar should correct. When I created the rar I had 'show hidden files' enabled (linux). So the rar captured temp stuff with the tild (~) prefix ... that then caused an error when unraring into a windows environment that saw files with the same names and tried to overwright them -> access denied because winrar shouldn't be deleting files. The new v0.4 rar should be clean. My bad for not inspecting the v0.3 rar. But at least we all now know what "Adgang nægtet" means in danish. Version 0.4 Changelog 0.4 - Corrected errors in rar (duplicate file names -> access errors during install) -Moved o2/h2/food cans to slightly higher tech node. 0.3 - Update for KSP 1.0.2 (no actual changes) -Added text to last three textures 0.2 - Update for KSP 1.0 -Flipped node on large in-line can. 0.1 - Initial release -5 parts -textures -tweakscale cfg.

Ah.. I see. Should be all fixed now. When I created the rar I had 'show hidden files' enabled (linux). So the rar captured temp stuff with the tild (~) prefix ... that then caused an error when unraring into a windows environment that saw files with the same names and tried to overwright them -> access denied because winrar shouldn't be deleting files. The new v0.4 rar should be clean. My bad for not inspecting the v0.3 rar. But at least we all now know what "Adgang nægtet" means in danish. Version 0.4 Changelog 0.4 - Corrected errors in rar (duplicate file names -> access errors during install) -Moved o2/h2/food cans to slightly higher tech node. 0.3 - Update for KSP 1.0.2 (no actual changes) -Added text to last three textures 0.2 - Update for KSP 1.0 -Flipped node on large in-line can. 0.1 - Initial release -5 parts -textures -tweakscale cfg.

Polite me: Take your time with the release. Get it right and don't loose any sleep. Sunday afternoon spent waiting for favorite mods to update me: Need parts now! Drop all life and work 24/7 without pay to finish this mod! Anyway, here is my balance pass on the engine ISPs. I;m having serious trouble getting MM to alter the G47b engine. I think it doesn't like the "key 0.5" middle key on the atmo curve. I cannot find the correct syntax for that decimal. /////// Engines @PART[G90] { @node_stack_bottom = 0.0, -0.967, 0.0, 0.0, -1.0, 0.0, 2 @MODULE[ModuleEnginesFX] { @atmosphereCurve { @key,0 = 0 340 @key,1 = 1 270 } } } @PART[G120] { @node_stack_bottom = 0.0, -1.175, 0.0, 0.0, -1.0, 0.0, 2 @MODULE[ModuleEnginesFX] { @atmosphereCurve { @key,0 = 0 320 @key,1 = 1 270 } } } @PART[HGRG47b] { @node_stack_bottom = 0.0, -0.626, 0.0, 0.0, -1.0, 0.0, 2 @MODULE[ModuleEnginesFX] { @atmosphereCurve { @key,0 = 0 360 @key,0.5 = 0.5 300 @key,1 = 1 90 } } } /////// Pods @PART[Spud] { @node_stack_bottom = 0.0, -0.76, 0.0, 0.0, -1.0, 0.0, 0 @node_stack_bottom2 = 0.0, -0.54, 0.0, 0.0, -1.0, 0.0, 0} @PART[Radish] {@node_stack_bottom = 0.0, -0.5, 0.0, 0.0, -1.0, 0.0, 1} @PART[HGR_Leek] {@node_stack_bottom = 0.0, -0.735, 0.0, 0.0, -1.0, 0.0} @PART[PumpkinLanderCabin] {@node_stack_bottom = 0.0, -0.577, 0.0, 0.0, -1.0, 0.0, 2}

Well, like, ya. Everything in stages. Now that the engines are functional I'll take a look at mapping them against similar stock models. Here is engines plus pods, enough to get things functional. /////// Engines @PART[G90] {@node_stack_bottom = 0.0, -0.967, 0.0, 0.0, -1.0, 0.0, 2} @PART[HGRG47b] {@node_stack_bottom = 0.0, -0.626, 0.0, 0.0, -1.0, 0.0, 2} @PART[G120] {@node_stack_bottom = 0.0, -1.175, 0.0, 0.0, -1.0, 0.0, 2} /////// Pods @PART[Spud] { @node_stack_bottom = 0.0, -0.76, 0.0, 0.0, -1.0, 0.0, 0 @node_stack_bottom2 = 0.0, -0.54, 0.0, 0.0, -1.0, 0.0, 0} @PART[Radish] {@node_stack_bottom = 0.0, -0.5, 0.0, 0.0, -1.0, 0.0, 1} @PART[HGR_Leek] {@node_stack_bottom = 0.0, -0.735, 0.0, 0.0, -1.0, 0.0} @PART[PumpkinLanderCabin] {@node_stack_bottom = 0.0, -0.577, 0.0, 0.0, -1.0, 0.0, 2}

Here is the code for the three main engines. I'll do the command pods next, but not the soyjus ones as they need more than a node adjustment. /////// Engines @PART[G90] { @node_stack_bottom = 0.0, -0.967, 0.0, 0.0, -1.0, 0.0, 2} @PART[HGRG47b] { @node_stack_bottom = 0.0, -0.626, 0.0, 0.0, -1.0, 0.0, 2} @PART[G120] { @node_stack_bottom = 0.0, -1.175, 0.0, 0.0, -1.0, 0.0, 2}