Refactor packaging system

[Fohlen]

There is a clear need to re-factor the packaging system. I thought about the following structure, which would offer the advantage to use existing map-cfg structure. Each package consists of the following components

• main package script -> package.cfg
• folders for textures, models and sounds

Here is a example config of package.cfg

// CC-BY-NC, package-author
package package //Define a package
map map.ogz //Define map(s) delivered within this package

mapmodelreset //Reset mapmodels

mmodel windecker/stair //Load model stair from package windecker

texturereset    // starts the texture slot/index at 0

texture 0 "package/blubber.jpg" //Load blubber.jgp from THIS package

texture 0 "ik2k/ik_brick_6464c.jpg" //Load texture ik_brick6464c.jpg from package ik2k

exec lunaran //Load all contents from package lunaran as specified in package.cfg

texture 0 "jf1/jfsquare.jpg" //Load texture jfsquare.jpg from package jf1

mapsound "ambience/wind.ogg" //Load map sound wind.ogg from package ambience

In spite of using the default folder structure in sauerbraten, all packages would be loaded in one central package location, from which the load-functions can bootstrap them easily. Dependencies would be "calculated" by looking up any external call. Any commentary on this issue is very much appreciated.

[a-teammate]

but thats just how the packages gets transfered to the user, right? actually we should additionally check which files are already in the user-package-dir and download just the needed stuff (ingame).

thou i like the ideas. We even could make the whole packaging global now, so changes on existing files will be applied to any map the same: A remade texture could easily be changed in a "textures.list" and every map will make the change. In the map-cfg you then just link to the specific address of the textures.cfg (or more accuarte to the index of the texture). this could be done automatically.

and your path-structure would look like this:

packages/ - maps ------------- - textures ------------------ -tek1 ------------------ -skybox ----------------------- -dark moon ------------------ -textures.list ------------- - sounds ------------- - models

any package of the server will be delievered as follows: server to client: package name and list of files to copy client: checks which files are still needed and whether the package already exists. client to server: i need xy and zx. the server sends the items, the clients registers the package in a global "addons.list", the end.

[Fohlen]

I moreover thought about static packages which are sent via archives (bz2++), which would ultimately support your idea. Maybe use a database (sqlite3) for the whole "registry" stuff.

[Croydon]

I dislike the idea of "dependencies" or that a remade texture would be automatically used by other maps.

First it would make the whole thing a lot more complex and I can't really see benefits of it. And even more important: the map of the creator perhaps don't look exactly as it was meant. It should be up the the creator if he want to update texture and other stuff.

Personally I would like a directory tree like: packages/ - maps ------------------ map.cfg ------------------ map.ogz ------------------ map.png ------------------ map.txt ------------- - textures ------------------ -[creator name] ------------- - sounds ------------------ -[creator name] ------------- - models ------------------ -[creator name] .......

BUT the most important thing imo keep the structure compatible to sauer so thats it's easy to exchange and maintance content for original sauer and the fork.

[koraa]

Hi Crydon, how would you tackle the following situation:

• Miss X creates a set of textures
• Misters Y,Z,A,B,C use them in twenty map; all of which are being installed on the fly

What problems do you see in staying compatible? To me it seems we can solve this problem by treating the content of Sauer as a special case.

Personally I would opt for a package system with dependencies and dynamic fetching. In addition I would suggest, that packages are identified by a unique hash and that shadowing packages should be explicit.

[aschaeffer]

The pro's of dependency management are:

• Less space required on disk due to reduncancy elimination (game content easily increases to multiple gigs)
• Less time needed for downloading a map:
  • One map with 50 textures -> 3 minutes
  • Another map with the same 50 textures -> only 10 seconds instead of another 3 minutes

But your point about map design constancy is valid: we need something like a version number for maps, textures, map models, and so on. If you know maven from the java world, you can specify a specific version for a library, or a range (for example 1.2 - 1.6). Something similar to would mean a map of a specific version depends on a texture of specific versions. So the map looks like the creator designed it.

[koraa]

@aschaeffer: Agreed.

What do you think of this: Each package gets

• A unique hash
• A version number
• An author attribute (while each author gets a uuid to)

I still think there should be a way to patch packages, without modifying them directly, especially since this would allow us to alter SB's maps without getting into any kind of legal trouble.

(see what Sauerbraten Enhanced did)

[Fohlen]

I clearly discourage @Croydon 's suggestion because it has lead to many trouble in the past. I rather agree with @aschaeffer and @koraa that there is a clear need for a dependency management system, though packages should not be static (should be able to be altered easily). koora's hash / version number seems a rather good idea, but we should moreover use md5sum's for the "unique hash" story.