A simple "theme" system for sounds/textures?

[grunch]

Don't know if this has already been discussed, but it might help people with red/green colorblindbess or anyone else wanting to change the texture and sound files if there was a simple method for importing "theme packs" and switching between them. This might allow some people to get involved creatively who wouldn't otherwise. Just a thought.

That said, here are my take on improved discernment textures for the tanks: the red is shifted slightly towards orange, the green slightly towards cyan, the purple a little more saturated, and the blue, well... couldn't resist adding a checkerboard in there somewhere. Also made a slightly muddier colored rogue, but it's not that much different, and it looks like only four attachments are allowed per post.

[L4m3r]

There have been assorted mods and textures for colorblind people in the past.

There are also lines in bzflag's configuration file that can change the radar blip colors used in-game. This is especially helpful for differentiating red and green for those who have trouble.

[grunch]

I did notice the red/green topic in a couple of places. I should probably clarify that the main thrust of post is not so much that specific issue, but the question of whether it would be a good idea to have simple theme loading and management from within the game, to make it more easily accessible for everyone who wants to try variations. Would this get out of hand, do you think? It might at least be nice if, on startup, bzflag checked a location in the user's data (~/.bzf/resources or whatever) for the files, then defaulted to the system-wide versions for any that weren't there. That way at least people could experiment without having to modify system files, and it would be pretty easy for someone to create an external app for management if the bzflag devs didn't want it in the game itself. Of course, if they don't want to encourage people to mess with this stuff, then nevermind.

[DTRemenak]

You may specify an alternate directory to load data from with the -directory command-line option. Anything it doesn't find there it will load from the installed data. It is persistent once set (written to the config file), so you don't need to specify it every time.

And yes, we would like some form of theme management eventually, it's just not a terribly high priority. Patches welcome (but please discuss implementation details first).

[grunch]

Ok, how about something like this: next release (or so) is simply patched to create an additional directory named "themes" in the user's data directory during installation, with a child directory named "original" or something similar, which contains exactly the same set of resource files as the system shared ones. Also in the directory is created a link named "current" pointing initially to the "original" directory, and which is checked first on startup, with the same behavior as if given a -directory argument in recent releases. This would be very simple to add immediately, and could be the basis for any future theme management in the game interface. Moreover, by using the "current" link, people could develop installable theme packages or simple management apps that wouldn't have to touch the config file, which is probably for the best...

Does that seem like a reasonable gradual approach to implementation, or is it too much of a hack? I'm pretty tired at the moment, so I apologize if none of that is coherent, or if it's just plain stupid.

[L4m3r]

Some OSes don't support links.

I think it'd make more sense to put a "themes" directory in the user files directory (alongside worlds and screenshots), instead of the client's original data directory. themes could then be selected by the client. If any data elements are missing, the originals can be used instead. it'd only take one additional line in the client config file, too.

[grunch]

I think it'd make more sense to put a "themes" directory in the user files directory (alongside worlds and screenshots), instead of the client's original data directory. themes could then be selected by the client. If any data elements are missing, the originals can be used instead.

Yeah, I think that's what I was actually trying to say.

it'd only take one additional line in the client config file, too.

Seems like the existing "set directory" line could be used. I just would feel more comfortable, myself, personally, if any package script I wrote didn't have to write to the user's config, but that probably wouldn't be an issue for someone who knew what they were doing, I suppose.

[L4m3r]

well, the idea would be that package scripts wouldn't be necessary (again, OS issues). extract the theme to the appropriate directory, start the client, and pick a theme. The client will check for theme directories and list them as options. the client saves the selected theme in its config, and you're done.

it's slightly different from the directory option, because the client actually checks a specific location for installed theme packs. the original data directory remains the same. Most theme packs would be incomplete (I would think that most would not replace every single texture and sound) and it'd be best to reduce redundant files.

[grunch]

well, the idea would be that package scripts wouldn't be necessary (again, OS issues). extract the theme to the appropriate directory, start the client, and pick a theme.

You're absolutely right assuming this functionality *will* be added to the client (but as mentioned above, it isn't on the priority list). The convoluted implementation I was proposing was based on the assumption that it wouldn't be implemented any time soon, and that maybe a few lines of code in the mean time (at simplest, a user data directory that is always checked without having to give a -directory argument) would lower the bar a little for people wanting to mess around with (by editing or obtaining otherwise) the resource files without possibly screwing up the system versions. Once again, I'm sorry for not making this very clear - posting while falling asleep.

it's slightly different from the directory option, because the client actually checks a specific location for installed theme packs. the original data directory remains the same. Most theme packs would be incomplete (I would think that most would not replace every single texture and sound) and it'd be best to reduce redundant files.

I was thinking along the lines of (eventually) the client checking for themes in the "themes" directory which would just be a sibling directory of "cache" etc. The only real change in behavior (for now) would be to apply an initial default value to "set directory" pointing to a default "original" directory (within "themes") containing copies of the system files. This would just remove the requirement for desktop-icon-launching users to use the command line if they wanted to try different resources without actually replacing the system copies. The idea of creating a redundant "user" set by default is for people who want to hack on or replace the existing ones without touching (and potentially messing up) the fallback system versions (possibly I have a minor obsession with failsafing ). Hope that makes sense, even if it's not a Great Idea.

In a nutshell: I'm just proposing what I'm guessing will be the most (immediate) benefit for end users given the least (immediate) effort by the devs. Don't want to divert coding time away from the important stuff.

[L4m3r]

Well, the next major release isn't likely to be out for some time, so there's really no hurry. You can hack up 2.0.11 as much as you like and release a patch if you want. Any new features will be implemented in 2.99.