Olion

[url]https://github.com/mangoszero/database/pull/227[/url]
Tested, and seemingly I forgot nothing.
It's funny also that the worgen tailor is a trainer, while he is vendor only in the human form.

The only question left: should the worgens retain the weapon from their human form? Now they don't, feeling themselves good in combat with their claws.

Cannot reproduce at current Zero version, even issuing the command from within the client. It means that the problem is either fixed, or appears at random depending on the moment the timer expires. For the latter case, should be tested at considerable online, like 100.

[url]https://github.com/mangoszero/database/pull/226[/url]

[url]https://github.com/mangoszero/database/pull/223[/url]
Sorry.. I should sometimes read the [URL="http://getmangos.eu/wiki/Reference%20Information/DB/mangos/MaNGOSZero/spell_bonus_data.md"]documentation I created myself[/URL]. Well, after it will be applied :)

This is close-to-full fix of the spell. The only problem left is the following. In case you have T8 bonus reducing HP loss due to this spell, the loss is calculated BEFORE the mana gain, and the MP gain is lowered too (by 12-16% depending on the talent). Thus, a problem in the core remains. Still ToDo.

How should the blade work?

I see the spell 28414 (as item enchant) proc'ing on melee/melee spell attack with 10% chance. Probably it is followed by the "Drain life" 29155 cast. However when does the blade say anything? Should it be at the same proc with the Drain life cast, or simply at random while equipped in/out of combat?

FYI, the sound entries for the blade: 8906-8908, 8920-8928 (these work actually) and a combined entry with no effect due to missing core support, 8940. The thing should be scripted, and it is not an easy task. In TC, I would say it is simple SpellScript task for triggering spell 28441. Here we need some inventions with Unit class event processor, m_Events.

Consider this as a sticker note to myself plz :)

P.S. And no, we never play on the servers we are trying to develop/fix.

[url]https://github.com/mangoszero/database/pull/221[/url]
This is a partial fix. It improves the picture greatly due to correcting the bug in the spell_bonus_data (so forget about 1k HP losses), but the numbers got from the spells are strange still. It seems that spell/character level difference affects them. Leaving this as ToDo.

Cannot reproduce. The sympthome is similar to this:
[url]https://www.getmangos.eu/issue.php?issueid=887[/url]
which was caused by an incomfortable for the client WP set. I wouldn't blame the PF mechanic. However it can cause this still while used for WP movement.

[url]https://github.com/Olion17/ZeroCore/commit/233d3f5f7e01fda3909ad89ef9300ac06ea0ee3c[/url]

Switching to the prepared statement mechanic, rely on them for string escape, as decribed [URL="http://stackoverflow.com/questions/4532572/escaping-string-for-sql-in-c"]here (with a bit excessive work)[/URL]. Tested for different mixing of single and double quotes in a whisper.

The pet power regen was killed in Rel20 branch at Aug 2014. Here is the fix of that useful but, say, unlucky commit:
[url]https://github.com/Olion17/ZeroCore/commit/6bfb014cac6badcea2ea71dac696c9c9ac138f97[/url]

I wish it be the last bug with the pets :D but it is far from one. After a brief testing, it seems that now we have to teach the pets to actually use the energy, then correctly calculate spell CDs... but I hope these will be another bugreports.

After some... say, experience with a newer Win OS that 7, another simple enough hack was found unexpectedly. The idea is in supplying the ACE project by define _WIN32_WINNT=0x0601. Below is CMakeList file patch which I will have troubles to upload because it belongs to the submodule "dep".
[ATTACH]191[/ATTACH]

Just found that at a server-type OS (different from my 7) the problem is different (at a stage of joining to the thread just before destroying it) and the "hack" proposed does not help. Trying again...

Sorry, forgot to do it. Adding.
However the field is used by the core only to be announced in-game, and for our table construction, the wrong db version is announced as you can see. I hope we'll get rid of this at least stupid mechanic one lucky day. A better way is to write all sqls reapplicable and, if any doubts, apply the whole "Updates/Relxx" content with a shell script/bat file.

Thank you for localizing the problem. The solution above is not enough elegant though.

[url]https://github.com/mangoszero/database/pull/220[/url]

Well, after some tinkering with the sources, the following log can be obtained:
Halting process...
X
CliRunnable: run() end! Thread=7084
Master.Run() before final return, thread=7068
[B]sMaster returned! Code=0, Thread=7068[/B]
Dtor: number of threads: 0, last ID=6468, thread=7068
Dtor: number of threads: 0, last ID=7064, thread=7068
Destroying singleton class LFGQueue, thread=7068
Destroying singleton class MassMailMgr, thread=7068
Destroying singleton class AuctionBotConfig, thread=7068
Destroying singleton class AuctionHouseBot, thread=7068
Destroying singleton class TerrainManager, thread=7068
Destroying singleton class OutdoorPvPMgr, thread=7068
Destroying singleton class MapManager, thread=7068
Destroying singleton class ObjectRegistry,enum MovementGeneratorType>, thread=7068
Destroying singleton class ObjectRegistry,class std::allocator > >,class std::basic_string,class std::allocator > >, thread=7068
Destroying singleton class CreatureEventAIMgr, thread=7068
Destroying singleton class GMTicketMgr, thread=7068
Destroying singleton class GuildMgr, thread=7068
Destroying singleton class AuctionHouseMgr, thread=7068
Destroying singleton class BattleGroundMgr, thread=7068
Destroying singleton class WaypointManager, thread=7068
Destroying singleton class GameEventMgr, thread=7068
Destroying singleton class PoolManager, thread=7068
Destroying singleton class CreatureLinkingMgr, thread=7068
Destroying singleton class MapPersistentStateManager, thread=7068
Destroying singleton class ScriptMgr, thread=7068
Destroying singleton class ObjectMgr, thread=7068
Destroying singleton class World, thread=7068
Destroying singleton class Master, thread=7068
Destroying singleton class Log, thread=7068
Destroying singleton class Config, thread=7068
ACE_Thread::setspecific() failed!: No error
Here, the line in bold is from mangosd/Main.cpp, more precisely, from extern int main(int argc, char** argv). After CliRunnable and WorldRunnable are shut down, the only active thread executes return() from the program body, and the OS calls all the static destructors (in undefined order, though in our case it seems logical). IIRC no substantial work is done in these dtors, mostly memory freeing and pointer setting. Not a big problem if some of the dtors will be ignored, OS will free the memory anyway. So this is a rare case where the symptomatic cure to be applied instead of the correct one, consisting in a major code redesign in an unclear to me way (for that we have no resources, as it looks out). And this is my version of, say, "a crude workaround" rather than "a cure". I ask someone who tried a 64-bit Win build to extend #ifdef correspondingly, if needed.

[url]https://github.com/mangoszero/server/pull/298[/url]

On Win client, this is not a crash but something like a hang: the CPU usage of the client process jumps to 100%, fps drops below 1, very slow reaction on controls. Server logs just about that time:
WORLD: Received opcode CMSG_QUESTGIVER_STATUS_QUERY - for Player Ahunter (Guid: 2) to Creature (Entry: 4941 Guid: 8491)
WORLD: Sent SMSG_QUESTGIVER_STATUS for Creature (Entry: 4941 Guid: 8491)
[Client: MSG_MOVE_SET_FACING]
WORLD: Received opcode CMSG_MOVE_TIME_SKIPPED
The last opcode is due to the "hang" and is repeated many times. The client can become back at once, mostly after SMSG_PING, only to get the same hang within a few tens of seconds. Turning off EAI for the mobs 4967, 4968, 4979, 4941 changes nothing. During the "hang", the client gets SMSG_MONSTER_MOVE as usual.

These are [URL="https://github.com/mangoszero/server/blob/Release20/src/game/Object/UpdateFields.h#L255"]datafields[/URL] for player object.

The best available our documentation are 3 enums [URL="https://github.com/mangoszero/server/blob/Release20/src/game/Object/Player.h#L392"]here[/URL]. You might also find [URL="https://github.com/TrinityCore/TrinityCore/blob/3.3.5/src/server/game/Entities/Player/Player.h#L386"]it in the TC[/URL].

There is an annoying difference in EventAI action definitions. [B]Zero[/B]:
ACTION_T_SET_STAND_STATE = 47, // StandState, unused, unused
ACTION_T_CHANGE_MOVEMENT = 48, // MovementType, WanderDistance, unused
ACTION_T_SUMMON_UNIQUE = 49, // CreatureId, Target, SpawnId
ACTION_T_EMOTE_TARGET = 50, // EmoteId, TargetGuid

[B]Two[/B]:
ACTION_T_SUMMON_UNIQUE = 47, // CreatureId, Target, SpawnId
ACTION_T_SET_STAND_STATE = 48, // StandState, unused, unused
ACTION_T_CHANGE_MOVEMENT = 49, // MovementType, WanderDistance, unused

I suppose it would be better to unify it throughout the cores, or else this will not be the last ACID/EAI problem of such type.

[URL="http://www.wowwiki.com/Quest:Corruption?oldid=128514"]Here[/URL] is the quest description of May 1, 2006, corresponding to the patch 1.10.1. The Swordsmith learning is listed as the quest reward, and this is so until [URL="http://www.wowwiki.com/Quest:Corruption?direction=prev&oldid=1258944"]February 28, 2008[/URL]/[URL="http://www.wowwiki.com/Quest:Corruption?direction=next&oldid=1227341"]March 13, 2008[/URL] (2.4.0). Then the learning was remowed from the reward list, probably being moved to gossip (or dismissed blacksmith subspecs at all?).

The 3 analogous quests (5306, 5307, 5305/8869) have neither RewSpell, nor RewSpellCast, and it is definitely wrong. Also gossips about "learn subspec" are to be removed.

These quests are NOT marked as repeatable and have NO ExclusiveGroup. If we believe in the data, then each of the quests may be done only once, so each subspec may be learned only once.

The first mention about "unlearn subspec" was made [URL="http://www.wowwiki.com/Weaponsmithing?direction=next&oldid=1044632"]December 18, 2007[/URL], patch 2.3.0. Wowwiki guarantees nothing, but it's a good hint. Anyway,

[SIZE=3]community input needed on how the profession subspecifications (ex.: Blacksmith: Weaponsmith=>Swordsmith) were (un)learned[/SIZE].

Then we have to use Player::removeSpell(id,false,false) in place of unlearn spellcast.

Actually, 17042, 17043, 17044 are the spells for learning the "skill" spells 17039, 17041, 17040 respectively. These spells should be cast in the mode NPC=>Player (the script erroneously uses Player=>Player) to present correct animation. I did not read why exactly, but the learning spells work really (tested with .cast back) though having EffectImplicitTarget==0. Wouldn't this be the case, a correction of EffectImplicitTarget1 in SpellMgr::ModDBCSpellAttributes() would be necessary. Note that these spells do not have any check on the Blacksmithing skill presence/level incorporated. Now the check is incorporated into the NPC script GossipHello_npc_prof_blacksmith.

These 3 learning spells were dropped in TBC and changed to ones with IDs mentioned in the scripted method SendActionMenu_npc_prof_blacksmith(...). Moreover, the Classic has no SPELL_EFFECT_UNLEARN_SPECIALIZATION=133 defined, as well as no spells named like "Unlearn". There might be ones still with effects DUMMY, SCRIPT_EFFECT, but my vote is for no such spells. So, the script fixing should consist in 1) changing learning spell IDs to Classic ones, 2) removing gossip options about unlearn, and 3) shifting to ADD_GOSSIP_ITEM_ID in GossipHello_npc_prof_blacksmith(...) method to transfer the textes into DB that allows a simple localization later.

I guess that at the time, it was Blizz's way to keep online: any specialization may not be unlearned in Classic. However, I did not play offy Classic, so the question remains open:

[SIZE=4]Could the profession specializations be unlearned in the Classic?[/SIZE]

Here is the assert breaking execution (Win32, internal ACE, OS_NS_Thread.cpp:950):
ACE_ASSERT (key_info.key_in_use ());
It seems that a thread, while gracefully finishing, activates and requests a [URL="https://books.google.com.ua/books?id=dz6Fm8brtScC&pg=PA309&lpg=PA309&dq=ace+tss&source=bl&ots=nME3UZsZEX&sig=mQ24DAhA9NcTWiPo3CVcmQ6hBqM&hl=ru&sa=X&ei=PTTVVJbAGcK8ygPM3ICYDg&ved=0CDgQ6AEwAw#v=onepage&q=ace%20tss&f=false"]TSS key[/URL] which is used no more by any thread (but why isn't it flagged correctly?). Would be this an ACE bug, a bugreport probably had been [URL="http://bugzilla.dre.vanderbilt.edu/buglist.cgi?component=ACE%20Core&order=changeddate%20DESC%2Cbug_status%20DESC%2Cpriority%2Cassigned_to%2Cbug_id&product=ACE&query_based_on=&query_format=advanced&resolution=---"]here[/URL]. But its likely an incorrect ACE usage. We need the help of one who created with ACE (Reactor + multithreading) something more complex than "Hello World".

Btw, one of the most powerful debugging and profiling tools is [URL="http://valgrind.org"]Valgrind[/URL]. It could probably help here even in more-or-less amateur's hands. And here a virtual server would be useful, but only if under Linux.

Finally:
[url]https://github.com/mangoszero/database/pull/210[/url]

But FullDB/creature_template.sql is already changed to the wrong form...

Sorry but do you realy have a task to break working mechanics? Request this BEFORE your update applied:
SELECT * FROM creature_template WHERE RegenerateStats & 1=0;
and see UnitClass of the mobs. Then you might try the same after your update.

In many cases, stopped health regen is used for decoration purposes. But not in all cases possibly. Are you ready to check each case of that 9 mobs? It was much simpler to create a more precise update request, I suppose.

@antz: It would be better to have a community review BEFORE merging PRs touching at least few sensitive DB parts, in case you have no time to review it personally. One such part consists of the creature_template, gameobject_template, quest_template tables with exception of their fields defining scripts. By the way, applying this update to One DB via "project sync" will directly destroy [URL="https://github.com/mangosone/database/commit/aaf8587c895bb9d647a27e2df4a34e29fc6e3077"]a bit of my job[/URL].

A very interesting problem indeed.

After setting up trap radius
UPDATE gameobject_template SET data2=15 WHERE entry=103661;
the trap will react (spawning required chest o:103662 with the quest loot).. on the air elementals. But not on the player: at present, the "trap" reacts on a non-friendly units, and it is owned by the player, thus being friendly to him.

A good solution requires change of basical core mechanics. There are several points in the codeflow where we can introduce such change:
[LIST=1]
[*] [URL="https://github.com/mangoszero/server/blob/Rel20/src/game/Object/GameObject.cpp#L1692"]Gameobject::IsFriendlyTo[/URL]. Here we might check factions before checking GO ownership, and if set a hostile faction to the trap, it will trigger. This GameObject method is simply absent in TC, so comparison is not possible. Don't like much this idea.
[*] [URL="https://github.com/mangoszero/server/blob/Rel20/src/game/WorldHandlers/SpellEffects.cpp#L4718"]SpellEffect TRANS_DOOR implementation[/URL]. The trap is spawned by the [URL="https://github.com/mangoszero/server/blob/Rel20/src/game/WorldHandlers/SpellEffects.cpp#L4845"]last part of the spelleffect[/URL] as a "linked GO". [URL="https://github.com/mangoszero/server/blob/Rel20/src/game/Object/GameObject.cpp#L903"]Here[/URL] we can summon this "linked GO" as wild one, i.e. not owned by the player. This idea [URL="https://github.com/TrinityCore/TrinityCore/blob/3.3.5/src/server/game/Spells/SpellEffects.cpp#L5211"]contradicts directly to TC[/URL]. The related spell has also no Attributes at all, so no help from there.
[*] [URL="https://github.com/mangoszero/server/blob/Rel20/src/game/Object/GameObject.cpp#L362"]Conditions of trap triggering[/URL] in GameObject::Update. Probably we have to check the trap spell, and if it isn't negative, then consider the trap as environmental one, activating by ANY player in range, including GO (trap) owner. Something like this [URL="https://github.com/TrinityCore/TrinityCore/blob/3.3.5/src/server/game/Entities/GameObject/GameObject.cpp#L471"]is present in TC actually[/URL], but it is limited there to the wild traps again, contradicting this idea too.
[*] Finally, a crude hack is possible in the discussed part of GameObject::Update, based on the GO entry. This is the worst variant, which I don't want to implement.
[/LIST]

For now, I propose the 3rd variant.