steve_v

Interesting, this thread seems to have returned from the dead. So be it. Agreed, it's a common argument from those pushing MacOS or *nix as a "better OS"... I prefer GNU/Linux or BSD personally, but malware has very little to do with that choice. There is more malware in the wild for Windows, but avoiding it only requires common sense... unfortunately, popular as it is, Windows tends to see lots of users with none at all. I do tire of the "every second third party app is trying to dupe you in some way, usually for money or advertising" thing that seems to go on with Windows applications though, I'm not sure if the same is true for OSX. Then again, maybe I'm just used to open-source everything, vetted by distro maintainers... after all, 'tis pretty hard to sneak malware or adware into something like the Debian repos without someone noticing, and usually kicking up one hell of a stink. Also true, and even more flexible are the various FOSS Unix derivatives (so much so that it confuses new users no end )- to me, Windows is restrictive in much the same way you describe OSX. I find this mildly ironic, as OSX borrows much code from open-source unix variants... a testament to how well Apple has hidden this behind all the shiny. As for the hardware, I've always considered Apple products to be somewhat overpriced, slick and "trendy", at the expense of flexibility and upgradeability - where white-box type PC hardware is just the opposite. If you know what you're doing, you can build a PC that will leave a comparably priced Mac for dead.

I like the quoted / tagged notifications... And thoroughly dislike pretty much everything else.

Dude, seriously? It's been reported, discussed to death, and it's still (AFAIK) hideous. I guess I'll just keep using mod fairings. If you're referring to putting such things on the bugtracker, I was under the impression that was for bugs... and the "suggestions and development" subforum was for suggestions - which this clearly is. I'm not sure why anyone bothers to bring these things up tbh, it's seems clear nobody from Squad is reading this.

I'll believe that when me poop turns purple and smells like strawberry sherbet... but one can hope. 64bit OTOH is becoming a necessity... I don't care much personally (GNU/Linux here), but the stock game is getting dangerously close to the limit as it is, and this pretty much means no new parts or not-boring texture updates until 64bit on Windows is a thing... Or until some form of texture management / streaming is implemented, like most other memory intensive / open-world games.

I could dig a "CausesGluttony" config option sitting next to the existing "CausesDeath", but personally I think loosing all the supplies is a fairly small price to pay for starving ones kerbonauts for two weeks. OTOH, I turned the death clause on as soon as I found it - seems a mite too easy otherwise.

I'd post my own examples, but I'm lazy and a 5 second search of this very forum does it for me.

Exactly. Not done to improve performance (though this is nice, thanks Unity) but because the system they were using went away. *cough cough* ~15 minutes of script-writing to do it for you *cough cough* Almost zero man-hours in this, if you use a command-line utility (e.g. nvcompress) + some script foo. You could even run said script at load-time, as ActiveTextureManagement does. I'll also note that this "optimisation" comes with some extra ugly compression artefacts...

Uh, yeah... which is why that wasn't the whole sentence: The bit I take issue with is the "Squad is doing things to make the game run better, i.e Unity 5", when most if not all the credit for speculated Unity 5 performance improvements should be going to those who optimised Unity 5. I see Unity getting the blame for a whole raft of bugs and performance issues, on a semi-regular basis. What I haven't seen is optimisation or performance improvements from Squad, that don't involve waiting for a game engine update. --- Of course they do, but again it's simply taking advantage of new features provided by Unity. If the UI system was such a performance black-hole, why has it taken so long to do something about it (AKA wait for Unity to fix it)?

Yeah, to take advantage of the new UI system in U5. If it was being done for optimisation reasons alone, why wasn't it re-written long ago when its deficiencies were first identified? To quote your link (emphasis mine): They have scrapped 90% of the UI in KSP. Currently 3 systems. They scrapped that. The new U5 system is so much better. This is not optimisation, unless it so happens that the new U5 UI is more efficient, in which case credit for that goes to Unity3D. Also, this: is a Crustacean. A Cetacean is one of these:

Err, don't you mean: Squad have waited for Unity to do some optimisation, and are now moving to the latest engine to take advantage of it? There's a difference between "Squad doing some optimisation" and "Squad porting to new engine version, which has been optimised by others". The way you phrase it, it sounds like you're crediting Squad for improvements in the Unity3D engine... Or can you point out some optimisation going on in Squads code that I don't know about?

Indeed, despite marketing claims to the contrary, pretty much every update since 0.25 or so has seen a slight performance decrease here. To be expected with better aero and heating going on, but if you're going to add lag-exacerbating features to the game, methinks some optimisation is in order too.

True, but one shouldn't really have low-part-count as a primary design consideration just because the physics engine is lousy. I sure do though, because it is lousy. Yeah, remember it well. KJR man, KJR.

Of course. But as it stands, there's a progression in place regarding VAB/SPH upgrades that pretty much says: "200+ parts is where it's at, but you gotta spend funds to get there"... when in reality that part count makes the game engine choke on most current hardware. 30 parts in tier 1 is limiting, but the jump from 255 parts to unlimited for tier 3 is utterly pointless - the engine just can't do it without seriously tanking framerates. I'm certainly not expecting the game to run smoothly with 1000 parts in one craft, but when the VAB says "part limit: 255" I expect the game to be able to handle 255 parts with some semblance of aplomb. Then there's the stutter / GC pauses, the thing that sends me running to a game that has reasonable performance partway through every career I start.

Reasonable framerates, decent multi-threaded or GPU accelerated physics that doesn't run like a gut-shot, three-legged pig at more than 200 parts. Nothing more, nothing less. Though if history is anything to go by, I'm not particularly optimistic. 64bit and physics performance are two separate issues, getting a 64bit client will do nothing to improve framerates by itself, though it should stop the out-of-memory crashes.

At risk of sounding like a smartass: Find and fix the code generating the unhandled exception?

While I hear you on the broken throttle settings, this: Is a real quick way to not get support.

Yes, joystick support is broken, and has, AFAIK, never worked in a satisfactory manner. But, you see, it's a "Unity issue", and we all know what happens to those. Nothing, zip, nada, at least not from Squad. Wait and hope the next Unity release fixes it. This gets real old, real quick. Dunno why the devs think that anything that can be pinned on the game engine isn't their problem, but it sure seems to be what happens.

Probably the well-documented 32bit memory limit (AKA too-many-mods syndrome). Posting your ouput_log.txt or player.log would pin it down, I'd say with 95% certainty you're running out of 32bit address space (assuming you're on Windows).

Where's the poll option for "less appallingly lousy performance"? The update I would like: Solid 60fps on a mid-high end PC with ~250 parts, and no stutter/framedrops.

In which case it should either generate an error and retract again, or simply break. - i.e. collide with the shroud.

How about we try this the other way around, as valid use-cases (Soyuz etc.) have now been presented. Have you any use-cases where this mechanic is actually helpful? If I stage an engine before I meant to, that's my screwup - whether it was inside a fairing at that point is completely irrelevant. What does this add to gameplay, besides aggravation when engines unexpectedly refuse to operate? The 'wings' example is irrelevant, wings not working inside a fairing is obvious and emergent... from the fact there is no airflow. Engines do not have the same limitation, hell, they'll work quite happily underwater - why not inside a fairing, or a closed cargo bay for that matter? I can't actually think of any part I'd want disabled when inside a fairing - RL radio antennas work just fine inside a non-metallic shroud for example. On the interlock argument, is this not precisely what the "lock staging" function is for - preventing unintended engine firing or stage separation? As far as I can tell, this is just a half-arsed fix for the half-arsed nature of fairings and the lack of same-craft collisions. Antennas or rocket exhaust coming through a fairing wall looks silly - hey, I know, lets just disable them. Or, one could fix the issue properly, and have things collide with the fairings / cargo bay doors as they should. Same goes for wings, model aerodynamics based on actual shape (ala FAR) and the problem of wings providing lift inside a fairing and needing to be disabled goes away by itself.

I call shenanigans. Built many a VTOL in 1.0.5, they just need more intakes, and the right type.

I was kinda looking forward to voxel water drag too tbh, but at this point half-arsed stock drag is certainly better than none at all. Here's hoping a solution can be found to overriding the stock system properly.

Thanks boss, I hear ya on the hotfix thing.

Yeah, that's pretty much what I'm seeing too, I just had a go with a fresh install + FAR, and what little drag I get on the water could easily be aero drag only - my craft decelerates at a rate comparable to rolling down the runway, brakes off. As I write this, it's still cruising along at 40m/s... and I landed some 20km back. Edit: Went away, made a coffee, came back... craft now upside-down, still doing 30m/s, I swear I've seen it actually accelerate... yep, down to 25 - back up to 30, something real funny happens when I get the splash effect. Still going, doing 35 now... Comparison with stock coming soon. Sorry to say... it's gotta be FAR. Stock has plenty of drag on the water - so much so that my test craft no longer has the thrust to break 50m/s. Same craft, no other mods, no phantom acceleration either.