(Also applies to Dream Daemon.)
Descriptive Problem Summary:
I can't test to be sure this is exactly what's going on as it only happens with remote servers and I don't have a remote server to test on, but it seems that assets added to the rsc at runtime (through fcopy_rsc(), for example) don't get sent to 514 clients under any circumstances (or at least get sent very rarely). Both Dream Seeker instances and local Dream Daemon instances work as expected. Only remote servers are affected.
EDIT: Ah, I was told of a way to get BYOND to treat the connection as remote even if it's actually local, so now I can test it. I'll make a test case if necessary.
Numbered Steps to Reproduce Problem:
1. Host a 514 server
2. Connect remotely with a 514 client
3. browse_rsc() an asset added at runtime to the client, through fcopy_rsc() or uploaded by a client, etc.
4. Watch as the asset does not appear in-game nor in the client's cache
Expected Results:
Files added to the rsc at runtime should work just as they do when either the client or the server is on 513 or the client is connected locally to the server.
Actual Results:
If both the client and the server are on 514 and connected remotely, the files don't get sent.
Does the problem occur:
Every time? Or how often?
I'm not certain if it's every time, but it is at least the vast majority of the time.
In other games?
Don't know.
In other user accounts?
Appears so.
On other computers?
Appears so.
When does the problem NOT occur?
When either the client or the server is on 513, or when the connection is local.
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.)
Doesn't happen if either the client or the server is on 513. Don't know about earlier versions of 514.
Workarounds:
None.
ID:2692149
 Jun 12 2021, 12:32 pm (Edited on Jun 12 2021, 12:58 pm)
|
|||||||||||||
Resolved
| |||||||||||||
|
Jun 12 2021, 6:29 pm
|
|
Lummox JR
   |
I'm not sure what you mean exactly. The client should still be getting the resources when it requests them, but it won't be given an automatic update of runtime resources. That behavior wouldn't be any different in 513.
|
I mean the files don't arrive. They don't show up in-game and they aren't in the cache. I have personally observed this with css, js, etc. files for browser windows but have seen someone report that user-uploaded icons also don't show up in the map.
EDIT: Ah, wait, I guess I should clarify other than in the steps to reproduce section that the part I've seen myself is about browse_rsc()ing files added to the rsc at runtime. The client doesn't get them. | |
Can you set up a test case for this? I need a way to investigate this better.
| |
It seems my assumptions were not quite correct. First, it only seems to happen when sending multiple files at once. In my test case exactly three get through each time, but I think in our live code the number might vary. I don't know what caused the custom icon failure that someone else reported. Second, it seems to happen on local connections too sometimes. No idea what's different, but NanoUI works on local connections and fails on remote connections in /vg/station, but my test case fails on both local and remote connections. Odd. Anyway, here's the test case I'm using: https://gofile.io/d/vT1ZJ8
Make sure to clear your cache between tests. | |
In my test project, simply naming one of the files explicitly (even if just in an fexists() call that does nothing) and thus getting it compiled into the rsc causes that one to get sent in addition to the three others. However, in our live code, I can do the same with a large list of files and they still don't get sent, so there must be more to this bug than my test project there demonstrates. I have no idea where to look to find the rest of it though. Hopefully it's all from the same root cause.
| |
Lummox JR resolved issue with message:
The new browse_rsc() enhancements had a bug where after a small number of waiting files in a row, new files weren't added to the waiting list and therefore weren't requested by the client. | |
Your test case turned out to be extremely important to determining the exact nature of this issue, since it revealed a problem I never saw in my own testing. Thanks for your help.
| |
Fortunately, 1557 does seem to fix the cases I couldn't track down in a test case, as well. Thanks!
| |