ID:2181150
 
(See the best response by MrStonedOne.)
So, every time I log on SS13 or relog after a disconnection or after the server restarts, I have to wait nine minutes before the game is fully functional. Let me elaborate.

After I log on to the server, reconnect to the server,, or after the server reboots, every five or eight seconds or so, I have a half a second margin to click on a tab, click on a verb, click 'ready', or click on anything for that matter, because while the game is attempting to fulfill my request, the window is in a period of (Not Responding) like this: http://puu.sh/sGquB/a636327a23.png during that period of time. Dreamseeker says I have a latency problem of 1.7k-2.5k ms or so, it says the window is (Not Responding.) For some reason, the 'Get Ready' window seems to disappear at times, and even separates itself from the SS13 window in the toolbar (it shows up as a separate tab).

IF I managed to click something during that half or quarter of a second margin, I have to wait another five or eight seconds for a response from the game or for anything to pop up, in which the process repeats itself for another nine minutes. Sometimes, I do not even receive that luxury and the game decides to not respond. At all. It allows me to minimize, for some reason, but, again 5-8 seconds for it to respond to maximize again, if it lets me, at all. In addition the station clock, say, if I joined at 13:08, it stays 13:08 for the entire 8-9 minute duration, in which it then updates the time after the problem subsides.

Strangely, while the window says it is not responding, even if minimized (showing a preview of the window) or maximized, the chat scrolls on as if absolutely nothing is happening. It is as if the chat box is its own little program and is unaffected by these periods of freezes. Also, strangely, during this period, the game only seems to be affecting my computer's memory by 2%, which is extremely abnormal, when Dreamseeker usually takes 10-15% memory, which makes me think something is preventing the game from working properly.

I have tried to look at 'Options and Messages' to see if there were any resources downloading, but there aren't. I don't know why this entire phenomenon occurs over a period of eight and a half to nine minutes EVERY SINGLE TIME I log on, reconnect, or after the server reboots. It does not matter if the server is in the middle of a game, just started, or is ending.

I have tried reconnecting multiple times, I have tried cleaning cache about 8-10 times, uninstalling and installing BYOND again, doing a CLEAN wipe of the directory, getting rid of all BYOND evidence, trying different BYOND versions, including stable and beta, updating my drivers, restarting the computer, enabling and disabling my antivirus for Dreamseeker, disabling adblock (I don't seem to ever receive advertisements, anymore, even with adblock off), restarting my wifi, and among tons of other things. I remember tweaking with my internet settings, such as disabling Nagle's algorithm and among other things in the windows Command prompt, which is the only thing I can think of.

Can someone please help me out, here? This only happens on certain SS13 servers.

I am on a Windows 8.1, on the latest Beta version of BYOND. Firewall on all BYOND programs is off and the BYOND folder has full permissions across the board.
Could you list what ss13 servers you have had this happened with. There is some passive asset sending that happens after connection (that doesn't always show in messages), but there are 3 key ways of sending these assets that different servers use, so know what one(s) it triggers on, or if it triggers on all three, don't worry about knowing what system the server uses, you just tell me what servers it happens on, I know the code bases well enough to figure out the rest.

How ever what you are describing sounds like an issue I had with winamp a few years back where my Anti-virus was conflicting with it and it would lock up and not take input, but the song name ticker would still scroll along.

you could try exempting the cache folder as well (if you haven't) and see if that helps.

edit: also, try looking in resource monitor to see if DS is using any disk during this lockup moment. This really sounds like seeker is blocking on disk access
It happens mainly on Paradise, Yog, and anything with 'Default' as its main codebase. Paradise is the worst (and, sadly, it is the server I play on the most and icon, code, and test things on.)

DS does seem to use disk, but it's 0.1 mb/s, as normal and during lockup.
Ok, If i had to guess, it sounds like something about the asset cache is triggering this (most likely something on byond end about getting the resources or the asset cache browser trick we use), as a theory, since you said you've done some coding on paradise, add a return at the top of this proc on a local server:

https://github.com/ParadiseSS13/Paradise/blob/master/code/ modules/client/asset_cache.dm#L130

and see if it still happens
In response to MrStonedOne
MrStonedOne wrote:
since you said you've done some coding on paradise, add a return at the top of this proc on a local server:

https://github.com/ParadiseSS13/Paradise/blob/master/code/ modules/client/asset_cache.dm#L130

and see if it still happens

code\modules\client\asset_cache.dm:127:error: return: instruction not allowed here

I am not exactly the best at coding.
find the line proc/getFilesSlow(var/client/client, var/list/files, var/register_asset = TRUE)

put it on a new line immediately after that line
old:
//This proc will download the files without clogging up the browse() queue, used for passively sending files on connection start.
//The proc calls procs that sleep for long times.
proc/getFilesSlow(var/client/client, var/list/files, var/register_asset = TRUE)
for(var/file in files)
if(!client)
break
if(register_asset)
register_asset(file,files[file])
send_asset(client,file)
sleep(-1) //queuing calls like this too quickly can cause issues in some client versions


new:

//This proc will download the files without clogging up the browse() queue, used for passively sending files on connection start.
//The proc calls procs that sleep for long times.
proc/getFilesSlow(var/client/client, var/list/files, var/register_asset = TRUE)
return
for(var/file in files)
if(!client)
break
if(register_asset)
register_asset(file,files[file])
send_asset(client,file)
sleep(-1) //queuing calls like this too quickly can cause issues in some client versions
Silly me, I forgot the indent. I'll see how this works and I'll update you in about 5 minutes.

Edit: OH MY KITTIES, IT WORKED! OH MY GOODNESS! Thank you so much!!!
Uh oh. We have a problem.

While my lockup issues stopped, Paradise's coders told me that it basically broke something else. This issue is specific to only a few people and it has to do with a specific BYOND bug with my asset cache.

They told me my only option is to try and get a bug report filled. Can you help me?
Since they're the ones who understand what broke with this change, they should be the ones posting the bug report. You can't be expected to magically know what this change broke for other people when it fixed your own issue. In order for me to understand what's happening, they need to communicate the problem clearly in a bug report themselves.
The lag stopped for me; I don't understand what broke, that's the thing.

I wanna know why my access cache is acting so funky to the point where Dreamseeker locks up on certain servers. I wish I could make a bug report for MY issue...
Best response
Lummox, this system is simple, it sends a browse_rsc, then a "<script>window.location=?trigger_some_topic_here</ script>", "window=hidden_browse_control_here") and then repeats sending the next resource via browse_rsc when it gets that topic. The idea is that this allows us to passively send all html resources that might be needed for any given window at client connection without clogging up the browse queue. (there are other parts of the system used when a window is opened to send over any that are in the soft queue immediately, and track what has been sent to avoid sending the same asset twice.)

/vg/ coded it the base system and /tg/ stole ported it over, where the rest of the code bases followed. The version paradise has is basically /tg/'s version.

everything you need to know about it is in this proc https://github.com/ParadiseSS13/Paradise/blob/ 0b77f70ef09106c17a7cdf6fbd1f928af19d5ee7/code/modules/ client/asset_cache.dm#L31

the client facing commands are

client << browse_rsc(asset_cache[asset_name], asset_name)
//...
if(winexists(client, "asset_cache_browser"))
//...
client << browse({"
<script>
window.location.href="?asset_cache_confirm_arrival=
[job]"
</script>
"}
, "window=asset_cache_browser")


This system has been for almost a year now with no issues, so it's odd puckaboo is even having issues.

I'd say something relating to disk access or something relating to that browse call is causing it, it may also be the winexists.

Puckaboo2, try this, remove that return you added, and go to this line just below that return, send_asset(client,file) and replace it with send_asset(client,file,verify=FALSE) (don't try to push this upstream to paradise, this breaks the entire point of the asset cache, its more for debugging.

This will tell us if it's the browse_rsc call, or if it's the browse() and winexist() call to narrow it down further.
After doing what you asked, Dreamseeker functioned normally for a bout 5 seconds after I logged in, then locked for about 10 seconds before going back to normal without any further lockups except with UI interfaces, which are laggy, anyway. This is a massive improvement, and I think that's what the game is supposed to do. It was basically the same as the 'return' thing I did.

I then went to the default code Para had, and it acted up just like I described in the OP, clock freezing up and everything.

so it's the winexists or the browse() call.... hmmm

that is...... odd. I was honestly expecting it to be the browse_rsc() line.....

revert back to normal para code, then this time, go to both /proc/send_asset and /proc/send_asset_list and find the line (both procs have it) called if(!verify || !winexists(client, "asset_cache_browser")) and replace that with just if(!verify)

This will tell us once and for all what of the 2 lines is causing it. if that fixes it, it's the winexists() line, a line that can be safely removed since its guarding against custom skins, something paradise doesn't support anyways. if it still happens, its the browse() line, and the cause is something on your end relating to javascript code
Okay, I replaced both lines with if(!verify) and it is back to freezeville again.
your antivirus scanner is hooking into the embedded IE windows byond uses (even thou you exempted it, that usually only applies to scanning files accessed) the lockup is from it scanning the small html script the server sends over that tells your client to notify the server when it gets the asset so it can send the next one down the line.

Try disabling any web protect or safe search or anything with a web related word and safe related word in the antivirus scanner's settings to confirm. what AV is it anyways?

It's McAfee. I'll check and see...

Do I need to turn firewall off besides the ones on the web?
Try turning everything off and see, and if that fixes it, try turning them all on one by one until it happens again, then you will know what of the five million features mcafee has is causing it.
I went to Chrome and IE and turned off webadvisor, I turned off real-time scanning, I turned off firewall, I disabled any McAfee services I could disable (some wouldn't let me disable them) and closed any McAfee programs up. Nothing worked.

I don't know what's doing it. Nothing's fixing it. I've had McAfee for over a year now and I never had issues like this with any SS13 server, so I don't know what McAfee is doing.

I can't just give up, now... if it's not McAfee, it's something else, but I don't know what!
download https://technet.microsoft.com/en-us/sysinternals/ processexplorer.aspx select dreamseeker, then hit control+d to view the dlls attached to it.

let us know what dlls are attached that don't say microsoft corporation for company name. something is attaching to DS that is screwing stuff up.
Page: 1 2 3