[Discussion] Changes to db-scripts and condition system

[Schmoozerd]

"(my approach sacrifices space for simplicity):"

infact the basic conditions (has-aura) will be less in your version -- which is kind of a good thing, because this might be the place where we can keep things easier between the different projects.

But you might require more "link-conditions" (with which I mean the conditions of type -1, -2)

With this system, you need to check the numbers of your conditions, and then how they are used within the "link-conditions"

[faramir118]

pushed updates to my repo, it now outputs in a format like the example in my last post.

[Schmoozerd]

nice, I will create an initial converter, to also see how the different db-projects look in this converted form.

The core changes should be relatively simple, and I will look into them "soon" (except someone else was faster)

[lillecarl]

What if we would have a columb where we could specify more then one link target?

[Schmoozerd]

the main idea is to melt it down into one column, so why readd more?

[lillecarl]

Never mind, i were thinking of another solution. But maby your's is smarter ^^,

[Schmoozerd]

updated my repo with some fastly hacked in stuff, that should support the core-side with faramir's system

[Schmoozerd]

A new conversion helper for initial fill: http://paste2.org/p/1973223

Results were:

Processing database zero_db (0 vector conditions)

Inserted 32 rows for database zero_db

Processing database tbcdb (0 vector conditions)

Inserted 148 rows for database tbcdb

Processing database udb_clean (0 vector conditions)

Inserted 267 rows for database udb_clean

Processing database ytdb (0 vector conditions)

Inserted 657 rows for database ytdb

Processing database zero_db (1 vector conditions)

Inserted 0 rows for database zero_db

Processing database tbcdb (1 vector conditions)

Inserted 0 rows for database tbcdb

Processing database udb_clean (1 vector conditions)

Inserted 0 rows for database udb_clean

Processing database ytdb (1 vector conditions)

Inserted 0 rows for database ytdb

Processing database zero_db (2 vector conditions)

Inserted 2 rows for database zero_db

Processing database tbcdb (2 vector conditions)

Inserted 33 rows for database tbcdb

Processing database udb_clean (2 vector conditions)

Inserted 57 rows for database udb_clean

Processing database ytdb (2 vector conditions)

Inserted 110 rows for database ytdb

Processing database zero_db (3 vector conditions)

Inserted 0 rows for database zero_db

Processing database tbcdb (3 vector conditions)

Inserted 10 rows for database tbcdb

Processing database udb_clean (3 vector conditions)

Inserted 34 rows for database udb_clean

Processing database ytdb (3 vector conditions)

Inserted 62 rows for database ytdb

Processed database(s): [['zero_db', 0], ['tbcdb', 1], ['udb_clean', 2], ['ytdb', 2]]

Difficult to say, if a shared initial fill would make sense - there is some huge data mismatch between the different projects

[lillecarl]

Does it really matter that there are data mismatch between the database projects? Just put the "initial filler" to the repo and let the database developers use it?

[Schmoozerd]

the problem is, that it will start to diff in the long term, so within time you won't be able to trust the other conditions datas to be equal, so need to check anyways when porting.

Also there are basic problems, like that conditions which check items or spells will throw errors on older-client databases, because the items/spells just don't exist.

And lastly between udb and ytdb there is atm a set of conditions related to fishing loot (day-time dependend), this is realized with game events, but they throw DB errors in udb because they don't exist.

Edit: Here you can see the conditions table: http://paste2.org/p/1973755

I looked roughly over it, but didn't find a clue of how to maybe improve some conditions to squash a few lines ..

[faramir118]

more changes to the utility, trying to automate the work as much as possible

If anyone has feature requests or suggestions, let me know

[lillecarl]

Schmoo, is the intention that the mangos team should start maintaining the conditions system? Because otherwise it doesnt really matters, then its the database teams individual "problem"?

[VladimirMangos]

I not see how this possible because different needs in conditions list for different DB projects and not calling conditions from core code directly (by ids).

[lillecarl]

@Vlad Are condition id's called from the core via hardcoded ids somewhere you mean?

[Schmoozerd]

no, vladimir was telling, that currently the core doesn't use anywhere any hard-coded condition-entry.

So actually no need to force the conditions table to be under sync of mangos -- which is also in the bigger picture impossible, because conditions are highly DB stuff related. (unfortunately even custom db-stuff)

However I suggest to keep a couple of condition-entries reserved for shared use (Mangos, EventAI maybe, SD2 maybe) - even if we currently see no need for them. But this might change

[lillecarl]

Well then just reserve a thousand?

[VladimirMangos]

possible do same thing as for string ids if this really need: signed ids with reserve some for core, other for DB.