New configuration API

Summary
Currently the starting section of dialogue displayed when a dialogue is initiated with an NPC (i.e. the NPC's greeting) is hard-coded and static - that is, NPCs will always greet the player with the same text, regardless of the player's actions. The proposed changes would add conditional statements to the START_SECTION tag which would be evaluated each time a dialogue is initiated to determine an appropriate starting dialogue section or root.

Rationale
Currently, configuration files are written in XML, which is overly verbose for this particular use case. An INI file would be easier for people to read and modify with a standard text editor. It might be argued that the files are never edited directly, but should the game crash due to a malformed XML file, a user might prefer being able to manually tweak a couple of lines in a configuration file, rather than deleting a file that they possibly spent a lot of time on and starting from scratch.

Furthermore, configuration file paths are currently hard-coded which restricts how the game can be packaged.

Also, the current API for settings seems rather C++/Java-like rather than Pythonic. This proposal, if implemented, would make the interface more intuitive for Python programmers, and would actually reduce the amount of characters needed to manipulate configuration options. Please consider the following syntactic differences:

from fife.extensions.fife_settings import Setting
 * 1) simplified from common/utils.py and objects/actor.py

filename = 'settings.xml' settings = Setting(app_name='PARPG', settings_file=filename) self.speed = settings.get("PARPG", "PCSpeed") - 1 vs from configuration import Configuration
 * 1) the new API

filename = 'settings.ini' settings = Configuration(filename) self.speed = settings.PARPG.PCSpeed - 1 # see [1] below

While it is not obvious from the above example, it is worth mentioning that the Configuration class is able to load settings from multiple sources (eg. loading a system-wide configuration, then updating with user preferences).


 * No quotes or parenthesis
 * No getter style methods. Sections and options are accessed as properties

Pros and Cons
Pros:
 * The format for config files is simplified
 * accessing and manipulating these files is easier for programmers

Cons:
 * default setting file needs to be converted from xml to ini format (see [2] below)

Implementation

 * My configuration module (see [3] below) would need to be added to PARPG
 * all occurrences of settings.get would need to be replaced by property access calls
 * something similar would need to be done for portions of code that set setting values