.uz3 Download Problem

[Al]

Hey Cap'n! With who do you use your redirect?

[edit] That was my problem too. They set it up to allow access to uz3 files and it works just fine

[clark kent]

What is the port=3128 for? I have not seen that yet in UT3...

If you set allowdownloads=True the server will download the file if it's not redirected. Not a good move! I always set downloads=False so if they get no download it has to be a redirect issue.

[Captain_Tea]

Hey Cap'n! With who do you use your redirect?

[edit] That was my problem too. They set it up to allow access to uz3 files and it works just fine

I am using a private one.

[AZ-{OVGY}]

What is the port=3128 for? I have not seen that yet in UT3...

If you set allowdownloads=True the server will download the file if it's not redirected. Not a good move! I always set downloads=False so if they get no download it has to be a redirect issue.

Don't worry about it, it isn't needed. People seem to have copied that from their ut2004 server ini's but it isn't actually needed, I don't use it and have no problems. All you need is RedirectToURL and UseCompression.

[aCruceSalus]

This is just ridiculous, I thought redirect was suppose to be fixed with patch 2. I have my redirect setup with AllowDownloads=False and downloads are very fast for some maps and sometimes it is very slow for the same map. Yes, I go in and clear out my cache to test this. It was a problem with uncompressed files and is still a problem with compressed files. When I say slow, I mean it can take 15-30 minutes to download a map. if I open up Firefox and go to the redirect location and download, it takes a couple minutes to download the uz3 file. Does anyone know what is going on and how to correct this? I am getting tired of people telling me that they can't join because they don't want to wait 30 minutes for a map to download and leave. No wonder nobody is staying on the servers. Thanks to anybody that knows a solution, or did Epic still not fix the problem?
Oh, I don't think this really makes a difference, but it is on a Linux server. Crash free since the latest patch and no errors or warnings in the logs to indicate what the problem might be.
Thanks,

[Elohim]

This is just ridiculous, I thought redirect was suppose to be fixed with patch 2. I have my redirect setup with AllowDownloads=False and downloads are very fast for some maps and sometimes it is very slow for the same map. Yes, I go in and clear out my cache to test this. It was a problem with uncompressed files and is still a problem with compressed files. When I say slow, I mean it can take 15-30 minutes to download a map. if I open up Firefox and go to the redirect location and download, it takes a couple minutes to download the uz3 file. Does anyone know what is going on and how to correct this? I am getting tired of people telling me that they can't join because they don't want to wait 30 minutes for a map to download and leave. No wonder nobody is staying on the servers. Thanks to anybody that knows a solution, or did Epic still not fix the problem?
Oh, I don't think this really makes a difference, but it is on a Linux server. Crash free since the latest patch and no errors or warnings in the logs to indicate what the problem might be.
Thanks,

It might be a file name problem on the redirect? I had a similar problem with DM-Lego. Once I named it DM-LEGO on my redirect, it would pull from there instead of the server.

[AZ-{OVGY}]

If he has AllowDownloads=False then no files should be getting pushed from the ut3 server, only redirect. @aCruceSalus, can you check that in your UTEngine.ini you have the following in there

[Engine.Engine]
NetworkDevice=IpDrv.TcpNetDriver

Also are you sure the path to your redirect is correct, it must have a trailing slash (/) at the end of it.
Redirect speeds do vary dependent on how much load is on the redirect server. Less load means faster speeds and heavy load means slower speeds, who is your redirect with?
I am trying to help somebody else with this problem to, that problem is with a Linux server redirect too.

It might be a file name problem on the redirect? I had a similar problem with DM-Lego. Once I named it DM-LEGO on my redirect, it would pull from there instead of the server.

That would be because your redirect is on a Linux/Unix webserver which are unforgiving when it comes to mistyped urls. They are case sensitive webservers so every letter in an url hase to be exact. Since he has AllowDownloads=False then if it was a file name problem he should recieve a connection failed error.

[aCruceSalus]

I am not sure when or how it happened, but my UTEngine.ini values have changed and my [IpDrv.HTTPDownload] is completely missing. It is almost like UT3 decided to overwrite my UTEngine.ini file with some default one. I will change the settings again. I wonder what would happen if I change the permissions on UTEngine.ini to read only.

Anyways, here is what I found in my UTEngine.ini file:

[Engine.Engine]
NetworkDevice=IpDrv.TcpNetDriver
....
[IpDrv.TcpNetDriver]
AllowDownloads=True
ConnectionTimeout=30.0
InitialConnectTimeout=200.0
AckTimeout=1.0
KeepAliveTime=0.2
MaxClientRate=15000
MaxInternetClientRate=10000
RelevantTimeout=5.0
SpawnPrioritySeconds=1.0
ServerTravelPause=4.0
NetServerMaxTickRate=30
LanServerMaxTickRate=35
IdleServerTickRate=30
DownloadManagers=IpDrv.HTTPDownload
DownloadManagers=Engine.ChannelDownload
NetConnectionClassName=IpDrv.TcpipConnection

I'll keep everyone informed at what I find. Also, if anyone else is experiencing this, please let us all know so we can make Epic, or if it is just Linux, Ryan know of the problem.
Thanks,

[AZ-{OVGY}]

Add -unattended to your server command line to stop it updating your config values with default ones.

[aCruceSalus]

Thanks. I give that a try.