Olion

Changed Status to In Progress Changed Assigned to Olion Changed Priority to Low

Indeed. This is because blizz relied on the gameobject casting in this encounter. The 5 spells involved do not complicate it further, so the simplest fix is evident. Just have to invent the Zeppelin Power Core's (shining blue crystals) behaviour based on the quest text.

Changed Status to Duplicate

Changed Status to Awaiting Feedback Changed Implemented Version to 22.1 Changed Milestone to 24 Changed Priority to New / Assign Priority

Could you provide a video to this quest? It involves also Zeppelin Power Core GO (186396), so the question is how many are there such GOs and what they do (spawn/despawn) besides adding the Energized! aura to the nearby players.

Changed Status to Cannot Reproduce Changed Implemented Version to 22.1 Changed Milestone to 24 Changed Priority to New / Assign Priority

One can barely do anything helpful without the stack trace. Also, nobody is able to fix a code without reading it. The fragment cited above does not belong to contemporary Mangos (Zero, One, Two), it is rather a part of the TrinityCore.

Changed Status to Completed

Changed Status to Completed

If you have Git installed, then you have the program able to execute Linux shell scripts. Start Git console, change directory (commands "cd" and "pwd" to check) to your client directory (where wow.exe file resides) and enter "./ExtractResources.sh" without quotes. But yes, this detail must be mentioned in the guide.

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.

Changed Status to Confirmed

Changed Status to In Progress Changed Assigned to Olion Changed Implemented Version to 22.1 Changed Milestone to 24 Changed Priority to New / Assign Priority

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.

Changed Status to Confirmed

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.

Changed Status to Completed Changed Implemented Version to 22.1 Changed Milestone to 24 Changed Priority to Low

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?