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.