Why the hate towards x64?

[Vanamonde]

... I see you didn't read the second sentence of the first paragraph where I acknowledged that...

... as you yourself point out...

Your words acknowledged it. Your argument ignores it.

And considering that it was Squad that truly opened the floodgates on this...

By withholding 64bit until it was put forth by others and then acceding to the demand for their official version? It was dragged from them unwillingly, which is hardly the same thing as carelessly "opening the floodgates."

... "broken" is a rather loaded and unfair term for something that was broken?

Sure is, if the thing in question was, to repeat this as many times as it takes to get the point across, withheld because they knew it wasn't ready, and only reluctantly released in the face of popular demand.

The difference was that the people asking for it to be pulled had their work directly hurt by it existing; Squad went and made things much more difficult for a group of people that created content for their game for free. Why?

Because Squad does not owe one segment of their players more than they owe another segment of their players. Anything they do is going to please some people and aggravate other people. Mod-makers are not a higher class of people deserving of greater consideration.

... none of this mess would have happened if they had never released the win64 build in 0.24.

And the players demanding it would have been screaming about it ceaselessly this whole time. And remember, they did not originally release the 64bit anyway. Somebody discovered a way to jury-rig it and make it available despite Squad's wishes.

Is it against the forum rules to state facts about what has happened if they reflect poorly on Squad?

Don't try to play the oppression card. You were not infracted and nothing was edited from your post.

You want facts? 1) They didn't release it because they knew it wasn't ready. 2) Somebody forced their hand by making a hacked version available, at which point they saw little harm in acceding to popular demand and making the official one available, despite its unfinished (or "broken", if you insist) state. 3) When people complained that the thing they had stated was unstable turned out to be unstable, they did both of the things you wanted: labeled it as unreliable, and then pulled it.

There is a lot of blame to be thrown around in this mess, but this is at least one situation where it's just plain silly to try to make it Squad's fault.

[yafeshan]

Guys, be cool.

Just go install linux for KSP and enjoy your time. Why do you even use windows at snail speed if your favorite game has a version for linux at rocket speed. Personally I planned my weekend to manage a new linux installation, just for KSP

[ferram4]

Your words acknowledged it. Your argument ignores it.

Oh, I see. The fact that I didn't give Squad a free pass like you wanted to is a problem. Or would something else have been sufficient?

It was dragged from them unwillingly, which is hardly the same thing as carelessly "opening the floodgates."

Oh my god. Someone hacked into their servers to release it? Or held their family hostage? Or blackmailed them? I mean, if it was actually dragged from them unwillingly, why didn't they say so? What made the crisis end?

Sure is, if the thing in question was, to repeat this as many times as it takes to get the point across, withheld because they knew it wasn't ready, and only reluctantly released in the face of popular demand.

You haven't answered my question:

What would cause it to count as broken? What, above and beyond how win64 was, would be necessary for that criteria?

Because Squad does not owe one segment of their players more than they owe another segment of their players. Anything they do is going to please some people and aggravate other people. Mod-makers are not a higher class of people deserving of greater consideration.

I thought the main reason for 64 bit was to make modding easier. Why ignore the portion of your userbase that has the most experience with modding?

And the players demanding it would have been screaming about it ceaselessly this whole time. And remember, they did not originally release the 64bit anyway. Somebody discovered a way to jury-rig it and make it available despite Squad's wishes.

Don't try to play the oppression card. You were not infracted and nothing was edited from your post.

Noted, but I will also note that when someone talks about things that reflect very badly on Squad, and then a moderator comes down to criticize it and play up Squad as so perfect, on Squad's forums, and there is no mention that it's a personal opinion, it gets very difficult to tell whether it is an official moderator notice or not. Especially since it is against the rules to criticize moderator actions, so basically arguing with a moderator is asking for trouble, because your posts are in a superposition of moderator statement / not-moderator statement at all times.

This is actually a serious problem with the forums. It's impossible to tell if a moderator is acting as a moderator or a user.

You want facts? 1) They didn't release it because they knew it wasn't ready.

...which was a good thing...

2) Somebody forced their hand by making a hacked version available, at which point they saw little harm in acceding to popular demand and making the official one available, despite its unfinished (or "broken", if you insist) state.

I fail to see how any of this forced their hand. I fail to see how them not thinking about the consequences of letting a (let's go with your words) completely unfinished (to the point of nearly being unplayable) version be released would not have negative consequences. I can't see how this isn't some form of negligence on their fault.

3) When people complained that the thing they had stated was unstable turned out to be unstable, they did both of the things you wanted: labeled it as unreliable, and then pulled it.

Labelled it as unstable only after, what, 3 months of (implicitly) claiming that it was stable? And then pulling the build after over a year of hell with it?

There is a lot of blame to be thrown around in this mess, but this is at least one situation where it's just plain silly to try to make it Squad's fault.

There's a lot of blame, but not for the ones that decided to make everything worse by releasing something that was clearly "unfinished"* when "they knew it wasn't ready." Got it.

*Thinking about it, I like this. It's a great euphemism, and fits KSP's development pretty well too. Thanks!

[selfish_meme]

I think your both right, yes it was an experiment that was possibly flawed. Yes they listened to users requests. The contradiction comes from who the users were. Essentially alpha testers. The game was in alpha. Only someone who completely ignored that fact would think they had a right to complain about a broken early release alpha.

This is a problem with all early release games. At least squad was listening at that point unlike many developers.

[steve_v]

Noted, but I will also note that when someone talks about things that reflect very badly on Squad, and then a moderator comes down to criticize it and play up Squad as so perfect, on Squad's forums, and there is no mention that it's a personal opinion, it gets very difficult to tell whether it is an official moderator notice or not. Especially since it is against the rules to criticize moderator actions, so basically arguing with a moderator is asking for trouble, because your posts are in a superposition of moderator statement / not-moderator statement at all times.

---8<---

This I too have noticed. Anything pointing the finger even vaguely in Squads direction is pretty quickly pounced on and there's no way to tell whether it's "Squad can do no wrong" personal opinion or something more official... Very proactive with the glowing praise and sidelining of bugs, not so much with the divulging of actual information as to what went wrong or why certain decisions were made.

If that's a personal stance, cool. If not... I'm discussing forbidden topics.

From a players perspective, modders are indeed a "special breed" worthy of more consideration, simply because they provide what the community wants and Squad has not (yet) provided.

I would have stopped playing some time ago were it not for people like Ferram filling the gaps in the stock game.

Edited June 25, 2015 by steve_v

[Padishar]

As far as I understand it, the job of forum moderators is to moderate the forums. I assume that anything they post that is not obviously related to the running of the forum is personal opinion and I would have no qualms about publicly arguing with them about it. They do not have the authority to make official announcements on Squad's behalf unless they also happen to be Squad employees. Your assumption that they even have the information that you want them to divulge is by no means guaranteed let alone that they would be given permission to post it publicly.

[katateochi]

Without wanting to get drawn into the existing arguments (and hopefully not starting a new one), I feel there is another good reason to leave 64bit alone right now; The problem is how KSP utilises memory, but 64bit is only a bandaid on that problem, not the actual cure. The cure is to address at the core game level how KSP uses memory, it still loads every single asset into memory at the start, regardless of whether that asset is actually required. In recent updates that problem has been reduced by using more efficient textures, but the game still packs every single part (and it's textures) into memory at the start and they remain in memory, regardless of whether they are going to be used. The recent improvement to textures applies to the core game, but many mods are still inefficient with their use of textures so they quickly fill up the available ram.

If Squad focuses on 64bit then they could take that as a cop-out for optimizing memory usage and modders will have no reason to optimize their mods and before you know it your 64 bit install will be using all of your available physical memory. The problem just gets delayed and it penalizes those who can't afford to just go out and buy a shed-load more ram.

The focus needs to be on optimizing KSP's memory usage, not trying to get 64bit working (that should come later).

[cantab]

Just ask the really bleedingly obvious questions early, like: "We are making a sandbox physics sim, with a huge gameworld, can we do this in a reasonable fashion with a game engine that has an already outdated, single threaded physics implementation?"

Or: "We envisage our universe to be <this> big, can we do the math and fit the textures into ram on a 32bit platform? maybe we could load textures on demand, does the engine support that?"

Squad has been fighting the limitations of Unity since day dot. The time to switch has been and gone, but it's certainly not an unforeseeable situation we're in now.

Well, what other choices were there when Harvester was starting out? A custom engine seems out of the question for a single guy with little or no game development experience doing this as a personal project on company time. Unreal Engine, so often suggested as what KSP should use, was at the time very expensive and from what I've looked into I think it's even less suited towards KSP than Unity. Similar cost issues applied to most commercial engines back in 2011, while Free engines are often weak on documentation, a big deal for a novice developer. SpaceEngine wasn't being licensed and still isn't and I'm not sure if it even has a physics model to speak of.

A discussion on making a game like KSP in Unreal Engine: https://forums.unrealengine.com/showthread.php?29261-how-to-create-planet-size-world . It sounds like making KSP in UE would be extremely difficult if not impossible.

[Red Iron Crown]

As far as I understand it, the job of forum moderators is to moderate the forums. I assume that anything they post that is not obviously related to the running of the forum is personal opinion and I would have no qualms about publicly arguing with them about it. They do not have the authority to make official announcements on Squad's behalf unless they also happen to be Squad employees. Your assumption that they even have the information that you want them to divulge is by no means guaranteed let alone that they would be given permission to post it publicly.

^^This. Our job is not to keep the forums as "pro-Squad" as possible or suppress criticism, only to keep the discussions civil and within our Community Rules. We are not spokespeople for Squad at all, and we all have our various opinions about the state of KSP and its development. Unlike some forums where I've been a member, the moderators are not standoffish here and actively participate in a many of the discussions and the opinions expressed should be seen as those of the member rather than the moderation team or Squad. The only posts that should be read in the context of "from a moderator" are those that are actually trying to keep a thread civil or polite; if it is just discussion about some topic (Squad or otherwise) then it is just that, discussion. We certainly would not use moderator privileges to win an argument or suppress an opinion, and everyone should feel free to discuss, criticize or debate non-moderation posts from moderators.

Anyway, let's return to the topic at hand.

[Vanamonde]

Ferram4, I have answered all of your other points already, so I'm not going to go through it all again. Go right ahead blaming Squad for the 64bit mess, and the Lindbergh kidnapping, and whatever else.

Noted, but I will also note that when someone talks about things that reflect very badly on Squad, and then a moderator comes down to criticize it and play up Squad as so perfect, on Squad's forums, and there is no mention that it's a personal opinion, it gets very difficult to tell whether it is an official moderator notice or not.

It's really not unclear. "Don't do that because it's against the rules" is a moderation statement. "You're mistaken and here's why... " is an opinion.

[Linear]

With ferram's argument, i think it just shows how 'fresh' the dev team is, in retrospect it was a terrible decision to release it, but a lot was learnt.

[regex]

With ferram's argument, i think it just shows how 'fresh' the dev team is, in retrospect it was a terrible decision to release it, but a lot was learnt.

This, right here. The release of the actual Win x64 client is why we have discussions like this instead of posts asking where a Win x64 client is.

[ferram4]

Ferram4, I have answered all of your other points already, so I'm not going to go through it all again. Go right ahead blaming Squad for the 64bit mess, and the Lindbergh kidnapping, and whatever else.

You never answered what would count as broken. Why not?

It's really not unclear. "Don't do that because it's against the rules" is a moderation statement. "You're mistaken and here's why... " is an opinion.

Except that hasn't always been the case. There was that Realism In KSP thread awhile back that got locked on the basis of going against a moderator (or something near to it, from when I talked to Rows about it) because Sal said something rather silly about physics in KSP, and Ippo made a snarky comment about trying that on his next physics exam. Because it was criticizing Squad after Ted and a ton of the moderators came in to defend them near the end of the thread it was locked.

To be honest, unless you guys explicitly state when it's a moderator action in your posts and when it's not, you're bringing the power you have as moderators to the front to win the argument, especially when you bat for Squad in the way that steve_v mentioned. We know how this works, we're not stupid. We know that you're only human, not perfect god-creatures, and that that means that you'll be tempted to reach for that moderator panel if you think it'll help.

[almagnus1]

Wasn't KSP x64 insanely unstable due to the Unity version they were using at the time?

I might be misremembering that, though >.>

[Renegrade]

Without wanting to get drawn into the existing arguments (and hopefully not starting a new one), I feel there is another good reason to leave 64bit alone right now; The problem is how KSP utilises memory, but 64bit is only a bandaid on that problem, not the actual cure. The cure is to address at the core game level how KSP uses memory, it still loads every single asset into memory at the start, regardless of whether that asset is actually required.

That's actually a relatively minor problem compared to the unexplained memory leaks and the fact that DX9 KSP is somehow using almost twice the memory of OpenGL/DX11 KSPs (my personal theory on that is the DX9 code somehow has two copies of each texture in memory, seeing as that's the majority of KSP's memory use..).

I do agree though that using x86-64/amd64 as a band-aid would definitely be a cop-out, regardless of where the memory is getting eaten heh.

[NathanKell]

Renegade, your personal theory is in fact totally correct. Unity 4.x has a known bug where D3D9 on PC (and, sadly, the OSX/OpenGL version too) keep a shadow copy of all textures in system RAM even after they've been uploaded to VRAM, even if you explicitly tell Unity not to (as KSP does).

The Windows OpenGL client does not have that bug. That's why you get ram savings, and why adding more parts barely increases ram footprint.

[KAO]

I am highly unfamiliar with the new upgrades Unity 5 will be introducing, will it fix the RAM shadow copy problem with DX9?

Also, I remember there was a mod in the add-on development forum that loaded textures on demand, though I don't remember if it had a great impact on the reduction of RAM usage, or a minor one. But since it was a working concept, it is a possible mechanic that Squad can implement. Though since Squads own assets don't overload RAM, I don't think they'll pursue it in the near future.

As it stands, despite DX11's and OpenGL's RAM usage reducing capability, they have a slew of their own problems that make them difficult to use with installs.

[magico13]

Also, I remember there was a mod in the add-on development forum that loaded textures on demand, though I don't remember if it had a great impact on the reduction of RAM usage, or a minor one.

I used Load On Demand extensively in 0.23 and 0.23.5. I'd get RAM related crashes every now and then, but after it added texture compression it was never an issue. The absolute best part of it was the lightning fast load times, which is the main reason I used it. Even the new DDS textures on a Stock game don't compare against a highly modded 0.23.5 game with LoD. I really wish Squad would come up with a better way of handling texture loading. I'd like to see that long before a Win 64 version, as I see the 64 bit version as just a temporary fix to the real problem. There's no reason we should HAVE to use more than 4 gigs of RAM when we're only using 1 gig of textures at once. Once 64 bit comes out and people start getting crashes from hitting their system limits of 8 gigs, or even 16 gigs... then we'll just be having this discussion again of "My game crashes when running a bajillion mods!". Plus, the complaints about load times.

[Renegrade]

Renegade, your personal theory is in fact totally correct. Unity 4.x has a known bug where D3D9 on PC (and, sadly, the OSX/OpenGL version too) keep a shadow copy of all textures in system RAM even after they've been uploaded to VRAM, even if you explicitly tell Unity not to (as KSP does).

The Windows OpenGL client does not have that bug. That's why you get ram savings, and why adding more parts barely increases ram footprint.

Makes sense - I knew it had to be something like that when forcing OpenGL rendering made me go from 2.1g to 1.2g... heh. There's little else that could take up that much memory

[DuoDex]

-snip-

You misunderstand how the moderation team works. There is no such thing as a moderator using moderator action to reinforce his own views over those of a non-moderator. If he did, he would be off the team.

If someone expressed their views in a fashion that broke the rules (and happened to disagree with a mod's opinion), of course that post would be appropriately dealt with.

[steve_v]

Renegade, your personal theory is in fact totally correct. Unity 4.x has a known bug where D3D9 on PC (and, sadly, the OSX/OpenGL version too) keep a shadow copy of all textures in system RAM even after they've been uploaded to VRAM, even if you explicitly tell Unity not to (as KSP does).

Ahh, I thought something like this was going on. I take it this is related to (or the the root cause of) the mystery malloc failures on OSX, even when KSP itself is well within the address space limit?

[katateochi]

That's actually a relatively minor problem compared to the unexplained memory leaks and the fact that DX9 KSP is somehow using almost twice the memory of OpenGL/DX11 KSPs (my personal theory on that is the DX9 code somehow has two copies of each texture in memory, seeing as that's the majority of KSP's memory use..).

I do agree though that using x86-64/amd64 as a band-aid would definitely be a cop-out, regardless of where the memory is getting eaten heh.

ah, yeah, I had meant to mention some of the other memory issues in that post. And as well as the ones you mention there are other performance related issues (that goram stutter problem, to name one) that need to be addressed before looking to x64.

* snip There's no reason we should HAVE to use more than 4 gigs of RAM when we're only using 1 gig of textures at once. Once 64 bit comes out and people start getting crashes from hitting their system limits of 8 gigs, or even 16 gigs... then we'll just be having this discussion again of "My game crashes when running a bajillion mods!". Plus, the complaints about load times.

Exactly.

[John FX]

I must say that after reading a few of these threads, there are some voices who seem to post in all of them who really are not doing themselves any favours, however strongly they feel about the topic....

[NathanKell]

In my experience OSX's limit for KSP is in practice <3GB, even though in theory it's supposed to be a full 4GB (unlike KSP-win32 where in theory and in practice it's ~3.4 GB). You combine a ~2900MB limit with the texture issue, and yeah, you can hit that stock.

[selfish_meme]

In my experience OSX's limit for KSP is in practice <3GB, even though in theory it's supposed to be a full 4GB (unlike KSP-win32 where in theory and in practice it's ~3.4 GB). You combine a ~2900MB limit with the texture issue, and yeah, you can hit that stock.

I have not had these issues, though I run the osx game at minimum. Maybe it is related to what gpu the apple has. My Intel while not very powerful chugs along fine with no issues. Latest OSX.