Jump to content

Olion

Members
  • Content Count

    532
  • Joined

  • Last visited

  • Days Won

    29
  • Donations

    0.00 GBP 

Everything posted by Olion

  1. 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.
  2. 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 issu
  3. 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::BuyItemF
  4. 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.
  5. 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.
  6. 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.
  7. 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 i
  8. 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.
  9. 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".
  10. 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
  11. 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 Ord
  12. The core mimics the official version, where players needed to buy the expansion update in order to get into the new maps or use the new class. It does this by using account.expansion field, which must be set to 2 to allow the WotLK map access to the account. Usually, you set this field to 2 by default in a PHP account registering script.
  13. So just a few ideas... Testing the check, I would load an addon and compose checks for its strings, begining with the name, something it says to the player when loaded, and up to anything it reports to the player's chat. Considering reference to the FrameScript::GetText client function (and hoping we got the offset correctly), it probably checks addon output strings. Also, the "failure" of the check may be the desired result, while "ok" may mean "the string is found". Once again, ensure that your client is of 5875 build. The in-core warden isn't ready for any other version for now.
  14. 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
  15. Well, FYI the present code was ported from the TC one. The TC table contains no entries for this type of check, and probably for a reason. I suspect this check type to be usable for addon activity. Yeah, there is the way to ban an addon through respective DB table. This check must be for monitoring some addons that aren't banned (yet).
  16. I remember that check type working in TC 3.3.5 well with the same warden module and the same core code. Unsure if it was tested fully here. Perhaps you need to use uppercase letters for the module name in the DB. Also, is your client of 5875 build, just in case?
  17. 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
  18. 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.
  19. 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,
  20. It's funny that the code above outputs actually a packed GUID (without any compaction for zero bytes, thus the bitmask is 0xFF). So it's ok when filling a packed GUID field in a packet.
  21. I do not check top of the header (it can be done using the sources), but should note that a packed GUID has variative length. In your post, the whole structure uint8 packedGUIDMask # for example, 0xFF uint64 packedGUID is termed as "packed GUID". It contains a number of bytes (1 to 8) for uint64. The number is equal to the number of non-zero bits in the bitmask packedGUIDMask, thus the length of the filed is well defined.
  22. You could find the method converting 64-bit (GUID) data to a packed GUID here. BTW, 1.12 client does not use this, which was/is a usual compatibility issue while backporting handlers to it. A brief explanation. A GUID is 8-byte long; consider is as a byte array A where A[0] is the lowest GUID byte, ..., A[7] is the highest one. Create a side byte (the bitmask) this way: if A[i] is nonzero then i-th bit is 1, else the bit is 0. Then we can omit zero-valued elements of A from transfer (a packet), and transfer the bitmask following non-zero elements of A only. In the worst case (like
  23. AFAIK the only difference between these two is the size. The compressed update may contain (and does, actually) updates for several objects at once. IIRC the compression is made simply by gzipping the packet data. Unsure if usual update SMSG_UPDATE_OBJECT may contain several updates at once, but perhaps it may as well. However I'm certain that these packets are fully interchangeable, i.e. equivalent. A compressed update becomes critical when you get an event-reach world around your character. It may be raiding a boss, a BG, just a capital with 200+ players so on. The updates are "broadcas
  24. I apologize for the wrong opcode referencing. The following is correct for 3.3.5a (12340 build) client: SMSG_UPDATE_ACCOUNT_DATA_COMPLETE = 0x0463, while for older ones, perhaps including 8606 build, the older SMSG_UPDATE_ACCOUNT_DATA = 0x20C must be valid. To avoid such confusions, you better create the needed dumps for the proper version yourselves. Run a Mangos server wih set up WorldLogFile parameter in the mangosd.conf. The log file will contain the communication sequence with symbolic opcodes and unparsed other packet data. If you use the TC for that, you set up PacketLogFi
  25. Check your content of the `realmlist` table in the `realmd` DB. The `realmlist`.`address` string field is used to tell the non-local clients on what host to look for the mangosd server (aka realm server). It might be either a full DNS hostname resolvable at your friends computers, or an IP (specifically, IPv4?) address accessible to them. It looks like your table contains the string 555.555.555.555 here, which is not satisfactory.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use