Sending clients .pak files

[OneManClan]

[DISCLAIMER: This is not a 'tutorial', I'm writing it here to clarify the procedure in my head, in case a month from now it seems too confusing, and for the benefit of anyone here more newbie than I. Also newbies read the responses to this post for corrections from those with more experience]



Hey people.

This is an implementation of sending a .pak file to clients, which uses a 'cfg' in the pak whiich is run by the server to confirm the pak was received. Your comments, suggestions, etc appreciated

OBJECTIVE
For the qw server (FTEQWSV) to:
1. send a pak file to clients (only if they haven't already downloaded it)
2. confirm that it was downloaded successfully
3. be able to send them an updated version if required in future.

IMPLEMENTATION
1. Make the .pak (I used taniwha's pak program which (unlike pak explorer) allows filenames bigger than 8 letters).

2. In the pak, make a folder called 'test', containing a txt file (which I've) called 'konfirm.cfg', and contains one line:

Code: Select all

 cmd bob123  //can be anything really

3. At the bottom of worldspawn() (world.qc) include the line:

Code: Select all

precache_model("test/konfirm.cfg"); 

This causes the server to look for konfirm.cfg on the clients computer, and if it doesn't find it, sends them the pak(!) [EDIT: Spike says "actually, it causes the server to tell the client that it needs said file. the client then asks the server for that file, and hopefully gets redirected to the pak instead of the cfg inside the pak"]. At this point we won't have a way of knowing whether the pak was successfully received, so..

4. In ClientConnect() (client.qc) we add the line:

Code: Select all

stuffcmd (self, "exec test/konfirm.cfg\n");

This will run 'konfirm.cfg' as a script, whenever a client connect, which will make them say 'cmd bob123'

5. In SV_ParseClientCommand (in fteqw.qc) do this:

Code: Select all

// this runs whenever the client types anything
void(string in) SV_ParseClientCommand =
{
    float argcount; // this will store how many words the client typed
    string s1,s2,s3,s4,s5,s6,s7;
    argcount = ftebi_tokenize(in);
/* put each word into the array[EDIT: It's not actually an 'array', it's just a bunch of strings, each one holding a 'word']. This puts the first word they typed into the string  s1 */
    s1 = ftebi_argv(0); 
// etc
    s2 = ftebi_argv(1); 
.
.

//This checks if the client cmd was 'bob123'
    if (s1 == "bob123")
        {
            // if we are here, it means the client downloaded the pak!
             dprint("Pak received!\n");
 // we return so that the hidden 'message' doesn't get seen by clients
return;
        }

CONCLUSION
There is is. This works with fte and ezquake clients [ EDIT (Dec 2013): No, it doesn't work w EZQuake clients, but it might with the upcoming EZQuake3.0] . It means you can make a bunch of 'stuff', send it to clients in one go, check whether they received it, AND if in future you update the skins/mdls/sounds/whatever, you can send an updated pak. This updated pak will have to be renamed, and needs the konfirm text to be updated to 'bob1234' or something, but you get the idea. [EDIT: Is this correct?]

Seems 'fiddly', but ..
1. Is there something I've missed?
2. Is there a better way of doing this?

thanks,

OneManClan
ps I couldn't figure out a more descriptive subject line .. suggestions welcome

[OneManClan]

SHORT VERSION
Following on from the previous post, I'd like to be able to send clients updated paks, and have them REPLACE the existing versions they have already downloaded. Is this possible?

LONGER VERSION
Lets say we have 'modname.pak', which contains a bunch of skins, and lets say a year later you've got a newer version of these skins. One option of course is to make a new pak (eg 'modname_v2.pak'), and send clients that, but... if possible, I'd like to keep calling it modname.pak, and just make clients download it again, replacing the old one. Possible?

I tried this btw:

Code: Select all

precache_file ("foo"); // this exists in the updated modname.pak

But the client (who had already downloaded the original modname.pak) simply said "couldn't find foo", so the logic must be:

1. Server: "hey client, load up foo"
2. Client: "I can't see it anywhere.. can you send it to me?"
3. Server: "sure it's in modname.pak, get ready for me to send it to you"
4. Client: "Hold on, I've already got modname.pak!"
5. Server: "Ah, cool, I won't bother sending it to you then"
6. Client: "Um, hold on, there doesn't seem to be a foo anywhere"
7. Server: "whatever, just play without it"

Is this accurate?
Is there a way to 'force' the client to replace the entire pak with the new one (w the same name)?

thanks,

OneManClan

[Spike]

fte servers report a pak list to clients when they connect. this list includes hashes.
If the client doesn't currently have a pak loaded with the given hash, it'll download it to some cache directory.
This cannot replace existing paks. It only selects one of multiple possible paks.

if they already have a pak with that name that is properly installed (ie: not downloaded within the context of these hashes) then you're probably screwed.

[OneManClan]

fte servers report a pak list to clients when they connect. this list includes hashes

I looked at FTE Filesystem Hash Table Caching, but all it says is:

This cvar controls whether the engine is allowed to build a hash-table of the filesystems that it uses. This can result in much faster load times.

I'm not sure what this means ... do I just set it to '1', and fte does the rest?

If the client doesn't currently have a pak loaded with the given hash, it'll download it to some cache directory. This cannot replace existing paks. It only selects one of multiple possible paks.
if they already have a pak with that name that is properly installed (ie: not downloaded within the context of these hashes) then you're probably screwed.

Well no-one has downloaded the pak yet, so does this mean its possible? More info please.

[Spike]

I'm not saying its bug free...
And I seriously doubt ezquake implements any of it.
For a client to download a pak, it must think that there's a reason to do so. This means that the server must be using resources within that pak.
You can check to see if the server is using resources within that pak by issuing the 'path' command and looking for the '(ref)' tag.
paks with a '(c)' are deemed copyrighted, and will not be available for download (so clients won't try, and servers will reject it if you try).
Paks downloaded using this mechanism are stored in some subdirectory with some gibberish extension (the hash). They will ONLY be loaded if the hash matches, otherwise it'll go ahead and download a new copy to use instead. If the client already has that pak then there's no need to download.
You can force the server to 'use' a resource in a pak by fopening some small text file or something. precache_model or precache_sound also work, so long as the named resource is actually within the pak you want to become referenced.
The referenced mechanism is mostly to avoid clients from downloading 500 paks that each contain an irrelevent map.

Note that fte also supports fs_pure. Which uses ONLY resources within the paks the server sends.
At least that's the theory. I'm not sure how well any of that works.

fs_cache is a file access speedup, it isn't meant to affect which files are used.