UomoCapra

Ending 32-Bit Support with Update 1.5

Recommended Posts

As our goal is to constantly improve upon and add more content to the game, we have decided to stop support of 32-bit KSP due to the memory limitations involving this version. If you are running 64-bit Windows and 32-bit KSP, you can move to 64-bit KSP without issue. For players running mods that only support the 32-bit version, note that they will no longer be compatible with KSP 1.5 and beyond.

Thanks!

Share this post


Link to post
Share on other sites
4 minutes ago, The Dunatian said:

64-bit will work with Windows 8, right?

Of course! The minimum Windows version hasn’t changed for 64-bits. 

Share this post


Link to post
Share on other sites

I'm pretty sure that unless you have a really old computer this will not affect you, so I think this will go over well. If you have a really old computer then you probably can't run KSP well in the first place...

Share this post


Link to post
Share on other sites
2 hours ago, UomoCapra said:

As our goal is to constantly improve upon and add more content to the game, we have decided to stop support of 32-bit KSP due to the memory limitations involving this version. If you are running 64-bit Windows and 32-bit KSP, you can move to 64-bit KSP without issue. For players running mods that only support the 32-bit version, note that they will no longer be compatible with KSP 1.5 and beyond.

Thanks!

Long time coming

Share this post


Link to post
Share on other sites
2 hours ago, Atroner said:

 Hello. The weekly today?

 

1 hour ago, Nightmare said:

 

11 minutes ago, Atroner said:

Next 1.5 and not 1.4.5

I don't know what 1.5 and 1.4.5 have to do with it. They stated pretty clearly:

On 10/5/2018 at 2:35 PM, SQUAD said:

Finally, we want to let you know that this is going to be the last KSP Weekly in its current format

 

Share this post


Link to post
Share on other sites
18 minutes ago, 5thHorseman said:

 

 

No sé qué tienen que ver 1.5 y 1.4.5 con eso. Declararon bastante claro:

 

 

¡Oh! Si, lo siento. Ya lo lei :sealed:

 

2 hours ago, Nightmare said:

I'm just coming back from Duna and I'm half confused with the news I'm sorry. 

you're right:sealed:

Edited by Atroner

Share this post


Link to post
Share on other sites

Nice to hear that decisions are being made to not keep a stanglehold upon the game's limitations... now lets ditch Unity 2017's Legacy DX9 support and move forward onto better things. :D 

Share this post


Link to post
Share on other sites

Good idea! 32-bit never did well on Linux anyway... heck, the reason I migrated my Debian box to 64-bit in 2013 was to run KSP 0.20.2!

Share this post


Link to post
Share on other sites
6 hours ago, UomoCapra said:

...For players running mods that only support the 32-bit version, note that they will no longer be compatible with KSP 1.5 and beyond."

  Which mods are 32-bit?  How can we tell if the mod maker does not denote that?

     Thanks.

Share this post


Link to post
Share on other sites
1 hour ago, jpkerman said:

  Which mods are 32-bit?  How can we tell if the mod maker does not denote that?

     Thanks.

I don't know specifically but I run exclusively 64 bit and have never, ever come across a mod that doesn't work with it. I didn't even know it was a thing until they said it here.

Share this post


Link to post
Share on other sites
2 hours ago, jpkerman said:

  Which mods are 32-bit?  How can we tell if the mod maker does not denote that?

     Thanks.

I can only speculate that mods that do PInvoke to libraries compiled in 32 bits would be the issue. I can't imagine a pure C# choking by running in 64 bits.

Right now, the X-Input.dll came to my mind.

Share this post


Link to post
Share on other sites

Good thing I'm getting a new computer, because my old one runs x32 better than x64.

Share this post


Link to post
Share on other sites
10 hours ago, UomoCapra said:

we have decided to stop support of 32-bit KSP

While you're busy culling superfluous stuff, how about also removing -and stopping KSP from auto-creating- all those empty unused directories in the main game directory? Internals, Parts, PluginData, Plugins, Resources. And that launcher that has been useless for a few versions now.

 

Btw, mod creators: this probably means that buildID.txt will be removed in favour of buildID64.txt. Time to adapt your check routines and ensure you look for the correct file.

Share this post


Link to post
Share on other sites
7 hours ago, swjr-swis said:

While you're busy culling superfluous stuff, how about also removing -and stopping KSP from auto-creating- all those empty unused directories in the main game directory? Internals, Parts, PluginData, Plugins, Resources. And that launcher that has been useless for a few versions now.

Quoted because why in the world are they still there?

Share this post


Link to post
Share on other sites
On 10/12/2018 at 6:14 PM, Poodmund said:

Nice to hear that decisions are being made to not keep a stanglehold upon the game's limitations... now lets ditch Unity 2017's Legacy DX9 support and move forward onto better things. :D 

How bout Vulkan :D https://en.wikipedia.org/wiki/Vulkan_(API)

 

Share this post


Link to post
Share on other sites
On 10/13/2018 at 1:38 AM, swjr-swis said:

While you're busy culling superfluous stuff, how about also removing -and stopping KSP from auto-creating- all those empty unused directories in the main game directory? Internals, Parts, PluginData, Plugins, Resources. And that launcher that has been useless for a few versions now.

 

Btw, mod creators: this probably means that buildID.txt will be removed in favour of buildID64.txt. Time to adapt your check routines and ensure you look for the correct file.

Having asked about this a long time ago, I've been told they were very very deeply anchored into how the game loader works. Something along the lines of them being harmless and that removing them could be more of a headache than anything. A bit like how a lot of old management systems are in COBOL but replacing them would be insanely expansive. Yknow, don't fix something that works. I guess.

Also... why not just use the Versioning class?

Edited by stupid_chris

Share this post


Link to post
Share on other sites
On 10/13/2018 at 8:38 AM, swjr-swis said:

Internals, Parts, PluginData, Plugins, Resources. And that launcher that has been useless for a few versions now

I unironically use Resources for dumping telemetry from the mod. Emty folders don't take much space, so let them be, there'll always be someone with his workflow broken.

Share this post


Link to post
Share on other sites
12 hours ago, Redneck said:

Heck yes! with vulkan API pretty much being a much better performing successor to OpenGL the performance gains would be phenomenal, best of all, it's also compatible with Linux so it could technically be the main API aswell

 

they'd have to upgrade to a newer version of unity however ( I think vulkan got implemented since 5.8, ksp is on 5.6)

Share this post


Link to post
Share on other sites
3 hours ago, stupid_chris said:

A bit like how a lot of old management systems are in COBOL but replacing them would be insanely expansive.

Ahh that brings memories of wholesale Y2K conversions from mainframes to open systems. Makes me wonder why it would still be 'insanely expensive', in this day and age of almost limitless options for virtualization.

 

3 hours ago, stupid_chris said:

why not just use the Versioning class?

Don't get me wrong: I am not telling modders how to do their checks. I'm just reminding those who still check for buildID.txt that this may be about to no longer be an option.

 

1 hour ago, Boris-Barboris said:

I unironically use Resources for dumping telemetry from the mod.

Why would you purposely use a non-mod directory to save mod-specific telemetry? Aside from the general no-no of a plugin contaminating the host software's working directories and ignoring the general consensus -if perhaps not specifically mandated one- of saving mod files in the mod's own directory structure, you are exposing yourself to being 'evicted' by development decisions of the host software. I am generally very much in favour of avoiding breaking workflows, but this one in particular seems to be rather self-invoked.

 

Share this post


Link to post
Share on other sites
19 minutes ago, swjr-swis said:

Why would you purposely use a non-mod directory to save mod-specific telemetry? Aside from the general no-no of a plugin contaminating the host software's working directories and ignoring the general consensus -if perhaps not specifically mandated one- of saving mod files in the mod's own directory structure, you are exposing yourself to being 'evicted' by development decisions of the host software. I am generally very much in favour of avoiding breaking workflows, but this one in particular seems to be rather self-invoked.

There is no official temp for mods outside of OS-provided temp (pita on windows), so I picked empty unused directory. No, this data does not belong to gamedata mod folder.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now