ID:138278
 
So our conversation a few weeks ago about how resources work confused me.

I had assumed that if a resource existed in the local .rsc file, that resource would not be downloaded from the server. But Tom said that the .rsc file is really only used for resource ids, and that the resource WOULD be downloaded.

In DragonSnot we have this really cool logo, and I've done a splash screen using it. But the .bmp is large enough that it takes quite a while to download the first time -- long enough that the player never sees the splash screen, and in fact can't see anything of the game because everything grinds to a halt while waiting for this .bmp to download. Most people would probably close DreamSeeker, assuming it was hung.

So I'm hoping that this will be alleviated somewhat by providing DragonSnot as a downloadable .exe pointing to the network, with the .rsc file there. But given my recollection of the discussion about .rsc files, I'm concerned that this might not actually save any download time.

Can you clear this up for me?
On 12/2/00 11:19 am Deadron wrote:
So our conversation a few weeks ago about how resources work confused me.

I had assumed that if a resource existed in the local .rsc file, that resource would not be downloaded from the server. But Tom said that the .rsc file is really only used for resource ids, and that the resource WOULD be downloaded.

I think we must have been talking about different things. Your interpretation is the correct one: if a resource exists in your (local) byond.rsc, it will not get downloaded (again) when you connect to a world that contains it.

So I'm hoping that this will be alleviated somewhat by providing DragonSnot as a downloadable .exe pointing to the network, with the .rsc file there. But given my recollection of the discussion about .rsc files, I'm concerned that this might not actually save any download time.

Yes, that will work.

I was most likely referring to the process whereby resources get transferred between the server rsc (let's call that world.rsc) and the user's client rsc (byond.rsc). Currently, all .bmp or .dmi icons in the world.rsc are immediately transferred to the byond.rsc upon connection, even if they aren't directly used in the world. This is done for speed purposes: since icons need to display immediately (especially in the case of flick()), the server transfers them as soon as possible. By being in the .rsc the server assumes that they have some use in the world-- in the case of an uploaded user icon that will be later referred through a savefile, the server has no way of knowing.

This behavior has the unfortunate side-effect of transferring unnecessary data in many cases. The most common situation is probably the case where you have a lot of junk built up in your world.rsc file (that you are using when you compile your world) and then you upload it to the server. All of the icons in that file will be transferred. So if you happen to test with a couple of different .bmp prototypes they will all most likely exist in that .rsc and will all be transferred to the user, even if only one is used. This is unacceptable, and will be fixed shortly. In the meantime, you should probably remove your world.rsc file and rebuild it from scratch (through compilation) right before you build your final world (that you will upload or distribute). That will ensure that only used resource files will remain in the the world.rsc. In the next release there will be an option to do this sort of "clean build" for you, and it will be the default when you build an exe distribution.