Olion

This is the only way to implement the mechanic without spell_linked_spell DB table. However it is wrong in details, and additional info is needed. Warrior's Devastate has 3 ranks, Sunder Armor - 6 ranks (looks like that 5 legitimate ones only, the 6th is for TBC). The proposed code casts Sunder Armor 5 irrespectively of Devastate rank. So, will it be correct to use the highest Sunder Armor known to the character? how the underranking situation must be handled, i.e. when a character knowing all 3 Devastate ranks and 5 S.A. ranks, uses Devastate 1?

Well, once again. I tested it yesterday on the current core/DB (Win32 build) with Rank 1 Drain Soul, char 10 lev, mob 5 lev. It worked. I've responded in another, now removed, bugreport topic, and asked to be more specific. @madmax, would you?

The lower 32-bit part of SpellFamilyMask of affecting (spellmod) auras is contained in the Spell.dbc, while the higher 32-bit part is not. The spell override table looks usually untractable even with its own structure and no additions. But in principle, yes, info from this table can be transferred to spell override: it is an addition to the spell definition. The same applies to the spell_threat, spell_target_position and few other present spell-related tables also.

The SpellFamilyName along with SpellFamilyMask are used to define the classes of spells, avoiding enumeration of all ranks, like it was done at the end of this commit. In the Spell.dbc, EffectItemType is 32-bit field, while SpellFamilyMask is kept in two 32-bit fields. Of total 1309 vanilla SpellEffects applying SpellMod auras (which corresponds to slightly less than 1309 spells), only 225 have no EffectItemType data. This table is needed when either the data is missing, or the higher 4 bytes of it are required to define the SpellFamilyMask. So, it must be not much of missing data in the table.

Their movement system looks here and there more elaborated than Zero's one. Their WorldSession::HandleMovementOpcodes is in general similar to ours save anticheat lines. But there might be changes substantial to this "fly" elsewhere, for example, in WorldSession::HandleMoverRelocation. Someone willing to port it could have this issue in mind. Personally to me, a plain porting of definitely non-blizzlike scheme seems both boring and inefficient, so sorry.

Description start_time length guid event Entry Name Fishing Extravaganza Announce 2006-01-02 07:00:00 240 54742 14 15116 Grinkle Fishing Extravaganza 2006-01-01 13:00:00 120 54687 15 15078 Jang Fishing Extravaganza 2006-01-01 13:00:00 120 54688 15 15079 Fishbot 5000 Fishing Extravaganza Turn-in 2006-01-04 16:00:00 180 105970 34 15077 Riggle Bassbait Most of the issues are shown here. Start time needs adjusting for 14 and 34 events. Using info about what events are related to each mob appearance, correct spawning. Game event system does not support appearing a NPC GUID for more than 1 event, this is usually solved by spawning another copy(-ies) of the mob. NPC 15007 must repeat the event announce during events 14 and 15, maybe with different frequency. For this, SD3 has no alternative since conditions are bound neither to DB scripts nor to EventAI. Not shown here, the quest may be given during events 14, 15 and taken during 34 (and 15?). Looks like another task for SD3.

It's a quite popular opinion. It even looks true because on TBC/WotLK with "official" flying, there was no one in pre-TBC zones. But, do you really think the blizz GMs had been walking? Or, they used a special non-public client build with additional features enabled? The fact is that the client handles somehow many packets marked in Opcodes.h as CHEAT (like MSG_MOVE_TELEPORT_CHEAT, MSG_MOVE_TOGGLE_COLLISION_CHEAT, MSG_MOVE_TOGGLE_GRAVITY_CHEAT, SMSG_GODMODE so on). The second fact is that the movement system of the MangosZero does not believe in any flight possibility, having also a lot of undescribed MoveFlag's. I was told about implementations of such flying, smth on the swim flag; I doubt strongly that they are blizzlike in the terms of packet sequence. Despite of this knowledge, I'm unable to implement the mechanic now. So, the answer above will hold until someone more knowledgeable disproves it.

It would be really messy. Even the TC uses (as far as I'm aware) separate tables for each DBC which requires a lot of on-the-fly modifications. Though I do not like the way they've reimplemented the scheme. Our task looks much simpler: for given DBC file (i.e. table), invent a scheme allowing a clear and efficient extension to later versions of the same DBC file. Unfortunately this does not mean that I have an idea for such an implementation. As to the issue. I recall (wrongly?) that the mounts should be available in the AQ instance, which means indoors on just a single map.

https://github.com/mangoszero/server/pull/24 (commits 2+3) I wonder why the details of the packet structure, requiring just a basic rev.eng. skill, are covered still. All other infrastructure (including DB data) was ready. The next issue will be here a strange (hardcoded) honor reward for the Leader kill.

https://github.com/mangoszero/server/pull/24 (commit 1) Tested on 719 and 1250 quests (client 5875 build), looks ok.

Sorry but this is not a bugreport. One must have a predefined form. I have no luck to reproduce the issue: entry 10200 guid 51892 gives Cat pet entry 10077 guid 134381 gives Wolf pet entry 14476 guid 51857 gives Scorpid pet Checked at [URL="https://github.com/mangoszero/server/tree/70592294b793319c112e083a126351b34d390163"]7059229[/URL], Win32 debug build. Well, other beatiful things are present. Like learning about "Creature is not tameable" only at the finish of the Tame Beast channel.

The good-style core support was [URL="https://github.com/mangoszero/server/commit/2a71b6a08901f927f2699436f415df33bd7e3fc5"]done[/URL] by @H0zen. [URL="https://github.com/mangoszero/database/pull/46"]Introducing[/URL] the DB change mentioned above. Missing lightning animation is related iirc to the spawn delay of the trigger being targeted by the spell.

It looks like the bug was introduced by [URL="https://github.com/mangoszero/server/commit/e16313c5b2617b364224b1fb82e5399cb32c0af1#diff-455b2dabe05641574822077561cec24e"]this commit[/URL] and empowered by [URL="https://github.com/mangoszero/server/commit/8261268c69c598b189d866310f35cb967ee41f64"]this one[/URL]. The new overriding spell is set correctly and client is informed about it, but then [FONT=Courier New]Player::addSpell([/FONT] for an unclear reason terminates prematurely [URL="https://github.com/mangoszero/server/blob/develop21/src/game/Object/Player.cpp#L2972"]here[/URL] signaling that the spell cannot be learned. In between, the skill is set/corrected in the method [URL="https://github.com/mangoszero/server/blob/develop21/src/game/Object/Player.cpp#L3011"]below that return[/URL]. I see the following options: 1) make use of EFFECT_0 of the learned riding spell (which is dummy effect) in a simple spellscript setting the skill value. It looks like there are 8 of such spells; 2) correct the added code in order to soften the condition for premature termination of [FONT=Courier New]Player::addSpell([/FONT]. btw the code does not look good having large replicated parts. I would prefer the 2nd option, but for that we better ask [URL="https://www.getmangos.eu/members/h0zen/"]the patch author[/URL].

Was merged [URL="https://github.com/mangoszero/server/commit/504a7c3b88d943a03ed80701059aaab93f84cb1d"]here[/URL].

Fixed [URL="https://github.com/mangoszero/server/commit/2aa0003d4278b92bb21916dd96830b8fb1a0f426"]here[/URL], finally.

After a cleanup, [URL="https://github.com/mangoszero/server/pull/82"]PRed[/URL].

Was fixed by [URL="https://github.com/mangoszero/server/commit/2000c8aa91c3ee23b1358861919a424ac2995a4c"]this[/URL] in the develop21 branch.

You did miss a point in the algorithm above. [quote=Olion]3) go away from the instance entrance;[/quote] Anyway, these both are due to a single implementation bug, namely a jammed delayed teleport. @H0zen has fixed it [URL="https://github.com/mangoszero/server/pulls"]here[/URL].

However, this mechanic does not explain a weird implementation bug with double call to Player::TeleportTo() due to delayed teleporting. For this particular instance, several entry ATs are defined. The 1st call returns OK for level 29, but the 2nd call finds an unpredictable AT from the fourth ones, depending on the DB entries order. The bug has the most beatiful look in such case: 1) as a non-GM 29 lvl character, try to enter the enabled - left for 29 lvl - teleport; 2) get "Required level 35" error; 3) go away from the instance entrance; 4) .gm on will now teleport you into the instance.

SELECT id,`name`,required_level FROM areatrigger_teleport WHERE target_map=189; 45,Scarlet Monastery - Graveyard (Entrance),29 610,Scarlet Monastery - Cathedral (Entrance),35 612,Scarlet Monastery - Armory (Entrance),33 614,Scarlet Monastery - Library (Entrance),31 Well, some idea is seen here, but I cannot say, is it wrong.

[quote=MrFreak]This is unique because it is calculated as id + delay which gives you a composite key between them. Delay field is responsible for the sequential execution of them.[/quote] Not that exactly. The world table structure is more or less reasonable and elaborated. If you do not see the key composed of the two fields, then it's not a key. Nothing prevents us to define several script commands with the same delay, i.e. executed at the same moment of time. The execution order remains undefined though. The dbscript_on_* tables should be moved as a whole to the same trash bin as EventAI engine, being substituted by something like TC's SmartAI. However, even TC's SmartAI has yet no full support for this (for instance, spell events not related to gameobjects, so the SmartAI cannot substitute dbscripts_on_event).

Thank you. I was too glad for the SPELL_ATTR_HEARTBEAT_RESIST_CHECK spell attribute found recently by the TC team, and switched off involved unit type checks. It turns to be an error. Since I introduced this bug, [URL="https://github.com/mangoszero/server/pull/35"]here[/URL] is the correcting PR. P.S. However, the PvE heartbeat resist is a topic requiring research. AFAIK there exists some.

Two other issues are difficult. The q:9759 Ending Their World should be scripted (luckily, TC 3.3.5 has the [FONT=Courier New]npc_demolitionist_legoso[/FONT] script which can be adopted). The q:9740 The Sun Gate needs server-side definition of the spell 38096, and for this mechanic Two core is not ready yet; so, for now, it also must be scripted.

The simplest case is q:9579 Galaen's Fate. The quest item drops from the [URL="http://www.wowhead.com/npc=17606/sunhawk-reclaimer#drops:mode=:50-18+1"]mobs[/URL] with 4% chance. Wowhead indicates 5%, but there is no way to say does it pertain to the WotLK (also the wowhead data for quest item drop are wrong oftenly because the statistics was taken for players with and without the quest). For these values, to have the amulet with 80% chance you must kill 40 and 31 mobs, correspondingly. But, only 26 mobs are spawned once. More reasonable values look like 10-20% (15 to 8 mobs for 80%). To change the drop chance, for example, to 10%, execute the following on your `world` database: UPDATE `creature_loot_template` SET `ChanceOrQuestChance`=-10 WHERE `entry`=17606 AND `item`=23873;

It is due to [URL="https://www.getmangos.eu/issue.php?issueid=424"]implementation of Heartbeat Resist[/URL]. So, Polymorph fades off usually between 20th and 30th seconds, and sometimes faster. It was said it's blizzlike for Zero only. A better formula to determine the timings is welcome.