The only thing jumping out at me in that list is Bonjour (mdnsNSP.dll), which is from Apple. I suppose there's a chance it might be interfering somehow.
Was this list taken while DS was in a freezy state? Because if it wasn't, then whatever's interfering may not be showing up in the list.
I disabled Bonjour and nothing changed. Still freezyland.
http://puu.sh/sFJCA/531e25e231.png Just tried again while in freezyland. Nvidia stuff is still at the bottom. | |
Yeah, MSO is pretty active and I check the forums on and off throughout the day.
| |
Bonjour won't go away. I don't know where this DLL is coming from. Should I find the location and delete it?
| |
Bonjour is an Apple DNS service. AFAIK you don't actually need it, but you could Google around for more info.
| |
I uninstalled Bonjour and I am about to see if it helped. For some reason, after I uninstalled it, I have to download Bay's resources again... Maybe things will turn out better.
Nope, they did not. It continues to do what it continues to do, which is function for just a few seconds before the chatbox fills up with 'Welcome to Paradise.' Then comes everything I've said in the OP. http://puu.sh/sGquB/a636327a23.png See how the 'New Player Options' screen disappeared? It didn't do that a few seconds prior, but it keeps disappearing and reappearing while Dreamseeker is in its 'Not Responding' tantrum. I tried process explorer again and http://puu.sh/sGqGO/7927ea54b9.png nothing seemed to be unusual, but I am unsure why the program highlights FMOD sound system, which I don't even have. Does anyone have any idea what could be doing this? | |
FMOD is what BYOND uses for sound. I think it's just highlighting that by default--unless somehow it's FMOD that's locking up on you, in which case something a lot more bizarre is going on.
| |
It may be the problem, but I also don't think so, because this phenomenon occurs only on servers with access_cache. This never, ever happens on any other server or any other game I play on. I can deal with sounds just fine.
I strongly believe it has something to do with how asset_cache because once MSO told me to tweak it, something made the freezing go away for me, but I don't know what of something made the freezing go away or what of asset_cache causes the game to lock up for me. Is something looping and finally saying 'I'm done' and canceling itself? I know loops can cause lockups. By the way, I just realized I forgot to put my operating system and BYOND version on the OP. It's at the bottom of the OP. | |
lummox, this is the line of code that if removed the lockups stop
client << browse({" <script> window.location.href="?asset_cache_confirm_arrival=[job]" </script> "}, "window=asset_cache_browser") | |
I also forgot to mention the Station clock in the Status tab completely freezes at the station time I connected at, for the duration of the problem. Like... it'll be 13:08 (time I connected) for about 8-9 minutes and then update after the issue subsides.
| |
One important thing to note: You should never use a URL starting with ? when setting the window.location value. It should always be byond://?... because that's the safer way to go. BYOND does have some workarounds built in to handle that, but always do it the safer way for robustness.
Out of curiosity, is the asset_cache_browser control actually visible anywhere or is it a hidden browser control? And if it's hidden, what happens if it's unhidden? | |
Is this basically where the non-coder sits back and munches on popcorn?
| |
lummox:
elem "asset_cache_browser"https://github.com/ParadiseSS13/Paradise/blob/ 562df952711e10c6c75d19372ec141ebea8ac9d0/interface/ skin.dmf#L1507 puckaboo, find that bit of code above in interface/skin.dmf (do not open in dream maker, open in a text editor like notepad++ or wordpad) (should be around line 1517 replace
is-visible = false
with
size = 1x1
then recompile and test to see if it still does it. | |
I will, tomorrow. I have a lot going on tonight.
| |
Don't even need to recompile to try it, just edit the local copy of your skin.
| |
Mainly I'm curious if the fact of the browser being invisible is setting up some kind of weird race condition. I suspect this line of inquiry is a long shot at best.
| |
Sorry I haven't been active. I am going to see if MSO's suggestion does anything.
Edit: Everything is a lot faster, but whichever race I choose, it seems to have a body accessory option (even which a race shouldn't, like Human or Vox Armalis and such), and these options are always for Vulpkanin, and these options can be displayed into the loadout preview. http://puu.sh/sJS1l/6c31558223.png Also, more often than not, whenever the server acknowledges I changed something in character preferences, like, changing a color, the window minimizes. Just what the heck is going on? | |
That is odd as hell, I would try resetting back to their master just to double check nothing odd got changed and then re-applying that change to skin.dmf.
| |
Kay, so, I assume, somewhere in the process of attempting to fix things, I broke something, so I am going to start from scratch again.
MrStonedOne wrote: find the line proc/getFilesSlow(var/client/client, var/list/files, var/register_asset = TRUE) Alright, I tried this again and I had absolutely no freezes or lockups. Same as what happened last time I did this. Undoing this change brought the freezes back. MrStonedOne wrote: 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. Tried this, again. No freezes at all, but strangely, this whole red wall of text popped up: No away missions found. Creating random space levels... Loaded random space levels in 0.1s. Populating asset cache... Populated 204 assets in 0.1s. Initializing objects... Initialized 139564 objects in 3.4s. Initializing atmospherics machinery... Initialized 584 atmospherics machines in 0.2s. Initializing pipe networks... Initialized 5744 pipes in 0.1s. Finished object initializations in 3.8s. Which does not occur with the previous 'return' fix or the default Para code. MrStonedOne wrote: 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) Tried this too to see what happens. The red wall of text did not appear this time, but my original problem came back again. http://puu.sh/sLYvV/b69e79e592.png MrStonedOne wrote: puckaboo, find that bit of code above in interface/skin.dmf (do not open in dream maker, open in a text editor like notepad++ or wordpad) (should be around line 1517 > is-visible = false with > size = 1x1 then recompile and test to see if it still does it.I botched the recent attempt of this, somehow. So, after attempting it again, I had the same results as the previous 'solution'. I am at my wit's end. I need help. | |
http://puu.sh/sFHNx/aec4915092.png and Nvidia at the bottom.