kebabstorm

Members
 View Profile  See their activity

  • Content Count

    7

  • Joined

  • Last visited

Community Reputation

11 Good

About kebabstorm

  • Rank
    Newbie

Personal Information

  • Specialty
    DBC Editing
    Serverside
    Interface
    Software Development

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. kebabstorm
    Yeah I checked that route, the thing is that many functions call a similar func sub_4D0090 which takes item's displayid as argument (instead of material) so it seems that even the original client does not always use the materialID field, but instead gets the sound to play from the ItemGroupSounds.dbc using the displayID as key. I've properly patched these calls from the root (not the sound func) so that's why the sound works for custom items in some cases, like picking it up from an action bar or guild bank. That also means that Blizz did an oopsie there and it's possible that item could have different sounds moving it around in your bank/bags and moving it on action bars/guild bank, if the sound entry in Material.dbc from the item's materialID is different to the sound id set in ItemGroupSounds.dbc by its' displayID. SndInterfacePlayItemSound(sub_4D0020) and sub_4D0090 both call the sub_4C6A40 func to actually play the sound. The problem is that SndInterfacePlayItemSound takes a object pointer (not database ptr or ID) as an argument, so the material part is missing from the actual pointer. Ofc I could patch some hacky mega-detour @ the SndInterfacePlayItemSound replacing the missing materialID, but that's not how I want to go about doing it. As so far I haven't resorted to any "hacky" improper fixes, but patched every other thing at the root where it's supposed to be patched. That "root" where the material is set to the object pointer would be the right way to do it. I just haven't located it. I've found some functions which I believe to be item constructors and trying change material values there, to no avail. edit: one example for this can be found in CGActionBar__PickupAction (sub_5ABE70) gets the displayID from Item.DBC (or cache, in my patched version) and then calls sub_520D30 with the displayID as an argument which calls sub_4D0090 with the same displayID. Sound is played. for the other, Lua_PickupContainerItem (sub_5D7FF0) which calls GetBagItem(sub_754390) which returns an (unique, meaning literally the instance of that single item) object pointer which is in turn turned to a guid and the guid is passed to SetCursorItem (sub_520770) which turns it to an object pointer again and finally calls SndInterfacePlayItemSound using that pointer. Since the material part is missing from the object instance, sound is not played.
  2. kebabstorm
    I'm using the same old IDB from TOM_RUS which has been floating around for years, where most functions remain unnamed (it's been great help though still, no doubt). I wouldn't know if a more recent one is available somewhere. That could help though. I found a function for "Get MaterialID" which accesses cache first and item.dbc second, at sub_758ED0 , but it's barely used. From that function you can see that the MaterialID is at *p+404 aka [eax+194h] when retrieving from cache (column 102 @ ItemCache.wdb) or *p+16 aka [eax+10h] when retrieving from DBC (column 5 @ Item.Dbc). Detouring the func where the material is actually set to here would be the way to do it, but the problem is finding the place(s), where to detour from. There's a good chance that it doesn't actually call any func to retrieve it but it's inlined somewhere. edit: it's this one: https://mega.co.nz/#!GdoCCSKD!U3BFM2bySKF2lW-X5wz4XQJcZp8aH3YZUTRBpLjQU0Q
  3. kebabstorm
    I still use HIEW for my editing which is (originally) a DOS program from over two decades ago
  4. kebabstorm
    I don't lie, it was a lot of work indeed. I saw the TBC version and thought to myself, oh well, this'll be easy. But the rabbit hole went deep.
  5. kebabstorm
    You are absolutely right, and I plan to eventually clean up my notes (so they make sense to other people than me) and do a proper post-mortem when I have the time and energy for it. The "source" is right now literally those offsets and they can make sense to reverse-engineers who by diffing can look at what has been done but it would definitely help to post all my findings and understanding I made in the process of creating the patch. As it wasn't as easy as simply patching couple of functions like what was done in the TBC version of the patch since 1) Item.dbc of 3.3.5 has 8 fields instead of 3 in 2.4.3 and 2) The paradigm of accessing dbc/cache is different in 3.3.5 and 3) lot of code was inlined by the compiler to not use a function but rather inline parts of the item.dbc and/or cache retrieval functions in-place making it sometimes rather difficult to patch the original functions 4) i had to understand exactly what many functions are looking for / doing to only patch the places where it's supposed to instead of blindly patching everything, to not modify any original functionality or break anything. I also found a problem in the original TBC patch which I posted to reddit about hoping the original dev contacts me so I can explain what's wrong and how to fix it.
  6. kebabstorm
    Thanks @00017144 for posting the offsets in a good, readable form :). I thought of doing that but couldn't be arsed, and on myself I only have my messy notes which are not fit for public consumption. You are of course welcome to patch it by yourself too, but please make 100% sure you are using a clean and unmodified 3.3.5.12340 enUS wow.exe before applying. The patcher takes care of that and will checksum the file before&after to make 100% sure the patch and resulting binary is correct. I also welcome any bug reports and if anyone has the technical experience to help with the last part of fixing the MaterialID to make it 100% can contact me to discuss the technical details on what exactly were done, how and why.
  7. kebabstorm

    Version r001

    408 downloads

    WoW 3.3.5.12340 Patcher This treat is for people who like to make custom items for 3.3.5. So I stumbled upon this reddit thread Reddit - [2.4.3] Patched Executable - Override item.dbc (Question Mark Icon fix) and figured if this was possible for 3.3.5 too. Well, 3.3.5 is quite different and it wasn't as simple as that, but after some tinkering I could made it work. When you patch your wow.exe with this, you don't need to make MPQ patches or edit the item.dbc at all. Just add the custom items you want to the "item_template" table in your SQL database and you're good to go. There are eight fields in Item.dbc: itemID, ItemClass, ItemSubClass, sound_override_subclassid, MaterialID, ItemDisplayInfo, InventorySlotID , SheathID And they all should work with the exception of Material. AFAIK it only affects which sound an item makes when moving it around in your inventory. So currently custom items won't have that sound. If anyone has expertise in reverse-engineering and can help me find the correct spot(s) for it, please PM me. I did some preliminary testing and everything has worked so far. But it still needs some more testing and I think it's 90-95% done. That's why I named it "Custom Item Fix (BETA) v1". I've tested this to work with the latest TrinityCore, but any core which supports custom items should work. If using TrinityCore make sure to set "DBC.EnforceItemAttributes = 0" in your worldserver.conf. If you find any bugs, post them and I will try hunting them down. TL;DR: Item.dbc patching is history Currently supported versions (r001): 3.3.5.12340 enUS Patcher supports Windows XP and newer. Currently it does not check whether you are on a 32-bit (x86) or a 64-bit (x64) system (forgot to do it, will include in r002) so if you are running a very old 32-bit system, do not use the "4GB RAM" patch. On the other hand, everyone on "new" (not from 20 years ago) systems should use "4GB RAM" patch. Patcher expects a clean and unmodified WoW.exe for it to work. This safeguard is in place so it can make sure the patch is applied correctly, as with binary patches it is absolutely necessary to have every byte in the right place to not have undefined behaviour or crashes. If you run into "invalid or corrupt wow.exe" error, it means your exe is modified and you need to use a clean wow.exe. You can find checksums for the unmodified wow binaries here: https://github.com/anzz1/wow-client-checksums The patcher was made mainly for this Custom Item Fix, but I decided to add some other popular patches for a clean all-in-one solution. "4GB RAM" - sets the "Large Address Aware" /LAA flag to allow a 32-bit WoW.exe to use 4GB of RAM instead of 2GB in 64-bit machines (More Info) "Allow Interface Edits" - allows editing interface files like the login screen "Cast Bar Fix" - shows cast bars on default nameplates "Disable Cache" - disables saving WDB cache Thanks: @BenjaminLSR and @rajkosto at the Rochenoire team for the original TBC version of the patch and with it pointing me to the right direction on where to start. Original creators of the "Allow Interface Edits" and "Cast Bar Fix" patches, whoever they are. Github Issue tracker: https://github.com/anzz1/WoWPatcher335/issues