Jump to content

Olion

getMaNGOS Developer
  • Content Count

    519
  • Donations

    0.00 GBP 
  • Joined

  • Days Won

    27

Olion last won the day on January 7 2019

Olion had the most liked content!

Community Reputation

30 Excellent

4 Followers

About Olion

  • Rank
    getMaNGOS Developer

Core Infomation

  • Core
    Zero
    One

Contact Methods

  • Discord
    Olion#5901

Profile Information

  • Gender
    Male

Recent Profile Visitors

1,623 profile views
  1. 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.
  2. 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.
  3. 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).
  4. 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?
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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 items on a long-living realm) we get the 0xFF bitmask and will transfer 9 bytes instead of 8 (non-packed GUID). However in the best case (player GUID under 256), we get bitmask 0x01 and transfer only 2 bytes instead of 8. A packed GUID emerges by the protocol in packets that may contain a player GUID, saving bandwidth for several (zero-valued) bytes.
  11. 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 "broadcasted", i.e. sent to every player participant, and network bandwidth fades quickly.
  12. 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 PacketLogFile in its worldserver.conf and get a binary file. You could parse it into a nice text form with the WowPacketParser utility. The utlity is capable to parse older data as well, for 2.4.3, in case you manage to get the binary packet log. An example sequence of actions at CMSG_PLAYER_LOGIN (i.e. at login by the chosen character) was presented here, once again for 12340 client. I could have misinformed you on the packet sequence as well, since had been referencing WotLK 12340 client. It looks like the login protocol was changed between 8606 and 12340 builds. Taking a 8606 packet log, I see SMSG_ACCOUNT_DATA_TIMES within the large responce sequence on CMSG_PLAYER_LOGIN. Also I see two CMSG_UPDATE_ACCOUNT_DATA without any server responce. So, analyse your own logs please. Good luck!
  13. 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.
  14. You need rather to send the confirmation that the server have handled the update successfully. This is a short responce packet. For 1.12 client, it would be probably the opcode SMSG_UPDATE_ACCOUNT_DATA = 0x20C, while for 2.4.3 it is SMSG_UPDATE_ACCOUNT_DATA_COMPLETE = 0x0463, Just remember this is a dialog, a query - a responce. On the TBC (2.4.3) client, the next packets represent another dialog phrase: CMSG_READY_FOR_ACCOUNT_DATA_TIMES SMSG_ACCOUNT_DATA_TIMES with the only difference that here CMSG is a short query and SMSG is a longer responce.
  15. Blizz have planned to teach a character some spells ingame. They have created the "Learn" counterparts for those spells. The Learn spells have spelleffect SPELL_EFFECT_LEARN_SPELL=36 and the spell id to learn in EffectTriggerSpell; they provide also the well known animation. It is why your spellids did not match. The learning process looks like casting a "learn" spell upon the character. You could find required spells with the SpellWork, for example (note that it needs access to the extracted DBC files, specifically, to the Spell.dbc).

Contact Us

To contact us click here
You can also email us at [email protected]

Privacy Policy | Terms & Conditions

Repositories

The Link to the master list
of MaNGOS repositories:
Copyright © getMaNGOS. All rights Reserved.

This website is in no way associated with or endorsed by Blizzard Entertainment®
×
×
  • 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