UseCopiableValues limitations (transform cards)
Posted: 03 Jun 2016, 20:31I've just done some tests on transforming cards (in DotP 2014) and discovered some info that may or may not be useful elsewhere.
As some have noticed, the art of transforming cards doesn't always change like it should. Changing the ARTID to numbers instead of letters seems to fix the issue. So, I decided to see if both the front and back faces needed changed, if there was a limit to the number or if it just needed to be digits, and to see if any other characters could be used.
I discovered that an ARTID which is a number between -2147483648 and 2147483647 (inclusive) will cause the art to change. So, the only character that can be used (based deductive reasoning, not exhaustive testing) is the - symbol. If the ARTID matches this format, then the displayed name will also change properly.
Therefore, I've come to a few conclusions.
When a card uses copiable values from a chest, it calls a function which changes the values the card is using to the values in the chest. This function checks the ARTID. It also checks the types and subtypes. The function which checks the ARTID is different from the normal ARTID parsing function. Unlike the typical function, it treats it as a 32-bit signed integer. If it fails to parse the ARTID, then it ignores the art change. If it can parse it, then it changes the art. If the new types or subtypes are different from the original ones, then it will call a function to change those as well.
Testing showed that if the front and back have different types or subtypes, then the name will change properly. If, however, the front and back have the same types, subtypes, and the art doesn't change, then the name won't change. So, there's a flow of functions that checks whether or not certain attributes of a card are changed. If the art fails, then certain functions related to changing the name will not be called (possibly because the name-changing function is inside the art-changing function, but more likely because an exception is thrown and the block exits before it gets to the name changing). If, however, a card ever changes types or subtypes, then its name is checked. If a card ever changes colors, then its name and art is checked (using the normal ARTID parser which understands strings). And if a card's art is ever changed, then everything is rechecked.
So, the key to making sure that the types, subtypes, name, color, and art are all changed properly is to make sure the art is changed, and the rest will follow. But for the art to change from within the UseCopiableValues function, the ARTID must be a number so it can be parsed by the more limited version of the art-checking function.
As some have noticed, the art of transforming cards doesn't always change like it should. Changing the ARTID to numbers instead of letters seems to fix the issue. So, I decided to see if both the front and back faces needed changed, if there was a limit to the number or if it just needed to be digits, and to see if any other characters could be used.
I discovered that an ARTID which is a number between -2147483648 and 2147483647 (inclusive) will cause the art to change. So, the only character that can be used (based deductive reasoning, not exhaustive testing) is the - symbol. If the ARTID matches this format, then the displayed name will also change properly.
Therefore, I've come to a few conclusions.
When a card uses copiable values from a chest, it calls a function which changes the values the card is using to the values in the chest. This function checks the ARTID. It also checks the types and subtypes. The function which checks the ARTID is different from the normal ARTID parsing function. Unlike the typical function, it treats it as a 32-bit signed integer. If it fails to parse the ARTID, then it ignores the art change. If it can parse it, then it changes the art. If the new types or subtypes are different from the original ones, then it will call a function to change those as well.
Testing showed that if the front and back have different types or subtypes, then the name will change properly. If, however, the front and back have the same types, subtypes, and the art doesn't change, then the name won't change. So, there's a flow of functions that checks whether or not certain attributes of a card are changed. If the art fails, then certain functions related to changing the name will not be called (possibly because the name-changing function is inside the art-changing function, but more likely because an exception is thrown and the block exits before it gets to the name changing). If, however, a card ever changes types or subtypes, then its name is checked. If a card ever changes colors, then its name and art is checked (using the normal ARTID parser which understands strings). And if a card's art is ever changed, then everything is rechecked.
So, the key to making sure that the types, subtypes, name, color, and art are all changed properly is to make sure the art is changed, and the rest will follow. But for the art to change from within the UseCopiableValues function, the ARTID must be a number so it can be parsed by the more limited version of the art-checking function.