NeoAnderson wrote:I think we could find a walk around, but i have to ask something to understand if it could be done.
When a card make a copy, does it changes also is CardRef? If the card ref remains unchanged probably we could make something.
I try to exaplain, supposing that the copy card card ref is fixed, we could do :
1. Add a primal clay ability who retrieve a datachest indexed with copying card ref number, when primal clay become target of a spell or ability. Set into this chest the choosen values.
2. Another ability who set the Primal clay to the stored value if the datachest is not nil.
3. Clear the datachest when the ability resolves or at end of that step.
The CardRefs of both the original card and the card becoming the copy should technically remain unchanged (the card doing the copying simply changed state it did not become a new instance). This method might work using the DuelDataChest() (or my ObjectDC functions) though it is definitely a crap shoot method of doing it as you would have to create a data chest for every card that targets
Primal Clay even if it is not doing any copying. It would add quite a bit of overhead (especially when making sure there are no collisions) so it may impact game performance.
NeoAnderson wrote:Theoretically I agree with you for this reason i have exposed this issue, i only would be sure that this should be the behaviour to be compliant with official rules.
If it is sure i think will be not so complicated to add a check to understand if this kind of cards have to add, remove or do nothing when they come back onto battlefield.
For a definitive official compliant answer we would need a DCI judge. Since I don't happen to have one on speed dial and I assume you don't either (hence why you posted in the forum) we should go with our best guess.
My best guess would be that
Oubliette and
Tawnos's Coffin would manage the counters it needs to put back on the
Clockwork Avian first then
Clockwork Avian's ZONECHANGE_TRANSITION trigger should fire (in the middle of
Oubliette and/or
Tawnos's Coffin resolving) and bring the total counters it enters with to 4 (adding or removing as necessary). Finally
Oubliette and/or
Tawnos's Coffin would put back in the auras attached to the creature.
NeoAnderson wrote:Last card coded and new doubts :
I have coded Tetravus, i have used Riiak ObjectDC Functions to implement this card.
It works but i would ask to you some opinions :
1. the card as i coded it is compliant to the follow official rules :10/4/2004: If the Tetravus is destroyed when the Tetravites are off the card, they are not destroyed, they are just orphaned.
10/4/2004: Any +1/+1 counter which is on this card can be turned into a Tetravite token. It does not care where the +1/+1 counter came from.
10/4/2004: Only Tetravites from this specific Tetravus may be used for the ability. Ones from a different Tetravus can't.
8/1/2008: This card now has two upkeep-triggered abilities. Its controller chooses the order they are put on the stack, and thus the order in which they resolve each upkeep.About the last rule i have used this idea :
I made an empty trigger ability for the Upkeep, and i have turned the 2 upkeep-triggered abilities of Tetravus into activated ability. These Activated ability can only be played into upkeep and just once per turn. Doing this way we can decide if we want or not to activate them, and we also can enstabilish the order.
Do you think this will be enough compliant to the Mtg rules, or the fact to have changed them from triggered into Activated abilities means a lot?
This change does have some implications the worst of which (which can actually be coded) would be abilities like
Burning-Tree Shaman (granted this one can be worked around by having the activated abilities claim they are mana abilities using my manual mana functions, though you would obviously leave off the forced_skip because it really isn't a mana ability). Another issue would be with cards that prevent the activation of activated abilities (
Linvala, Keeper of Silence, etc...) and this could be worked around by having the card detect if it is being affected in that way and switch back to using real triggered abilities which are unaffected. Also to make sure they can't activate the abilities more than once in the upkeep you would need to make sure they each have a per turn limit set as with activated abilities without that you could activate them more than once which would definitely not be rule compliant.
Overall, this simply makes the card considerably more complex for something that could be considered relatively minor (ordering of which triggered ability to use first). Personally I would stick with keeping them as triggered abilities because it would make coding the card easier, but if you want to go for the more complex route feel free.