Schmoozerd

Just a small note to make things easier: I am pretty sure that there are possibilities to solve conflicts in favour for one side with git, maybe also for single files. If this was so, maybe some small merge-helper script could do this, and these simple conflicts would show up no more for users. Also you could add an own revision-file for playerbot, to prevent some conflicts. But the main point why i write: Blueboy I sent you a PM ages ago

I have never looked at related code - but will this have impact (desired, undesired) onto * warlocks? * ghools? * some exotic "pets" like shaman wolfes?

you can probably add a AT_LOGIN flag to force them to change PW or so.

After long wait. All three decimate spells in [11956]. Thank you guys

Hi virusav - hope you are alright. Yes - actually a place to collect publicly available sniffs is a good idea! If we get links here, I think I will make this thread sticky

In [11954]. Thank you

Ah, you are talking about the BG-weekend events? Yes the battlemasters in the cities are only around on weekends. Afaik normally you need to walk to the actual BG-entries to join a BG Take a look at udb wiki, game_event table, to see how to start a event permamently (add start-time in past and duration near infinity)

@lillecarl The code you pasted is used only to change the password (which is for case s = v = 0)

s, v != 0

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

little bump here. From wowwiki and wowhead comments it should do way more damage (depending on caster's mana pool) Edit: After some research, and bit thinking in [11950] Thank you Known bug: The spell hits oneself - but I am pretty convinced that this must be fixed with basic spell-targeting, and not as effect of spell 27820.

This thread is about the new conditions system, which is intended to replace the current condition handling. (Faramir's version) The basic idea is: Wrap up all conditions into one table, called `conditions`, and refer to this table from loot or gossips directly by entry. To be able to have complicated conditions (like HasAura AND NotHasItem), two Meta-Conditions for AND (-1) and OR (-2) are introduced. Reason for this: Advantages: * Less space in the database * More powerfull concept * Easier to add conditions to other places Disadvantes: * Harder to read (always require an additional join - or a set of joins) * Harder to port entries from tables with conditions between different DB-projects * Converting requires some additional tool (realized with a non-optimal working python script) To Test Source Code for core changes can be found here: http://paste2.org/p/1975570 or on my github repo: https://github.com/Schmoozerd/mangos/commits/condition_system You need to apply the file sql/updates/66666_01_conditions.sql An Update for current UDB 404 can be found here: http://paste2.org/p/1975572 An Update for current YTDB 618 can be found here: http://paste2.org/p/1975574 You can generate the SQL changes yourself easily with the python tool located within contrib/ConvertConditions This is extremely usefull to use if you have many custom conditions - you then just can use a clean conditions table for starters, and rebase your custom conditions on top of them. NOTE: I have currently reserved the condition_entries 1-99 for mangos' use, please do not fill them with custom data! In the moment the system coexists with old conditions for gossip-system, but REPLACES the condition in the *_loot_template(s), so you must apply the SQLs or no loot-condition will exist. I think there is no rush in directly removing the old conditions from the database, this will happen some time after the new conditions system is applied. For easier work with the new conditions, faramir wrote a helper tool, located on his github repo: http://github.com/faramir118/MangosUtil/ Please feedback test-results

Reject this, as this aura is not applied to new night elf druids. Some alternative solution is still required. (Probably learn the passive aura when the spell is learned or something) Edit: Store for future reference, in case something alike is required diff --git a/sql/mangos.sql b/sql/mangos.sql index 139d6c9..b77121e 100644 --- a/sql/mangos.sql +++ b/sql/mangos.sql @@ -12190,6 +12190,7 @@ INSERT INTO `playercreateinfo_spell` VALUES (4,11,22027,'Remove Insignia'), (4,11,22810,'Opening - No Text'), (4,11,27764,'Fetish'), +(4,11,44835,'Maim Interrupt'), (4,11,45927,'Summon Friend'), (4,11,58984,'Shadowmelt'), (4,11,61437,'Opening'), @@ -12701,6 +12702,7 @@ INSERT INTO `playercreateinfo_spell` VALUES (6,11,22027,'Remove Insignia'), (6,11,22810,'Opening - No Text'), (6,11,27764,'Fetish'), +(6,11,44835,'Maim Interrupt'), (6,11,45927,'Summon Friend'), (6,11,61437,'Opening'), (6,11,66530,'Improved Barkskin (Passive)'), diff --git a/sql/updates/77799_01_mangos_playercreateinfo_spell.sql b/sql/updates/77799_01_mangos_playercreateinfo_spell.sql new file mode 100644 index 0000000..5899906 --- /dev/null +++ b/sql/updates/77799_01_mangos_playercreateinfo_spell.sql @@ -0,0 +1,4 @@ +DELETE FROM playercreateinfo_spell WHERE Spell=44835; +INSERT INTO playercreateinfo_spell (race,class,Spell,Note) VALUES +(4,11,44835,'Maim Interrupt'), +(6,11,44835,'Maim Interrupt');

Spells 48250 and 46556 are the only ones with positive basepoints, so they (and they alone) would _increase_ the dodge chance with your patch. about 46556 it is not possible to say much, looks like a test-spell to me. spell 48250 seems to be used ingame, but the overall dbc data looks crappy (in description use of basepoints of effect0 instead of proper effect2..) Don't know what to make of this.

Thank you. Move to rejected, as seems to be already implemented in master. Alternative added in commit 6696da55bc203c32a70c99d66d50f144f2a8e118 [9967] Fix 16164 proc conditions please rebump if I am mistaken.

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 ..

A new conversion helper for initial fill: http://paste2.org/p/1973223 Results were: Difficult to say, if a shared initial fill would make sense - there is some huge data mismatch between the different projects

well, the level-requirements might be possible to add like this. BUT it would be redundant (dataz already in areatrigger_teleport) BUT it would hardly be possible to expand heroic key or quest-requirements to this.

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

this is slightly more difficult; indeed I agree we need to refactor the code currently within the area-trigger, and use this also within CanEnter, but this is more complicated, as the checks are atm toggled to area-triggers, and not maps. So we need to find a way to go from CanEnter (knowing map-id) to _the_ (which might not be unique) areatrigger holding the information about requirements

Repacks are not supported here. But if you are already able to compile your own core from the sources, the remaining step is only to set up a database server and fill in the required content. You can do it

such behaviour is usually scritped with EventAi, for which acid is the most commonly used project. It can be found on sd2 forums www.scriptdev2.com

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

this is some problem with default behaviour of casters. While in "cast-mode" they stop moving and cast. This casting fails because of LoS isssues. If you are too far way they will start following, until they are near enough for casting. So much for explanation, but as this is a fairly complicated problem for the AI, I don't know yet how to outline a proper solution.

sure, do you say that it doesn't compile without it? Edit: Fixed in [11943]. Thank you