Olion

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.

Both [URL="http://db.vanillagaming.org/?quest=33"]Zero[/URL] and [URL="wotlk.openwow.com/?quest=33"]Two[/URL] databases agree with this. So, what is the problem?
SELECT `PrevQuestId` FROM `quest_template` WHERE `entry`=33
> 5261 (Zero DB)
> 0 (Two DB)

So try to push, because I will not.

Yes. The patch below fixes this bug.

You are correct.

[URL="https://github.com/mangosone/server/blob/develop21/src/game/WorldHandlers/SpellAuras.cpp#L6431"]This "ModifyPower"[/URL] should be put under the check if(target->IsInCombat()).

The developers use the latest available version, which is one from the repo branch develop21 now. I switched to the older release20 branch, applied the patch and (after re-creating VS project files with cmake, what is my usual procedure) got the sources compiled cleanly.

It means that you failed to apply the patch somehow. Reset your sources with "git checkout -f" and try again "git apply" ensuring there was no error on each step. Note that the patch does not require any change of the VS project, so if you use pre-built slns, they are ok still.

I realize that it would be much more comfortable to get changes from the repo with "git pull", but the PRs [URL="https://github.com/mangoszero/server/pulls"]are not being merged for months[/URL], and we can do nothing about it.

Use the patch provided.

It accounts for a possibility of missing characters rolling for an item, on the instance map with the mob corpse. These characters will not get the rolled loot, though a roll is done for them and the group is informed about it. If such behaviour looks undesirable, the roll for such characters may be suppressed resulting in just a minor code complication.

More specifically,
a player opens a group loot and roll begins; he votes for rolled item (either need or greed); no others votes for the item (cannot say is this required); he leaves the instance (by heartstone so on) appearing on another map; when the roll expired, the core crashes. See Group.cpp:1120-1121. The cause is evident.

Unfortunately, this copypaste from TC will not compile in Zero due to missing SpellInfo class.

The problem of the casting mode for such spells, either player->player or questender->player, looks permanent :) The correct solution seems to use both modes depending on conditions. The above patch provides an incomplete list of the conditions.

In general, the questender->player mode seems to be the reasonable one, except the spells which cannot be casted in this mode. Most of later spells have TARGET_SELF=1 (we don't need usually the questender to cast the reward spell on itself, do we?). After a brief look on the spells actually used for RewSpell, we've to add the spells either with TARGET_NONE=0 (the core interprets it as TARGET_SELF) or with SPELL_EFFECT_LEARN_SPELL=36, SPELL_EFFECT_TRADE_SKILL=47. The difference between these two solutions on the actual DB arises just for dummy auras 23356,23357. Checking if the core allows .cast back the auras from mob to player will solve the dilemma: if yes, then 2nd way (check spell effects); else 1st way (check TARGET_NONE=0 for non-empty spell effects).

Again, due to missing SpellInfo class, a special method has to be created to check the mentioned conditions correctly basing on SpellEntry entity.

Now in Zero warden, the main problem is that the (client) signatures are present for 5875 version, and some of these will fail for 6005 version. At least, it is the 634 check. Until multi-client support implemented, the check is better to be removed. The question is, should we do it globally in develop21 branch; I suggest no.

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

Nothing unpredictable; some TODOs are such that better be done :)

CreatureAI::Reset() is called now right after AI construction also (in addition to default evade and respawn). Also, a minor correction introduced to the AT 522 "at_twiggy_flathead" script.

Hm, I did not imagine that it will raise so fast. I suspect this is due to a detail I intended to fix sometime later :)
Trying right now instead...

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