You are not logged in.
I've seen eihrul state elsewhere that he wants to implement automatic map downloading for the Cube 2 engine before he issues another release of Sauerbraten, and that he would need as a prerequisite for that to ensure that downloaded maps and their associated files can't do evil things to the users who download them. What are the requirements for an implementation of ‘safe’ (or at least safer) map and material configuration files to be included upstream in Cube 2 and/or Tesseract? Do the current CubeScript .cfg files need to remain supported by the new system? If not, what data file formats would be accepted upstream? JSON? ‘Turtle’ (a non-horrible RDF serialization format)? Something else?
Offline
config files wouldn't change per se. The difficult part is restricting the code inside them from doing anything that could be potentially bad, such abusing the cubescript to overwrite legit files by using the text edit functions, which, for some unknown reasoning, can extend beyond the game's directory, potentially causing chaos.
Red Eclipse already has a system in place allowing only specific commands to run within map configs but I don't know the extend of its power.
Offline
Should map packages be permitted to include or reference textures and texture configs? If so, should they be permitted to overwrite existing files?
Offline
Should map packages be permitted to include or reference textures and texture configs? If so, should they be permitted to overwrite existing files?
Referencing textures/models/sounds/etc is fine for a map. The issue is whether it would call anything else or run commands that could be potentially malignant. As for overwriting existing files, that would be a no-no.
Offline
how i would handle it is similar to how tesseract and cube run on window. All data is saved to mydocs/mygame/tesseract (and from there uses the normal root directories) so if you save a map it will appear there. So you could use the same or similar idea for this. You could get a list of recources from the server, and if the resources dont exist in the base game (or in the users copy) then you create a dummy directory that these files are saved to. Then when loading files you look in this dummy directory first for the files, if it doesnt exist then you look in the mydocs then the base file. This would prevent the base game from actually changing and only the temporary directory would change (this could be named with the server name so this directory is only used when on this server or server branch (could be set by svars)) This would allow a robustness that cube really doesnt have, And is how many games like tf2 and cs:go handle loading server specific content.
Offline
config files wouldn't change per se. The difficult part is restricting the code inside them from doing anything that could be potentially bad, such abusing the cubescript to overwrite legit files by using the text edit functions, which, for some unknown reasoning, can extend beyond the game's directory, potentially causing chaos.
Red Eclipse already has a system in place allowing only specific commands to run within map configs but I don't know the extend of its power.
I looked at Red Eclipse; it adds a set of flags to every ‘ident’ (command or var), one of which indicates whether a variable can be modified by (or was created by) map config scripts, and a set of global state flags, one of which indicates whether map config script code is running. Command implementations have to check for themselves whether the map-script-is-running flag is set, and either ignore the command call or change its behaviour as appropriate.
I don't know the script system well enough to backport the script sandboxing feature from Red Eclipse to the other Cube 2 engines.
Aside from that, it'll break at least one of the Cube 2 SP maps (‘lost’, which sets a keybind in the map .cfg file). If scripts are still allowed to create their own commands (I can't tell whether that's the case in RE), that could be avoided by reserving a few global bindings for map-specific actions.
I'll focus on other areas of the engine first then.
Referencing textures/models/sounds/etc is fine for a map.
Sorry, I was unclear. I meant ‘include or reference’ textures and texture config files to be downloaded from the Internet if they aren't already installed. Specifically, one of the following possibilities:
(A) Include textures/media and their configs in the map package itself (presumably a zip file).
(B) Reference other packages (.zips) to be downloaded along with the map package if they aren't already installed on the client.
(C) Reference textures/media and their configs to be downloaded from a single central server (or a set of servers which are trusted to all serve the same set of files).
(D) Reference textures/media and their configs by their hashes, to be downloaded from either a central server or the server hosting the map.
With (C), (D), or a well-thought-out implementation of (A), untrusted maps can use (be downloaded into) the same virtual directory tree as trusted maps if those are necessary (e.g. for ‘lost’ or other scripted SP maps); with (B) they can't. (B), (C), and (D) require less bandwidth and client disk space than (A) for textures used by multiple maps. (C) or (A) done well can safely auto-download upgrades of existing content. (D) requires more changes overall (e.g. map configs would need to change even if they're still sandboxed CubeScript), but would be fairly easy to add during a switch to a declarative map config language.
Offline
Regardless of how you implement it, bind scripts would not be an issue at all. It's as simple as either working around the current shortcommings of cubescript by implementing a separate layer of bind control or outright doing it in the source. Either way, it can easily be fixed.
As for the rest..
Referencing external content would require quality control to be implemented as well, or in the very least a warning that the map requires unverified content to be downloaded or something. Can't depend on hashes or zips with non-standard content.
Offline