Implementing variants

[moomarc]

There seems to be a problem with the PlaneswalkedFrom trigger. I tried using it to script Orzhova but it acts exactly the same as though I'd used PlaneswalkedTo in that it triggers when I planeswalk to Orzhova. I've double-checked all the variable names and everything is right. I also inserted loads of println's and the correct card is being passed to the triggerHandler, but there's just something wierd with the timing. I've looked through the code trail and it seems straightforward and it should work... but it just doesn't. I don't get it!

Anyway, here's the script if someone can figure out what the issue is. The final script would use ValidCard$Plane.Self in the PlaneswalkedFrom, but for now that doesn't work because it's triggering at the wrong time so is checking the Plane left when it arrives at the new plane.

Code: Select all

Name:Orzhova
ManaCost:no cost
Types:Plane Ravnica
Text:no text
T:Mode$ PlaneswalkedFrom | ValidCard$ Plane | TriggerZones$ Command | Execute$ OrzhovaDeal | TriggerDescription$ When you planeswalk away from CARDNAME, each player returns all creature cards from his or her graveyard to the battlefield.
SVar:OrzhovaDeal:DB$ ChangeZoneAll | Origin$ Graveyard | Destination$ Battlefield | ChangeType$ Creature
T:Mode$ PlanarDice | Result$ Chaos | TriggerZones$ Command | Execute$ RolledChaos | TriggerDescription$ Whenever you roll Chaos, for each opponent, exile up to one target creature card from that player's graveyard.
SVar:RolledChaos:AB$ ChangeZone | Cost$ 0 | Origin$ Graveyard | Destination$ Exile | ValidTgts$ Creature.OppCtrl | TgtPrompt$ Select target creature each opponent controls. | TargetMin$ 0 | TargetMax$ OneEach | References$ OneEach | TargetsWithDifferentControllers$ True
SVar:OneEach:PlayerCountOpponents$Amount
T:Mode$ PlanarDice | Result$ Planeswalk | TriggerZones$ Command | Execute$ RolledWalk | Secondary$ True | TriggerDescription$ Whenever you roll Planeswalk, put this card on the bottom of its owner's planar deck face down, then move the top card of your planar deck off that planar deck and turn it face up
SVar:RolledWalk:AB$ Planeswalk | Cost$ 0
A:AB$ RollPlanarDice | Cost$ X | SorcerySpeed$ True | ActivationZone$ Command | SpellDescription$ Roll the planar dice.
SVar:X:Count$RolledThisTurn
SVar:Picture:http://www.wizards.com/global/images/magic/general/orzhova.jpg
SetInfo:PC2|Common|http://magiccards.info/extras/plane/planechase-2012-edition/orzhova.jpg
Oracle:When you planeswalk away from Orzhova, each player returns all creature cards from his or her graveyard to the battlefield.\nWhenever you roll {C}, for each opponent, exile up to one target creature card from that player's graveyard.
End

Only difference between PlaneswalkedFrom/To at the moment is the valid card checked, not when the check happens.

[Hellfish]

Huh.You're right, it looks straightforward.. I'll take a look either today or this weekend.

[Hellfish]

I think what's happening is that the stack is frozen while the planeswalking ability resolves, hence the PlaneswalkedFrom trigger for the previous plane causes Sol's(I think Sol implemented it) WaitingTrigger system to kick in and create a WaitingTrigger for that plane and put it in a queue. Then the planeswalking ability finishes resolving, putting away the current plane and putting Orzhova in the command zone before running the WaitingTriggers. So now we have Orzhova in the command zone and a waiting PlaneswalkedFrom trigger that only now gets run, which Orzhova picks up on.

Now to figure out how to fix it

[friarsol]

I think what's happening is that the stack is frozen while the planeswalking ability resolves, hence the PlaneswalkedFrom trigger for the previous plane causes Sol's(I think Sol implemented it) WaitingTrigger system to kick in and create a WaitingTrigger for that plane and put it in a queue. Then the planeswalking ability finishes resolving, putting away the current plane and putting Orzhova in the command zone before running the WaitingTriggers. So now we have Orzhova in the command zone and a waiting PlaneswalkedFrom trigger that only now gets run, which Orzhova picks up on.

Now to figure out how to fix it

Shouldn't the script be
T:Mode$ PlaneswalkedFrom | ValidCard$ Plane.Self

[Hellfish]

Heh,true. I must need glasses.
PlaneswalkedFrom still doesn't run for the plane because it's not forge-technically in the command zone (It's in the players planar deck List) at the time the WaitingTrigger runs. *This* is what I actually need to fix.

[moomarc]

I think what's happening is that the stack is frozen while the planeswalking ability resolves, hence the PlaneswalkedFrom trigger for the previous plane causes Sol's(I think Sol implemented it) WaitingTrigger system to kick in and create a WaitingTrigger for that plane and put it in a queue. Then the planeswalking ability finishes resolving, putting away the current plane and putting Orzhova in the command zone before running the WaitingTriggers. So now we have Orzhova in the command zone and a waiting PlaneswalkedFrom trigger that only now gets run, which Orzhova picks up on.
Now to figure out how to fix it

Shouldn't the script be
T:Mode$ PlaneswalkedFrom | ValidCard$ Plane.Self

That's what I said in my original post. I just didn't post that version of the script because then nothing happened. Thought I'd post something where you could see what I was talking about more clearly.

[friarsol]

Heh,true. I must need glasses.
PlaneswalkedFrom still doesn't run for the plane because it's not forge-technically in the command zone (It's in the players planar deck List) at the time the WaitingTrigger runs. *This* is what I actually need to fix.

I would imagine it shouldn't have a TriggerZones parameter at all. (Since this is determining when this trigger should fire.)

See how Aven Riftwatcher's leaves the battlefield trigger works?

T:Mode$ ChangesZone | Origin$ Battlefield | Destination$ Any | ValidCard$ Card.Self | Execute$ TrigGainLife | Secondary$ True | TriggerDescription$ When CARDNAME enters the battlefield or leaves the battlefield, you gain 2 life.

[Hellfish]

Also true *but* the planar deck lists are not included in the "allCards" list that the triggerhandler loops through looking for triggers.That's what I meant fixing.

Edit: Look at me going all politician with the misleading evasive answers Sorry about that
.

[moomarc]

We would probably have had to make the planar deck a game zone eventually anyway so that we could script the phenomenon/plane (can't remember which, let alone the name) that let's you search your planar deck. (You might notice that I didn't study it to carefully I just saw it while scanning for a card to script)

[friarsol]

Edit: Look at me going all politician with the misleading evasive answers Sorry about that
.

Apology not accepted. (In fact, I'll often use this diplomatic answer tactic, and it is quite entertaining.)

[Hellfish]

I may just have to knuckle down and implement Card Piles in the UI or this could get real hacky real fast... The daunting part is rewriting the VField bits and touching the forge.view.arcane package in general D:

[friarsol]

Hellfish,

It looks like http://magiccards.info/query?q=Fractured+Powerstone is an easy script. If you try to roll a Planar Die in a non-Planechase game, does something still happen?

[Max mtg]

UI home screens are displayed incorrecly on large monitors. The panel moves somewhere to the right and looks misaligned.

Misaligned variants sample: http://img534.imageshack.us/img534/6641/misalign.jpg
Correctly aligned contructed menu (for reference) : http://img717.imageshack.us/img717/5467/rightalign.jpg

Images appear to be downscaled from 1920 px wide to 1024, but misalignment is visible despite of that.

[Hellfish]

Sol: triggers will be run but nothing would care, of course.

Max:sorry about that.I couldn't test beyond 1280x1024 at the time.I'll take a look at the constraints, confusing though they are

[Chris H.]

Max:sorry about that.I couldn't test beyond 1280x1024 at the time.I'll take a look at the constraints, confusing though they are

 
Hey, Hellfish.

It looks like the problem is fairly widespread throughout the views. The lblTitle for the various views are pushed to the right and I think that they would look better if they were centered. I guess that the variant classes were created using the same "ax right" statement as the lblTitle add commands.
 

Archenemy ax right

 

Archenemy ax center

 
It looks like it might be a simple case of searching for "ax right" and replacing it with "ax center".

Here is the old populate method from VSubmenuArchenemy:

Code: Select all

    public void populate() {
        VHomeUI.SINGLETON_INSTANCE.getPnlDisplay().removeAll();
        VHomeUI.SINGLETON_INSTANCE.getPnlDisplay().setLayout(new MigLayout("insets 0, gap 0, wrap 1, ax right"));

        VHomeUI.SINGLETON_INSTANCE.getPnlDisplay().add(lblTitle, "w 80%!, h 40px!, gap 0 0 15px 15px, span 2, ax right");

        for (FDeckChooser fdc : deckChoosers) {
            fdc.populate();
        }

        VHomeUI.SINGLETON_INSTANCE.getPnlDisplay().add(tabPane, "gap 0 0 50px 50px, growx, growy");

        VHomeUI.SINGLETON_INSTANCE.getPnlDisplay().add(pnlStart, "span 1, ax center");

        VHomeUI.SINGLETON_INSTANCE.getPnlDisplay().revalidate();
        VHomeUI.SINGLETON_INSTANCE.getPnlDisplay().repaintSelf();

    }

 
I replaced the two cases of "ax right" with "ax center" and it looks a lot better. I will merge in my change so people can take a peek and see if they agree that this change should be made in other places.