The **Proper** Way to Remove Flags from Items

ChthonChthon Posts: 1,855
edited November 2012 in General Modding
This post is a byproduct of my attempts to write an infinite external stash program.

The methods for removing the "cheat flag" from items outlined in existing posts are not exactly correct. They lead to files that are not in proper form, even though TL2 (or at least the current patch of TL2) is robust enough to read past the errors; and they leave files that are distinguishable from an ordinary drop given close inspection. Since some of you all are going to keep on deflagging items no matter what anyone says, and since I'd rather that people didn't go around producing (and possibly sharing/trading) malformed item data that may break in a future patch, I'm going to spell out the proper way to remove the "cheat flag" from an item so that you can do it right.

We're going to do this on the shared stash, since it's a **** of a lot easier to parse manually than the character saves.
  • Step 0: Back up your stash file in case you mess up.
  • Step 1: Use the decrypter to decrypt your stash file. Then fire up your hex editor.
    The overall structure of the stash file is as follows:
    • version number - int (4 bytes) - better be 0x42 or this guide may be outdated.
    • 0x01 - 1 byte - the mystery byte
    • checksum - int (4 bytes) - the decrypter will have changed this to 0. You don't have to worry about this because the decrypter will fix it when you encrypt at the end.
    • number of items in stash - int (4 bytes)
    • items - variable lengths, stacked end to end
    • file length - int (4 bytes) - You don't have to worry about this because the decrypter will fix it when you encrypt at the end.
  • Step 2: Find the item you want to deflag.
    Just scan manually or do a search for it's unicode name string. Shouldn't be hard to find.
  • Step 3: Update the bytecount
    The relevant parts of the structure of the item are as follows:
    • bytecount - int (4 bytes) - specifies the number of bytes in the item (excluding the 4-byte length of the count itself)
    • 0x00 - 1 byte - mystery byte
    • item base type GUID - 8 bytes - tells TL2 what the base type for the item is. Not important for removing the flag; just interesting to know.
    • item name - 2+(2*char_no)bytes - this should be the unicode string [format is: short (2bytes) number of characters, followed by a string of 2-byte characters] that you recognized as your target item's name.
    You should be able to find the bytecount fairly easily be reading backwards from the name.
    Subtract 45 (decimal) from the byte count.
  • Step 4: Update the magic mod counter for the first mod group.
    The relevant parts of the structure of the item are as follows:
    • Shortly after the name, there is a block of 24 0xFF's. You can't miss it.
    • Then there is some stuff. This will be 139 bytes long, unless there are things in this item's sockets.
      {If there's something in a socket, the *ENTIRE* socketable item is inserted into this block between the 123rd and 124th bytes, so you will have to skip over these "items within an item." (Hint: each socketable should be obvious because of its name string and will include exactly one block of 24 0xFF's and one block of 12 0xFF's, so you can be sure that the next block of 12 0xFF's is the one that belongs to the item proper.) (*To be precise, the entire socketable beginning from the 0x00 before the GUID is inserted. There's no bytecount, which really **** for programmatic parsing.)}
      There's lots of cool stuff in here, but none of it is relevant to deflagging.
    • A block of 12 0xFF's. Again, can't miss it. [edit: Bad news - There is at least 1 item (Vyrax's Heartfire) where this block is NOT 12 0xFF's. The total length is the same, but the contents are different. Major PITA for programmatic parsing.]
    • Number of 12-byte thingies - short (2 bytes) - usually zero. If it's not, advance forward by 12 bytes times the number here.
    • magic mod counter for the first mod group - int (4 bytes) - specifies how many magic mods are in this item's first mod group. (Hint: You can double check that you're in the right place if the next for bytes are an int - 0x41 81 00 00 (LE) and 0x41 80 00 00 (LE) are extremely common.)
    Subtract 1 from the magic mod counter for the first mod group.
  • Step 5: Delete the flag.
    Scan forward for this 45-byte string: 48 80 00 00 00 00 01 00 00 80 BF 00 00 EE 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 7A C4 00 00 00 00 00 00 80 BF 00 00 00 00
    Delete it.
  • Step 6: Save your changes in your hex editor. Use the decrypter to encrypt the stash file again. Load TL2 to see if it worked.
Torchlight 2 Rapid Respec - Putting the "hack" in "hack-n-slash"
StashNinja - INFINITE Stash for Torchlight 2
NullMod - Play together in the same multiplayer game with different mods!

Comments

  • The methods for removing the "cheat flag" from items outlined in existing posts are not exactly correct. They lead to files that are not in proper form, even though TL2 (or at least the current patch of TL2) is robust enough to read past the errors;

    The method I outlined does in fact leave files in proper form. The only thing being changed is the Item Effect. The only impact this would possibly have in future patches would be if they decided to add a new enchant to the game which overwrote the blank enchant. This would not break anything. It would just result in the item having that new enchant.

    I agree your way would be the most "correct" way resulting in file that would be closer to one that the game would generate, but my way is easier for inexperienced people to understand which is why I posted it that way. It is in no way "incorrect" its just a different approach.

    Thanks for your post though, it is good for people to know.
  • ChthonChthon Posts: 1,855
    mrboggles wrote:
    The methods for removing the "cheat flag" from items outlined in existing posts are not exactly correct. They lead to files that are not in proper form, even though TL2 (or at least the current patch of TL2) is robust enough to read past the errors;

    The method I outlined does in fact leave files in proper form. The only thing being changed is the Item Effect. The only impact this would possibly have in future patches would be if they decided to add a new enchant to the game which overwrote the blank enchant. This would not break anything. It would just result in the item having that new enchant.

    I agree your way would be the most "correct" way resulting in file that would be closer to one that the game would generate, but my way is easier for inexperienced people to understand which is why I posted it that way. It is in no way "incorrect" its just a different approach.

    Thanks for your post though, it is good for people to know.

    I don't have complete faith that 0x09 is defined anywhere as "blank." For all we know, Ogre/TL2 goes right ahead and tries to dereference some non-existent thing pointed to by 9, and trying to dereference that throws an exception that Orge/TL2 has to deal with (and fortunately does, in this patch) or, even worse, ends up reading an arbitrary memory address and fails to blow up only because you get lucky that wherever it's pointing has already been initialized to a value that's a valid input for whatever function is doing the dereference.

    Also, assuming that 0x09 is really defined as "blank," you're left with an item that's got this non-naturally-occurring mod. And it's not a purely "blank" mod either. No other mods appear to use the leading int 0x48 80 00 00. What it looks like is happening is that the "display cheat flag" function is still getting called, but you're feeding it a bad a parameter so it never finishes its job. There's at least 3 ways this isn't future-proof: (1) Anyone who looks at the item in a hex editor can see that the modified cheat flag is still there. [disclaimer: You don't need to trade, because you can spawn items. And I don't advise trading spawned-then-unflagged items, because the other person might care about it. But, if you're going to do it, you should at least show the courtesy of completely unflagging the item so they never have to deal with the fallout of discovering it was a spawned item.) (2) Since the "display cheat flag" is still getting called, who knows how Runic might unintentionally (or intentionally) change that function in future patches? It may end up doing something undesirable before conking out on the bad parameter you're feeding it. (3) Runic could always just change the detection to look for the modified cheat flag. [Not that I think they're going to. I think the cheat flags were always intended as an expedient to placate the whiny closed server crowd rather than a serious feature. In any event, I'm sure that Runic recognizes that pre-GUTS modding provides such an easy end-run around the cheat flag that enhancing the cheat flag detection would be like polishing the brass on the Titanic.]

    Anywho, bottom line is that I don't recommend just swapping 0xEE for 0x09. However, that is still better than some of the other methods posted that involve just zero-writing or deleting the string, usually with the wrong length.

    ---

    As for "doing it right is too hard": If this is too hard for someone, that person probably shouldn't be mucking around in their save files to begin with. When I've got the infinite stash up and running, it will probably include a deflag feature. People who can't do it right can always wait for that.

    ---

    Bottom, bottom line: It's your file. Do as you like. (Just don't do it wrong and then give/trade the item to someone else.)
    Torchlight 2 Rapid Respec - Putting the "hack" in "hack-n-slash"
    StashNinja - INFINITE Stash for Torchlight 2
    NullMod - Play together in the same multiplayer game with different mods!
  • Also, assuming that 0x09 is really defined as "blank," you're left with an item that's got this non-naturally-occurring mod. And it's not a purely "blank" mod either. No other mods appear to use the leading int 0x48 80 00 00. What it looks like is happening is that the "display cheat flag" function is still getting called, but you're feeding it a bad a parameter so it never finishes its job. There's at least 3 ways this isn't future-proof: (1) Anyone who looks at the item in a hex editor can see that the modified cheat flag is still there. [disclaimer: You don't need to trade, because you can spawn items. And I don't advise trading spawned-then-unflagged items, because the other person might care about it. But, if you're going to do it, you should at least show the courtesy of completely unflagging the item so they never have to deal with the fallout of discovering it was a spawned item.) (2) Since the "display cheat flag" is still getting called, who knows how Runic might unintentionally (or intentionally) change that function in future patches? It may end up doing something undesirable before conking out on the bad parameter you're feeding it.

    After I wrote my reply, I thought about it and realized that there is one flaw with what I posted. The parameter values in the cheat flag are -1. So essentially, IF 0x09 was not a blank enchant and did point to some value, that could possibly be modified. A work around is to change the -1 ( BF800000 ) to 0 (00000000). This way no data will be modified.

    As for the 0x48 80 00 00 this is NOT just associated with the cheat flag. It is used for the 'simple' enchants such as the cheat flag and the various types of armor (fire,poison,ice,electric). So there is no worry of the game'calling the cheat flag routine with a 'bad parameter.'

    The more complicated enchants, are the ones that require spell names and these generally use 0x41 85 00 00 (something like that, I can't confirm because I am on my laptop).
  • ChthonChthon Posts: 1,855
    mrboggles wrote:

    After I wrote my reply, I thought about it and realized that there is one flaw with what I posted. The parameter values in the cheat flag are -1. So essentially, IF 0x09 was not a blank enchant and did point to some value, that could possibly be modified. A work around is to change the -1 ( BF800000 ) to 0 (00000000). This way no data will be modified.

    I don't see any reason to assume this is true.
    As for the 0x48 80 00 00 this is NOT just associated with the cheat flag. It is used for the 'simple' enchants such as the cheat flag and the various types of armor (fire,poison,ice,electric). So there is no worry of the game'calling the cheat flag routine with a 'bad parameter.'

    Perhaps it's just that none of the items in my stash happen to have one of these "simple enchants," but the ONLY occurrences of 0x48 80 anywhere in my stash file are the cheated items I created for testing. Can you show me an example of a magic mod that starts with 0x48 80 that's not the cheat flag?

    Ultimately, I don't see the point in relying on guesswork to make a dud modifier that won't crash the function that's reading it or confuse it about the offset to the next modifier or won't work with a future patch when you can just delete the **** thing, fix the modifier counter, and fix the byte count.
    Torchlight 2 Rapid Respec - Putting the "hack" in "hack-n-slash"
    StashNinja - INFINITE Stash for Torchlight 2
    NullMod - Play together in the same multiplayer game with different mods!
  • I don't see any reason to assume this is true.

    Well since each Effect ID operates on a different stat we know that the function which changes the stat must be something like:

    mov eax, value
    Add dword ptr [effect_id_ptr], eax

    Since the stat can be modified in positive or negative ways depending on the value of the float used. (Adding negative numbers to it reduces it) So the game reads the enchant flag ie. vitality which is 02, then finds the pointer to vitality and adds the value to it. So therefore for if value is 0, there is no modification.
    Perhaps it's just that none of the items in my stash happen to have one of these "simple enchants," but the ONLY occurrences of 0x48 80 anywhere in my stash file are the cheated items I created for testing. Can you show me an example of a magic mod that starts with 0x48 80 that's not the cheat flag?

    I was mistaken here, the armor values aren't associated with 48 80 but 4A 80. However using 48 80 in place of it does not affect the game. The cheat flag enchant and the armor flag enchants have the same structure so of course it should work. I have noticed however that these values seem to 'describe' the enchant that follows. It has to do with the number of parameters the enchant should have and whether or not it has a string (spell name) in it. If you look into it, you can see that you can change the text color of an enchant from light blue (associated with the enchanter) to dark blue (stock enchant). Also if you don't use the right flag the game will crash. This is why I am assuming the game determines the number of parameters from this flag.
  • ChthonChthon Posts: 1,855
    mrboggles wrote:
    I don't see any reason to assume this is true.

    Well since each Effect ID operates on a different stat we know that the function which changes the stat must be something like:

    mov eax, value
    Add dword ptr [effect_id_ptr], eax

    Since the stat can be modified in positive or negative ways depending on the value of the float used. (Adding negative numbers to it reduces it) So the game reads the enchant flag ie. vitality which is 02, then finds the pointer to vitality and adds the value to it. So therefore for if value is 0, there is no modification.

    I have no reason to believe this is true either. See below.
    I was mistaken here, the armor values aren't associated with 48 80 but 4A 80. However using 48 80 in place of it does not affect the game. The cheat flag enchant and the armor flag enchants have the same structure so of course it should work. I have noticed however that these values seem to 'describe' the enchant that follows. It has to do with the number of parameters the enchant should have and whether or not it has a string (spell name) in it. If you look into it, you can see that you can change the text color of an enchant from light blue (associated with the enchanter) to dark blue (stock enchant). Also if you don't use the right flag the game will crash. This is why I am assuming the game determines the number of parameters from this flag.

    Yes. That value right there is the start of the modifier. It specifies the type of modifier. It's usually 0x41 81 00 00 or 0x41 80 00 00, but there's a bunch of others too. After reading that int, the function is going to branch. We know it branches because the structures of the different types are different, sometimes very different. (To see how different, take a look at a 0x41 A1 02 00 mod.) Since the only place we've ever seen the 0x48 80 00 00 type is on the cheat flag, we've never been down that branch under any other context, so it's really just speculation what exactly that branch does. Is this a special function for "display cheat flag mod" or a generic function for "display red text mod"? If it's a special function for "display cheat flag mod," does it perform any intermediate steps before reading onwards to the parameter you changed from 0xEE 00 00 00 to 0x90 00 00 00? (And if it does, does it do anything we care about? Or will it do so in the next patch?) It's also guesswork to say that this branch treats the first float the same way another branch treats the first float because the data they parse has parallel structures.

    All of your guesswork could be right. It could be. It could also be wrong. My larger point is that there's no reason to take a chance on guesswork when there's a surefire way to do it.
    Torchlight 2 Rapid Respec - Putting the "hack" in "hack-n-slash"
    StashNinja - INFINITE Stash for Torchlight 2
    NullMod - Play together in the same multiplayer game with different mods!
  • Agreed :) I enjoyed our little back and fourth, you've made some good points. Thanks for keeping it mature, I know a lot of people would have gotten defensive. Keep up the good work!

    Mrboggles
  • ChthonChthon Posts: 1,855
    mrboggles wrote:
    Agreed :) I enjoyed our little back and fourth, you've made some good points. Thanks for keeping it mature, I know a lot of people would have gotten defensive. Keep up the good work!

    Mrboggles

    Indeed. I find that people who can code are more likely than average to be logical thinkers who are more open to considering evidence and reasoning.

    (Also, I'd say I'm >=85% sure your method works fine (except for being detectable after the fact in hex editor) and will always work fine. I'd just rather be 100% sure.)
    Torchlight 2 Rapid Respec - Putting the "hack" in "hack-n-slash"
    StashNinja - INFINITE Stash for Torchlight 2
    NullMod - Play together in the same multiplayer game with different mods!
  • (Also, I'd say I'm >=85% sure your method works fine (except for being detectable after the fact in hex editor) and will always work fine. I'd just rather be 100% sure.)

    That sounds reasonable, I've updated my post to redirect to yours since I don't seem to be able to delete it.
  • So I was following the steps here and the first value you state to edit is the byte count. I have only one item in my stash (to make it easier) I've counted both forwards and backwards using your breakdown below and I always end up on the same byte. However that byte is a hex 27 so that's 39 in Decimal...can't subtract 45 from that and end up with a valid hex number. I set mine to 00, saved and encrypted. Loaded up the game and the item has the cheater flag removed.

    So I'm assuming I edited the correct value, but wanted your input. My guess is that the value in this byte changes on a per item basis, but then I'm not sure how to know what to set it to, 00 did away with it on this item, but i may have messed something else up.

    Also are the steps after that (steps 4-6) just to do the cleanup behind the scenes to make the item "legit", because step 1 seems to remove the visual indicator but my guess is that the final 3 steps remove the evidence of it?

    Thanks!
  • ChthonChthon Posts: 1,855
    necabote wrote:
    So I was following the steps here and the first value you state to edit is the byte count. I have only one item in my stash (to make it easier) I've counted both forwards and backwards using your breakdown below and I always end up on the same byte. However that byte is a hex 27 so that's 39 in Decimal...can't subtract 45 from that and end up with a valid hex number. I set mine to 00, saved and encrypted. Loaded up the game and the item has the cheater flag removed.

    So I'm assuming I edited the correct value, but wanted your input.

    Ints are 4 bytes long, not 1 byte. You probably reduced the least significant byte by 39 and got lucky that this truncated the item in a place that didn't cause a fatal error.
    Torchlight 2 Rapid Respec - Putting the "hack" in "hack-n-slash"
    StashNinja - INFINITE Stash for Torchlight 2
    NullMod - Play together in the same multiplayer game with different mods!
  • Hmmm you might be right, i respawned an item and started all over.

    This is the hex

    42 00 00 00 01 00 00 00 00 01 00 00 00 2D 03 00 00 00 5F 5D B2 6C 95 D7 56 EB 0E 00 43

    The 43 at the end of the line is the first letter of the item name.
    Working backwards from there...
    The underlined par is the item base type GUID
    Then the bold 5D is the mystery byte
    Then the 00 00 00 5F is the bytecount int right?

    5F I can see reducing by 45, but the first item I did this it was a 27 in the same place this one is a 5F. I'm going to see if I have a backup copy of that stash to look again.
    So I just need to change the 5F to a 32 right?

    Then do the rest of the steps.
  • ChthonChthon Posts: 1,855
    necabote wrote:
    Hmmm you might be right, i respawned an item and started all over.

    This is the hex

    42 00 00 00 01 00 00 00 00 01 00 00 00 2D 03 00 00 00 5F 5D B2 6C 95 D7 56 EB 0E 00 43

    The 43 at the end of the line is the first letter of the item name.
    Working backwards from there...
    The underlined par is the item base type GUID
    Then the bold 5D is the mystery byte
    Then the 00 00 00 5F is the bytecount int right?

    5F I can see reducing by 45, but the first item I did this it was a 27 in the same place this one is a 5F. I'm going to see if I have a backup copy of that stash to look again.
    So I just need to change the 5F to a 32 right?

    Then do the rest of the steps.

    0x42 00 00 00 - file type
    0x01 - pre-checksum mystery byte
    0x00 00 00 00 - checksum (decrypter zeros it out)
    0x01 00 00 00 - number of items in stash
    0x2D 03 00 00 - byte count for first item
    0x00 - mystery byte (always zero)
    0x5F 5D B2 6C 95 D7 56 EB - GUID
    0x0E... - start of the item name string. Apparently 14 characters long in this case.

    This might be helpful to you, particularly part 4.

    [edit: OK, I see part of the problem: Strings do NOT start from their first letter, they start from a short (2 bytes) that states the number of characters in the string. You're off by those 2 bytes.]
    Torchlight 2 Rapid Respec - Putting the "hack" in "hack-n-slash"
    StashNinja - INFINITE Stash for Torchlight 2
    NullMod - Play together in the same multiplayer game with different mods!
  • Ah! thank you so much.
    You clearly stated that 2 byte short but I read over it at least 3 times.

    So the int I need to reduce is the 0x2D 03 00 00
    which is 813 in decimal right?
    So i need to change it to
    00 03 00 00 right?

    After reading your link, which was immensely helpful, the writing the hex backwards is a bit...weird :-)

    Thanks again for all your help
  • ChthonChthon Posts: 1,855
    necabote wrote:
    Ah! thank you so much.
    You clearly stated that 2 byte short but I read over it at least 3 times.

    So the int I need to reduce is the 0x2D 03 00 00
    which is 813 in decimal right?
    So i need to change it to
    00 03 00 00 right?

    Precisely.
    After reading your link, which was immensely helpful, the writing the hex backwards is a bit...weird :-)

    Thanks again for all your help

    Glad someone found it useful.

    There really, truly are good hardware-efficiency reasons for little endianness, but it is an absolutely confusing thing for hex editing data files.
    Torchlight 2 Rapid Respec - Putting the "hack" in "hack-n-slash"
    StashNinja - INFINITE Stash for Torchlight 2
    NullMod - Play together in the same multiplayer game with different mods!
  • idleNewbieidleNewbie Posts: 2
    edited November 2012
    Another simple dirty method:
    Search: 48 80 00 00 00 00 01 00 00 80 BF 00 00 EE 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 7A C4 00 00 00 00 00 00 80 BF 00 00 00 00
    Replace: 48 80 20 00 00 00 01 00 00 80 BF 00 00 EE 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 7A C4 00 00 00 00 00 00 80 BF 00 00 00 00
    Pros simple(1 bit change), Cons the CHEATED ITEM effect still there and DISABLED. ppl@runicgames will know if they do check.

    edit: outdated.
  • undertaker79undertaker79 Posts: 153
    There is already a program to automatically remove the cheated flag from items in the stash (as Chthon described) so there is no need for dirty methods that can cause problems as Chthon has explained in this topic.
    Automatic "CHEATED ITEM" flag remover: Making consoled items as good as legit
  • ChthonChthon Posts: 1,855
    idleNewbie wrote:
    Another simple dirty method:
    Search: 48 80 00 00 00 00 01 00 00 80 BF 00 00 EE 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 7A C4 00 00 00 00 00 00 80 BF 00 00 00 00
    Replace: 48 80 20 00 00 00 01 00 00 80 BF 00 00 EE 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 7A C4 00 00 00 00 00 00 80 BF 00 00 00 00
    Pros simple(1 bit change), Cons the CHEATED ITEM effect still there and DISABLED. ppl@runicgames will know if they do check.

    That's unwise. In other cases, the **** **** 20 00 type modifier has some extra fields that make it longer than the **** **** 00 00 type. So, I suspect you may causing a misparse there. (Either because 48 80 20 00 is undefined or it expects more data than is there.) Have you tried it with items that have additional mods below the cheater flag? Do they come out right?

    If you really want to try this "just change one byte" business, do it mrboggles's way. At least we've got a pretty good guess what the variable he's tweaking does, and that probably nothing bad is happening because of it (or will happen because of it in a future patch).

    Still, I can't really advocate any of the "just change one byte" methods for the reasons discussed before. There's no reason to rely on "this probably works, and probably won't cause any problems" when you have access to an alternative that is 100% sure to work and not cause a problem. There's also no reason to leave a malformed modifier hanging around in your item data when you know how to remove it.
    There is already a program to automatically remove the cheated flag from items in the stash (as Chthon described) so there is no need for dirty methods that can cause problems as Chthon has explained in this topic.

    Is there? Mind sharing a link? Well, that will certainly make me feel less bad about doing it myself.
    Torchlight 2 Rapid Respec - Putting the "hack" in "hack-n-slash"
    StashNinja - INFINITE Stash for Torchlight 2
    NullMod - Play together in the same multiplayer game with different mods!
  • CailleCaille Posts: 127
    viewtopic.php?f=48&t=46083

    There ya go mate.

    Alexis
    *smiles*
    The fairer **** indeed exists, even though tales may yet persist; that no girls on the intraweb can there be found. Do you get the gist? Or shall my tongue in cheeky manner spin this into other banter?
  • tho autopatcher's out, 48 80 20 00 outdated.

    48 80 00 00 is bitmap descripts how the effect activated, 00 01 00 00 denotes the effect string adds an extra 0 padding, 00 20 00 00 denotes there's an extra TransferGUID after effect string for those Conveys, 00 40 00 00 denotes current effect is given by enchanter, and 00 00 20 00 disabled the current effect (inspecting socketables armor effect socketed to weapon, or weapon effect socketed to armor).
  • ChthonChthon Posts: 1,855
    idleNewbie wrote:
    tho autopatcher's out, 48 80 20 00 outdated.

    48 80 00 00 is bitmap descripts how the effect activated, 00 01 00 00 denotes the effect string adds an extra 0 padding, 00 20 00 00 denotes there's an extra TransferGUID after effect string for those Conveys, 00 40 00 00 denotes current effect is given by enchanter, and 00 00 20 00 disabled the current effect (inspecting socketables armor effect socketed to weapon, or weapon effect socketed to armor).

    That post appears to be very useful, but it's not entirely clear. Could you try rephrasing?


    I'm not sure, but I think you're saying:

    The first 4 bytes are:
    AA BC DE EE
    where
    • AA is the effect's trigger type, with 48 representing "always on."
    • B is -- you say two different things -- first you say that it denotes the number of TransferGUIDs, then you say it denotes whether or not it's an enchant. Or are you saying that different bits here are being used to represent different things? Please clarify.
    • C is the extra padding after the string. (I think this is probably right, but I have a suspicion that it's not padding, but rather a second string that is usually blank (hence 00).)
    • D is enabled/disabled (00/20)
    • E EE is unknown. (Ever seen it not 0 00?)
    How much of that is what you were saying?

    [edit:
    idleNewbie wrote:
    bitmap

    Ah-ha! Bitmask! Now your post makes a lot more sense! That's useful information indeed!

    end edit]
    Torchlight 2 Rapid Respec - Putting the "hack" in "hack-n-slash"
    StashNinja - INFINITE Stash for Torchlight 2
    NullMod - Play together in the same multiplayer game with different mods!
Sign In or Register to comment.