Jul 3 2015, 5:57 pm
|
|
Lummox JR
  |
This isn't a new bug at all. The problem is I've never had a reliable way to reproduce this.
|
Gotcha. Sorry but I'm not finding any pattern to it either or any way to repeat it...too random to tell...
As for your memory leak with certain fonts (if I understand you correctly) - I'm not having any of those issues. I'm just watching Stargate: Atlantis and keeping SS13 in Observe mode with Windows Task Manager pulled up as well watching the Process Memory of dreamseeker.exe *32. It is hovering around 356K, but goes up and down I guess as things are loaded into the viewport and out. I've seen different fonts popping up in the chat log (I don't know them off the top of my head), but I haven't noticed any memory leaks or so contributing to the font. Is there anything, ANYTHING at all that I can do at my end to help figure out this issue? Besides find a way to reproduce the issue? Is there any debug mode I can run or a log or something I can find?? | |
Without a consistent way to reproduce the issue I really don't know. The memory leak thing I think is a red herring and may no longer exist.
| |
The bug tom is seeing may be unrelated, we've had reports of the ManualFollow verb being extremely laggy, which is probably a ss13 coding error rather than a byond issue
https://github.com/tgstation/-tg-station/issues/10093 | |
Descriptive Problem Summary: Basically, in every game i play, over all the time i've played byond, the main window of the game will freeze, and (on my end) it seems as if i am doing nothing, no matter what keys i press, howwever, other people still see me doing actions or moving, chat still functions normally, and verb windows function normally, since this has been across all versions of byond, I'm believing it's my PC, i've fully updated my gfx card and removed the check mark near use graphics hardware for maps, neither of those solved the issue.
Numbered Steps to Reproduce Problem: Not really reproducable on a "simple" scale, just randomly happens over time for me. Does the problem occur: Every time? Or how often? every time, at random times In other games? over all games In other user accounts? on all accounts On other computers? only have 1 computer so i'm unable to say When does the problem NOT occur? when byond is not running :) Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.) yes, all. Workarounds: closing that dream seeker window and re-opening it | |
There's a bug report for the issue of the map freezing already, but there hasn't yet been a reliable way to reproduce it. If you have any info that will help, I encourage you to share any details you can.
| |
id:1492576 is one, but not the original. id:1825847 is a better-known recent thread, and is the one I'd recommend looking into most. The oldest report will probably be hard to find, and the issue was known to exist even before that.
I have a gut feeling that some kind of lag spike or connection hiccup is to blame for this. It's not a total connection loss because output always still works, as do statpanels IIRC. What I do know about it is that changing rendering modes doesn't help (not a surprise considering the bug's age), which means the problem is either in client-side code deciding not to update the drawn map, or far more likely, server-side code no longer sending map updates at all. I also know that this issue does not happen to all players at once, but only to some players. | |
Well, I've never played ss13 (or whatever that is) and each game it's happened to me on has been a completely different source, and everyone i've asked has never had it happen to them, my memory usage doesnt change too much (sits between 70k and 110k) and i've yet to get a dream seeker has crashed msg, is there any sort of diagnostic that i could run on my computer just to see if it would be causing the issue?
| |
None that I can think of, no. I know some users are more prone to it happening but I don't know why.
The fact that verb panels update for you, not just stats, is extremely interesting. That suggests you're receiving map updates, but they're not being redrawn. | |
This can happen if you have 2 monitors, if you watch movie fullscreen via the internet, if you Play PC Games on fullscreen while having a byond game open there is more but those are the ones that I can think of atm!
This also disables hardware mode sometimes | |
I'd like to propose a radical experiment. While switching from hardware to software mode has not shown any impact, I'm curious if a definite forced icon refresh would. Switching in and out of text mode will do that, so I recommend trying a server that does not have control_freak set (or at least lets you access the command menu, so you can go to Client | Command...). The next time you get a freeze on that server, go to Client | Command... and try this:
.winset ":map.text-mode=true"
Follow that up with:
.winset ":map.text-mode=false"
My goal here is to narrow down at what point in the logic the map is failing to update. These are the contenders: DrawMap_CIO(): This function is on the frontend. It's called whenever the backend says the client map-related data is in a changed state--which it should be, considering that statpanels and verb info are updating. It sends the Draw() command to each map control. The Draw() function in turn will force an icon refresh, as opposed to Redraw() which uses the same icon list but tries to draw them again. Various actions on a map control will force a refresh, switching in and out of text mode being one of them. GetMapIcons(): This function is on the backend and retrieves an icon list to be drawn. If the update flag is false, it will use the old icon list. Otherwise, the main map will update if the map is in a state where it's ready to be drawn. The map_consistent value that determines this is set in a couple of places that I think are definitely being hit. Therefore, it's my expectation that a forced refresh should always work. My analysis based on the known symptoms suggests the following: - Because the verb panel is updating, the server must be sending the map updates as expected. - The client tick routine on the frontend is happening, because statpanels are refreshing. This also means the client tick is happening on the backend. - cmap_changed has to be true, because it's set to true in about a zillion messages that you would have to be receiving in order for your verb panel to update. - Because cmap_changed is true and the backend timer is happening, DrawMap_CIO() is apparently being called. - Since we can probably assume the map's window is not incorrectly believed to be invisible or minimized, Draw() is being called for each map control, and Draw() forces an icon update. - GetMapIcons() should therefore be called with a true update argument. As long as map_consistent is true, which it should be because the server-side SendMaps() loop appears to be sending all the updates, then the icon list will be rebuilt and redrawn. Somewhere along the path, one of these deductions is incorrect, because you're not seeing map updates. Since this issue is known to persist across changing hardware modes, it means the icons are not being updated, so GetMapIcons() is either never being called with a true update argument, or map_consistent is false. (The value of map_consistent is only set to false when the map bounds change, so that's an infrequent message; it's set to true in two different messages, both of which are logically being called.) The experiment I proposed will force a Draw() call. If the logic leading up to the DrawMap_CIO() is wrong, or the logic in that function is wrong, then changing to text mode and back will force a Draw() call to the map control. If the logic I traced through Draw() and GetMapIcons() is broken, then I would expect to see no change. But a lot of this logic is also predicated on the verb panel actually updating. It would also help to know the exact ways that your verb panel is changing. Specifically, are you seeing position-dependent verbs (e.g., ones that only activate when you're next to an object) change as your character moves around the map, even though you can't see the movement yourself? Finally to cover all bases, I'd like you to play with mousing over objects when it's stuck. Do you see the right names showing up in the statusbar that go with the objects you see under your cursor? (I expect this is the case, but I'm curious to know for completeness' sake.) | |
I will try the commands next time it happens,
when i mouse over objects, i do see the name of the object (such as an item on the ground) even after i move on other peoples screens (item of course remains stationary along with everything that i can see) and they are the correct names to get the proper results, do you know of any server that doesnt have the controlfreak thing you mentioned so that i can input those commands? Edit: tried it on two games i play frequently, the command did nothing so i assume they're control locked, however i did learn that its ALL icons that lock up, including ones in different panes (for example a picture of what your character is doing in the menu that has your stats or character inventory) | |
Descriptive Problem Summary:
While playing games, the map screen will stop updating after a seemingly random amount of time. The game plays like normal. I can use all associated commands, and I can still move around in the game but the screen doesn't update to reflect that. The map itself just flat out freezes. If there is any animation on the screen at the time it will stop mid-animation on whatever frame it was on. The info tabs and chat will keep updating though. Numbered Steps to Reproduce Problem: Log in to game. Wait randoml amount of time. Code Snippet (if applicable) to Reproduce Problem: No coding. Game doesn't crash so no error report. Does the problem occur: Every time? Or how often? Every time the game is left open long enough for it to happen. In other games? Any game I play. In other user accounts? No other users i've talked to have mentioned it. On other computers? I only have 1 PC to test this on. When does the problem NOT occur? It always happens if the game is left open long enough. Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? This has been happening for a little while now. At the very least, it's definitely been happening for 507 and 508. It may have been happening before that too. Workarounds: Close dream seeker and log back in. Using the reconnect function in dream seeker will not solve the problem. | |
Can most definitly confirm it isn't SS13 exclusive. It happens to me on nearly any game that's relatively large in scale, Naruto, Dragonball Z etc.
It isn't related to maptext, I've had it happen in games which make no use of it. It seems to be like a time bomb, it can happen after 10 minutes but it >will< happen within 24 hours. This isn't 100%, but the longer it's running the more chance of it happening. Strangely, though this might be complete coincidence, 100% of the time that it's ever happened, has been whilst the game is alt-tabbed. I've NEVER had the viewport freeze whilst actually looking at the game. I also periodically move on the game, and this seems to "extend" the lifespan of the viewport for some time. Almost as if extended periods of inactivity cause the issue. I can relatively (Within 24 hours usually) reproduce this bug, is there anything I can do to help narrow it down? | |
What supposedly is the case so far (it'd be nice if you can confirm) is that not only does chat keep updating, but so do statpanels and position-sensitive verbs. If that's the case, it means that the server-side map loop is running and its messages are being sent, and there's a limited selection of things that can impact this on the client.
I just merged in another thread on this issue where I discussed some of the logistics of this, and a possible experiment to try the next time it happens. | |
Yeah, everything keeps running. You can still even move and do things, just the viewport doesn't update.
| |
This happens when the monitor flickers when opening a game thats in fullscreen mode or windowed fullscreen depends on the game you open, this issue is present if you have 2 monitors aswell. Games that are on Steam for example.
| |
Zasif wrote:
This happens when the monitor flickers when opening a game thats in fullscreen mode or windowed fullscreen depends on the game you open, this issue is present if you have 2 monitors aswell. Games that are on Steam for example. While I do run dual monitors, programs going to full screen are not the cause. At least not for me. The screen can stop updating while im playing the game and doing nothing else. | |
Lummox JR wrote:
What supposedly is the case so far (it'd be nice if you can confirm) is that not only does chat keep updating, but so do statpanels and position-sensitive verbs. If that's the case, it means that the server-side map loop is running and its messages are being sent, and there's a limited selection of things that can impact this on the client. Yes. The map stops but the stat panels and chats continue. | |