It is currently 26 May 2018, 07:56
   
Text Size

UseCopiableValues limitations (transform cards)

Moderators: Xander9009, CCGHQ Admins

UseCopiableValues limitations (transform cards)

Postby Xander9009 » 03 Jun 2016, 20:31

I'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.
_______________________________
Community Wad - Community Wad Website - How to Help and Report Bugs
Discord: discord.gg/4AXvHzW
User avatar
Xander9009
Programmer
 
Posts: 2792
Joined: 29 Jun 2013, 07:44
Location: Indiana, United States
Has thanked: 100 times
Been thanked: 418 times

Re: UseCopiableValues limitations (transform cards)

Postby Tejahn » 17 Jul 2016, 02:30

Xander9009 wrote:...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.
Thanks for confirming this. My limited testing of transformation cards in Magic Duels indicate that it's the same for that version as well. (Forgive me for assuming you're test were done on DOTP 2014 if that wasn't the case)
Tejahn
 
Posts: 430
Joined: 14 May 2013, 01:35
Has thanked: 25 times
Been thanked: 25 times

Re: UseCopiableValues limitations (transform cards)

Postby Xander9009 » 17 Jul 2016, 17:05

Tejahn wrote:
Xander9009 wrote:...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.
Thanks for confirming this. My limited testing of transformation cards in Magic Duels indicate that it's the same for that version as well. (Forgive me for assuming you're test were done on DOTP 2014 if that wasn't the case)
You're fine. On the first line in parentheses I noted it was in 2014. And I'm not surprised that Magic Duels has the same problem. They seem to be the same system from one iteration to the next with just a few tweaks for that version's particular needs.
_______________________________
Community Wad - Community Wad Website - How to Help and Report Bugs
Discord: discord.gg/4AXvHzW
User avatar
Xander9009
Programmer
 
Posts: 2792
Joined: 29 Jun 2013, 07:44
Location: Indiana, United States
Has thanked: 100 times
Been thanked: 418 times


Return to Programming Talk

Who is online

Users browsing this forum: No registered users and 1 guest


Who is online

In total there is 1 user online :: 0 registered, 0 hidden and 1 guest (based on users active over the past 10 minutes)
Most users ever online was 279 on 11 Jul 2013, 22:03

Users browsing this forum: No registered users and 1 guest

Login Form