using "show hand" and having triggered moveto effects sometimes does not draw card in hand.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Cast Naturalize on a Rancor enchanting a creature.
2.
3.

What is the expected output? What do you see instead?

Rancor should go back to your hand. In fact it does, but it gets inivisible 
causing a "gap" in your hand (draw another card to see what i mean). Rancor is 
not only invisible, but cannot be cast or targeted for the rest of the game.

Please use labels and text to provide additional information.

The code for Rancor i use is:

[card]
name=Rancor
target=creature
auto=@movedTo(graveyard) from(this|battlefield):moveTo(myhand) 
all(this|mygraveyard)
auto=2/0
auto=trample
text=Enchant creature -- Enchanted creature gets +2/+0 and has trample. -- When 
Rancor is put into a graveyard from the battlefield, return Rancor to its 
owner's hand.
mana={G}
type=Enchantment
subtype=Aura
[/card]

Original issue reported on code.google.com by dan.solo...@googlemail.com on 25 Sep 2010 at 8:03

[GoogleCodeExporter]

Original comment by dan.solo...@googlemail.com on 25 Sep 2010 at 8:26

• Changed title: _Cards disappearing/getting unusable when returning to owner's hand. _

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This is true for every other card with this effect, a relatively big card group.
Should be fixed before the release!

Original comment by dan.solo...@googlemail.com on 25 Sep 2010 at 10:01

[GoogleCodeExporter]

Did this start to happen recently ? What revision are you testing with?

Original comment by wagic.the.homebrew@gmail.com on 26 Sep 2010 at 5:06

[GoogleCodeExporter]

This could not happen before because cards like Rancor and Endless Cockroaches 
worked completely different, before a code change let them not work anymore.

This is a card group that those status had not been safed by test_suote tests!

Original comment by dan.solo...@googlemail.com on 26 Sep 2010 at 6:50

[GoogleCodeExporter]

Why did you change the code for Rancor? It worked before from what I can see, 
and we had a test for it. If I put the old code, the test suite works again, 
and the bug you mention here goes away. Is there a reason you changed the code 
for Rancor? I plan to revert that change for now.

Original comment by wagic.the.homebrew@gmail.com on 26 Sep 2010 at 8:52

[GoogleCodeExporter]

Adding the code here:
Code for Rancor before:
autograveyard=@movedTo(this|graveyard) from(battlefield):moveTo(myhand)

Code for Rancor now:
auto=@movedTo(graveyard) from(this|battlefield):moveTo(myhand) 
notatarget(this|mygraveyard)

The old one works, the new one does not. Can you explain why you changed it? 
I'm sure you have a good reason.

For now I'll revert to the old one because 1) it doesn't break the test suite 
and 2) it seems to work when I test manually (I don't see the issue you talk 
about).

Then we can discuss more about the issues you have with the old code.

Original comment by wagic.the.homebrew@gmail.com on 26 Sep 2010 at 8:57

[GoogleCodeExporter]

because the 1 test is just one situation.

I think in other game situations the card did not work (like when the creature 
it enchants dies in combat or when Rancor is destroyed by a Disenchant.)

Original comment by dan.solo...@googlemail.com on 26 Sep 2010 at 8:57

[GoogleCodeExporter]

ok. Then here is what I suggest:
I will revert the code, so that the test suite passes again.
Then we can write NEW tests that show the bugs you are describing. We can open 
tickets for the other bugs if needed. Maybe there's a post somewhere in the 
forum that describes those bugs?

Original comment by wagic.the.homebrew@gmail.com on 26 Sep 2010 at 9:00

[GoogleCodeExporter]

I tested the old code and the invisibility issue is occuring when the creature 
dies in combat.

Original comment by dan.solo...@googlemail.com on 26 Sep 2010 at 9:01

[GoogleCodeExporter]

Tests won't help us, because Rancor IS returning to your hand, BUT you cannot 
play it anymore after that! How do you want to simulate that with test suite? 

Original comment by dan.solo...@googlemail.com on 26 Sep 2010 at 9:02

[GoogleCodeExporter]

Look at the tests in the "manual" folder.
You can add:
human
human
at the end of a test, and it will give you control.
This is a "semi automated" test, which will help. This is how I tested with the 
old code.

So, does "casting a naturalize" on the Rancor cause a problem with the old code 
or not? 
Let's dig a bit deeper, but I will still revert the mtg.txt to have the test 
suite pass again.

Original comment by wagic.the.homebrew@gmail.com on 26 Sep 2010 at 9:08

[GoogleCodeExporter]

what about tlaking in the chat room about that?

Original comment by dan.solo...@googlemail.com on 26 Sep 2010 at 9:12

[GoogleCodeExporter]

i wait there

Original comment by dan.solo...@googlemail.com on 26 Sep 2010 at 9:12

[GoogleCodeExporter]

you should playtest rancor ingame to see what i mean...

Original comment by dan.solo...@googlemail.com on 26 Sep 2010 at 9:23

[GoogleCodeExporter]

so, I did, and as we discussed, I can't reproduce the issue.
It doesn't mean the issue does not exist, but for now I can't solve what I 
can't see. It would be great if you can get anybody else (Zethfox?) to 
reproduce the same problem, so that we are sure the issue is not only on your 
side.

Original comment by wagic.the.homebrew@gmail.com on 26 Sep 2010 at 10:00

• Changed state: New

[GoogleCodeExporter]

One important thing about this issue:

"autograveyard" + "@movedTo" should not work together. 

other "@"-events do not work with it, nor does "lord" or "aslongas".

Zethfox can confirm this does not work anymore on the newest checkout.

Original comment by dan.solo...@googlemail.com on 26 Sep 2010 at 2:28

[GoogleCodeExporter]

triggers are not allowed in graveyard....

also bug confirmed with rancor...this card USE to work...no longer works now.

the reason it passes test suite is because the game THINKS it gave you the 
card, adds the cards name to your hand...but not the ACTUAL card.

Original comment by omegabla...@gmail.com on 26 Sep 2010 at 2:51

[GoogleCodeExporter]

I played with a wagic on rev2100, rev2000, and rev 1900.

autograveyard=@movedTo(this|graveyard) from(battlefield):moveTo(myhand)

never worked...

Original comment by dan.solo...@googlemail.com on 26 Sep 2010 at 4:18

[GoogleCodeExporter]

#Testing Rancor
#When Rancor is put into a graveyard from the battlefield, return Rancor to its 
owner's hand.
[INIT]
FIRSTMAIN
[PLAYER1]
inplay:Llanowar Elves
hand:Rancor,Shock
manapool:{G}{R}
[PLAYER2]
[DO]
Rancor
Llanowar Elves
Shock
Llanowar Elves
[ASSERT]
FIRSTMAIN
[PLAYER1]
graveyard:Llanowar Elves,Shock
hand:Rancor
manapool:{0}
[END]

this test passes, that means the game sees the card is added to the hand, if 
you MANUELLY test this, you will see that that card is NOT actually in your 
hand...this is indeed a bug...

Original comment by omegabla...@gmail.com on 26 Sep 2010 at 4:26

[GoogleCodeExporter]

I manually tested it several times and had no problem

Original comment by wagic.the.homebrew@gmail.com on 26 Sep 2010 at 10:29

[GoogleCodeExporter]

However I agreed that triggers are not supposed to work in autograveyard...
If you guys are 100% sure that this card cannot work for now, then please 
remove it (and the test) from the primitives for now.

Original comment by wagic.the.homebrew@gmail.com on 26 Sep 2010 at 10:38

[GoogleCodeExporter]

it actually returned to you hand? for me it acted as tho the effect just 
fizzled.

i kind of can not really decide what is going on, it is not really a mtter of 
if we think its not 100%, more like theres a clash here. you say it works fine, 
we say it fizzles. if it works for you then there might be a file, different 
code, something that allows it to work correctly for your build and not ours.

Original comment by omegabla...@gmail.com on 26 Sep 2010 at 11:30

[GoogleCodeExporter]

here is a card in SVN i PERSONALLY coded myself

[card]
name=Endless Whispers
auto=@movedto(creature|mygraveyard) from(battlefield):all(trigger[to]) 
counter(0/0,1,endless)
auto=@movedto(creature|opponentgraveyard) from(battlefield):all(trigger[to]) 
counter(0/0,1,endless)
auto=@each endofturn:moveto(opponentbattlefield) 
all(*[counter{0/0.1.endless}|mygraveyard) && moveto(mybattlefield)
text=Each creature has "When this creature is put into a graveyard, choose 
target opponent. That player returns this 
card from that graveyard to the battlefield under his or her control at the 
beginning of the next end step."
mana={2}{B}{B}
type=Enchantment
[/card]

this card USED to work 100% now it takes the trigger creature out of the grave, 
and they vanish completely.

im not trying to grind this into a huge issue, but SOMETHING has changed that 
is returning invisible card to hand.

Original comment by omegabla...@gmail.com on 26 Sep 2010 at 11:50

[GoogleCodeExporter]

*battlefield....and other instences where a card moves out of graveyard.

Original comment by omegabla...@gmail.com on 26 Sep 2010 at 11:55

[GoogleCodeExporter]

WOW i will add even further. PLEASE run a real game with this above card. 
please note that this card worked 100% when it was added to the svn.

WATCH THE CRAZY SHIT THAT HAPPENS!!!! omg its NUTS. aparently the ai is allowed 
to use these invisible cards. and it shifts the battlefield to the left and 
right and does a TON of other complete crazy things when the ai uses the cards.

the first turn its completely fine, but it just gets progressively crazier as 
it goes.

sometimes it looks like the card keeps coming back into play, then sometimes 
you see this really strange animation where the card is litteralyy in your face 
then zones back down to the feild and shots off to the far right.

it confirms the bug. and that the bug is recent.

Original comment by omegabla...@gmail.com on 27 Sep 2010 at 12:04

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

ok i think i can confirm, the cards do indeed go to the locations they state, 
but FAR FAR FAR off screen.

like it it would appear in hand it appear WAYYYYYYYYYYYYYYYYYYYYY off to the 
right. if its moving to the battlefield it is like WAY off to the far right 
bottom courner.

the cards are really there. you just can not click them yourself, but ai doesnt 
target its cards like this.

so it does not need to worry about not seeing the card on screen, reason i 
suggest this, watch a fight where the ai now control one of your 
creatures...when the creature are places in the little red row, which mind you 
does not appear when this bug happens, it sratches the creatures that actually 
belonged to it LONG ways some almost going off screen over by the players hand. 
as if the gui is trying to include the creatures WAYWAYWAY off screen in the 
fight also.

this appears to be gui and graphic related, on where cards are placed in 
locations when it moves to and from a location.

Original comment by omegabla...@gmail.com on 27 Sep 2010 at 12:13

[GoogleCodeExporter]

Let's calm down a bit.
1) We are talking of two different issues I think.
Let me summarize:
a - issues with the code for Rancor:
autograveyard=@movedTo(this|graveyard) from(battlefield):moveTo(myhand)

I tested this card with both the SVN version and the alpha on my psp. In real 
game situation (did 5 real matches on the PSP), and I had no problem.

Dr.Solomat mentions that this card doesn't work, but he changed it in the 
meantime, so I want to be sure "which" version doesn't work

b - issues with the "movedTo" trigger in auto. These ones are probably caused 
by a recent change in the code. Probably when I attempted to fix one of the 
numerous bugs a few days ago.

Note that there is a HUGE difference which is that Rancor uses autograveyard, 
while your code uses auto.
I will test your card, but as far as I'm concerned, Rancor works fine 
(especialy in the alpha, I played with it for the last 30 minutes)

Zethfox/Dr.Solomat: please revert your code to revision r2296, compile it, and 
test those cards again. It is essential for us to understand when we broke 
these cards. if the issue happened between r2296 and now, it will be fresh in 
my mind, and one of my fixes is probably the culprit. Please also prepare a 
"semi automated" test for me to try. It's like a regular test, except you have 
to add: 
human
human
before the [assert] tag.

I would do all that myself but I'm at work, and with all the fixes I did last 
week, you guys owe me that ;) (just kidding! Except it's true I can't do it 
myself).

Really counting on you guys on this one. If we can pinpoint WHEN the issue 
happened, it will be WAY easier for me to fix it, probably tonight when I'm 
back from work.

If we can't figure out where the problem comes from in the next couple days, 
we'll remove those cards.

Let's keep Rancor out of this for now, since its code has changed, this card is 
confusing and that doesn't help, so let's just test with Endless Whispers (by 
the way, I remember a test about Endless Whispers being broken a few weeks ago?)

If you find other cards with the same issue, please put them here, so that we 
can "understand" what's going on.

By the way, the following line doesn't make any sense to me:
auto=@each endofturn:moveto(opponentbattlefield) 
all(*[counter{0/0.1.endless}|mygraveyard) && moveto(mybattlefield)

why isn't it:
auto=@each endofturn:moveto(opponentbattlefield) 
all(*[counter{0/0.1.endless}|graveyard)

or
auto=@each endofturn:moveto(opponentbattlefield) 
all(*[counter{0/0.1.endless}|mygraveyard)
auto=@each endofturn:moveto(opponentbattlefield) 
all(*[counter{0/0.1.endless}|opponentgraveyard)

Original comment by wagic.the.homebrew@gmail.com on 27 Sep 2010 at 12:31

[GoogleCodeExporter]

By the way, regarding Rancor: I think the "autograveyard" just doesn't take the 
trigger into account correctly, and simply returns rancor to your hand anytime 
it goes to the graveyard (independently of it being on the battlefield before 
or not...) That's probably the issue with the autoraveyard keyword, but for now 
let's forget about this one.

Original comment by wagic.the.homebrew@gmail.com on 27 Sep 2010 at 12:37

[GoogleCodeExporter]

pin pointed.

this is not a probelm with rancor, or card code, or graphic/gui.

@ triggers which have move to effects cause all sorts of havok the next time 
the trigger would fire exsample 

auto=@each my endofturn:moveto(mybattlefield) all(creature|mygraveyard)

same it true for targeted moves from @ triggers. same is true from moving to 
and from any location.

i wrote a 2 page explaination about this while you were typing. and it didnt 
submit and erased it when i hit back, so you get to read the summirized version.

we need to talk, like now.

Original comment by omegabla...@gmail.com on 27 Sep 2010 at 12:45

• Changed title: @ triggers that move cards cause extremely weird and undesired effects
• Added labels: Priority-Critical
• Removed labels: Priority-High

[GoogleCodeExporter]

i will do a fresh check out going back one rev at a time. i will tell you when 
this issue doesnt happen, i repeat this is not related to rancor, it related to 
triggered events that move cards from one zone to another.

Original comment by omegabla...@gmail.com on 27 Sep 2010 at 12:53

[GoogleCodeExporter]

this bug is happening on and off, 12 games in i have had 3 games now where no 
bugs happened, and everything worked fine. after that last one, i started 
having the issue again.

Original comment by omegabla...@gmail.com on 27 Sep 2010 at 12:57

[GoogleCodeExporter]

This is going to be difficult to solve if we can't reproduce it correctly. If 
you can find a way to reproduce the issue 100% that'd be great. As I discussed 
with Dr.Solomat yesterday, this could be a graphical issue that depends on the 
speed of your machine...

Original comment by wagic.the.homebrew@gmail.com on 27 Sep 2010 at 1:06

[GoogleCodeExporter]

this is very tough wololo. im leaning more on graphical. and where cards are 
being placed on battlefield now. 

12 games, not a single issue, except one time the ai had a card then an empty 
space, then 2 cards. like there should have been something in that spot.

the fact that cards can sometimes appear off screen makes it seem like its MUCH 
worse then it is, because those cards influence the game.

im leaning on graphic. but this JUST started happening wololo. movetos and 
triggers working together are sometimes throwing the cards off screen, and in 
rancors case, WAY off screen, i recommend you try what i did, get a version of 
rancor code from doc that he saids makes invisible cards, then give a mock 
card, move to my graveyard all rancor my hand. AFTER rancor supposedly 
vanished. guess what appears in the graveyard, rancor. so rancor IS currently 
working with docs "invisible cards" issue. THAT is the closest we can get to 
CONSTANTLY reproducing this issue. doing it with other triggers going off is 
too intermitent to rely on it, and theres no telling if the Ai is the one 
blasting me with a bunch of discards and moveto effects either.

has anything been changed on graphic side that could cause cards to suddenly 
want to appear off screen?

Original comment by omegabla...@gmail.com on 27 Sep 2010 at 1:31

• Added labels: Priority-Highveryhighbutnotcrit
• Removed labels: Priority-Critical

[GoogleCodeExporter]

by the way thats 12 games issues, then 3 no issues, then 1 issues, then 12 with 
no issues. if you wanted to try and keep count.

Original comment by omegabla...@gmail.com on 27 Sep 2010 at 1:37

[GoogleCodeExporter]

ok reproduced in alpha on psp.

play alpha on psp, use rancor, have a seeker of skybreak or similar card that 
targets something specific. 

once the creature rancor enchants die, rancor does not return to hand. NOW use 
seeker of skybreaks power. it will grey out targets that it can not target. you 
will see in your HAND a grey "can not target" shadow where rancor is supposed 
to be. the card is in my hand wololo. except it is not on screen.

Original comment by omegabla...@gmail.com on 27 Sep 2010 at 1:53

[GoogleCodeExporter]

I can confirm it does not work on PSP alpha version, too. The same symptoms as 
my current svn version.

Original comment by dan.solo...@googlemail.com on 27 Sep 2010 at 4:26

[GoogleCodeExporter]

Zethfox: don't make up priorities, thanks. We can create new priorities, but 
please discuss it with the rest of the team before.

I will play a bit more with the PSP version, but so far, no problem for me 
guys. You are going to need to figure out what's "wrong" in here by yourselves 
I think (I really can't help until I can reproduce the issue).

The good point though is that this issue wasn't introduced by my recent fixes 
(since you could reproduce it in the alpha).

Regarding graphical changes: the last relevant change to the hand graphics was 
done in 2009:
http://code.google.com/p/wagic/source/detail?r=1566&path=/trunk/projects/mtg/src
/GuiHand.cpp

My guess is therefore that the issue has always been here, you didn't realize 
it when you coded the cards (because it seems to happen quite randomly, depends 
on many factors, etc...)

Maybe another possiblity: did you guys enable something weird in your options 
maybe? Like autopassphase, or stuff like that? Try to revert your options to 
the default and see if that helps maybe?

Also let me know what your options are (especially new stuff like passphase). 
Maybe there's something to dig here...

Next step: revert your code to the revision where the card (rancor or endless 
whispers, your choice) was added, and check again. Does the error occur or not? 
If yes, then you've got it, the error has always been here.
If not, then maybe we can dig a bit more.

Original comment by wagic.the.homebrew@gmail.com on 27 Sep 2010 at 6:21

• Added labels: Priority-High
• Removed labels: Priority-Highveryhighbutnotcrit

[GoogleCodeExporter]

How can i find out when Rancor was added to the game?

Original comment by dan.solo...@googlemail.com on 27 Sep 2010 at 8:30

[GoogleCodeExporter]

i think i know why its in your hand wololo and not mines. do you play with the 
option

"always show hand" 
im guessing you do not.

i have my hand set to verticle and always show. i have not tested this yet, but 
i will check it out.

Original comment by omegabla...@gmail.com on 27 Sep 2010 at 9:06

[GoogleCodeExporter]

Good point!
I have mine set to "hide hand" and "horizontal".
I'll try vertical + show hand!

Original comment by wagic.the.homebrew@gmail.com on 27 Sep 2010 at 9:09

[GoogleCodeExporter]

@DrSolomat: rancor was added here: 
http://code.google.com/p/wagic/source/detail?r=1704
(I used tortoise SVN "show log" on ULG/_cards.dat, then loked at the various 
versions)

Original comment by wagic.the.homebrew@gmail.com on 27 Sep 2010 at 9:21

[GoogleCodeExporter]

OMFFFFFFFFFGGGGGGGGGGGG.

rancor works, YES i used "open hand button" guess what the F decides to be in 
my hand!
rancor!!!!!!!!!!!

we were all fighting with each other about this. and it worked all along.

the REAL bug is now, 
using "show hand" and having triggered moveto effects sometimes does not draw 
card in hand.

once you use the "open hand" button. it updates the cards.

Original comment by omegabla...@gmail.com on 27 Sep 2010 at 9:49

• Changed title: using "show hand" and having triggered moveto effects sometimes does not draw card in hand.
• Added labels: Priority-Low
• Removed labels: Priority-High

[GoogleCodeExporter]

this explains why we thought we were getting invis cards. ALSO part 2 of this 
bug.

triggered moveto effects sometimes draws cards off screen.

Original comment by omegabla...@gmail.com on 27 Sep 2010 at 9:52

[GoogleCodeExporter]

btw i changed it to "low cause this is not a make it or break it bug, its an 
anooying one. but not as bad as we thought.

im sure the % of people that use "always show" options are MUCH MUCH lower then 
those that use default.

Original comment by omegabla...@gmail.com on 27 Sep 2010 at 9:56

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

final update, this bug has existed as far back as i bothered to test :) every 
rev all the way to i think the M10 changes.
the reason i think it went unnoticed for so long, the very next "moveto" that 
is not triggered effect, updates the cards in hand and BOOM rancor was always 
there.

so in normal play it went unnoticed FOREVER.

Original comment by omegabla...@gmail.com on 27 Sep 2010 at 10:03

[GoogleCodeExporter]

found the possible cause. when the code that "updates and redraws cards" was 
written, wagic did not have as many cards as it does now.

it is possible that the event is asking for an updated gui draw and WHILE the 
game tries to find the image, the event resolved and the cards image never got 
to the event
so it does not update the card veiw in hand that is always open.

the reason this does not show up in open/close button events, is cause that 
event appears to ask for an update everytime you click the button. so it can 
rearrange them in the little pop out square.

always open option can not do this, because that event is handled in real time.

Original comment by omegabla...@gmail.com on 27 Sep 2010 at 10:08

[GoogleCodeExporter]

ok further explaining cause sometimes i over explain, sometimes i dont explain 
enough.

when a card is moved to hand and the option "always show hand" is on. the 
moveto event send for an gui draw update. since the move to was triggered, it 
have to resolve that event also, but the game ask for an update gui draw FASTER 
then the event that triggered it. this is why cards with direct moveto codes do 
not cause this. they resolve fine, but since the latter is a triggered event 
that is asking, it resolves as a trigger. 

the game will recieve the triggered event, then it sends out to have the cards 
in hand updated in their card views. since the event that redraws the cards 
happens and resolves faster then the triggered event that sent it. the card 
appears to be invisible.

this is because the triggered event sent for the updated draw event and *might* 
still be looking for the cards image to draw in your hand. the event to update 
the drawn cards in hand resolves, then triggered event saids "ok i still have 
this image here guess ill just toss this out since you went ahead without me"

we now have invisble card in hand. now if you MANUELLY call for a updated draw 
event, it acts much like direct moveto events, it sends an event to collect the 
cards it will be drawing in your hand, then it sends one to rearrange them in 
the pop out square. during this time the game saids, "hey triggered event, do 
you still have that image you collected, cause we need it now"

and there you have your rancor, in a square waiting to be used.

Original comment by omegabla...@gmail.com on 27 Sep 2010 at 10:18

[GoogleCodeExporter]

for the second half of this bug its a bit different.

the 2nd part is most avident when you use triggered events with "all(" and 
moveto.

*pure speculation*
the triggered event is trying to find "all" the cards it will be handing over 
to the moveto. at this point the triggered event starts going through the 
cards, 
ok this one, this one, not this one, this one.

what will happen when its drawn on the field, it THINKS that the ones that were 
rejected by the trigger still deserve to have a space on the battlefield. which 
is why it sometimes draws the cards and there will be a gap in the middle where 
a rejected card would have been IF it was not rejected, or WAY off screen pass 
the players hand.

so triggered moveto events are sending out information too late, or sending out 
the incorrect amount of cards that will move in the 2nd parts case.
i imagine it is telling the gui events that it counted 5 cards in the grave, 
the gui event saids "ok make 5 spaces to add cards", the gui event draws the 
cards THEN triggered moveto saids "wait wait i will only be giving you 3 of 
those cards!"

but it is too late, gui event already drew the new empty spaces and assigned 
the cards a slot on the feild.

if you manage to recreate this. use another effect DIRECTLY after it the "moves 
all card from the battlefield to the battlefield" and you will get a better 
idea of what i mean. it will remove the unused slots at that point and place 
the off screen cards in the right places.

Original comment by omegabla...@gmail.com on 27 Sep 2010 at 10:29