64-bit Garry's Mod - Developers

Definitely true but I've had crashes bothering my servers for a long time which I can never reproduce, perhaps due to some race condition or other variable that I am missing. Having crash dumps would help so much to just find where it actually crashed.

I completely understand that minidumps are useless for us because we are missing debug point files or something like that right? I'm not super into debugging But why can't we really have those files, doesn't unity3d ships unity with those files already? I've heard once from someone that with those files "You may apply reverse engineering and get game source code", but what's the deal about that, garry's mod it's about making the possible to achieve our goals with all the tools we have But well, I can understand if there are licenses behind, if game runs slower due running in debug mode, or any logical reason about why we have to accept the face we can't do anything against crashes

They're not going to be any more useful than the current dumps we get from Windows SRCDS, but yeah.

windows mdmps have lua stacktraces and linux crashhandler only outputs engine errors.

Holy keks! I'm able to run SP GMod 64bit with wiremod, m9k and e2 addons on linux I got error: [Wiremod] lua/wire/wireshared.lua:1013: attempt to index a nil value 1. v - lua/wire/wireshared.lua:1013 2. unknown - lua/includes/modules/hook.lua:84 I tried to connect to 2 servers First server - i was able to see world, then game froze and crashed Second server - i was able to see MOTD after loading on loading screen, game froze and crashed. Shooting is weird, all bullets shoot in some strange direction. https://files.facepunch.com/forum/upload/315618/cc92d6b8-f230-44fb-b07b-af41c1eb8ee8/Screenshot_20181221_164206.png

I joined some DarkRP server. Ping in game ~200ms, server browser showed me ~70ms ping. Something was with my movement, can't describe. Like screen flickering or similar. Another server - instant crash after loading.

Please check the video I posted on page 6 - does that look like the issue you had?

Yes

Having played gm_raid last night as a brief stress test thanks to the large assortment of NPCs and cluttered combat to deal with, everything worked pretty fine and even loaded the combine reinforcements in an instant compared to the brief hitch on 32-bit. The only noticeable problem I seemed to have was that, at a complete inconsistency, some models in my custom folder had their textures loaded and others didn't. Mainly an M9 replacement for the pistol, and various HD ammo boxes.

i just saw that in the 64Bit version that jit.util does not exists so this may also break some stuff (i use it to check for bad functions on the client as an example)

I seem to be crashing a lot more on the 64-bit branch recently, and playermodels seem to have begun to flicker with certain SWEPs as well? This is on Windows 10 (v1803, Build 17134.407). Here's a few dumps: https://winteris.moe/share/2018-12-28_22-59-07.dmp https://winteris.moe/share/2018-12-28_22-59-21.dmp https://winteris.moe/share/2018-12-28_22-59-28.dmp

I know you're probably not working on a linux version but here are my test results, I've noticed three problems: engine_client.so lib problem, it can easily be solved by users by looking at this file with ldd and installing/linking missing libraries Flickering weapon and leaping movement on remote servers (client-side prediction problem?) When firing a weapon bullets fly in wrong direction (they are always skewed towards one direction, when shooting into that direction they fly straight) Not really a problem because it's probably not caused by 64 bit version but by bad scripts but I've crashed on some public rp servers

The Linux builds should be better now. There's both 32-bit and 64-bit binaries shipped and most of the dependency issues are resolved (although there is still some confusion in terms of Chromium & editline.) The weird movement jittering on Linux is fixed too.

Great work Willox! Does that just leave the remaining dependency issues with Linux and support on macOS before release or is there yet more to be done?

I've still got hundreds of fixes to go back and improve on. A lot of them were done lazily with the intention of just getting the game to launch. I also think there are going to be a lot of bugs specific to non-Windows builds which will need to be ironed out. macOS is a big question mark. It's gonna be really easy or really hard. Many of the fixed bugs on Linux will be shared by macOS, so hopefully there will not be as much to fix there. I do need to move it over to SDL2 though.

I am already so excited about this and what the game will be in the future.

Chromium part fails to start, when kernel.unprivileged_userns_clone=0, sandboxing issues. Possible ways to fix: Catch exception and request user to enable, sudo sysctl kernel.unprivileged_userns_clone=1 Start chromium without sandbox Something other i don't know

I think we'll be taking your first idea, although probably with a more generic message. Chromium can be sandboxed through a separate SUID binary too, but it'd require manual setup on the users end and I can't really tell how supported it is.

Right, so odd request, but could you change the #autoplay-policy in Chromium's flags to "No user gesture required."? As of Chromium version 71, Autoplay for Video/Audio is disabled by default unless the user interacts with the page. A useful feature for desktop versions of Chromium/Chrome certainly, however it breaks YouTube/embedded video/audio playing in Cinema and other media player implementations where no direct user interaction ever happens with the panel that plays the media.

Would be better if you can specify this by function

So I've been following this thread for awhile, but I remain somewhat lost as to the utility of all this. What sort of avenues does 64-bit Garry's Mod open up? Will it run better under heavier loads? Allows more entities to exist in a given environment (any anything that may have hit limits previously)? What kinds of things would it open up to a small-time creator such as myself, if anything at all?

By function? What are you meaning?

I think he's implying Chromium policies should be implemented as some kind of hook/setter function/convar so the client (or the server's client implementation) can choose.

local DChromium = vgui.Create("DChromium_idk_how_it_was_really_named",DFrame) DChromium:EnableAutoPlay(true) DChromium:EnableAutoPlay(false) For example if I want to use Chromium but don't want to play things in it. By default I think auto-play should be, if I don't want then use a function to disable

Oooh, yeah, okay. I agree with having the option for most things honestly, but I'm not entirely sure if opening up the entire Chromium Policy settings to developers would be a smart idea, given the power some of them have. I think your approach, with specific policy functionality, would be a good idea instead, but really just so long as Autoplay isn't disabled or we can enable it through some method; either way works for me.

Here's an example: It stops the game from crashing from "Lua Panic: Out of Memory" on Linux. And Windows too, but personally that error was rare for me on Windows. I used to get it a ton on Linux. Now the 64 bit beta doesn't crash with certain addons and I'm able to stay connected to a server with many addons with PAC and Outfitter enabled without crashing, when usually I'd crash almost immediately if an Outfitter playermodel or a PAC loaded.

fixes: lau running out of memory issues becoming a thing: it cant recenter my mouse to the window.. aka no mouse capture... aka i cant look around

I think I see what you mean about the mouse. Could you make sure you have 'raw input' enabled for now? You can change it under GMod's options.

So it's primarily a thing for Linux systems. What about entity limits? At least I think it's entity limits. I have a map I was working with, gm_boreas, which is so massive it's hit some limit that crashes clients quickly when they spawn a bunch of entities in. Would 64-bit Garry's Mod alleviate this problem?

it would seem that the option for raw input is greyed out... wat