Dawn of Light

GlobalConstants.cs already has a class in it named GlobalConstants, so how about we put it in there?

Or if it's not a configurable value, and not a value re-used throughout the code, why not just use the literal value instead of a variable?

GlobalConstants.cs already has a class in it named GlobalConstants, so how about we put it in there?

Or if it's not a configurable value, and not a value re-used throughout the code, why not just use the literal value instead of a variable?

yes but it holds no single constant value just methods and i didnt wanna mix them. should i?

its a variable so someone who really needs it, can set it to 0 to have old behaviour, also it will be used in more places in future

yes but it holds no single constant value just methods and i didnt wanna mix them. should i?

Sounds reasonable to me - then it's simply GlobalConstants.USE_AUTOVALUES instead of GlobalConstants.Constants.USE_AUTOVALUES. It would be good if we can think up a more descriptive name than USE_AUTOVALUES.

its a variable so someone who really needs it, can set it to 0 to have old behaviour, also it will be used in more places in future

This is why I wonder if it might be best to make it yet another SP.

I'm not clear what the aversion to server properties is. It's a good tool to place server specific changes that the operator can change when they need too. You can organize these by area even, so why not use them?

I'm not clear what the aversion to server properties is. It's a good tool to place server specific changes that the operator can change when they need too. You can organize these by area even, so why not use them?

instant thoughts :
1st : its out of code, so i can not use vs to know the value.
2nd : its not easy to maintain cause it has no good structure (currently)
3rd : not all really needs to be read from db/be changed while a server is running
4th : i am sure that many people are unaware of them completely or do not pay much attention to them, i'd prefer a structured config file for most of them, yet some make really sense to be changeable on the fly. the system is not bad per se, just its far away from code
5th : i do not see a real net gain to add all magic values, that should be constants, to be added as sps

if the value is meant to be fixed then it should be a constant, but a lot of those things needs to be tweaked .... honestly I could probably remove 10 or so properties that are no longer needed, especially once I clean up the keep code ... but doing tweaking reboot to reboot would take a year!

I am a fan of server properties, but the lack of structure makes me shudder every time we add another one.

I think it's really great that the behavior of a DOL server can be significantly tweaked by adjusting SPs, and I really appreciate that many can be updated without even restarting the server.

I've long dreamed of cooking up some sort of GUI for editing SPs, but in the meantime I'm none too fond of slogging through that big table looking for what needs tweaking, or what I misconfigured or overlooked (for most of my server's history I had nerfed XP in DF because I didn't realize I needed to adjust an extra SP for DF in addition to the normal SP for setting XP rate).

i worked, Kakuri, to implement this. Another unfinished project - but it should end up as soon as i could have a decent feedback on the db engine migration (somebody is working on this) (ie: either i wait, either i continue without it).

The goal is to allow other DB engines, and not only MySQL. The goal is to totally replace XML (introduced back by Etaew because he dev with this feature), by a traditionnal DB engine file oriented: SQLite. Thus we have a totally normalized data interface, and we are not keeping 2 data. management systems. And as the work is done for another engine (SQL flattening to allow SQL92 norma), this must lead to use MySQL, SQLite, PostgreSQL, MSSQL, because they all have a working ADO.NET driver.

But back to SP organization.
Structurally, i added a new field in serverproperty table, called structure, pointing to the id field on the new serverproperty_x_category table, which have the following structure:
id, parent id, name

with:
id is the id as entered in serverproperty.structure
parent_id is the parent id category if necessary,
name is the name of a category or sub-category. If null, this is the serverproperty.

Example:

we have 2 SPs: rp_rate, xp_rate.

we want :
Settings (category)
- xp_rate (property)
- Rvr (sub-cat)
- Rp_rate (property

table contents:
structure field value for xp_rate = 2
structure field value for rp_rate = 4

serverproperty_x_category

Code: Select all

id parent_id name
------------------------------
1 0 Settings
2 1 (null)
3 1 Rvr
4 3 (null)

Not sure at all if i'll continue this way (i find it a bit... mhhhh... hard to complete without performing a query with join command). I simply try to find an extensible way to db handle all the organization of SPs.

That looks really great Graveen!

Wow that's really really nice. Will make it much easier to manage SP's when it's released.

expect a release soon anw, but as is - i mean the categorisation will be not really accurate, but we could tweak it later.