64-bit Garry's Mod - Developers

Yeah, I decided to keep it forced on for our Linux and macOS builds.

GMod's been a little crashy today while moving between servers. Doesn't seem to be creating any crash dumps, but I found this in chromium.log: [0129/215323.099:ERROR:gpu_process_transport_factory.cc(990)] Lost UI shared context. [0129/225657.270:FATAL:hwnd_util.cc(64)] : The current process has used all of its system allowance of handles for Window Manager objects. (0x486)

So I'm not able to find any part of the game that will allocate many of these handles (unless you happen to be opening hundreds of Chromium panels at once.) You can enable a column of 'User Objects' under the details tab in task manager if you want to keep an eye on it yourself.

Server 1: Game crashed instantly after join Server 2: Game crashed after join (3-5 secs) Server 1: (connected again) Game used all my ram+swap and crashed

The 64bit change alone is not a huge deal - without taking advantage of it, there usually isn't much of a reason to care. Edge cases like Lua running out of memory is just one such somewhat minor reason to care. The bigger change (for me, at least, as a web dev myself) is that this includes the new Chromium web renderer stuff, so loading screens, motds, etc, will be using a more performant and up-to-date/safer renderer.

Apple ditching 32-bit executables and opengl stuff finally gave a kick to reset implementation of CEF into game. CEF is not available for 32-bit mac/linux systems. So 64bit branch kills two rabbits at once.

Seems props on maps tend to go invisible and running r_flushlod 0 in console causes a crash (it usually resolves it) on 64 bit builds. I'll put this into an issue if I can replicate it.

I believe this will only result CPU-based WebGL rendering not working. It's something I've been thinking about including, arguably there's no reason not to.

Please do, WebGL would be really cool to have working in GMod's CEF.

I found these fixing engine_client.so issue sudo ln -s /usr/lib64/libcurl.so.4 /usr/lib64/libcurl-gnutls.so.4 sudo ln -s /usr/lib64/libedit.so.0 /usr/lib64/libedit.so.2

Chromium hasn't supported 32bit Mac for 5+ years, Apple hasn't produced a 32-bit OS X device for 11-12 years now and stopped supporting them in 2014 lol.

64-bit fails to load some textures on a model properly on certain maps when 32-bit will load those textures fine. These model textures appear to be leaves/foliage. Map example: https://steamcommunity.com/sharedfiles/filedetails/?id=1625359200 Occurs on multiple maps that use the same model(s). CMaterial::PrecacheVars: error loading vmt file for models/props_foliage/hedgerow_01 KeyValues Error: LoadFromBuffer: missing { in file materials/models/props_foliage/hedgerow_01.vmt (*VertexLitGeneric*), CMaterial::PrecacheVars: error loading vmt file for models/props_foliage/hedgerow_01 KeyValues Error: LoadFromBuffer: missing { in file materials/models/props_foliage/hedgerow_01.vmt (*VertexLitGeneric*), CMaterial::PrecacheVars: error loading vmt file for models/props_foliage/hedgerow_01 CMaterial::DrawElements: No bound shader KeyValues Error: LoadFromBuffer: missing { in file materials/models/props_foliage/hedgerow_01.vmt (*VertexLitGeneric*), KeyValues Error: LoadFromBuffer: missing { in file materials/models/props_foliage/ash_bigbranch.vmt (*VertexLitGeneric*), KeyValues Error: LoadFromBuffer: missing { in file materials/models/props_foliage/ash_bigbranch.vmt (*VertexLitGeneric*),

Yeah, and it should be reiterated (again) that OpenGL isn't getting the same treatment as 32-bit. It's "deprecated" just like the Carbon framework was deprecated 7 years ago and that is only going away this year because it never got updated to support 64-bit. Deprecated APIs are generally not removed. OpenGL should still be around for the years to come, it's just that they "may" remove it at any point in the future.

On the beta builds (both 32- and 64-bit), often specularity or cubemaps or whatever gets all corrupted and stuff. https://files.catbox.moe/dztewg.jpg You can tell that it's not supposed to happen. And yes, it happens exclusively on this beta branch alone, and is not limited to this map.

For me, the game was not even able to boot, until I created a symbolic link for libegl and libglesv2 into the swiftshader folder. (unless I am misunderstanding what is being said, in which case, my bad) Although your solution works, I think it would be best to symlink to the (steamapps)/GarrysMod/bin/linux(arch) directory, rather than messing with system directories. Just my opinion though. Aside from the need to symlink libraries I love the x86_64 beta. The linux 32bit version was more prone to crashing and freezing in my experience than this version (at least the stable one is, I haven't tested the 32bit beta yet).

The map actually does have syntax errors in those files. Apparently GMod used to ignore them, so we'll just do the same on 64-bit.

True.

Ooooh. So that explains why VMTs on other branches with syntax errors don't fail to load like here.

I assume because Valve wanted to be overly accepting since mappers/modellers aren't programmers and placeholders are better than tons of texture errors. More importantly, it's been that way in Source for a long time so changing it now would break any map with packed texture errors.

branch has broken hammer world editor in at least 2 ways 1, it is lacking a halflife2.fgd so hammer has no knowledge about half of gmod's entities 2, all advanced compile options are gone

ok so it seems to have broken the editor for displacements

I’m on a Mac and when I try and run the beta I get an error ‘server browser’

Having issues getting steam to load on srcds_win64 [code] Initializing Steam libraries for Workshop.. ********************************************************* * Unable to load Steam support library.* * This server will operate in LAN mode only.* ********************************************************* [/code]

Willox Those foliage VMT files are now being loaded properly on the latest 64-bit branch, thanks! Would there happen to be another way of following 64-bit branch updates, such as a publicly-accessible branch repo?

https://gmod.facepunch.com/commits/1

Why so many hidden commits?

Any update on 64-Bit for MacOS?

Right, so I've been looking at this, and during the Workshop Complete phase, the User Object count will shoot up to incredible numbers, like 5,000 to 10,000+ sometimes. Also, it seems to mostly happen not when rejoining servers, but when joining them for the first time during a session. It can happen during both, but the worst scenario I've found to demonstrate the problem is to join one server, be on that server for a while, like at least an hour, then join another server. While joining the second server, the User Object count tends to be greater and joining tends to take longer. So maybe it has to do with memory allocation for Workshop content, and it struggles when there's already a lot of stuff in RAM from the previous server?

Hi, sorry I'm new to Facepunch's forums. So I wont be so professional on my writings. But I signup to report on an Issue, that running the 64-bit version of Garry's Mod, on my Ubuntu system (18.10), seems to break the Steam Overlay, not allowing me to open it up, or using any web features, requested by the game. Like trying to access Workshop. This is specifically odd, as Steam servers within the game still works, so it seems to only be the overlay that is broken.

Uh, so I've just discovered crash dumps sitting around in %LOCALAPPDATA%\CrashDumps for GMod, that I assume are being generated from the 64-bit branch, so here's a dump that might help you for this: https://winteris.moe/share/2019-03-03_00-00-10.dmp