• 64-bit Garry's Mod
    281 replies, posted
The game crashes on load on Ubuntu 18.04 x64. It doesn't get past the blue screen with Facepunch logo. Crashdumps don't create.
On a scale from 1 to 10 how broken are modules going to be
11
64*
Well, they'll only be 32 broken to be fair. A more serious answer (that I'm definitely not qualified to give) is that at the very least they'll need their headers fixed and to be recompiled. So an old module won't work out of the box with 64-bit gmod. I'm pretty sure they'll be trivial to fix. Now hopefully sometime will do a Cunningham's Law on me.
Little harmless error I found When pressing play right after updating to this beta branch it says "Missing executable hl2.exe" but after pressing play again it downloads a few files then fixes itself
Yeah, it also can't be launched from the tray. But willox did say that he knows about this.
Good to know! When I saw the error I went to google to try to look it up, some people might search for a while before they decide to re-launch the game, thankfully I wasn't stupid this time around
Yeah, it's in the OP: and somewhere else I can't find right now where he explicitly said that default isn't working. So yeah, nothing to worry about!
WARNING: setlocale('en_US.UTF-8') failed, using locale:'C'. International characters may not work. SDL video target is 'x11' SDL video target is 'x11' SDL failed to create GL compatibility profile (whichProfile=0)! This system supports the OpenGL extension GL_EXT_framebuffer_object. This system supports the OpenGL extension GL_EXT_framebuffer_blit. This system supports the OpenGL extension GL_EXT_framebuffer_multisample. This system DOES NOT support the OpenGL extension GL_APPLE_fence. This system DOES NOT support the OpenGL extension GL_NV_fence. This system supports the OpenGL extension GL_ARB_sync. This system supports the OpenGL extension GL_EXT_draw_buffers2. This system DOES NOT support the OpenGL extension GL_EXT_bindable_uniform. This system DOES NOT support the OpenGL extension GL_APPLE_flush_buffer_range. This system supports the OpenGL extension GL_ARB_map_buffer_range. This system supports the OpenGL extension GL_ARB_vertex_buffer_object. This system supports the OpenGL extension GL_ARB_occlusion_query. This system DOES NOT support the OpenGL extension GL_APPLE_texture_range. This system DOES NOT support the OpenGL extension GL_APPLE_client_storage. This system DOES NOT support the OpenGL extension GL_ARB_uniform_buffer. This system supports the OpenGL extension GL_ARB_vertex_array_bgra. This system supports the OpenGL extension GL_EXT_vertex_array_bgra. This system supports the OpenGL extension GL_ARB_framebuffer_object. This system DOES NOT support the OpenGL extension GL_GREMEDY_string_marker. This system supports the OpenGL extension GL_ARB_debug_output. This system DOES NOT support the OpenGL extension GL_EXT_direct_state_access. This system DOES NOT support the OpenGL extension GL_NV_bindless_texture. This system supports the OpenGL extension GL_AMD_pinned_memory. This system supports the OpenGL extension GL_EXT_framebuffer_multisample_blit_scaled. This system supports the OpenGL extension GL_EXT_texture_sRGB_decode. This system supports the OpenGL extension GL_NVX_gpu_memory_info. This system supports the OpenGL extension GL_ATI_meminfo. This system supports the OpenGL extension GL_EXT_texture_compression_s3tc. This system supports the OpenGL extension GL_EXT_texture_compression_dxt1. This system supports the OpenGL extension GL_ANGLE_texture_compression_dxt3. This system supports the OpenGL extension GL_ANGLE_texture_compression_dxt5. This system supports the OpenGL extension GL_ARB_buffer_storage. This system DOES NOT support the OpenGL extension GLX_EXT_swap_control_tear. Failed to load engine_client.so: (null) AppFramework : Unable to load module engine_client.so! I get this when running on manjaro linux. And also a xorg dialog box with "AppFramework : Unable to load module engine_client.so!" message.
5/10 if the modules don't use the Source SDK (just need recompiling when the new headers are final and you did code it well enough) and 2^64/10 if they rely in the Source SDK, which does not exist for 64 bit. It's likely to be broken for 32 bit as well depending on the use case.
With the move to 64 bit, with reasoning being chromium support for web enhancement for all platforms (sounding like this was the main holdback for pushing such an update out to Windows only), I have a few questions. Recently I ran into the Autoplay Policy changes in Chrome - which means that people wanting to listen in the Chrome browser to the jukebox will have to manually uncheck a box deep within chrome settings. I was wondering if this would be an issue within the game, and if I should focus my efforts on a different attempt for an autoplaying jukebox, or if these worries are unfounded. Many thanks.
https://i.imgur.com/2Deyrd9.png I can't be more proud of you guys
1% Disco, huh? To each his own, I guess.
0 mbps of Red though? that might be pushing it
https://i.imgur.com/Yaae4Kr.png I know this is not priority at all, but i hope we keep the orange icon for SRCDS
I have to remind myself occasionally that orange and blue are actually the other way around in the Wiki documentation. It does look spiffy in orange, though.
Huh, you're right about the colors being the other way around. FWIW, the wiki colors are just the same as the default print colors, so the icons are the wrong ones :P
now this make sense, we should open a petition to make gmod icon color change to orange when we connect to a server and make it bicolor when we open a server
Fighting the real fight here?
Can anyone else confirm that SOMETIMES you freeze in Sending client info? I've been noticing it recently although i can't give any reproduction rate since i just restart the client and then it solves itself What i mean, i don't remember having this issue with normal client
I can only guess. We need to sort out crash dump code for 64-bit.
I recently tried one of my modules on the x86-64 branch (32-bit version), and I got errors about a missing import from tier0.dll. It was _spewInfo or something like that. I would normally just open dependency walker to verify the exact symbol, but windows 10 has done something horrible with its dll dependencies that causes dependency walker to freak out and take forever to process any dll.
Missing imports from vstdlib and tier0 we can maybe provide support for. I think any module using these is probably going to break for other reasons (I would imagine they rely on fairly internal stuff.) Can you give me specifics, such as the module's name or code?
It's my debugger module. I'm in the middle of re-working it, and I think the only functions I currently call from tier0 are Msg() and SpewOutputFunc().
So most of the console spew/printing methods have changed. It's probably possible to provide the old functions.
SpewOutputFunc() is the only one I really need. I can do without Msg().
That's the part that changed the most, hah. It's an entire interface instead of just function pointers now, I suppose. I wouldn't expect this to be fixed soon honestly, but hopefully before any real release.
I'm getting this engine_client.so load error too - on the same distro. I'm using the native Steam runtime that's its own package on Manjaro, since steam's own runtime is borked.
I think I found the problem, strace shows a bunch of openat() calls (presumably for dlopen()) for libedit.so.2 that all return -1 with errno set to "no such file or directory" right after loading engine_client.so
Sorry, you need to Log In to post a reply to this thread.