Olion

The `GetWorldObject` method must be getting the reference to an existing (closest to the player) gameobject with presented entry (179697). If you get nothing, then there is no such gameobject in (the some default) range. Perhaps you need to create the gameobject. Look for the methods named with Summon or Spawn; I do not know the exact name in Eluna. Upon creation, the core informs all players about the gameobject.

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.

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.

You could prevent entering into a new map (not the first login changing player's Map* from null to something!) to a player in dead state. It is easy enough, just do not forget to handle the ships/zeppelins. Or, disable dungeon portal usage to the dead instead. However, you need to check the dungeon binding mechanic. A player who died in a dungeon, needs a friend to get resurrection. The friend should enter the same dungeon instance. I do not remember if a dead player may invite anyone to the group, allowing access to his dungeon instance that way. Especially, what happens, if the friend is bound to the own instance of the same dungeon map. Perhaps you have to prevent any spirit movement as well, sticking it to the corpse place.

IIRC it is the only way to allow resurrection by other players. Also it is an even better way, but you will need to handle both ones properly. There are lots of situations involving dead and ghosts. For example: logout in dead state. At next logon the spirit is free. Perhaps you manage to create that "corpse with spirit unreleased" thing instead; the same but in dungeon at logon since dungen save expired, so there is no place to create that "corpse with spirit unreleased".

I believe a better way to do this must be implemented at the protocol level. For example, when player hits the "Reclaim Corpse" button, the client sends to the server CMSG_RECLAIM_CORPSE opcode. As defined in Opcodes.cpp, it will be handled in void WorldSession::HandleReclaimCorpseOpcode(WorldPacket& recv_data) To prevent corpse reclaiming, you could just return at the start of that method, preferably since the packet is read. A drawback is that the player will be seeing/getting the menu with that button; the same holds for your proposed method. Perhaps a more subtle and cleaner way would be mangling with the SMSG update object packet sending, but it's much more complicated. Also you need to check any method if it prevents legitimate resurrection by spell. Similarly, at player chat, client sends CMSG_MESSAGECHAT packet handled in WorldSession::HandleMessagechatOpcode(WorldPacket& recv_data). You could implement the chat filtering here by the chat type. See `enum ChatMsg` in SharedDefines.h. Looks like you need to disable many chat types, particularly everything related to the CHANNEL in enum ChatMsg. The spirit healer interaction creates CMSG_SPIRIT_HEALER_ACTIVATE packet, though I'm unsure if there is nothing more to it. For example, WotLK spirit healer pulses (do not requiring player interaction other than getting in range) are handled in a different way. However, it may be easier this time just change the spirit healer NPC unit flags in the world DB (creature_template.UnitFlags, add UNIT_FLAG_NOT_SELECTABLE; do not forget to reset the client cache after this).

Hallo! So ich versuche die Fragen der Reihe nach zu beantworten. Der Ordner serverTwo-build enthielt Zwischendateien der Compiler. Die Dateien beschleunigen nur die weitere Kompilationen. Du kannst die Dateien eliminieren wenn der Server läuft. Die Anleitung sieht gut aus. Die Punktenumerierung unwesentlich ist. MySQL Workbench ist deine Programm um die Tabelle zu ändern. Die Maps und die andere extrahierte Dateien müssen in den Ordner serverTwo_install sein. Das ist in den mangosd.conf festgelegt. Wenn du hast DataDir = "." der File mangosd.exe muß in derselben Ordner mit dbc/, maps/, vmaps/, mmaps/ sein. Wenn DataDir="data" dann mangosd.exe wird in data/maps/ die Maps suchen. Es scheint das Problem hier zu sein. P.S. My German is inactive since long. While reading is acceptable still, writing German takes far too much time from me.

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.

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.

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.