Olion

3 hours ago, Tuker said:

we are actually producing a script to have 13 different pools

Why that many?

The idea of a pool is limiting the number of simultaneously spawned objects. If you join all the 100 nodes to a single pool with spawn limit say 30 (see pool_template), then there will be no more than 30 spawns at the given time. "No more" stands here due to the timed respawn control. Reducing pool sizes, you reduce randomness and that is barely the goal. A large pool means that when you gather a node then another one (not being on respawn CD) may appear randomly at any of a lot of spawn places. In general, you will need to travel a longer distance to find it.

The issue of the gatherer addons is that they are unable to provide any info on the pooling. All the nodes are shown at once.

P.S. Pool of pools (see pool_pool) is usually used when a node of different type (copper/tin, or tin/silver, for example) may be spawned at a place. The scheme introduces another issue at underpopulated realms though.

4 hours ago, Tuker said:

what i think is that probably is wrong that at Client Side the message it’s triggered with the opcode SMSG_BUY_ITEM

I'm sure the Blizz had the task of traffic minimizing in mind. At their position, it looked easily: search the traffic log (sniffes, to us) for repeating packet (opcode) patterns and modify the protocol implementation to reduce them.

On the contrary, the core implementation doesn't look very good. Player::StoreNewItem and Player::EquipNewItem both do ItemAddedQuestCheck(...) sending the SMSG_QUESTUPDATE_ADD_ITEM packet. We can either provide the two methods a flag to avoid ItemAddedQuestCheck (the signature change), or inline the corrected code from the methods right into Player::BuyItemFromVendor(...). I like the second option better, while the proper way may be even changing Player::StoreNewItem and Player::EquipNewItem as well as their callers.

Only respective sniffes give a solid ground to modify current protocol. While solution is efficient, it looks wrong at the same time. Try to buy an item with limited vendor quantity, for example the one from Tharynn Bouden (entry 66), and look at the item number present by the vendor.

Perhaps conditionally avoid to send the SMSG_QUESTUPDATE_ADD_ITEM packet after SMSG_BUY_ITEM is the proper way. I have no sniffes as well.

It looks very like to the one described here:

https://github.com/namreeb/nampower

If so, then it is rather a client issue with respective non-core-related solution.

Unfortunately, the proposed way is incorrect. Every NPC is identified by a `guid` field in the DB (GUID = Global Unique ID), renamed to the SpawnId in the current TC. This "DB GUID" may be used in several other DB tables, for example, game_event_creature or creature_linking. Your approach will surely change the NPC DB GUID; even if you delete it first and add it second, you won't get the old DB GUID for it back. Also, NPC removal doesn't care for cleaning up any reference to the NPC in the other tables.

In other words, you destroy much more than you gain.

The `creature` table is not reloadable as well. You have to restart the whole server. It's due to a reason, again. A proper way might be changing the in-memory (i.e. loaded) image of the table along with the respective DB content. It's not so simple because you have to show the change to the every client connected that knows of the changed NPC.

The 2 spells of health and mana restoration are triggerred by 2 spelleffects. Evidently, the later overrides the former one, this way restoring HP aura gets dropped. The false positive check of aura inconsistency is traced to be in

SpellMgr::IsNoStackSpellDueToSpell(

The closest TC equivalent is Aura::CanStackWith(. The lot of exclusions is moved there to the DB (spell_group mechanic), and we find that the Mangos check

    // more generic checks
    if (spellInfo_1->SpellIconID == spellInfo_2->SpellIconID &&
        spellInfo_1->SpellIconID != 0 && spellInfo_2->SpellIconID != 0)

is far outdated and too restrictive. Not that I have an idea of a correct fix beyond porting the whole TC mechanic. However it would be simple to add an exception above (the both SPELLFAMILY_GENERIC and either SpellIconID=1778 or for 2 sets of restoration auras) with the later solution looking a bit cleaner.

The EventAI script of npc 2642 was made as somewhat sophisticated one. However EventType 9 (EVENT_T_RANGE) has no InitialMin/InitialMax parameters, so events 4 and 9 (both with mask 0) casting the spells, happen at once.

Unfortunately, the 6005 build Spell.dbc is clear about this: the poison is applied unconditionally once the food is used. SpellValue 70 pertains only to the 1st effect, that is hp regen. The application is the second effect of the 6410 item spell, and the incore handling looks pretty solid: it is similar to the TC 3.3.5. If the whole spell hits (which is always true), then the 2nd effect is executed unconditionally. Also, the duration of both 6410 and 6411 is the same. If you insist that there must be a chance, then we may face the following: either 1) it was handled by Blizz in a special way, not reflected in the Spell.dbc, or 2) it had been changed during patch progress, but in 6005 got to the present form.

On the other hand, I failed to find a coherent description of the mechanic. Versions vary from "ate like 150 never was poisoned" (Patch 1.9.4) through "i ate 11 looking for poison resist in the combat log, nothing" (Patch 1.8.1) to "got poisoned at 2-4 piece". While "poison at tick" scheme looks the most logical, it may be not the actual case. However I feel able to imagine smth like this: the char gets a "poison proc" aura (like 3616 or 7276) from being victim of a scorpid attack, and the aura procs over that food spell; the aura itself has infinite duration and falls off when the char leaves the zone.

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.

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.

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.