resource.AddFile not working after map change?

Materials sent to the client with resource.AddFile seem to only work on the map immediately after a server restart, and never afterwards. After a map change, clients will have “Downloading x Textures” when joining, but they never actually download and GMod skips to the next loading step. The materials appear as purple and black checkerboard after this.

I have Evolve installed, and our server runs TTT 24/7.

There are a few possible causes for this. If your server is configured to use a fast download server, and the file doesn’t exist on the fast download server, it will be skipped. If you are not using fast download and the file’s size is greater than the download size limit, it will be skipped.

Yeah, likely that the files are on the gameserver and not the fastdl.

But why would they successfully download and appear in-game on the first map after a server restart? And the files are definitely on our fast download server. They may be above the size limit, is the convar “net_maxfilesize” in KB or MB? It is currently set to 64.

Megabytes.

Post the script that you are using, maybe there’s something wrong with that. And the location.

Well the icons for Evolve have this problem, and also my custom TTT weapon icons. Basically any texture that isn’t in vanilla GMod has this problem. But here is where I include the material in a SWEP in case I did add the resource wrong:

[lua]if SERVER then
AddCSLuaFile( “shared.lua” )
resource.AddFile(“materials/VGUI/ttt/icon_dart.vmt”)
end[/lua]

[editline]10th November 2010[/editline]

The SWEP itself works, just not the icon.

Isn’t resource.AddFile normally called in GM:Initialize()?

Well I have the same problem with Evolve’s usage of resource.AddFile.

I’ve never seen a script do this.

I’ve reinstalled my server and added my custom weapons, and the icons seem to work now. I’ll be installing vanilla Evolve, then each of my plugins to see what causes it. Although it may just have been that the server was installed incorrectly the first time.

[editline]10th November 2010[/editline]

Seems to be fixed now, must have been a bad install last time.

Something is probably setting the fastDL URL twice

first it sets it to some server where it doesnt exist

then on the first start it disabled fastDL, but only on first start, causing map changes to screw up fastDL

Post the value of the sv_downloadurl convar after mapchange