ID:133116
 
Applicable Configuration:
BYOND Version: 438.1014
Operating System: Windows XP
Web Browser:
Game/Hub(s): hub://
Video Card (for graphics bugs):

Descriptive Problem Summary: When downloading resources from the server, clients will receive text messages (say, emote, worldsay, what-have-you), but they will not receive graphical updates until the entire resource has finished downloading.

I'm not entire sure if this should be a bug report or a feature request. Sometimes they're hard to tell apart.

Numbered Steps to Reproduce Problem: start an instance of the game and upload a large song to clearly see the problem, although the problem still exists with smaller songs, just to a lesser degree.

Code Snippet (if applicable) to Reproduce Problem:
        verb
Change_Song()
var/F = input("Which file should you like to upload?") as null|file
if(!F)
return
else
usr.client.Export(F)
world << sound(null,channel=0)
song = sound(F,repeat = 1,channel = 1)
song.status = SOUND_UPDATE | SOUND_STREAM
world << song


Expected Results: Graphic updates should be intermingled, just like text messages.

Actual Results: The host sees movements, but clients who are still downloading the resources don't see the results until the entire resource is downloaded.

Does the problem occur:
Every time? Yes.
In other games? From what I heard when I asked around, yes.
On other computers? Yes.
In other user accounts?

When does the problem NOT occur?

Workarounds: The only workarounds I'm aware of is minimizing resource uploads, which minimizes the issue, or including all resources from the start. However, the entire point of being able to play your own music, whatever it may be, without disrupting gameplay. Since timing is a sensitive issue in the game I'm creating, I'm currently forced to choose between the two.

This isn't a bug so much as just the way it works, but it might be something where there's room for improvement. I kind of wonder if there might be a way to send multiple resource downloads at once instead of in batches.

There are of course workarounds. The first is, don't let users upload arbitrary-length songs. Now that you have the AllowUpload() proc, you can use that to prevent any huge uploads. And for the resources you do have, do what you can to limit their size. PNG files can be compressed further with a program called AdvanceComp, sound effects can be downsampled or converted to .ogg, and for music you're best off using a module format instead of MIDI or .ogg.

Lummox JR
In response to Lummox JR
Yes, I realize that putting in a limit to how large the file size can be will minimize the issue, but it will technically still be there, just harder to gleam its affects.

As I said, I wasn't sure if this should be more of a bug report or feature request. Regardless, if it is something that could be taken a look at it, I would definitely be grateful.
In response to Stupot
We took a look at some resource downloading issues recently. I think that an idea like multiple streams for resources could be worthwhile, particularly where one of those resources is ginormous, but because the server has a fixed amount of bandwidth available and so may the client, there's going to be a limit to the effectiveness of such a scheme when large downloads are in play.

Ultimately, bandwidth is a limited resource at the server end. Most hosts aren't even aware that if you're on a cable connection your upload speed is limited, and on DSL it's a trickle. If you have a dozen players and one of them uploads a 1MB file, that 1MB download at your end might not impact your overall network performance, but the 11MB worth of parallel uploads to the other clients will probably matter a lot. Adding more uploads to that mix may do little more than swamp your connection--still, it's something we could always look into at some point.

Lummox JR