Jump to content

Why the hate towards x64?


JeeF

Recommended Posts

Why the hate for 64?

Because while the stock version of 64 bit KSP was available, it was surprisingly unstable. In my personal experience, It would crash every ten minutes or so, with zero mods installed while 32 bit ran perfectly with 30 mods.

Windows-specific? Well, that's pretty serious, given the huge portion of users who aren't running Mac or Linux. And also, my friend has Mac KSP. It isn't very stable either and required a number of workarounds to keep that running as well, even with 32-bit.

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.

Previously mentioned friend of mine running a Macbook Pro with a GTX 760 or something like that. Crashed every time until he ran the Texture compressing mod. (Before 1.0 which now has that effect natively.

It's interesting news that the community has created a stable 64-bit option, however. I will have to try that out.

Edited by Camaron
Link to comment
Share on other sites

Kerbonauts,

I'll be as much of a neutral party here as I can...

I'd prefer that we not get into a debate in this thread about wielding (or not wielding) moderator powers to gain an advantage. It's well off topic. If you have concerns about moderators abusing their powers, there are other avenues to address that.

In regard to the topic, there is a lot of factual information and emotion in this thread about the history and evolution of Windows x64 version of KSP. As I stated before, with so many topics within KSP, there are polarizing factors that some people simply cannot get past. If you'd like to discuss x64 amicably (as the OP asked), then it's best to stick to factual statements and avoid looking to place blame. You might feel that finding someone to blame is important to you, but it will simply propagate the polarizing factors. Also, as I stated before, bear in mind that regardless of how many times or ways something is explained, some times the "why" will remain a mystery.

That being said, I'm now in one of those precarious situations as a moderator. To give some slight insight and perhaps guidance to the rest of this thread's progression, here are the two most basic options I have available:

1) Close the thread for being answered, and straying off topic.

2) Let the thread keep on trucking, and hope that the agnostic notes that I post above pushes the train back on the tracks.

* (Yes, there are more options. No, we don't need to debate them.)

So I pretty much can't use option 1, at least not for now, simply for the fact that moderators have become involved in this topic. Why? Because that would "add proof" that moderators wield powers to squash down any dissent, regardless of my actual motives. This is the dual hat that we have to wear and be cognizant of.

So please, back to the topic.

Cheers,

~Claw

Link to comment
Share on other sites

I don't believe there really is hate for X64 among the users/modders. As said before many times, preventing mods to run under x64 is a form of selfprotection as long as the x64 version of KSP has too many issues (no matter what is causing it). KSP is a game for everyone, computerexperts and computerignorants. KSP 64 bits can work but not for most users (i've tried it and reverted back to 32 bits).

I always run a heavily modded KSP and frankly, i would love to use even more, but i guess i 'll just have to wait for a stable 64 bits version.

Link to comment
Share on other sites

I don't believe there really is hate for X64 among the users/modders. As said before many times, preventing mods to run under x64 is a form of selfprotection as long as the x64 version of KSP has too many issues (no matter what is causing it). KSP is a game for everyone, computerexperts and computerignorants. KSP 64 bits can work but not for most users (i've tried it and reverted back to 32 bits).

I always run a heavily modded KSP and frankly, i would love to use even more, but i guess i 'll just have to wait for a stable 64 bits version.

I think some modders have added the x64 protection just "in case" and because KSP is not giving official support to x64. And I'm not happy with that over defensive approach.

I agree that if a modder has tested his mod for x64 and he can assert that his mod is not working on x64 then the mod should be disabled. Otherwise it should be enable by default.

Let the users test your mod. You will get the feedback sooner or later about if the users are happy with your mod running on x64.

And obviously you will need to test this everytime KSP is getting an update. It is painful, but I think is the way to go.

Edited by jrodriguez
Link to comment
Share on other sites

…I agree that if a modder has tested his mod for x64 and he can assert that his mod is not working on x64 then the mod should be disabled. Otherwise it should be enable by default…

The problem isn't that mods work or don't on win64. The problem is KSP doesn't work, more or less, on win64. So to a casual user, it's not clear whether a bug is in the mod, or in the base game.

Often, they assume it's in the mod. After all, it's been hacked in, right (hint: in all actuality, no, at least not any more then stock is)? And they don't bother to replicate it in stock, especially if it's difficult or impossible to do so (read: most behaviors in FAR).

So modders are dealt a lot of bug reports they can't do anything about. And they need to take time to investigate whether that's or not that's the case, because it's not often clear.

Ferram4 in particular has this pretty bad, in part because his mod is so complex and popular. He has enough trouble getting users to understand that the way he works*, he needs bug reports to have certain information; and users still fail to do this yet give him flack anyways for not responding to their posts. I invite you to peruse the FAR release thread to see what he's dealing with. And that's *without* win64 shenanigans thrown into the mix.

Give your modders a break, and if they say "don't use this in this-or-that environment," kindly respect their wishes?

* and it's really what any modder does need; informal bug reports don't help anyone

Link to comment
Share on other sites

I agree that the users should be "educated" about how to report a bug and minimun of information it must contain to be accepted.

But this is not about "wishes".

We need to acknowledge that since 1.0 the statement "The problem is KSP doesn't work, more or less, on win64" it is getting more difficult to probe, and each day the number of users playing on x64 is increasing. That is the reason why in my opinion, modders should know whether or not a mod is going to FAIL on x64.

I said fail because as I mentioned before, I think with the smallest bug because of x64 the modder should block execution on x64, but if you cannot probe that is failing then you should have your mod enabled for x64.

Link to comment
Share on other sites

Why should a mod author support x64 if there's no current official release? Just because there are some players who somehow got x64 KSP working?

I think with the smallest bug because of x64 the modder should block execution on x64, but if you cannot probe that is failing then you should have your mod enabled for x64.
You can't dictate mod authors what they should do. You either accept their mods as they are or don't install them. Something else will cause the mod authors to keep their mods private or only publish them to a small group of people.
Link to comment
Share on other sites

Well... indeed a lot of useful info here.

Yes, the problem indeed is not really with x64, but rather on how Unity utilizes memory.

Bottomline is: People want to use mods, it's what keeps the game alive.

Personally, I have a really hard time playing KSP without about 50 mods that I consider "must haves".

Most of them are parts mods, which increase mem footprint like crazy.

Since the start of this thread, I've installed 32-bit version and been trying to play it with minimal mods.

A few science mods, FAR, Fasa, tweakscale, and a few others, 12 in total and all of them downloaded latest version and installed properly.

The mem footprint never goes over 3gb, NEVER! And yet, the game crashes for me more often than my x64 copy with over 100 mods and a 12gb ram footprint.

Go figure.

The reason I decided to try the 32-bit was to see if I could get around a couple of annoyances from the x64, like the difficulty in accessing a part menu when the ship has too many parts and fps is low.

And a few weird... kraken behaviors every now and then. Nothing game-breaking, but can be sometimes annoying.

Turns out I didn't even have the patience to test for those annoyances in my 32-bit copy... game was crashing every 15 mins, so I gave up.

I've heard mixed opinions about dx11. After all, does the game work or not in dx11? What about LoD?

Any other things I can try to reduce my 32-bit mem footprint? (Other than openGL, for me it gets very glitchy with textures missing and weird screen artifacts).

Thank you.

Link to comment
Share on other sites

Why should a mod author support x64 if there's no current official release? Just because there are some players who somehow got x64 KSP working?

You can't dictate mod authors what they should do. You either accept their mods as they are or don't install them. Something else will cause the mod authors to keep their mods private or only publish them to a small group of people.

I'm not saying support it, but allow it.

About "some players" I can give you some figures about the traffic on my KSP x64 Total Unfixer release folder, but we are talking here that at least 500 users.

Also I'm not dictating. Should < Must <<< Dictate

- - - Updated - - -

Well... indeed a lot of useful info here.

I've heard mixed opinions about dx11. After all, does the game work or not in dx11? What about LoD?

Any other things I can try to reduce my 32-bit mem footprint? (Other than openGL, for me it gets very glitchy with textures missing and weird screen artifacts).

Thank you.

I still using my 0.90 Realism Overhaul with 4gb RSS textures, entire KSP folder converted to DDS and OpenGL (I prefer OpenGL because I don't like the black/pink textures problems with Dx11)

Link to comment
Share on other sites

I'm not saying support it, but allow it.

About "some players" I can give you some figures about the traffic on my KSP x64 Total Unfixer release folder, but we are talking here that at least 500 users.

Also I'm not dictating. Should < Must <<< Dictate

I agree, not support, but allow it.

And if you take into consideration that a very small part of the community visit the forums, and from those, a small percentage use mods, and from those, a small percentage would have the know-how or the curiosity or the courage to get x64 working, 500 downloads on your unfixer tool is a HUGE number. :D

Link to comment
Share on other sites

Thing is, it's not your call whether a modder does or does not allow something. You can of course ask nicely, and as it turns out, several have said no.

So your choice is to either respect their wishes, or wind up with restrictive licensing.

Link to comment
Share on other sites

Thing is, it's not your call whether a modder does or does not allow something. You can of course ask nicely, and as it turns out, several have said no.

So your choice is to either respect their wishes, or wind up with restrictive licensing.

All the more reason to use an open license - let the people fork to experiment, because that moves the responsibility from the author to the complaining forkers. (pun intended). Plus the DMCA does allow people to reverse engineer or "hack" (in the old sense of the word) even restricted rights software for "identifying and analyzing parts of the program needed to achieve interoperability", so restricting a game mod in such a community based environment is can be ultimately counterproductive and generate more work rather than less. Not to mention the mod doesn't die when the author decides to stop putting time/effort into it. But it is a choice, some wise, some not.

Link to comment
Share on other sites

Actually quite the opposite. Just like when there was a 'Fork' of FAR, they kept going to Ferram's thread to ask questions. So the net effect is that in order to prevent redistribution of software that ultimately causes the modders support issues, they end up having to resort to restrictive licensing (ala RealChutes).

The most productive thing? Respect the wishes of the folks providing you free content. Pretty simple, really. If folks can be neighborly, we get to have nice things.

Link to comment
Share on other sites

The most productive thing? Respect the wishes of the folks providing you free content.
If you don't, you might find them leaving the community for greener pastures after relicensing.
Link to comment
Share on other sites

I really can't understand what's so hard about ignoring post/pms about issues you're not interested.

Because most people looking for support, after ignoring the warnings, are careful to not admit they have Win64 until they get caught. Same way people will tell you they have the latest version, have no other mods, did a clean install, or any number of things thinking they know better and that it must be a mod issue, not pilot error.

Link to comment
Share on other sites

We need to acknowledge that since 1.0 the statement "The problem is KSP doesn't work, more or less, on win64" it is getting more difficult to probe, and each day the number of users playing on x64 is increasing.

I doubt the number of users on win64 builds are anywhere near peak levels. For one, we don't have an official win64 KSP release anymore, and for two, the steps necessary to make the hack work aren't straightforward and require you to download all 1.6 Gb or whatever of Unity. That's a fair bit of time, effort and bandwidth that users don't seem to be willing to go through with.

I'll also note that since 1.0, despite the increase in users, I have had many, many fewer "why no win64, ARGHBARL GIVE WIN64 SUPPORT NAO" kind of posts.

On the other hand, if you're using "x64" specifically to include Linux users in a kind of "technically correct, but deliberately misleading" kind of way, then you are correct. But you're being deliberately misleading by being too broad.

That is the reason why in my opinion, modders should know whether or not a mod is going to FAIL on x64.

All mods will fail under some circumstance, precisely because of what win64 builds of KSP are. Win64 KSP build are like sandy, waterlogged ground in an earthquake zone; any building you put there that's more substantial than a hut (and if you put enough of them, even that) will collapse into the ground eventually.

I said fail because as I mentioned before, I think with the smallest bug because of x64 the modder should block execution on x64, but if you cannot probe that is failing then you should have your mod enabled for x64.

As noted, win64 KSP == guaranteed failure at some point. This has been proven by our tests again and again and again, and it doesn't matter which mod it is; it's all of them.

It's nice to know you're on our side though. Oh, thanks for pointing to Contract Configurator as having a win64 locking version that you haven't figured out yet, that led me down a few paths that should allow me to prevent the unfixer from working. Should be very useful.

I really can't understand what's so hard about ignoring post/pms about issues you're not interested.

And now, instead of being able to address the legitimate issues that win32, OS X, and Linux 32 / 64 users have posted, they have to hope that I see those when they've been buried in a flood of "Y WIN64 NO WORK?!" posts. It makes the signal to noise ratio a lot worse. We tried this, and user support for anyone on the other builds suffered. A lot.

Then, you know what happens? As was already noted earlier, though you seem to have ignored it as it was inconvenient, users try random things to make their installs work, like delete ModuleManager and other hard dependencies. Things break more. Eventually, they come back and try to get support and make more noise, and guess what then? More signal to noise ratio worsening, plus, until we recognize that this is a bug entirely caused by user error, we've wasted development time tracking it down.

The end result is that it adds more work for us and screws over your fellow users because they can't get good support, and mod development slows too. So I gather you want us to have more work, your fellow users to get less support, and for mod development to slow.

Link to comment
Share on other sites

I'll also note that since 1.0, despite the increase in users, I have had many, many fewer "why no win64, ARGHBARL GIVE WIN64 SUPPORT NAO" kind of posts.

It could be because FAR is doing really well with x64! :)

As noted, win64 KSP == guaranteed failure at some point. This has been proven by our tests again and again and again, and it doesn't matter which mod it is; it's all of them.

I agree that before 1.0 it was like that, 0.90 was unplayable using x64. But now it completely different. I'm not saying win64 KSP != guaranteed failure at some point, but to find "the point" is getting hard.

It's nice to know you're on our side though. Oh, thanks for pointing to Contract Configurator as having a win64 locking version that you haven't figured out yet, that led me down a few paths that should allow me to prevent the unfixer from working. Should be very useful.

:D Of course I'm on your side! In fact we have more in common that the 95% that rest of the world! (ksp fans, software, aerodynamics, space, science...)

Back to topic, I don't want to unfix something if I know that then it is going to fail. On the next release of the unfixer my plan is to add a whitelist to block the unfixer from hack those mods that will fail.

About to block the unfixer, it is very easy (max 5 min) to add the code to block the unfixer. I'm a honest guy, and it is up to you to do it.

If I found that unfixer is not useful anymore and I have to go through VS to recompile every single mod, then I will create forks for everything, and a CKAN for x64. Maybe this approach is more fair and I will help to reduce your signal/noise ratio redirecting those 'bad users' to my forks.

Edited by jrodriguez
Link to comment
Share on other sites

I doubt the number of users on win64 builds are anywhere near peak levels. For one, we don't have an official win64 KSP release anymore, and for two, the steps necessary to make the hack work aren't straightforward and require you to download all 1.6 Gb or whatever of Unity. That's a fair bit of time, effort and bandwidth that users don't seem to be willing to go through with.

I'll also note that since 1.0, despite the increase in users, I have had many, many fewer "why no win64, ARGHBARL GIVE WIN64 SUPPORT NAO" kind of posts.

On the other hand, if you're using "x64" specifically to include Linux users in a kind of "technically correct, but deliberately misleading" kind of way, then you are correct. But you're being deliberately misleading by being too broad.

So I take you've never tried the 64bit workaround yourself?

As noted, win64 KSP == guaranteed failure at some point. This has been proven by our tests again and again and again, and it doesn't matter which mod it is; it's all of them.

It's nice to know you're on our side though. Oh, thanks for pointing to Contract Configurator as having a win64 locking version that you haven't figured out yet, that led me down a few paths that should allow me to prevent the unfixer from working. Should be very useful.

See this is contradictory with your quote below:

And now, instead of being able to address the legitimate issues that win32, OS X, and Linux 32 / 64 users have posted, they have to hope that I see those when they've been buried in a flood of "Y WIN64 NO WORK?!" posts. It makes the signal to noise ratio a lot worse. We tried this, and user support for anyone on the other builds suffered. A lot.

Then, you know what happens? As was already noted earlier, though you seem to have ignored it as it was inconvenient, users try random things to make their installs work, like delete ModuleManager and other hard dependencies. Things break more. Eventually, they come back and try to get support and make more noise, and guess what then? More signal to noise ratio worsening, plus, until we recognize that this is a bug entirely caused by user error, we've wasted development time tracking it down.

The end result is that it adds more work for us and screws over your fellow users because they can't get good support, and mod development slows too. So I gather you want us to have more work, your fellow users to get less support, and for mod development to slow.

Suppose you guys find a way to completely block out mods from being used in 64bit systems. Then the use of ALL parts mods and/or mods that increase memory footprint will drop, since all of us running those mods won't be able to anymore. We'll be limited by 3gb, and so we'll stop using some outstanding mods out there, which means less development on those areas, which is bad for everybody.

I understand your argument and I do agree that it can be very frustrating dealing with users who don't follow the rules, but you can't deny that forgetting about 64bit mod development altogether is also bad for the game.

At least until Unity finds a better way to handle textures.

Edited by JeeF
Link to comment
Share on other sites

It could be because FAR is doing really well with x64! :)

That would be news to me, considering I can't get the hack to not crash.

I agree that before 1.0 it was like that, 0.90 was unplayable using x64. But now it completely different. I'm not saying win64 KSP != guaranteed failure at some point, but to find "the point" is getting hard.

My tests indicate that the point is where it's always been; you try to use over 4 Gb RAM, you're getting a crash. No ifs, ands or buts. Sometimes instability before.

And this is with the hack.

About to block the unfixer, it is very easy (max 5 min) to add the code to block the unfixer. I'm a honest guy, and it is up to you to do it.

If I found that unfixer is not useful anymore and I have to go through VS to recompile every single mod, then I will create forks for everything, and a CKAN for x64. Maybe this approach is more fair and I will help to reduce your signal/noise ratio redirecting those 'bad users' to my forks.

Unfortunately, as I noted back in my history of win64 KSP builds, this was tried. Still had nearly all the users coming to my thread. The only advantage is that it's a little easier to figure out what's going on sometimes. We also both know that if a win64 issue comes up you'll blame it on the mod; it's impossible to convince people that's not the case.

So I take you've never tried the 64bit workaround yourself?

Nope, I've got it sitting next to the win32 version for the purposes of testing ways to break the unfixer. Can't add more mods to it than the win32 build without risking crashes, and I haven't noticed any increase in stability above that of the official builds. I have no idea where this, "win64 is stable now" idea came from, because it certainly isn't playtesting.

See this is contradictory with your quote below:

Win64 KSP guarantees failure is contradictory with what? That users blame the mods anyway and bury legitimate issues? Or are you trying to argue that there are issues that are on all platforms is proof that win64 is completely blameless in all ways, and that's it's never caused crashes?

Suppose you guys find a way to completely block out mods from being used in 64bit systems.

I don't see why we would, Linux 64 has always behaved. Just like all the win64-pushers, you ignore this because it's inconvenient.

Then the use of ALL parts mods and/or mods that increase memory footprint will drop, since all of us running those mods won't be able to anymore. We'll be limited by 3gb, and so we'll stop using some outstanding mods out there, which means less development on those areas, which is bad for everybody.

Windows users would, yes. Linux users would not, because Linux 64 doesn't crash frequently, and so isn't disabled.

Why do you ignore that it's only win64 that is locked? Does it hinder your argument that it's irrational hate of x64, because all the mods that you're screaming about aren't locked on all x64 builds, only the busted (read: win64) ones?

I understand your argument and I do agree that it can be very frustrating dealing with users who don't follow the rules, but you can't deny that forgetting about 64bit mod development altogether is also bad for the game.

The only 64bit-specific mod development that has occurred is the development of the detection of whether the KSP process is a 64-bit process on a Windows system, i.e., "is it win64 KSP?" Perhaps you noticed that everyone downloads the same dll, regardless of OS or word size; that's because the code is identical in all those cases. C# compiles only to bytecode, which is then turned into machine code specific for that system by the Just In Time (JIT) compiler. The end result is that we can't do any win64 development for mods, because there is nothing to develop. It's exactly the same as win32, and OS, and Linux 32, and Linux 64.

I would suggest that you actually get into modding and attempt to handle any of this if you don't believe me. There is jack that we can do for this problem, and the only people that do seem to think it have some idea that coding is magical, that modders are witch doctors, and that the only thing they don't get what they want is because the modder is a big meanie that won't chant the right words. It doesn't work that way.

Link to comment
Share on other sites

KSP is officially supported in 32-bit on Windows, Linux, and Mac. Modders should support all three of these platforms.

KSP is officially supported in 64-bit on Linux. Modders should support this platform.

KSP is officially not supported in 64-bit on Windows or Mac (somebody verify for me for Mac). Modders are under no obligation to support these platforms. Given the problems that occur due to the 64-bit hack, there is an argument to be made that the opposite should be expected - they should be doing what they can to de-incentivize the use of the hack.

You are expecting modders to support that which the developers themselves have declared to be un-supportable. Don't do this. We can have the conversation again when the devs re-evaluate this completely relative to the Unity 5 release.

Link to comment
Share on other sites

I would suggest that you actually get into modding and attempt to handle any of this if you don't believe me. There is jack that we can do for this problem, and the only people that do seem to think it have some idea that coding is magical, that modders are witch doctors, and that the only thing they don't get what they want is because the modder is a big meanie that won't chant the right words. It doesn't work that way.

This could probably sum up the entire thread right here lol

...and whatever you say, I personally refuse to believe you guys aren't witch doctors. It's the only theory that makes sense.

Link to comment
Share on other sites

Honestly I think everyone complaining should just get linux on a partition. It'll take an hour tops as long as you aren't totally technologically illiterate and then neither you nor modders will have to do with the utter trainwreck that is the win64 hack

The linux64 version runs like a dream for me, now I've just got to wait eagerly for all of my mods to update to the new heat mechanics so my entire crafts don't sublimate on the launch pad when I forget to turn off max heat in the console

Link to comment
Share on other sites

Honestly I think everyone complaining should just get linux on a partition. It'll take an hour tops as long as you aren't totally technologically illiterate and then neither you nor modders will have to do with the utter trainwreck that is the win64 hack

The linux64 version runs like a dream for me, now I've just got to wait eagerly for all of my mods to update to the new heat mechanics so my entire crafts don't sublimate on the launch pad when I forget to turn off max heat in the console

I ain't complaining. Like I stated before, my KSP runs fine. I was just trying to understand.

By forcing the issue with some of the folks here, I've got some very good intel, even from you: I didn't know L64 ran the game so well.

I've been into modding for many years, spent about 12k hours modding and releasing mods for a game called Silent Hunter 3, probably the best game I've ever played.

So I kinda know the drill, and I can definitely understand the issue here, and mostly agree with most I've heard.

Working in the gaming industry, I know dealing with players is much harder than dealing with the game itself.

But my modding days are mostly over, I'm afraid. Real life takes most of my time away. I do miss it, very much. Hence why I'm poking my nose in here so much! XD

I do a fair bit of modding into my own KSP, but definitely wouldn't have the time to release and manage any of it.

I'll give it a try on my linux, thanks for the tip!

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...