steve_v

I have no real problem with micro updates, so long as they are actually micro updates... not insufficiently tested, bug introducing feature updates that break a bunch of stuff every couple of days. I thought 1.0 meant the end of that kind of thing, but instead we get more. Because testing and quality control fail, or version numbers being meaningless somehow. Do it right, even if it takes longer. Fix all the known bugs before adding more features, one rushed modification / patch can quickly snowball into panic and more rushed patches etc. As we have seen with the last 3 updates. Aaand even further off topic... Windows 8 <shudder>. I still deal with Win2k machines from time to time, and I recon it's actually more productive, for a GUI. Give me a *nix CLI shell any day, less time spent poking about with a mouse, more time spent doing something useful. I do use a GUI, (mostly for the web browser, CLI browsers all suck for obvious reasons.) but still spend a large proportion of my time in a terminal emulator Doing support when you can say (or type) "type this command, what does it output" is a whole lot easier on my end than "click start, select foo, click icon bar, navigate to tab 3... look for the spinbox on the right... etc etc.

I'm pretty sure none of those mess with thermals... but who knows, theoretically every part has changed somewhat to accommodate the new skin heat mechanic.

Just like a sufficiently large automation project. I prefer to get my information somewhere other than a TV show, thanks.Starting over is never a good idea, and can be financially catastrophic, at least in my industry. But if that's what it takes... In the long run, reputation > immediate profit. So you fix it. There is also such a thing as evaluating proposed components and tools for suitability before starting work. It's not like Unity suddenly removed multithreaded physics and 64bit part way through development. This BS could, and should have been foreseen.

Meh, it really doesn't matter. Use steam if you like steam. Or not, it's the same files, just a different distribution method. Personally, I start it from a shell script - so I can stream it to my netbook with VGL, among other things. The force opengl switch is both pointless and MIA on Linux, as OpenGL is the only option anyway.

Thermal data appears in the right-click part menu after you enable it in the debug window. It might also show you where the heat is coming from. Hotspot also provides a slightly more intuitive thermal overlay, using "weather map" rather than "black body" colours for temperature. If it's the bug I'm thinking of you'll see it as rapid, seemingly random colour changes at warp. Do you run any (possibly outdated) mods? I know HeatControl from the Near Future pack makes the thermal system go slightly insane, there may be others.

It's true, but I'm getting pretty tired of that lame excuse. Unity is not the company releasing a "complete" (post 1.0) game. It is a poor workman who blames his tools. If I were to sell a customer an automation/software solution, and that solution turned out to be unacceptably slow and buggy because I used cheap or unsuitable components... Guess who would be expected to fix it? That's right, me. By ripping it out and starting again at my cost if need be. Why should it be any different in the game industry?

Sure it's the 1.0.3 -> 1.0.4 change that did it? Reports are beginning to trickle in of the new (1.0.3) thermal system freaking out in physics warp... Turn on the part menu thermal data, if the flux values start leaping about when warping... I'm pretty sure it is indeed "just another stupid bug" No solid confirmation or fix yet though, AFAIK. As far as I am aware, the 1.0.4 patch only addressed the save breaking / planet vanishing heatshield bug introduced in 1.0.3. Also, if you have modified the physics settings previously, make sure they aren't too far off the new stock settings. This caught me out with 1.02 -> 1.03, stuff exploded violently etc.

Is a GNU/Linux distro, so I guess you're on Linux? In which case there's a perfectly serviceable 64bit build.It's the same download, just launch with the KSP.x86_64 binary. ATM will help to reduce memory load, which won't be a problem for 64bit on GNU/Linux anyway. I doubt you'll see a general performance improvement, but it won't hurt to try it. What it will do is make initial loading take forever (while it converts textures), and any subsequent loads somewhat faster.

With regard to Stock Bugfix modules, I had removed it for 1.0.3 bug/mod breakage hunting... and forgot to add it back in. Traction silliness much improved. As for the controls, looks like there's a separate section for "Wheels" now, set to WSAD by default. However, no matter what I bind the wheel controls to (and there aren't enough appropriate keys free on the KB anyway), they simply don't work at all when in translation mode. There is no "Translation" controls page as such, just "Flight", containing "Rotation" and "Translation" keybinds (no mention of driving), and "Craft" containing Action groups etc. and "Wheels" keybinds. There's no mention of docking in the controls settings at all now. I kinda need that quick drive <-> rotate switch (AKA spacebar in docking mode) for um... "high speed maneuvering". It also allowed quick use of RCS for recovering from those "accidental liftoff" driving events. So, do I take it the wiki is now wrong, and 1.0 flat out broke the recommended driving controls? That would be very much not cool. The old control scheme was great, and I'm wondering why Squad mucked with it in the first place. Then again, it could simply be another new bug. Can anyone else confirm this so I can file a decent bug report?

No takers? Surely someone has driven a rover on the mun in 1.0.3? Can you steer in docking / translation mode?

Haven't seen this one before, fairings work fine for me (heavily modded x86_64 on Debian Jessie). Posting OS / Hardware specs might shed some light, particularly GPU/driver details. Logs too. You might also try disabling edge highlighting fx in settings, as IIRC it's known to be broken on some GPUs.

So the patcher is operational again, Claw? Because it still looks pretty broken to me, unless of course it's supposed to do absolutely nothing, with no output as to why. If one ignores the irrelevant moaning, the original (and legitimate) complaint is that the patcher is still non-functional. So, has it been fixed or not? - - - Updated - - - Since you're after "more information": KSP version: 1.0.3 OS: Linux 3.16 Debian 8.1 64bit CPU: Intel® Core i7-3820 CPU @ 3.60GHz (8) RAM: 16030 GPU: GeForce GTX 680/PCIe/SSE2 (2048MB) Mods: None Reproduction steps: Hit "update" in the launcher. Expected results: Patcher downloaded, game updated to latest release. Actual results: "Downloading patcher" appears briefly, both "Play" and "Update" buttons are disabled, no further progress (no patcher /rsync process launched, no console output, no network traffic etc.). Investigating the downloaded "Patcher.zip" reveals it is not a valid zip archive. Both x86 and x86_64 launcher exhibit the same behavior.

Agreed, FWIW. The new heat system is a shambles. As usual, a great concept ("inspired by" a mod, of course) hobbled by inadequate testing. While I'm sure it will improve with time, it's looking like 1.0.3 was just another post-release 'hot-fix' that introduced as many new bugs as it squashed. Good work on getting 1.0.4 out quick, but seriously telling that it was required at all - did nobody think that players might like to continue running games? Really? I'll be happily playing 1.0.2 +FAR + DRE until such time as the stock heating actually works properly. Once again, keeping backups and taking the word of a certain game developer with a large grain of salt pays off. If this kind of breakage is going to be the status-quo for post 1.0 KSP, I'd strongly suggest an official "earlier versions" archive so people can actually play the damn thing rather than dealing with new bugs every few days or weeks. Either that or, you know, get some quality control going...

Functional for me so far, can't comment on balance though. Try it and find out?

Jeez people, why the 64bit shenanigans again? Squad pulled the Win64 build from the store, what does this tell you about it's stability and debug-ability? Especially as there's no Win64 editor to actually test things in... Mods started with a "do not report Win64 bugs" warning, and it was ignored by entitled brats demanding support... because it couldn't possibly be the 64bit player unity causing problems. If you are clued up enough to hack together an unofficial 64bit build, you're also clever enough to remove the 64bit check from the mods you want to use - with the exception of one notable mod it's pretty easy to find. TL/DR: There's no hate, all the mods work on all the officially supported KSP builds. If you want to head into territory even Squad won't support, you're on your own.

RO can be installed with CKAN now (for 1.0.2 anyway, might need to wait for mods to update yet). It doesn't get much easier than this. -> ckan.exe install RealismOverhaul <- Viola, all dependencies installed in one fell swoop.

Argh, again with the bugs. Try this. Recon we could sticky this somewhere?

Don't. Unless the claw bugs have been fixed, when 'docking' one must always control the vessel fitted with the claw, not the other way around. But yeah, what sal said

Yup. 10char

I do wish Squad would put this stuff up in neon when releasing a save breaking patch... but anyways, glad to be of assistance.

This one?

Gah, what can I say... Bugs. Horrible, ship destroying, kraken summoning bugs. Quicksave often, make multiple backups etc. etc. Something went wrong in the physics calcs, propagated through the rest of the system, and then the kraken came to restore disorder to the universe.

Now that I have finally gotten around to landing rovers here and there in my current game, It appears I have some control issues... Previously (0.90) I always drove rovers in docking (translation) mode, so as to avoid unwanted pitch torque from reaction wheels. The wiki recommends driving in translation mode too, but I get no life from motors or steering unless I switch to rotation - obviously this has the same problems as driving in staging mode. Combined with the absurdly low traction / brake values, this is making my mun rovers pretty much uncontrollable. Is this normal behavior now, or should I be looking for something to fix? - - - Updated - - - And yeah, I have my probe core / pilot oriented in the foward direction, not that it appears to make any difference. ------------------------------------------------------------------------------------------------------------ As the most authoritative answer I have received lacks a reasonable fix, I guess we can close this now. As with all the other new bugs, I guess I'll just Deal With ItTM. I'm still not happy with it, but oh well.

To me, the simplest kludge would be to simply disable all heat conduction into parts in the (closed) cargo bay... if the doors are a perfect insulator, make the walls likewise. The point of a cargo bay is, after all, to protect the cargo... not roast it. I have already had more than one payload explode because I forgot to open the bay doors, and the probe core sucked all the heat from the main engines. This is IMO a bug, and one that need fixing ASAP. Admittedly, I tend to physics warp during the coast to apo on ascent, so it may well be related to warp. More testing needed.

Ah, yeah... Parts accumulate heat from everywhere else, yet cannot radiate at all if in a bay? Whut? How can a part in the cargo bay get hotter than the bay itself, with no internal sources of heat? Parts in a cargo bay should both conduct and radiate heat to the cargo bay walls, and thence into space. A bay is either an insulator or it's not, at the moment cargo bays operate like magical heat pumps. Thermodynamics fail.