Olion

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.

No, the pets are handled by another code portion. Sorry for offtop, but remember me plz about the pet buffs (feeding, for instance) [B]in vanilla[/B] (ie Zero): should the buff duration be visible to the pet owner/other players? As well as auras on the mobs: should these be visible at all and duration of its in particular?

The instance reset times are well know. Instead of an unsafe using ForcedDespawn() right at the creature creation moment and implanting a thrash into many instance scripts, one should correct boss respawn times creature.spawntimesecs in the way that these values were not less that the corresponding instance reset times. Also, two helper functions related to moving are misplaced at least. These helpers are supposed to be used in SD2 scripts, therefore they should be defined in either of ScriptedAI, CreatureAI, UnitAI class. If these are needed by Eluna too, it can implement them either by own LUA scripts or at the interface level. Try do not mangle the Creature class as long as it's possible plz :)

PR: [URL="https://github.com/mangoszero/database/pull/206"]database[/URL]. The value 210 is taken from the analogous quest 2501.

The [URL="http://db.vanillagaming.org/?quest=2203"]quest reward[/URL] is the "learn spell" spellcast. The Master Guide does not mention an item too. Completely other question is, how your LW/skinner got the quest, because a skill of 171 (Alchemy) is required to obtain it. I suppose 'twas .quest add, and this command is badly shaped now. As expected, Player::CanAddQuest is the only check, and it checks close to nothing (free slot in quest log and possibility to add SrcItem). Note that the character level/race/prequest requirements are silently ignored too. UPD. Read the template more carefully. The "required skill level" is 0, then "required skill" is ignored. Fixing.

[quote=Olion]Moreover, in two code parts the spell is identified via two different SpellFamilyFlags values, which is not good.[/quote] PR: [URL="https://github.com/mangoszero/server/pull/292"]core[/URL], unified method of the spell recognize. A minor code improvement.

Duplicate, see [URL="https://www.getmangos.eu/issue.php?issueid=805"]this[/URL].

PR: [URL="https://github.com/mangoszero/server/pull/291"]core[/URL]. Implemented now. Here the spell is allowed in a "hacky" way. To solve the probem more accurately, two things are needed: 1) the full answer to [URL="https://www.getmangos.eu/community-input-needed/10265-vanilla-dispel.html"]this[/URL], 2) an analysis of unknown spell flags. The spell has four such flags. The later is achievable much harder, so I'm not ready to promise it. Moreover, in two code parts the spell is identified via two different SpellFamilyFlags values, which is not good. Cast is enabled, but actual dispel effect application should be tested (seemingly ok).

Confirmed. Now the client allows me to look how Deathguard Philip moving on WP kills zombies, for just half an hour. Before this, 2 minutes were enough to get the crash.

Whose scheme is correct? Is the [URL="https://www.youtube.com/watch?v=eDeED3OJ2YU"]confirming video[/URL] really from an offy? Usually, the realm was pointed out for offy videos. Dont see one. What means "Vanilla WoW FTW!" in its comment? Potions will override neither elixir nor flask effect. Just realized that [url]http://www.wowwiki.com/[/url] as a fully functional wiki supports the history of each page, as well as discussion pages. Reading the history is a meditative process, the search through older page versions is not possible. I did not find exactly this information (maybe one has to search it somewhere else under "spell damage cap" topic), but indirect signs are for non-additivity. For instance, [URL="http://www.wowwiki.com/Flask?direction=next&oldid=582574"]the oldest encounter[/URL] of the term "Elixir flasks" refers to the 2.0.12 patch. Should we make it stackable like Fenix?

The cause may be only in different MinLevel for the quests. The three quests (1000,1018,1004) are grouped into ExclusiveGroup 1000, and only 1004 has MinLevel=54, while two others as well as the next 1123 (Rabine Saturna) have 55 here. Then if your char is 54, he may get 1004 but not 1123. Correcting. PR: [URL="https://github.com/mangoszero/database/pull/204"]database[/URL].