ID:1868765
 
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
Hi,

We should have an extra parameter for browse_rsc that tells it to behave synchronously, i.e., only return once the client has verified that it has received the file (or the server already knows the client has the file, because it previously received it).

Implementation-wise I think the server should maintain a list of files the client has in its cache (if it hasn't already) with the filename and the hash of the file.

If you use browse_rsc and the file is not on the list, send it to the client. If synchronous=true then wait until the client signals it has placed the file in the cache before returning.

If the file is on the list, browse_rsc should return immediately.

I thought the default behavior of browse_rsc was to wait until the client had received the file, but this seems to have been broken years ago. Because certain games may depend on the proc returning immediately (SS13, other games that preload resources on /client/New and call browse_rsc multiple times in quick succession) I think it's better to implement it as a parameter instead.

Thanks!
By the way, this issue has existed for years and should not need to delay 508 IMO (I really like try/catch statements).

The current workaround is to preload resources by calling browse_rsc for everything that the client needs at /client/New, but this obviously slows things down when it should be downloading content only when necessary (and to prevent /client/New from getting clogged up).
It's mostly synchronous for browse(), except when output() is used in place of browse(). That is, DS only downloads files in order and the server knows to send a browse() as a file if there are resources pending. The problem is, output() interferes with that.

I do like this idea, although I suspect you'd probably only want to use the synchronous flag on the last browse_rsc() call.
In response to Lummox JR
Lummox JR wrote:
I do like this idea, although I suspect you'd probably only want to use the synchronous flag on the last browse_rsc() call.

Maybe allow a list to be passed then? Since we can't be sure that the first browse_rsc has finished if the last one claims to be.
In response to NullQuery
NullQuery wrote:
Lummox JR wrote:
I do like this idea, although I suspect you'd probably only want to use the synchronous flag on the last browse_rsc() call.

Maybe allow a list to be passed then? Since we can't be sure that the first browse_rsc has finished if the last one claims to be.

Actually you can, because browse_rsc() calls definitely happen in sequential order.