#Utime lua panic gmod mod#
#Utime lua panic gmod update#
#Utime lua panic gmod Patch#
#Utime lua panic gmod code#

I had the same issue on my server people joining were timed out with aĮngine Error: Lua Panic! Something went horribly wrong! 'not enough memory'įailed to lock vertex buffer in CMeshDX8::LockVertexBuffer: nVertexCount=174, nFirstVertex=0, nVertexSize=4, VertexFormat=8Įrror. I'll keep looking into it as time allows. I wish I had more definitive results to such a puzzling problem, but this is all I could gather today.

#Utime lua panic gmod Patch#

So, to me, this could mean that players who typically crashed while UTime was installed were joining with the default utime_enable 1 and were still timing out, whereas our tester who definitely had it set to 0 was not.Īgain, this is not a proper test and these results could be misleading, but this could also mean that sparky's patch + my patch + a default of utime_enable 0 could prevent this issue - at least for as long as it remains disabled.įor now, UTime is removed from the server and I have yet to see a single timeout (going for about 45m with ~35 joins). However, other players who were also trying to join before and had been timing out were still timing out.

#Utime lua panic gmod mod#

Our tester kept restarting garry's mod and rejoining successfully each time. While not a perfect test, it was the best we could do (I needed to know if I had to do another restart to remove UTime entirely ASAP before players got established). Anything they could to quickly replicate what the server might look like (from a memory perspective) after hours of gameplay.

I had a group of our players spawn a bunch of dupes all over the map, spawn money printers, holograms, gun shipments, etc. I had our tester modify their client.vdf and config.cfg (just to be safe I guess?) to set utime_enable 0 (with the proper formats for each file) to ensure that when they join, the convar would already be set to 0.īecause I couldn't get any valid results on the test server, I took a risk and just threw it on our primary server where we regularly see 20-30 players.Īfter restarting, our tester was able to join without issues. My thinking was that if it was something to do with the logic, breaking out early and defaulting utime_enable to 0 could help the clients running on the base gmod branch. On top of sparky's patch, I also tried simply breaking out of the think function if the panel was supposed to be hidden (if the convar is set to 0, or if the player is using the camera, etc.). All of the logic (the traces and so forth) was still being done even with the convar set to 0.

#Utime lua panic gmod code#

I can't use that server as a way to test because our testers aren't even crashing reliably anymore.Īs a result, take all of these outcomes with a grain of salt.Īfter digging through the clientside code some more I realized that the utime_enable convar doesn't really do anything but show/hide the panel. I really expected them to have crashed at this point. They had tried joining at different points in the game - when there were no props but many players (right as it started), and when there were many props and players (after hours of gameplay). This threw me off because they have been timing out reliably ever since we added utime.

Had our reliable-crasher connect there instead (it was just him and I, no props or anything on the map).

Made an exact copy of our darkrp server, put the master branch of UTime on, and started it.

I tried a little experiment with someone who was reliable timing out I've also all but confirmed that those affected are all using the base gmod branch. With Sparky (thegrb93)'s patch, we noticed that fewer people were timing out, but still a non-0 number.

#Utime lua panic gmod update#

I'll update this comment with any additional info I find. It's worth noting that players on the 64bit branch of GMod did not experience this problem at all, or if they did, it was significantly less frequent. I am now fairly confident UTime is the culprit but will continue to test. This continued to happen after another restart, and only stopped after removing UTime and restarting the server again. After restarting it was like a pandemic - easily 30% of players were timing out while, or shortly after loading in.Īfter analyzing the logs, we discovered that zero players timed out within 6 minutes of spawning from the time the server opened, to the point where we added UTime. We just recently opened a DarkRP server and added Utime a few days after opening (UTime was the only thing that was added or changed at that point). To add to this issue: We've been experiencing frequent and numerous clientside timeouts for years now. Edit: On my vanilla server these lines were automatically added to the clients client.vdf file, but on the afflicted server it would not add them.ĭo you know which of those specifically helped? I can't imagine changing the colors would have an enormous impact on clientside memory usage?