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.

The actual GM levels are assigned to the commands in the DB, see the number in second column of the command table. If there is no entry for particular one, the defaults get into effect. You can find that in the Chat.cpp code. There isn't many people having now a good solid view over the emulator as a whole. Something like documentation at the most can be found here. TrinityCore is the long ago splitted branch of Mangos, and it controls the same client. However difference in the code may be huge. One of the best open source Cata projects, in my opinion, is this, though OvahLord had lost much when started cherry-picking all TrinityCore core commits. Of those, usually about 50% are unuseful and 1-3% are clearly wrong.

I assume that you have good (i.e. not broken) client files. Then you could try to do the extraction under Windows to ensure the file names are case insensitive. The same can be achieved under Linux at a FAT32 filesystem. I had an issue once (with a Camera file though) of capsed/not capsed file name.

One could start such estimation counting instance scripts (script_binding, type=10). Without such a script, proper save of the dungeon state is impossible. It's not critical though for dungeons without boss priority and doors to control. MangosOne has 43 entries, and that is about 10 entries off: in Auchindoun, TK, and elsewhere. The next step of a quick estimation is just the total source code size in a dungeon folder of SD3, divided by the boss number. Then you can expect some disappointment from Sholo, Sunken Temple, DM, ZF, Hyjal and perhaps several others. For example, (IIRC) mine nodes in Hyjal must appear to the raid after completion only; I do not believe that it's implemented (and do not see any implementation at a quick glance). What you can be nearly assured, is that all dungeons are completable. The playing experience is another thing... typical issues: missing atmospheric encounters, textes, visuals (due to missed spells), simplified fight mechanics, missing some boss spells ("not implemented in the core"). All this pertains to the most open source projects.

You won't get here a proper support for this. The usual policy of not supporting repacks comes from that we barely know what's inside of the repack. For example, one can see 6 access ("GM") levels instead of 4 Mangos default ones. And the first question, is the repack based on MangosZero or Cmangos. Anyway, you can get a general idea on the GM command set either typing ".help" ingame, or browsing through this. Adding/removing NPCs is similar for the most emulator flavours, so I believe you're looking for ".npc add"/".npc del" command. Controlling loot tables is, on the contrary, too complicate to be implemented as a GM command. You need to modify SQL tables for that, so I suggest to find a tool (even having a GUI) for the task. And no, I do not know such a tool outside developer scope.

What server version is this about? Warden had been ported into Zero, and lot of the checks is meaningful for Windows client build 5875 only (neither another builds nor the Mac client!). I would expect the described behaviour from the One core.

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 look for a desciption of the source info, from which the map and other files are calculated by the extractors, at the cite https://wowdev.wiki. No one knows, how much accurate is it.

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.

This is not an issue. A citation from my CMakeCache.txt: //Enable remote access via SOAP SOAP:BOOL=OFF By default, SOAP build is turned off. You need to turn it on while running CMake.

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