Status Database

[Panallox]

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:

1. Be retained when the Sage skill Dispel is used
   
2. Be retained when a character logs out
   
3. Be retained when a character dies
   
4. Override or cancel previous statuses
   
5. 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.

[Haziel]

Agreed.

I have no proper skills of development, but, I belive that, like Item_DB, in most of the cases, it can be set with 'bonus' script in a { } field.

It's something that can be REALLY useful if can be done by this way.

Obviously, some of them will must be scripted on source, but, a lot of others can easly be 'translated' as Scripta Commands, if I'm not wrong.

I suggest a "Status Needed" {} field that will automaticaly check all status separated with ; to allow it to be set or not.

<status id>,<status icon>,<recalculate flag>,<status flags>,{ <override statuses> },{ <needed statuses> },{ <bonus scripts>}

Edited December 15, 2011 by Haziel

[Lighta]

Yes totally agree, I think there way too much hardcode in src atm, I mean not totally hardcoded since using enum but we should change thing for more database oriented or group instead a big swicth(case x: case y:.. function()), like dispelable check. ac_vulture effect and etc..

[KeiKun]

100% Agree with this one

This will make Everything Easier

For me >__<

@ Epoque

You are really the Master of Surprises-

[Panallox]

I like the idea of having the require column. Although the reason we're not going to implement a 'script' column is because it's not accurate enough to generate the values we'd need (like the source does), and it'd also be slow (since every status would run a script on the user, this would be painfully time consuming).

The database for the time being will server as a medium which will allow administrators, and developers, to maintain and edit the statuses as necessary I've added the required column into my list of to-do for it. Thanks

Edit

I have the conceptual database currently working. Note the following test entry:

SC_STONE,0,SCB_VIT|SCB_DEF,0x02,{ SC_BLESSING, SC_CURSE },{ SC_FREEZE }

Produced the output:

status=0, icon=0, flag=0x0002, recalculate=0x00004020, cancels=30,5, requires=1

[Haziel]

I thought that 'Script' field could be a optional one to help to create or recreate the simples ones, like, Food Bonuses.

By the way, once on DB we have a require field, it's good to put on sc_start a kind of flag which can avoid it, I do know, sometimes it may be needed.

[Lighta]

bump !, I think we should also had some propriety like (not dispelable), (doesn't affect boss) etc..

I don't know if we should had those in flag value or with a new colum.

[Panallox]

Hey guys, thought I'd post an update. I've re-written the source to use the status database, works just fine, just need any suggestions on where to store skill status entries. In the source it was originally assigned in set_sc() however I'm looking to move from statically designating the statuses in the source.

For those who don't quite understand, how/where should the definitions be to define skill -> status infliction. There's no point adding a new database for storing these 2 values alone, it's possible to add a new column though in status_db.txt to retain skill IDs (IE: { <skill1>,<skill2> }. Open for suggestions, then the first commit will be ready

[Lighta]

It.s not a 1-n relation so usually you should have a new table for that, anyway I think putting these association in status table will be best. I mean I found skill_db quite crowdy already so could be balance out. Plus you'll keep skill_db compatibility for old systeme.

Oh and I'd like to see a line of this new database if that possible.

Edited January 17, 2012 by Lighta

[Panallox]

The chances are that an extra column with a list of affected skills associated with the status effect might be the simplest method, until perhaps it gets re-written at a later date.

An example of some entries below:

//==================================================
// status database
//--------------------------------------------------
// <status>,<icon>,<recalculate>,<flags>,{<cancels>},{<required>}
//--------------------------------------------------
// recalculate:
//		  eg. SCB_STR|SCB_INT
// flags:
//		  0x01 : buff skill
//		  0x02 : debuff skill
//		  0x04 : cannot be dispelled
//		  0x08 : cannot be lost when character dies
//		  0x10 : does not override the previous instance
//		  0x20 : does not affect boss monsters
// cancels:
//		  eg. { SC_INCREASEAGI, SC_ADRENALINE }
//--------------------------------------------------
// note:	this file can use values from const.txt
//--------------------------------------------------

SC_STONE,SI_BLANK,SCB_DEF_ELE|SCB_DEF|SCB_MDEF,0x20,{},{}
SC_FREEZE,SI_BLANK,SCB_DEF_ELE|SCB_DEF|SCB_MDEF,0x20,{},{}
SC_STUN,SI_BLANK,SCB_NONE,0x30,{},{}
SC_SLEEP,SI_BLANK,SCB_NONE,0x30,{},{}
SC_POISON,SI_BLANK,SCB_DEF2|SCB_REGEN,0x30,{},{}
SC_CURSE,SI_BLANK,SCB_LUK|SCB_BATK|SCB_WATK|SCB_SPEED,0x30,{},{}

[Lighta]

Ah yeah look sweet, if I found other long switch case enumeration I'll tell you as a suggestion for new flag. (cleareance quite as long as dispel for exemple).

I presume require colum are for skill. I really think it's better that way instead an extra row on skill.

One last thing, for cancels there 2 differents things, one status can cure something but can also immune, and those 2 ain't always the same, I don't have exemple in mind yet but I'll edit to complete it. I guess cancels was for cure option.