Build and Shoot

Something we had to deal with while making VoxelAuth (most of the practical stuff was figured out by UnrealIncident, because he's a sexy fuck) was client<->server communication. This got me thinking about adding some other stuff (either in VoxelAuth or as a separate mod) that would allow servers to have a little more control over clients. There have also been other posts, that mention similar ideas, so I figured we should have a proper discussion on this, instead of either no-one working on it, or everyone making their own.

Related posts:
http://www.buildandshoot.com/viewtopic. ... 734#p20030
http://www.buildandshoot.com/viewtopic. ... =50#p19654

(Note: I call this thing a "mod" for lack of a better word)

Ideally, a client without the mod should be able to connect to a server with it, and vice versa (unless the server chooses to require a mod), so my proposed way of doing this would be for the client to notify the server that it is running the mod by sending a chat command. If the server isn't running the mod, nothing happens. If the client isn't running the mod, the server obviously does nothing. If the server is running the mod, all other comms can happen using custom packet IDs that aren't used by the default game (this should be easy enough to do in the client, and easy in the server (although requires a recompile of certain parts, so a simple plugin wouldn't be enough)). How it works from that point on will require some thought, so discussion would be good.

I'm also curious at what point models are loaded, as if that happens right at the start, server-decided models would require either more modding of the client, loading new models after the originals are loaded (not sure how easy that would be), or for there to be some wrapper to the game that gets this information from the server before the game itself is started.

Anyway, yes, I don't know as much about the game's internals as I'd like to, but I know some others here do.

Also, I'd prefer if people who didn't know what they were talking about didn't comment in this thread.

Somewhat tangential, but related to model loading. I'm pretty sure voxlap and the example game can take a list of zip files, the game will search them in order for various needed file names. I am guessing AoS is might be based on the example game, and thus maybe that functionality is buried in there.

I would certainly like to see the protocol extended with this sort of iceball-like functionality. Not only would it be great for AoS itself, it would also possible iceball integration into pyspades.

Also I would love to see collaboration between stack, rakiru, UnrealIncident on an open-source launcher, just sayin'.

KV6's are loaded in response to packet 0xF, which is the packet where the team names are sent in.
Sound is loaded on first use.
PNG's seem to get loaded around the initial connect.

all of them can be reloaded (See modloader), but some are trickier than others.

Oh, I always assumed modloader just swapped files or something.

Sonarpulse wrote:

Oh, I always assumed modloader just swapped files or something.

not at all :)

it intercepts read operations on the files, and redirects them to the files in the 'Modloader' folder.
To make sure that everything is used from the mod,
the sound system is re-initialized,
Images are (manually) unloaded and the game is forced to reload them,
KV6 files are (manually) unloaded and the game is forced to reload them.

Oh! my sincere apologies, that is a damn good piece of software right there then.

rakiru wrote:

If the server is running the mod, all other comms can happen using custom packet IDs that aren't used by the default game (this should be easy enough to do in the client, and easy in the server (although requires a recompile of certain parts, so a simple plugin wouldn't be enough)).

I'll have a bit more of a read of how PySpades works one day soon. I'm pretty sure with some ghetto rigging I should be able to do it all from a script without recompiling.

Sonarpulse wrote:

Oh! my sincere apologies, that is a damn good piece of software right there then.

I was under the same impression. This. ^

They way Ken handled audio and kv6 loading relies on a hash value for the name of the file, which saves reloading from disc if the file is present already. By finding the location in the hash, and invalidating it, you should be able to trigger a reload of both audio and kv6 models. Files in the directory take precendence, then zip files. You probably know this already, but it might help.

Duff Paddy wrote:

They way Ken handled audio and kv6 loading relies on a hash value for the name of the file, which saves reloading from disc if the file is present already. By finding the location in the hash, and invalidating it, you should be able to trigger a reload of both audio and kv6 models. Files in the directory take precendence, then zip files. You probably know this already, but it might help.

.75 doesnt do hashing, nor reloading of files,
and neither does it comes with zip files.

Cool.