Yea, definitely sleeps is the key to this problem (i did some fun researches), but it wasn't very obvious for me, that world.Export() could do something like that, until i started to think about it like - "it sleeps because it waits for the answer from another server" and then it become very clear that way.

Anyway, would be nice if this information will be mentioned in byond docs for Export(), that it can sleep while waiting for answer.

Also, i curious about - why view port totally dies and never recovers, even after all sleeps already gone.
We get this problem constantly still.

The only world.Export() we use is on player login to check and see if they have the game set as a favorite. There's no sleep used in the proc that gets called for it.

The issue could be happening when someone logs in, I don't think anyone really associated the 2 of them happening at the same time, but if it is, it's not the player who logged in that had their viewport frozen, it'll be a player who's already logged in and playing.

I'll try disabling the proc with the next update to see if it helps anything but it seems weird that its what would be causing it.
In response to IceFire2050
With my problem its just simply that world.Export() may sometimes wait for the answer for about 15-20 seconds until service returns us IP information about that player (didn't know that it can take so long, until i started to debug that question), and in simple words - sleeping client/New() for 15-20 seconds may freeze player's view port and only, if player relogs, while old client/New() is still waiting to finish (at least, this is what i got while testing).

So, the only when and why Export() can freeze view port is - when server didn't return answer instantly, because it waits for something and to fix that problem, we need to use spawn() or another approach if i'm not wrong.

But if we use something like spawn(), it means sometimes we will get info with Export() with delays, which may not be good for every feature where we need to use it, but i think there is nothing we can do about.

Also, i couldn't to get any problems with small delays, this only reproduced for me with long delays, even sleep(100) wasn't enough, but sleep(200) did that every time (sometimes world.Export() may take 20-30 seconds to complete request) (yea, i tested with sleeps to get some idea on when this can happen), at least for our build.

Edit: i just noticed, that if we login local server with "yellow GO button in DD" - sleep won't do anything bad, and if we join server using "open location" in byond's drop down menu - it will. This is strange, i wonder, whats the difference... I usually use 2nd account to test things locally.
If your game has a lobby structure, or loading screen, you can hide your blocking operations like database queries and world.Export() calls there, in those kinds of situations you probably don't care about instantaneous results.

loading screens are designed to hide things, it's practically gamedev tradition at this point.
So in my most recent build, I disabled any uses of world.Export() to see if this was the cause. Mine and other players viewports still freeze.

It may also cause this issue but if it does, it's not the only cause of it.
I think world.Export() was a red herring all along. It's clear it only came up in the context of client/New(), where it's a horrible idea to do that for fairly self-evident reasons.
Question for those still experiencing this: During a freeze, do animated icons keep animating? (I mean specifically ones that use an animation built into the icon itself, not the animate() proc.)
How about you pick an ss13 server and play for a few rounds and see for yourself?
for what it's worth, i've never experienced this problem in my games, i've been programming since 2005, and i haven't used client/New() in any of my games.
In response to Mista-mage123
Mista-mage123 wrote:
for what it's worth, i've never experienced this problem in my games, i've been programming since 2005, and i haven't used client/New() in any of my games.

Coolio, something in client/new it would be nice for somebody with debugging tools to experience it for themselves so the issue can be put to rest after all these years.
In response to Pomf123
Pomf123 wrote:
How about you pick an ss13 server and play for a few rounds and see for yourself?

It likely won't help. Since I'm fairly convinced the problem is server-side (all of my experiments with users who had this reliably showed me nothing amiss on the client side that I could point to), I'd need to catch it there and figure out what state it was in by analyzing it in the debugger. Although being able to catch it reliably client-side would at least help me definitively rule some things out, chances are they're not going to get the job done.
In response to Lummox JR
No. The viewport is frozen to its entirety.
In response to GreatPirateEra
Thanks. That's helpful to know.
Getting a similar bug on Teridal very consistently. Once every 3-4 hours, screen freezes and I have to fully close and reconnect to fix it.
I'm getting this bug every 5-20 minutes. I haven't found any workarounds other than simply closing/reopening the client.

The frozen viewport issue doesn't seem to change in frequency when there are more players around; it seems to happen just as consistently when playing alone on test servers.

Honestly, I doubt it's entirely server-side since other people don't seem to experience it nearly as frequently as I do. The BYOND version seems to be irrelevant as well, since a select few others have reported it happening with pretty much every version out there.

When I experience the bug, the viewport freezes completely (all animations stop mid-frame) and, strangely enough, most sounds are cut off. I can usually hear an audible *pop* when the bug happens, as the currently playing ambient track stops playing. However, I can still hear global sound effects such as command announcement dings and alert level changes.

Nothing out of the ordinary turned up in the server logs when I tested the bug. Admittedly I have no idea what I should be looking for.
Just to be clear, the bug almost always seems to resolve itself after some time, usually upwards of 5 minutes. Every time I've tried waiting it out, the viewport unfroze itself. I've only had the patience to test this two or three times, though.
My game had this bug a few times. What seemed to fix it is fixing all runtime errors in my game although I say this very vaguely because it was a long time ago.
In response to Lummox JR
Lummox JR wrote:
Question for those still experiencing this: During a freeze, do animated icons keep animating? (I mean specifically ones that use an animation built into the icon itself, not the animate() proc.)

I know this is way late at this point but all animation stops. Animated icons will freeze on whatever frame they happened to be on at the time. This also applies to movement as well.

Also, I did notice that, at least in my game, if I populate a stat panel with icons of multiple objects at once like if a player is viewing their inventory, if the viewport is frozen, that stat panel will only display a the first few icons in the list and then stop loading more.
This happens very frequently to users in our game. For some it's as often as every 20 minutes, and for others it's every couple of others. But it's pretty alarming with how many users it happens to and the general frequency.

We're on the latest stable release (511.1385).
Yeah, this is a growing issue.

The weird part about it is, although I haven't experienced it myself, as soon as I updated my server to 512.1411 and required players do the same, at least a few people reported connecting to a black screen. Weirdly enough, two of those users fixed the issue by installing 512.1411 again.

I can't remember the last time I've experienced this issue myself, but with the update to 512.1411 immediately causing issues for players, it makes me wonder whether there's a clue in this process somewhere... perhaps resource related?
Page: 1 2 3 4 5 6