Olion

While knowing nothing on how the EasyBuild works, I would not recommend to use the latest mysql version anyway. Try the proper build (32 or 64 bit) of the later 5.x version instead.

Nice. Why not push the fix of the first spellcast, spell 3237? As to other curses, one has to compare the spell structure. The 3227 spell has target type 6 (designated as TARGET_CHAIN_DAMAGE, but probably being the same TARGET_ENEMY as in 12340 client). So the spell must get an explicit target, i.e. would it be casted by a player, the player needs to select a target unit. Other spells mentioned above have target type combination 22/15 (TARGET_CASTER_COORDINATES/TARGET_ALL_ENEMY_IN_AREA), being essentially selfcasts with an AoE effect. The "self" target type is the one required by these spells.

Changed Status to Cannot Reproduce Just have checked the "Garment of Darkness" on the current DB and core, it's ok. A hindering bug had been introduced into the core Aug 27 and then cleaned up Oct 9. Update your core to the version of Oct 9 or any newer one.

It is a wrong way. Since this applied, you can get the quest credit casting the spell upon self. I've fixed this scripted quest (NPC SD3 script) twice in 3 years. I just wonder, what is broken now again.

Check SMSG_MONSTER_MOVE_TRANSPORT packet implementation. It is not implemented in Zero, which becomes critical in Two. The TC has it since long, though.

LFGDungeons.dbc file marks the dungeon as suitable to the 13-22 levels. And this limit may be actually imposed by the client. While the wowwiki seemingly shows 10+ there, the client is the ultimate source of the information. Changing a DBC file is antiblizzlike, even if we put aside legal issues. Right now I cannot say where the zone enter condition is defined (needs to be found), but it is definitely not the instance_template table. The code cited above is checking that condition. P.S. Level range 13-20 for 8606 client, 15-21 for 12340 client.

Thanks! Just a few minor notes: 1) do not forward port 3443 unless you exactly know what you're doing. This would be a server security break if the RA console were not disabled by default; 2) no need to change BindIP in the config file while it stays at the default value 0.0.0.0, which means, as usually, binding to every system IP found. If, perchance, you found it set to anything different (in particular, 127.0.0.1), then check the same setting in the realmd.conf file also; 3) no need to change default 127.0.0.1 value in the localAddress column of realmlist table, such change may prevent local client access to the server for some firewall settings.

I suspect you have introduced a syntax error into the SharedDefines.h. The header file is included into lot of cpp files, it could generate such amount of compiling errors. Check you modifications thoroughly against usual C++ syntax.

Changed Status to Completed Changed Type to Core

After a while, had to do it myself. https://github.com/mangoszero/server/pull/53

I suppose the spell is due to a mechanic ("periodic haunting") not yet implemented. The creature_template_spells table is just a pitfall to keep unexperienced devs occupied It is consulted only for pets and few other (scripted) mobs, which leaves us with 90-95% of the records being never used. The cast can be done with either type script. The general procedure follows. Look in the creature_ai_scripts with action=11 (cast) and param1=7057. Then, in the DB scripts with command=15 (cast) and datalong=7057. Then, in every cpp file under SD3 directory. However, in our case we see AIName='EventAI' in the creature template, so we are sure where to look, and stop actually after the first search.

I proposed the solution I consider as the correct one in my first post in the topic. Do not touch quest_template except learning what a QC type is required for the quest under discussion. If the QC is described there correctly, add to your EventAI command one more command, ACTION_T_KILLED_MONSTER or ACTION_T_CASTCREATUREGO, depending on the required QC type.

Casting on other creatures was the only pitfall of the present solution I can think of. If it is disabled somewhere (a try to use the item gives an error message), then the proposed fix is ok.

I understood both the issue and your solution. In order to have your understanding of my questions, I repeat it: after your fix applied, have you tried to use the item on any creature/NPC except the quest target dwarf-"survivor"? are you given quest credit for such use, if you have the quest incomplete?

While I do not support anything above MangosOne, I would like to ask still. Haven't you tried to cast the spell (i.e. to use the item) on another mob except the quest target? I do not have Cata Spell.dbc at hand to check, but I'm pretty sure such cast is enabled. If so, you can get QC on any mob, and since it will not despawn, as many QCs as you want. Modifying quest_template should be avoided as much as possible (see WDB field concept on the TC wiki). The correct way is giving the quest credit by the quest target mob before despawned; it is just a single extra line in creature_ai_scripts.

There were no doubts. Now, if you just commit the Player.cpp change since 1) you've tested that and 2) no need to catch the developer who broke the method if he doesn't read the bugtracker. Btw the last fix to the script was mine, two and a half years ago. There was SetPvP() method missing which disallowed player's positive casts on the mobs. The same effect must be achievable with a `creature_template`.`UnitFlags` setting though. Also, OOC health regen is disabled through `creature_template`.`RegenerateStats`.

Alright, let's analyze the log together. We start, for example, from record #4. Spell.cpp:1128 : { ((Creature*)unit)->AI()->SpellHit(m_caster, m_spellInfo); } The SpellHit method appears on the next record, #3, as a deeper one in the calling sequence. npcs_special.cpp:1108 : ((Player*)pCaster)->TalkedToCreature(m_creature->GetEntry(), m_creature->GetObjectGuid()); The next method in the stack trace (from record #2), Log::outString(), is not referenced here. But wait, maybe one of the two RHS methods, GetEntry() or GetObjectGuid(), was compiled inline and calls the log? Look at Object.h: 150 ObjectGuid const& GetObjectGuid() const { return GetGuidValue(OBJECT_FIELD_GUID); } 155 uint32 GetEntry() const { return GetUInt32Value(OBJECT_FIELD_ENTRY); } None of the methods is defined as virtual, they may not be (and actually are not) overridden. Also, these methods are far too popular to have any logging inside. The Player::TalkedToCreature() method is too long to be auto-inlined by any sane compiler (and does not contain logging anyway). The only conclusion left to us, is that some s**t happened at npcs_special.cpp:1108. At this point I cannot help further except by a hint. Do "a fresh clone" only into an empty directory, not forgetting --recursive parameter. P.S. The usual cause of such crash is the difference between std::string and C string. The later is awaited by any C print(). So, to print GUID for example, you need the c_str() conversion: GetGuidStr().c_str();

This is your custom logging in the SD3 script. Just take the original npcs_special.cpp and change only Player.cpp as described above.

SELECT * FROM `gameobject` WHERE `id`=375; There are 10 GOs spawned with respawn time 6 minutes. The quest objective is 10 items (= 10 GO uses), thus we really have insufficient GOs and/or too long respawn time. The decision can be made with a movie about the quest. Extremely simple DB issue.

This refactoring commit was inaccurate and had killed the Player::TalkedToCreature( method giving KC. To fix it, remove this line containing { continue; } which was erroneously left of a removed conditional operator.

https://github.com/mangoszero/server/pull/51 I apologize for the bug I've introduced here about 2 months ago. The slot ID issue is gone with this revert, but quest loot from the original report is to be tested still. It should not be relevant for other cores.

I'm aware of that. You could try to remove the two spell assotiations reported here, from the table, and check all the 3 ranks. Otherwise, you can ignore it safely.

Have you tested it on the latest core?

My bad, really. Thanks for the feedback. Here is the solution: https://github.com/mangosone/server/pull/75 Changed Status to Completed

Those were my commits. I'll check it as soon as possible, but unfortunately it will be possible not before this Sunday. Changed Status to In Progress Changed Assigned to Olion Changed Implemented Version to 22.1 Changed Milestone to 24 Changed Priority to High