New Config System
Well, technically the config system isn’t that new, considering it was created a while back. However, it wasn’t until recently (thanks to xapantu and tshirtman) that the system was capable of being fully integrated into USF. This accomplishes a few different things:
- Only 1 configuration file to maintain. Before, it was neccessary to modify sound.cfg, config.cfg, and keyboard.cfg. Now there is a single config named user.cfg (Though technically, the game can be configured with the GUI).
- New config options no longer break user configs. Before, every time the config options were added, you had to delete your old config file. Now the new config options are automatically integrated meaning your changes aren’t clobbered
- Cross-platform support. The config is now saved in a sane spot, depending on which platform you are running in. In fact, if you decide to run USF locally, your home directory won’t be polluted by unneccessary config files
- Creating new config options no longer breaks users configs. Simply add your configuration option to system.cfg, and if the user hasn’t already done so, their user.cfg will be updated accordingly.
- Easy access to all config options. The Config class automatically creates a new dictionary for each section in the config file (currently general, audio, keyboard). Adding a new section will create a new dictionary. Assigning a new config value is as simple as assigning a new value to a dictionary key: config.section['option'] = value (eg config.audio['SOUND_VOLUME'] = 0
- The new config class is smart enough to do duck typing on configuration values. In the example above, sound volume would automatically be converted to an integer.
New Build System
I’ve leveraged the power of Python’s built-in distutils module to create a setup.py that will automatically, given the correct command line parameters, create source tar.gz and zip packages, rpm packages, and deb packages. I was attempting to make this script generate exe files for Windows uses, but I have hit a road block that I can’t seem to get around: files don’t install to the correct location. For Mac OS X, I don’t have access to such a machine, and as far as I understand it, it’s not feasibly possible to run Mac in a virtual machine, so I haven’t come up with a solution for that platform.
I have thoroughly tested the produced source tarbals (which are great for creating packages for Arch Linux, Gentoo, etc), and tshirtman has had some success building debian packages with it (he’s using them on Ubuntu), but we have yet to test the RPM packages, though I suspect we will not run into any problems on that distro.
If you have any experience with distutils and Windows or Mac, please don’t hesitate to contact one of us or post a comment. We definately want USF to be accessible to everyone, not just Linux users.