This is the discussion topic for the implementation and maintenance of a 'status database'.
Information
The concept behind this change would be to remove the entirely hard-coded current 'status table' system, and move the flags into a database file. This database file would be editable and customisable by any server owner, and would allow much more flexible implementations of things.
Example
Currently the source stores status related information in tables in status.c:
static sc_type SkillStatusChangeTable[MAX_SKILL]; // skill -> status
static int StatusIconChangeTable[sC_MAX]; // status -> icon
unsigned long StatusChangeFlagTable[sC_MAX]; // status -> flags
static int StatusSkillChangeTable[sC_MAX]; // status -> skill
The first step in reforming this system would be to allow a status database (ie, status_db.txt) to define the characteristics of the statuses. This would mean the status icon displayed and the status change flag (which determines which statuses should be recalculated once it starts). However these are not the only areas left to be defined.
The source dictates which statuses can:
Be retained when the Sage skill Dispel is used
Be retained when a character logs out
Be retained when a character dies
Override or cancel previous statuses
Override the previous status active on the user
To tackle these hard-coded solutions, it would then be plausible to implement a 'flag' column (for defining features such as 'buff' status, 'debuff' status, 'un-dispellable') and have an additional column to list statuses which are cancelled when the status is activated.
Of course some areas of the status system will be kept in the source, mainly the actual bonuses (such as in the status_calc_* functions) and status specific checks (some statuses cannot be activated when another is active etc.)
Proposition
The idea would be to have a database in the format:
<status id>,<status icon>,<recalculate flag>,<status flags>,{ <override status 1>, <override status 2> ... }
The purpose of this topic is to collect additional ideas for this implementation, and thoughts on using a database like this.