Olion

[url]https://github.com/mangoszero/server/pull/6[/url] I introduced this with SD2 refatoring. Details: SD2::GossipSelect contained clearing of the player gossip menu, which become executed in cases when an NPC has an SD2 script does not overriding OnGossipSelect, and has also GossipMenuId defined in the creature_template.

It is exactly about was my question. We have to ask the community, how oftenly Blizz took items out of players. I suppose it should be kept in all the later DBs but with nerfed stats from wowhead. In Zero, we may leave it also as a GM item, i.e. not attainable by players; the correct spells (auras) are to be found. Knowing the stats, it's simple task.

It is not that simple. [URL="http://www.wowwiki.com/Fists_of_the_Unrelenting?oldid=251413"]Here[/URL] we see a bit different set of stats. By date: patch 1.12.0. [URL="http://www.wowwiki.com/Fists_of_the_Unrelenting?oldid=343958"]Here[/URL] is said that the item was found in drop only in Naxxramas beta-test, later it "can not be aquired ingame". Patch 1.12.2. [URL="http://www.wowwiki.com/Fists_of_the_Unrelenting?oldid=370922"]Here[/URL]: it is added back as a drop from Sapphiron, the same stats. Patch 2.0.3. [URL="http://www.wowwiki.com/Fists_of_the_Unrelenting?oldid=596201"]Here[/URL]: a bit different set of stats. Patch 2.1.0. [URL="http://www.wowwiki.com/Fists_of_the_Unrelenting?oldid=1060023"]Here[/URL]: yet another set of stats. Patch 2.3.2. [URL="http://www.wowwiki.com/Fists_of_the_Unrelenting"]The last version[/URL] tells that it was removed in Patch 3.0.2. However, the final mentioned stats differ from ones by wowhead. So, it was never available in Classic (up to us to create it there still), was available in TBC as Sapphiron drop, and was gone in former WotLK. The question is, were the item instances destroyed, or simply become not attainable with Naxxramas upgrade. Seeing wowhead stats (nerfed), I support the latter idea.

[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]