64-bit Garry's Mod - Developers

Heh, I was tempted to bring this up as well but I realized it's technically unrelated to the 'bitness' of the game and it'd just veer the conversation away from the real topic. But thanks for doing it for me! :P Did anyone reproduce this? All those 'informative' ratings aren't very informative.

Limitations on Lua types remain unchanged. Lua always stores numbers as 64 bit floats. This gives you about 50 bits worth of integer to play with, which should be fine unless you're playing some very strange games. The precision limitations come from the engine, not from Lua. The main changes the new LuaJIT version bring are possible increased performance in the JIT (see the things marked 2.1 here), and the ability to allocate more memory (IIRC without GC64 this would not be the case).

So I've got SRCDS up now. There's no 32-bit Linux SRCDS yet and I also still need to sort out some Linux dependencies, but feel free to try it out. app_update 4020 -beta x86-64 -betapassword z8MvH7F6OW3HExir validate

so there seem to be some issues with hammer, already i can tell that some of the tool textures are broken, such as toolsskybox in the preview window, i'll post more as i discover them

Do you mean there is no 64-bit linux srcds? A side question would be will you guys be supporting 32 bit modules in a 64 bit srcds? I know that you can get around this by using surrogate processes, but understand that thats a tedious thing to do. Just thinking about backwards comparability to 32-bit srcds so that people won't want t worry too much about their binary modules not loading.

64-bit is there, but I plan to continue shipping 32-bit SRCDS builds. I just need to sort out those 32-bit builds for Linux still. There won't be any crazy plugin host process stuff going on. Most modules rely on reading/writing the game's memory anyway. In the case that they don't, they should be pretty easy to build as 64-bit.

the steam GUIs that are normally green? they're grayscale now also this was in the server console, not sure if this only happens in GUI mode every few seconds it prints out Tried to look up command stats as if it were a variable.

I guess you could consider this a bonus :P

Is there any reason why we would still want to ship 32-bit builds? Why aren't we just keeping it strictly x64?

Some binary modules need the Source SDK 2013 libraries to access the virtual file system for example. I guess, the Source SDK will not compile/run for x64, does it? Is there any way around that or is there a version of Source SDK that support the x64 build without reverse engineering / modifying it? As the GMod Headers currently supports x64 for windows only, will it support other platforms later as well? Other Topics: For me a working source engine as x64 build seems to be a quite big undertaking, as it was supposedly quite hard for Valve themselves to do it right with their hl2 x64 build. I think GMod is propably the first source engine that runs on 64 bit probably when it's done. Is it true that the new Lua version can allocate much for memory per state (like 1 GB+) than before? Do we get a function to check for 64 bit in Lua?

Yeah. People already use it, they might want to keep using it, be that for binary module support or anything else. The only realistic option is to probably offer more functionality from the GMod api. I would expect that we will never release a version of the Source SDK that can be built in a 64-bit environment. GMod's binary module headers already support all of our platforms (the game itself relies on them), I just need to update the GitHub repo. People are always gonna reverse engineer the interfaces, and it isn't really very hard for those that do.

If there's no discernible difference in 32 vs 64 bit versions, and the only reason people would have to keep 32-bit is legacy binary modules, wouldn't it make sense to just end 32-bit support across the board and force module developers to update? Especially since module developers are going to need to develop a 64-bit version of their module to support all OSes any ways?

I do hope there will be no noticeable differences in the two builds, but removing the 32-bit server builds isn't going to make my life any easier. The only outcome I see from removing them is to annoy some people. They can move over in their own time. I'm 100% set on removing 32-bit macOS client builds, and almost 100% on removing 32-bit Linux client builds. For players, I doubt there's any reason not too (especially those two builds, the amount of crashes from failed memory allocations is just sad). For servers, I'll just let them do their own thing.

Do we get a function to check for 64 bit in Lua? You can use jit.arch but I don't think there are many cases where you'd need to check.

On the topic of reverse engineering, I think a game that revolves around people modding it should have the interfaces public. Like sure it's possible with reverse engineering, but it takes time, and it's prone to error, and all in all it's a shot in the dark most times. I try and push some pr to danielga's github page that is very friendly towards people who want to build binary modules for gmod - but I feel like all header files for interfaces should be public. Plus, I swear SourceSDK has a batch script to export header files (in particular the public folder). This is looking at the old leak of course, and I have no idea how much of the game code you guys have, but it should be possible no matter what, right?

As I understand with my null knowledge about architecturs: if I update Linux server to 64x, players will need to upgrade too?

I don't think so. My knowledge is really small as well, but I'm pretty sure the network packets going between servers and client will remain exactly the same, so it doesn't matter which version each side is.

'll try

Every poster is saved with the name poster-This needs fixing.png (or the folder name poster-this needs fixing for a split poster) - but the files seem to be fine... This is on both 32-bit and 64-bit, but only in this branch (doesn't happen in dev or live). The filename was obviously set to that manually as a placeholder, I'm just wondering why! It makes it significantly harder for me to stay on 64-bit because I'm working on poster-related things.

Power 4 displacements seem to have no physics collision? Props and vehicles will fall through, players and npcs won't.

It had an issue that can only be fixed in a 64 bit environment because rendering big pictures (like 100MPixel+) allocated more than 4 GB of memory. In those cases some parts stayed black after rendering. It was added in as an experiment, by Garry. After finding these bugs Garry said that it was officially unsupported and left it there.

Since it was brought up, how does Havok work in the 64-bit builds? Previously we couldn't touch it because it would have required a license or something like that, but I can't imagine the binaries from the 32-bit build could just be dropped in place?

Right, but that's only half the story. 2 years ago we got split poster support: https://github.com/Facepunch/garrysmod-requests/issues/636 This made it possible to get arbitrarily large posters without having to allocate the memory for it. And with 64-bit, presumably larger posters will be possible without need for splitting. None of that is related to what I was asking though - everything about the poster still works, but it always saves to the same file and overwrites it! Previously it just had the date and time in the filename in some format.

i have a huge problem, i tried to connect to my test server and it keeps accusing me of using an older version of the game

Downloading a Dedicated Server To revert back to stable branch: login anonymous app_update 4020 -beta NONE validate quit The development branch is updated regularly.

The 64 bit branch version doesn't have the latest game code, so you can join it with the latest game version, yet. I guess it will get the needed merges from main soon. Do not use this version for ~productive~ environments jet.

Does this mean no more 2^56 precision loss?

Doubles are still 64-bit, regardless of whether it's a 32-bit or 64-bit program. So that won't change.

phooey

It appears Awesomium is what is causing my present TTT crashes, but I wasn't looking very hard at my other logs. I assume they were probably just memory problems. So there is no public access to 64-bit for macOS yet?