No compression, check serverfiles hash against redirect files hash, upload redirect file to player, done.
md5 does not match? Check file on redirect 2, does hash match, upload, done.
brainstorming ideas for redirect
Re: brainstorming ideas for redirect
billybill wrote:Wouldn't work with-out native. I would store them compressed at 120gb even if another file held data about them. Anyway it's become obvious that you don't understand simple concepts like how Uscript on a linux ut is the same as Uscript on a windows ut. toodles bud still awaiting an explanation on that one in the pm
Re: brainstorming ideas for redirect
pretty much in a nutshell noccer.noccer wrote:No compression, check serverfiles hash against redirect files hash, upload redirect file to player, done.
md5 does not match? Check file on redirect 2, does hash match, upload, done.
but as you will find .. Nothing is ever easy in UT.
Re: brainstorming ideas for redirect
True.Wises wrote:noccer wrote: but as you will find .. Nothing is ever easy in UT.
I have no idea if it would work for ut, like i suggested it.
If not, hey, this is a brainstorming thread
Spoiler
I don´t know what you are talking about. Please find a hairdresser and tell him your problems. I don´t care for them.billybill wrote:Anyway it's become obvious that you don't understand simple concepts like how Uscript on a linux ut is the same as Uscript on a windows ut. toodles bud still awaiting an explanation on that one in the pm
Re: brainstorming ideas for redirect
Newer UnrealEngine do challenge with a GUID on the package name, and you can have various cached packages with same name and different GUID, and in UE3, language support is added as well.
Thing here is:
- Server runs a MOD.u, version 13, lang=english.
- Client has MOD.u, version 6, lang=spanish.
The language thing is easily solved, as you conform version 6 spanish against version 6 english, so you gain the ability to join both v6_eng and v6_spa servers (servers should exclusively run v6_eng tho).
Versions can be handled via conformation as well, but there you have ACE being a bitch.
And using an external redirect is going to be no help at all, unless the redirect supports UT GUID seeking.
So, redirect GUID based packages:
- Rename duplicate files like MOD.u.uz1, MOD.u.uz2, etc.
- Run a script that finds files with .uzN extension, cache GUID for both these filse and the original .uz into GUID.ini
- Redirect must be able to parse URLs formed like this: http://www.domainname.domain/path/file?utguid=GUID, and if utguid= keyword is found, and have the server's program send this file instead.
(Keeping the base .uz instead of starting with .uz0 or .uz1 guarantees backwards compatibility).
- Client must reimplement the FindPackage systemwide method (CORE_API) and have it check GUID when joining (UE3's code for that but implementing it is a different story).
- Write a new HTTPDownload manager (or hack current) for clients to send the required file's GUID in the HTTP request.
Server GUID based packages:
- Server cannot have dupes, so no change here.
- Client must reimplement the FindPackage systemwide method (CORE_API) and have it check GUID when joining (UE3's code for that but implementing it is a different story).
Conformation solves the issue, until you stumble upon two completely different packages with the same name.
The best way to deal with this is to merge them, and conform the merged package against the most used one.
So you get a package that contains all resources, and is backwards compatible to one of the older ones.
(Clients still have to delete their version and update).
Thing here is:
- Server runs a MOD.u, version 13, lang=english.
- Client has MOD.u, version 6, lang=spanish.
The language thing is easily solved, as you conform version 6 spanish against version 6 english, so you gain the ability to join both v6_eng and v6_spa servers (servers should exclusively run v6_eng tho).
Versions can be handled via conformation as well, but there you have ACE being a bitch.
And using an external redirect is going to be no help at all, unless the redirect supports UT GUID seeking.
So, redirect GUID based packages:
- Rename duplicate files like MOD.u.uz1, MOD.u.uz2, etc.
- Run a script that finds files with .uzN extension, cache GUID for both these filse and the original .uz into GUID.ini
- Redirect must be able to parse URLs formed like this: http://www.domainname.domain/path/file?utguid=GUID, and if utguid= keyword is found, and have the server's program send this file instead.
(Keeping the base .uz instead of starting with .uz0 or .uz1 guarantees backwards compatibility).
- Client must reimplement the FindPackage systemwide method (CORE_API) and have it check GUID when joining (UE3's code for that but implementing it is a different story).
- Write a new HTTPDownload manager (or hack current) for clients to send the required file's GUID in the HTTP request.
Server GUID based packages:
- Server cannot have dupes, so no change here.
- Client must reimplement the FindPackage systemwide method (CORE_API) and have it check GUID when joining (UE3's code for that but implementing it is a different story).
Conformation solves the issue, until you stumble upon two completely different packages with the same name.
The best way to deal with this is to merge them, and conform the merged package against the most used one.
So you get a package that contains all resources, and is backwards compatible to one of the older ones.
(Clients still have to delete their version and update).
Re: brainstorming ideas for redirect
billybill wrote:Unfortunately these messages read backwards. The disclaimer here is I don't normally post PMs, this guy has been hounding me in public for months now and I feel I can break etiquette to let others here know what he's like in privatenoccer wrote:I don´t know what you are talking about. Please find a hairdresser and tell him your problems. I don´t care for them.billybill wrote:Anyway it's become obvious that you don't understand simple concepts like how Uscript on a linux ut is the same as Uscript on a windows ut. toodles bud still awaiting an explanation on that one in the pm
@Noccer
Edit by papercoffee
- papercoffee
- Godlike
- Posts: 10447
- Joined: Wed Jul 15, 2009 11:36 am
- Personal rank: coffee addicted !!!
- Location: Cologne, the city with the big cathedral.
- Contact:
Re: brainstorming ideas for redirect
Nope ...private messages are private ...I made a mistake once by just quoting a little sentence out of a PM.
And justifiably so I got scolded.
Please refrain from posting PMs in public ...nothing good will come from it.
Put him on the ignore list ...and set him up as foe.
And justifiably so I got scolded.
Please refrain from posting PMs in public ...nothing good will come from it.
Put him on the ignore list ...and set him up as foe.
Re: brainstorming ideas for redirect
I'm with higor here.
As opposed to a database an easier solution would be to rename the files including the GUID, e.g Zan_b.dbdc5a8147ef0550015a7abba58878e5.umx.uz. The filename of the package is stored inside the .uz so renaming it won't be a problem (unless the windows ucc behavours differently). I'm not sure if UT can handle the renamed package though but I think it won't be a problem as UT will just receive the data and sticks it's own name on it or might carry on with the renamed package?. In the end it's also possible that a script picks up the request and sends the required file as Zan_b.umx.uz,.
Some files (i.e. package format < 68) do not come with an easily extractible guid, although I think UT does send it in the request. For these the guid should be determined in another way.
As opposed to a database an easier solution would be to rename the files including the GUID, e.g Zan_b.dbdc5a8147ef0550015a7abba58878e5.umx.uz. The filename of the package is stored inside the .uz so renaming it won't be a problem (unless the windows ucc behavours differently). I'm not sure if UT can handle the renamed package though but I think it won't be a problem as UT will just receive the data and sticks it's own name on it or might carry on with the renamed package?. In the end it's also possible that a script picks up the request and sends the required file as Zan_b.umx.uz,.
Some files (i.e. package format < 68) do not come with an easily extractible guid, although I think UT does send it in the request. For these the guid should be determined in another way.