FastDL issues/pickiness

Post Reply
Cactus
New to forums
New to forums
Posts: 2
Joined: Wed Apr 01, 2015 2:02 pm

FastDL issues/pickiness

Post by Cactus » Wed Apr 01, 2015 2:36 pm

I'm having a very frustrating issue with my FastDL in that, it won't always let people download what i have set up, regardless of it being in the correct file path/directory. In this case, I have a player model or a "skin" that people will be able to play as in my server. When clients attempt to download this model from the fastdl server, they are only getting about half the textures the model requires.

I have looked into the .mdl's material paths to make sure it wasn't an issue on the model's end and it doesnt appear to be. If i have said model manually installed into my directory, i can see everything just fine. But attempting to download it from the server, it randomly rejects some of the VMT files from going through(and thus the VTF files). I had a case with a model before this one, where the fastdl decided that because in the .mdl material file path the texture it was pointing to had a capital letter, that unless the VMT file also had the capital letter, it did not download, which i've never known to be an issue, but that fixed it. But that's where that answer ends, and where the horribly frustrating part comes into play. The above fix does NOT work for this new model. I've tried hexing the model for it to view the correct VMTs in a different way, aswell as creating a secondary model with the textures it wasn't downloading, to see if it would bypass the problem and allow them to be downloaded once the second model called for it's textures. It worked partially the first time. But then, once again, would no longer download all of the VMTs. The file paths on the fastdl and on the server are exactly as they should be, i just don't understand why it's being so picky. I've been told this has happened in the past by my friend who is also a server operator, but he had never found a fix for it. I have also downloaded this model successfully from another server's fastdl.

Are there any suggestions for dealing with this issue?

Cactus
New to forums
New to forums
Posts: 2
Joined: Wed Apr 01, 2015 2:02 pm

FastDL issues/pickiness

Post by Cactus » Wed Apr 01, 2015 2:54 pm

I'm having a very frustrating issue with my FastDL on my Counter Strike Source server in that, it won't always let people download what i have set up, regardless of it being in the correct file path/directory. In this case, I have a player model or a "skin" that people will be able to play as in my server. When clients attempt to download this model from the fastdl server, they are only getting about half the textures the model requires.

I have looked into the .mdl's material paths to make sure it wasn't an issue on the model's end and it doesnt appear to be. If i have said model manually installed into my directory, i can see everything just fine. But attempting to download it from the server, it randomly rejects some of the VMT files from going through(and thus the VTF files). I had a case with a model before this one, where the fastdl decided that because in the .mdl material file path the texture it was pointing to had a capital letter, that unless the VMT file also had the capital letter, it did not download, which i've never known to be an issue, but that fixed it. But that's where that answer ends, and where the horribly frustrating part comes into play. The above fix does NOT work for this new model. I've tried hexing the model for it to view the correct VMTs in a different way, aswell as creating a secondary model with the textures it wasn't downloading, to see if it would bypass the problem and allow them to be downloaded once the second model called for it's textures. It worked partially the first time. But then, once again, would no longer download all of the VMTs. The file paths on the fastdl and on the server are exactly as they should be, i just don't understand why it's being so picky. I've been told this has happened in the past by my friend who is also a server operator, but he had never found a fix for it. I have also downloaded this model successfully from another server's fastdl.

Are there any suggestions for dealing with this issue?

Post Reply