for me it's just when i have 1 game running, and as long as my computer's fan doesn't kick into high gear, then i don't lock up =/

Here is a bug report that MIGHT shed some light on the issue:

https://github.com/tgstation/-tg-station/issues/12226

They get this to happen pretty consistently when viewing lots of orbiting ghosts.

Ghost orbit uses transforms to make the user's sprite appear to orbit around something 24 pixels out. here is the code for that:

https://github.com/tgstation/-tg-station/blob/ 2feedfa0093e2c30e5a4fe807a37cdaf8db57923/code/__HELPERS/ unsorted.dm#L1210

(line 1210 if it doesn't jump you automatically)

Arguments used by ghost orbit are: src.orbit(thingtooribt, 24, 0)

This suggests transforms OR animate MAY be involved. We do use them elsewhere a lot

Find the common denominator, something state wise that both animate AND transform change or fuck with, that's been around for ever.

They could be two causes of the same core issue. Especially since it does seem like there might be a link to a timing issue or clock drift.

When I said state change, I was referring to internal state.

Something that processing a transform or animation (current guess is that it's animation that's causing it in the ghost orbit case because of a similar issue on /vg/ relating to abusing animate on all lighting changes) changes, or triggers state wise, that's existed since 300 and could be related.

Mainly look at anything where an internal state is changed then changed back where there might be a case where it's never changed back.

I don't know enough about how byond does things client side to make any better guesses than that, but just for the sake of it might help, assume these things are related, use that to try and find a potential common denominator so to speak. (Assuming you aren't already doing this.)

And lets re-cap, sounds and appearances stop updating, right clicking shows the items on the tile in the frozen state, etc etc etc, so this could also be something in network code? or some abstraction intermediary about processing network data or appearances?

I'd think not because apparently animations stop, be they animate() or animated sprites, unless there is some state variable that is common (or in some method called by the code) with the code of any number of: network data, appearances, animate(), ui tick loop.

How ever, there is potentially two completely different issues here, since some people are fixed by text toggle, and some people aren't

Regardless, that is a hint none the less, as it tells you one is fixed by doing that, and one isn't.

The key to figuring it out is finding a project--preferably a low-overhead one--that reliably triggers the issue on all machines. If I could get it to happen to me in a controlled environment with the debugger, I could make headway on it.

Short of that, there's a slight possibility I could put together a test build that included debugging info to say what was happening on the client end. However that might not tell me the whole story, if it's the server that's screwing it up.

If you're fine with giving out a debug build I'm sure we can get someone to trigger the bug with it on ss13. I have no idea if we can make a program to easily reproduce it unless we have some kind of automated script that terminates dreamseeker.exe and reconnects until the freezes start happening.

Did the text mode test, it had no effect.

What I did find while editing the variables of a frozen person's client was if I changed their view range the port would update and zoom out correctly, but instead of loading in the newly visible tiles the same frozen image is displayed zoomed out with black bar borders.

So the """""fix""""" we're having success with is telling people with the screen freeze to delete the cache folder in documents/BYOND then relogging. If that's any help.

Might be a red herring though.

Yeah it's basically 50/50 on if it works so rip.

Hello, i just found out that world.Export() may "kill" viewport updating for a player if previous call is still in progress when we are trying to get new call or something like that. But for our server (ss13), this is only a login problem, since we use that to get IP info from external source when client logins inside "client/New()". The way how this happens - while world.Export is in progress and still havent recieved information, just relog into the server (which will start another world.Export call) and it will lock game's viewport.
Setting "set waitfor = FALSE" in a proc that uses world.Export seems to fix that issue, but i have feeling, its not a proper way to fix it.
Anyway, maybe there is anyone else with this problem or it may give another valuable information.

Dunno, but i think it puts a whole client/New() procedure on pause while waiting for the answer. Anyway, i have no idea how that thing actually works.

I just put simple debug messages with some text to see, if there is any delays and to me it looks like thats is the problem. If client disconnects then shortly reconnects while world.Export still tries to get an answer - it makes view port to die.

From a test it looked like that:

client connected > world.Export called > client disconnected > world.Export still waiting for the answer > client connects again > new world.Export is called while old still is in progress > viewport died.

i can provide a link to our repo where that world.Export is located, if that will give anything usefull.