Olion

Namely, this is their solution preventing a crash. Which does not mean that there are no other similar bugs causing crashes.

Probably it would be good to import this change up to One and Two.

This is a DB-based implementation. I was confused about the spell_linked table (whch core does contain it and which one does not), so I had to port it from Zero.

It is not the last crash due to holding Player* in control structures instead of ObjectGuid. This one must be mended by the recipe from the referred topic.

Thank you for the valuable info on spell linking.

However the fix proposed is unacceptable. An obvious reason is sharing issue. If you do need to modify Spell.dbc visible within the server, use SpellMgr::ModDBCSpellAttributes(). This is not the case, the spell_linked table must have the desired effect and deserves to be filled finally.

I wonder what blizz have meant omitting Effect1. I suspect the link between the spells may be more complex, but the presented info gives us a good start.

I consider a "fixing" as "to make things blizzlike". It's more complex to make the mentioned spells exclusive (as they are now) than to make them stackable. But, in this case "blizzlike" means "exclusive since 1.7.0 version", so until we support either 1.12 or a TBC version here, it's all right.

The "bugged server" can support vanilla 1.6 version and be correct in the buff stackability. But if they claim supporting any TBC (2.x), the stackable Sayge's buffs are non-blizzlike (more exactly, antiblizzlike due to our knowledge of desired behaviour) and, in my terminology, bugged.

Quote

Patch 1.7.0 (13-Sep-2005):

Sayge's buffs at the Darkmoon Faire are now exclusive to one another.

Sorry, the screenshot cannot be accepted also, since it is from a buggy private server.

Note also that the spells have attribute SPELL_ATTR_EX6_NOT_IN_RAID_INSTANCE, meaning the buff vanishes while walking a raid instance.

Exactly this bit on CreatureEventAI is shown in the logs (both console and world-server.log) with all default mangosd.conf settings. To get others, I suppose, you need to request more detailed logging in the config.

I tested it on a Win32 clean build with DB set up via InstallDatabases.bat. Just checked that the latest DB updates were installed too.

Quite possible. However, few errors from this list I've randomly looked at, are One DB bugs actually.

Here.

I did not manage to get both DND and Blizz tags (the later has priority), but it is possible that at these ancient times blizz GMs had been never resting .

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?

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.

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.

2 hours ago, bdebaere said:

Flying does not work in Mangos zero (vanilla) as it did not exist then.

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.

8 hours ago, antz said:

@Talendrys - I would go further and say have a dbcOverride table which has the dbc name as one of the fields, that way all overrides are located in a single place.

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