joloha.blogg.se

Utime crash
Utime crash






utime crash utime crash
  1. #Utime crash mod
  2. #Utime crash update
  3. #Utime crash code

#Utime crash 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 crash 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 crash update

    I'll update this comment with any additional info I find.

    utime crash

    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?








    Utime crash