Why the hate towards x64?

[Dodgey]

Jeef this is going to sound harsh but its the truth. You're dreaming. The debate is over we have already had it. Should a big disclaimer be enough, yes it should. Is it enough, no. You are overestimating the collective intelligence of the Internet. All we can do now is wait for a universally stable Win64 release. Like you said you are fresh. But that means that you didn't see the flames that arose from people re-releasing mods without the consent of the author recompiled for Win64. I don't usually like to be this harsh but that's what happened.

[ferram4]

Since you're asking to understand, I think I'll fill you in on a brief history of win64 KSP builds and how this has all gone. It helps explain a lot of how this worked out.

It starts back in 0.23.5. Up until this point, while Squad has toyed with win64 KSP builds privately, none of them were deemed stable enough to be released. Someone (whose name escapes me currently) in gets into modding by coming up with the method to hack a win64 build of KSP together; the same exact method that is used for the current hack. It gathers a small following, despite the random crashes, and some work starts to try and determine what mods are compatible with win64 KSP. The thread fills with contradictions and misinformation, with mods listed in the OP as "incompatible" being reported working fine later on, and lots of bad solutions throughout.

Nevertheless, because of user interest, Squad releases a win64 build of KSP for version 0.24. It is more stable than 0.23.5's hack (in that a rather critical, reproducible bug was fixed by upgrading Unity versions), but it still crashes rather frequently and without warning; despite this, no warning of its instability is mentioned anywhere in the store or on Steam. The end result is that a large number of people who had previously not used win64 jumped on to it and suffered a ton of issues once they installed mods and increased the memory usage, leading to them (wrongly) blaming the mods, rather than the broken engine/game. This is compounded with a new PartModule saving bug, that could cause issues like multiple instances of engine modules to show up on re-loaded vehicles. Simply due to the mechanisms of the bug, lots of mods got hit with the stock behavior from two sides, turning support for 0.24.0 into a living nightmare; the PartModule bug was fixed for 0.24.1 and 0.24.2, but the win64 crashes weren't, and in a bid to reduce the workload, lots of modders declared "NO SUPPORT FOR WIN64 KSP BUILDS."

Unfortunately, this didn't work. No one bothered to read OPs, people continued to blame mods for crashes due to the stock game, and a large number of users simply refused to believe that win64 KSP was unstable; if it was, why would Squad have released it, especially without a warning? In the lead up to 0.25, a few modders (including myself) asked for Squad to pull win64 builds. They were unstable, modders didn't support them, and the crashes were most often caused by high memory usage (read: above 3 Gb); if the win64 build became unstable when memory usage was still below the 4 Gb limit, why bother with it? It's useless for mods. Further, word was that 0.25 would have Porkjet's SpacePlane Plus mod integrated, increasing stock memory usage, possibly making the stock game less stable, and certainly making modding it less stable.

They didn't pull it. Instead, they only added a label of it being "unstable," but by this point, users didn't care that it was labelled unstable; they were certain it was the mod's fault, it couldn't possibly be KSP itself, and the modder not providing support was a jackass. Best solution was to keep demanding support, keep telling people bad ideas to "fix" mods that were fine (that would cause support issues later), and generally just make support work for modders. So a bunch of us made the decision to lock out mods from functioning on win64 builds of KSP using the CompatibilityChecker utility that many mods include. (Side note: locking out mods on incompatible versions of KSP was the original concept of CC; it was downgraded to warnings for the first usage after some debate, but it's funny that users pushed it back towards its original plan). If users wouldn't read the OP and understand "not supported," maybe they'd understand when they couldn't run it.

Everything. Went. To. Hell.

Apparently one KSP version with win64 was sufficient to make users expect it forevermore. Flamewars erupted, people filled mod threads with hell over this, and even threw enough flak at Squad over this that they needed to make an official statement saying, in essence, "No, modders don't owe you anything, they can choose not to support or even allow their mods to work on win64 if they so choose." Which is kind of amazing that such a post was needed, but I digress.

This leads to a few adventures in other technically proficient non-modders taking steps to try and undermine this. One of these was Cerebrate, who initially tried to release a fork of stupid_chris' RealChutes with the win64 locking removed, which was removed due to not including he proper license; this led to stupid_chris re-licensing RealChutes with a more restrictive license to try and avoid this (with a few bugfixes as well), while Cerebrate created the first of the win64 UnFixer utilities to hack the dlls as a way around this. The end result is that stupid_chris took a rather long hiatus after that and nearly quit modding.

Another adventure was that of Senshi trying to maintain win64 forks of FAR and a few other mods (I forget which), on the basis that he would handle all the bug reports and nonsense from that. Despite this, people still tried to get support from the original modders and bring win64 issues to our threads; I only found out because Senshi's fork of FAR was off of a dev version that included a rather predictable bug that occurred in a few support requests in my thread. Eventually he gave up because of win64's instability combined with the users that he had and the mess involved there.

Things stayed relatively calm throughout 0.90, with the occasional thread on this subject, some like yours, others insisting that all the modders must irrationally hate win64 because it stole their firstborn or something, few of them wanting to accept the answer of, "leaving all of this open makes modding enough work that it makes us consider quitting. Please stop making this difficult for us, or you'll eventually lose us." I guess the idea that you could be causing problems for people is best answered by being a jerk and causing problems to prove they're right? I dunno, few of the response really made sense to me with those.

And finally, the leadup to 1.0 comes around, and Maxmaps floats a trial balloon about pulling win64 on a Squadcast, and pretty much all the modders involved in this have a combination of, "finally!" and "what took you so long?" as their reaction. 1.0 comes out, win64 is pulled, sadly, Linux 64 was as well, despite its stability (seriously, never had any issues with Linux 64 and mods, no idea why they pulled that). edit: nope, they didn't; misunderstanding on my part. Things look like they might be stable again.

And then the win64 hack comes back, and the thread starts up, with people trying to figure out which mods are compatible and which aren't, filled with contradictions and misinformation... And so it goes.

Edited June 24, 2015 by ferram4

[Vanamonde]

... no warning of its instability is mentioned anywhere in the store or on Steam...

This neglects to acknowledge that Squad sensibly withheld the 64bit version because they knew it wasn't ready for release, as you yourself point out, and that they only finally did so because the hacked version was already out there and there was widespread demand for an official version even in its unfinished state. I suspect they didn't feel a need to label this thing as unstable since it was common knowledge at the time, and people were demanding access to it anyway. Please do not try to make this all Squad's fault because they did what so many people are always nagging them to do, and "listened to the community." They knew it was a bad idea, and were badgered into it against their better judgement.

... rather than the broken engine/game.

"Broken" is a rather loaded and unfair term for something they had tried to withhold specifically because they knew it was unfinished.

... a few modders (including myself) asked for Squad to pull win64 builds... They didn't pull it.

Because for each of you making this demand, there were a dozen insisting on just the opposite.

Ultimately, Squad did label the 64bit as unstable and did pull it, and yet despite their doing what you wanted, you're still mad at them and blaming them for the situation, when the real responsibility for the mess lies with impatient people who refused to wait for a completed 64bit build.

[ferram4]

This neglects to acknowledge that Squad sensibly withheld the 64bit version because they knew it wasn't ready for release, as you yourself point out, and that they only finally did so because the hacked version was already out there and there was widespread demand for an official version even in its unfinished state. I suspect they didn't feel a need to label this thing as unstable since it was common knowledge at the time, and people were demanding access to it anyway. Please do not try to make this all Squad's fault because they did what so many people are always nagging them to do, and "listened to the community." They knew it was a bad idea, and were badgered into it against their better judgement.

I see you didn't read the second sentence of the first paragraph where I acknowledged that; I guess it was inconvenient to your argument:

Up until this point, while Squad has toyed with win64 KSP builds privately, none of them were deemed stable enough to be released.

Is it really wrong to note that, for 0.24, if a user looked at the KSP download page, there was no message that win64 was unstable? Do you dispute this? Do you dispute that there are many users that do not use the forums, whose first awareness of the win64 build was when it appeared with no warning message on the store? If you do not, and you acknowledge that there are portions of the KSP userbase that were not aware of the hack or its instability at the time of 0.24 going out with it, you can't defend Squad here; they made things a lot worse through neglect.

And considering that it was Squad that truly opened the floodgates on this, and carelessly at that, I see no reason to not give them a share of the blame. Perhaps you didn't notice that it wasn't Squad throwing the contradictions and misconceptions around in my post? The implication that users were to blame? Was that also inconvenient to acknowledge?

"Broken" is a rather loaded and unfair term for something they had tried to withhold specifically because they knew it was unfinished.

I see... "broken" is a rather loaded and unfair term for something that was broken? What would be the criteria for it being broken? Would crashing unpredictably, with multiple additional bugs count? If not, what does? I get that you're trying to defend Squad, I get that it's your job, but really; it fits the definition of being broken.

Because for each of you making this demand, there were a dozen insisting on just the opposite.

For each of the modders doing that, there were a dozen users demanding the opposite. 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?

Ultimately, Squad did label the 64bit as unstable and did pull it, and yet despite their doing what you wanted, you're still mad at them and blaming them for the situation, when the real responsibility for the mess lies with impatient people who refused to wait for a completed 64bit build.

I see you completely missed the point of my post. I provided a history of what happened; that they made large mistakes and made things much worse is a fact, and none of this mess would have happened if they had never released the win64 build in 0.24.

Honestly, I'm kind of confused; I've stated facts throughout. Is it against the forum rules to state facts about what has happened if they reflect poorly on Squad? Is that what I should take away from a moderator getting involved here?

[Claw]

Is that what I should take away from a moderator getting involved here?

Quite frankly I think it has to do with the fact that there are quite a few of us (on all sides of this) who are worn down on the whole x64 debate.

I see your post as factual, and sometimes we moderators like to post personal thoughts. I would say that, as a moderator myself, it would be nice to be able to display my own thoughts on a subject from time to time without it being construed as some sort of official forum stance. Regardless of what we think and how we frame our own conclusions, our personal posts are often interpreted as some sort of official stance. I nearly always steer clear of any conversations involving the standard debates on the forum for this very reason. While not trying to speak for him, I think that Vanamonde's post is reflective of his own personal viewpoints. It would be nice if more people understood that slight subtlety, thought I acknowledge that it can be difficult to discern our personal postings from official stances.

That's probably a roundabout answer. So, to answer your questions more directly.

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

No, it's not.

Cheers,

~Claw

[Guest]

It would be nice if more people understood that slight subtlety, thought I acknowledge that it can be difficult to discern our personal postings from official stances.

It's unavoidable, especially when the post comes off as combative.

[Claw]

It's unavoidable, especially when the post comes off as combative.

I agree. Which nearly every thread that has any level of debate eventually devolves into. I've seen so many of these "why not" threads on so many topics. Regardless of how many facts are stated, they "why not" remains a mystery to some.

In all of this x64 business, I see no reason to point fingers or blame at anyone. It's unfortunate that "trying something out" that fails inevitably results in the absolute driven passion to find someone responsible for it. Rather than accepting the fact that an experiment was attempted and it fell totally flat. Here we are, many Mun's later, still lamenting over who did what.

This is a common theme for so many things in KSP. So many add-ons, so many "stock things that are broken," so many "why can't person X do something so simple?"

Because we are all humans, and we all have different things going on, and eight bosses Bob. Eight. And, my own observations after living on so many borders of the KSP world, it saddens me the combative environment that happens constantly around such a great (utterly fantastic) game. The constant pokes, jabs, and outright harsh criticism over the same things grows quite old...regardless of where it comes from or who it's aimed at. I'm not just referring to "Squad hate," but all if it. It just gets really, really old.

My non-moderator thoughts.

Cheers,

~Claw

[blackice504]

I was going to write something long but many people will not like what i have to say anyway and i rather play then be on a forum but the simple answer is UNITY, they are very slow to adopted new tech and to understand why you will have to look at a long boring history of where unity comes from and why ect here is the short version.

Most of you should know this.

The first 64bit consumer "for use at home" CPU's where released in 1993 even for Apple Acolytes they could get 64bit proc's in 1998 by 2004 64bit CPU's would be everywhere.

So now that i mention that you can see why not having programs compatible with 64bit is kinda funny in 2010+ especially when its a program that can benefit from a large memory usage, don't get me started on Multi-threading so many people with low single core performance could benefit from this even people with high single core performance can benefit as it gives more head room to allow very complex programs but anyway Unity wants to live in the Archaic times so be it so yes fingers can be pointed, but not at the modders or KSP DEV team as they are the ones that have to put up with this crap and try to get the best out of this ....ty engine, but that been said they did shave some time off dev time as Unity is very simple to use.

A good thing is that Unity Engine makes it easier for small DEV teams like KSP and Subnautica ect can release there idea and concepts with small overhead as the bigger companies with massive teams and massive funds are just ....ting out old Idea's like people don't notice.

I just hope the DEV Team at Unity start to realize just how old some features are and just add them to there Engine as i am 100% sure everyone has 64bit support and everyone has Multi-threading. "even my modem has a Multi-core arm proc in it ffs".

:rant end

[steve_v]

...the simple answer is UNITY...

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?

Edited June 24, 2015 by steve_v

[selfish_meme]

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?

Because a game is the result of the contributions of a team of developers over years of time. They could go start again but we would not have a comparable game for a couple of years. Also go watch Silicon Valley and learn about burn rate and see if you still think starting over is a good idea.

[steve_v]

Because a game is the result of the contributions of a team of developers over years of time.

Just like a sufficiently large automation project.

go watch Silicon Valley

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.

Edited June 24, 2015 by steve_v

[blackice504]

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?

Hey steve i tend to agree with what your saying, i personally would never use such an Engine to build a game on because its so out dated and rather spend the time making things from scratch if i have to rather then put up with a ....ty engine and the luxury of some prefab content, but we clearly are a different breed, but its too late for many of these games to change engines now i mainly bring it up because you would be surprised at how many programmers don't know anything about hardware ect or don't know that some hardware has been out for soo many years that the chances of a person using z hardware with a program are nill, i mainly bring it up to let people know if they are planing on releasing a game similar to ksp or just making a game at the same time been a little frustrated as for me I.T is not just a hobby its my whole life.

Another way of putting it is i have no idea why people back windows 8.1 or 10 when its a fail, not because of start bar or online cloud .... that you can never fully turn off, but the fact that it takes longer to use "not talking about performance" especially if your a person who gives support or a person that goes into control panel all the time, Even windows 7 takes longer to do things "more mouse clicks" I honestly think if Linux had the game support Windows does no person in the right mind would use Windows anymore, but that is another story, anyway i must fix my mod pack AGAIN.........

I also wish many games like KSP stop releasing so many minor updates i rather wait for something that does allot then a little then another little patch to fix the first patch that was only a little and that patch is not fully working so they patch that patch to make the first patch works that's inside a KFC and the KFC is inside a McDonald and the Fireman need ladders to go up levels inside someones dream that is shared via some wires with the aid of a drug...de de de dada da bong....."south parks intersheeption"

Or needing a mind that can understand the day after tomorrow but before yesterday during a full planetary alignment....

Please people don't get me wrong i really do like the new features but i can wait.

Anyway back to fixing my mod pack 1.03 oops i mean 1.04.723.13423.234324.3657.56456.434324.4656547645.45345345.X "Everyone hate adobe they where the first company to release micro-update annoyance technology that requires a reboot but only on a Sunday but the Sunday before last Sunday during a full moon......."

In short many software guys are on crack.

[Umcookies]

I also wish many games like KSP stop releasing so many minor updates i rather wait for something that does allot then a little then another little patch to fix the first patch that was only a little and that patch is not fully working so they patch that patch to make the first patch works that's inside a KFC and the KFC is inside a McDonald and the Fireman need ladders to go up levels inside someones dream that is shared via some wires with the aid of a drug...de de de dada da bong....."south parks intersheeption"

Please people don't get me wrong i really do like the new features but i can wait.

Anyway back to fixing my mod pack 1.03 oops i mean 1.04.723.13423.234324.3657.56456.434324.4656547645.45345345.X "Everyone hate adobe they where the first company to release micro-update annoyance technology that requires a reboot but only on a Sunday but the Sunday before last Sunday during a full moon......."

In short many software guys are on crack.

Yup, I definitely wouldn't want them to release a patch for a potentially game breaking bug that could literally ruin saves, screw those people that are effected by it, hah am-i-right?

The stock game works between patches, it's your choice to install the third party mods that effect the game play. Disable auto updates and live in your current version until a new patch comes out that you like, update then when all the mods you use have been updated. Why is this so hard to understand?

[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.

Another way of putting it is i have no idea why people back windows 8.1 or 10 when its a fail, not because of start bar or online cloud .... that you can never fully turn off, but the fact that it takes longer to use "not talking about performance" especially if your a person who gives support or a person that goes into control panel all the time, Even windows 7 takes longer to do things "more mouse clicks"...

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.

Edited June 24, 2015 by steve_v

[blackice504]

Yup, I definitely wouldn't want them to release a patch for a potentially game breaking bug that could literally ruin saves, screw those people that are effected by it, hah am-i-right?

The stock game works between patches, it's your choice to install the third party mods that effect the game play. Disable auto updates and live in your current version until a new patch comes out that you like, update then when all the mods you use have been updated. Why is this so hard to understand?

If any company gives them self more time and not rush things out the door it would be no issue to begin with that makes a program / game useless.

Just like Minecraft and Freelancer and many other games that have mods many of these mods offer far more content and game play mechanics then the games there based on hence many people use mods.

So please stop defending them there not the only company out there doing this sort of thing its a big problem though the I.T industry, Adobe been the biggest offender but then again they make money every time they trick people into installing bloat ware, give praise where its due and criticism when needed or we will all be in a world of .... storms.

kids just need to learn to wait instead of jumping on the latest stuff.

[steve_v]

Yup, I definitely wouldn't want them to release a patch for a potentially game breaking bug.

Sure, patch the bugs. But if they didn't slip through testing in the first place this whole scenario is neatly avoided.

I boycott Adobe on all levels, for this reason and several others.

[cantab]

I'd like to believe that all of us, users of x64 version, have the brains to know not to ask or demand support for the experimental version of the game.

I think everyone would like to believe that. Unfortunately experience has shown it isn't true.

The other factor I think is that Winx64 behaviour has been very variable. The original "hack" was OK, as was the first Squad release. A couple of versions later we had a Winx64 version that was flat-out broken with a bug preventing career progression (0.90 I think that was). Perhaps the new hack in 1.0 is greatly improved. Even on the same version it's often been a case of it works well for some players, is hopeless for other players, and nobody knows why.

[selfish_meme]

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.

I think you assume that this was born as a fully fledged concept, it was not.

Also Unity was at the time one of the only engines that published to many platforms.

Many of the issues we have today are the result of the evolution of the game, not the failure in planning.

This game has broken new ground and as such is well outside the repeatable box where all issues can be foreseen.

[sarbian]

As usual when this subject come we get some people who complain at modders, suffer from tunnel vision and don't care about the answer they get. The next time someone suggest to just ignore 64 bit report I'll send them 1 PM a day and tell them to just ignore them.

[includao]

I wouldn't play Kerbal without my 50+ plus MODs installed. This game survives on mods and needs more performance fixes, efficient garbage collector and a x64 client.

Modders got mad because inevitably people are dumb, blaming them for bugs. But let's not neglect the fact that many people enjoy this game a lot because of the MODS.

[steve_v]

Hear hear. I'm pretty sure everyone loves mods

Just remember that they're all gratis, and the authors are doing support of their own free will. Do not antagonize the modders, lest the modders go away and we all suffer.

[Umcookies]

If any company gives them self more time and not rush things out the door it would be no issue to begin with that makes a program / game useless.

Sure, patch the bugs. But if they didn't slip through testing in the first place this whole scenario is neatly avoided.

Mistakes are made, there's no way around it. Even patches that have been reviewed and tested for months can have bugs crop up when thousands of users get their hands on it. Plus I doubt they have a huge team to test every nitty gritty detail about the game every time they update something. It simply isn't efficient to test EVERYTHING when you've made changes to very specific things about the game.

Now, in the case with the last couple of updates there have been rather glaring bugs, I can't defend Squad on that one but still some leeway needs to be given. In fact I believe they're still in Beta mode where they believe they can use the players as the review process for updates as that's exactly what a beta is for.

In my opinion they need to adopt a similar setup to minecraft, allow people to participate in a "beta" update program, still let your dedicated users find the bugs while allowing them access to the bleeding edge versions of the game. In that case everyone wins, people can see what direction the game is going and test new parts while it doesn't effect the majority of the user base. Win-Win all around.

Will they do it? I don't see a reason not too but who knows. One can hope.

[steve_v]

The last few updates are exactly what I'm referring to.

Prior to the 1.0 release/price hike/bug injection cycle I was patiently waiting for bugfixes and a performance/optimisation pass before leaving the beta phase. I would have been fine with waiting another year or more if that's what it takes to fix all the bugs.

It didn't happen, in fact quite the opposite.

If Squad had released one stable, mostly bug free "1.0" release for those who expect to be able to play through it like a complete game, that would be fine. Make the "testing" version an option for those who like to live on the bleeding edge, but don't break everyones game within weeks of release. Repeatedly. It's really not cool, and it doesn't bode well for future development.

- - - Updated - - -

This game has broken new ground and as such is well outside the repeatable box where all issues can be foreseen.

Not all the issues, after all no plan survives contact with reality intact.

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.

Edited June 24, 2015 by steve_v

[pincushionman]

In early versions, there was no win64 port, because SQUAD didn't have the tools necessary to support it. They DID have internal releases with it, they said they did! That's how they knew it wasn't ready for primetime.

Then the community found a way to hack it to win64. SQUAD slready knew there was interest so they decided to release their win64 version alongside the 32. They even went out of their way to explain that it was buggy and they didn't have the tools to support it, but I'm sure part of the thinking was "well…people are going to hack out bastardized versions of this, we may as well give them ours so at least we're starting from the same baseline."

Now, I'm going to have to apologize to Ferram4 for the heartache it caused him, but just because it caused a gigantic mess, that didn't make it a bad decision…at the time. After all, the game was still in early access. And that's when you need to find out about that stuff.

So we had a mess. And before 1.0 released, SQUAD said "we cannot sopport this port in the production environment. Win32 is known to work on your systems, use that instead." They probably knew at this point that U5 had the potential to allow them to support it, so theydecided not to waste their time and effort anymore.

…

Now, that didn't actually address modder support. I'm not aware of modders being under any obligation to support any platform. I myself wrote and released a spreadsheet to calculate burn times, which is only available for Office 2007 or later. Not OpenOffice. Not Google Sheets. Not whatever Mac uses.

Now it generally IS bad form for a "real" mod to refuse support for a particular platform. But that only applies to OFFICIALLY SUPPORTED platforms. And I'm not aware that SQUAD ever officially supported the win64 port; it definitely does not now. It is irresponsible to then expect modders to support non-supported versions.

[Eric S]

They DID have internal releases with it, they said they did! That's how they knew it wasn't ready for primetime.

Correct. In fact, one of the devs, Maxmaps if I remember correctly, said that the reason they started shipping the Win x64 client right after a modder showed that it could be done wasn't because that modder had shown that it could work, it was because the initial community that sprung up around that modders work seemed more accepting of a less stable product than squad assumed that they'd be.