Page 7 of 16

Re: Implementing variants

PostPosted: 30 Nov 2012, 14:50
by moomarc
gos wrote:I would like to be able to specify a default Avatar for Vanguard decks in the .dck file.

I post a lot of decks from DailyMTG (I hope everyone knows this by now :)), and during a certain period, quite a few Vanguard decks built for specific Avatars were posted in the Online Column of the day (mostly Into the Æther). Being able to specify a default Avatar in the .dck file would save everyone the trouble of referring to a web page to know which Avatar the deck was intended for. I hope the existence of a goodly number of pre-existing Vanguard decks will encourage people to play the new variant, especially those who prefer to play constructed, and this will make life a little bit easier for them.

Cheers and thanks for all the good work!
Once Hellfish has the Commander section of decks working I was planning to have a look to see whether it would be possible to make it so that if a deck has a Vanguard avatar in the Commander slot, then the list would only show that one. But having it select the card as the default would be even better, because then you can still swap it out if you want without having to build a new deck if you want.

Re: Implementing variants

PostPosted: 30 Nov 2012, 15:23
by Hellfish
I'm thinking we could add [vanguard] deck section for the default avatar and a checkbox in the settings tab "Use default avatar if possible." that applies to all players. We could do the same for plane and scheme decks later.

EDIT: We should probably let the deck editor add default avatar too, then.

EDIT: Done. (Except for the deck editor part, notepad it for the time being. Use "[avatar]" as a header for the section)
Now, if you want to use deck-default avatars, you check a box in the settings panel and Forge will check each player's deck on start. If it finds an avatar there, that avatar will override the choice in that player's list and notify you.

Re: Implementing variants

PostPosted: 01 Dec 2012, 20:37
by Hellfish
Moving on to Schemes, I think they'll be handled basically the way avatars are now in that a default scheme deck is included in a regular deck file and can be overridden with a separate scheme deck. Thoughts?

Re: Implementing variants

PostPosted: 01 Dec 2012, 22:17
by Sloth
Hellfish wrote:Moving on to Schemes, I think they'll be handled basically the way avatars are now in that a default scheme deck is included in a regular deck file and can be overridden with a separate scheme deck. Thoughts?
Works great already! Thanks a lot Hellfish.

Re: Implementing variants

PostPosted: 01 Dec 2012, 22:52
by Hellfish
Glad you like it. :)
Enabling Scheme cards is really only part of it, though. I'm more worried about implementing the notion of teams (Sort of there already, it's just always AIs vs Humans :mrgreen: ) and then the Shared Team Turns Option (rule 805) for the authentic experience :D

Re: Implementing variants

PostPosted: 02 Dec 2012, 21:15
by Hellfish
Currently trying to implement AF_SetInMotion and ReplaceSetInMotion for Plots That Span Centuries.. I'm getting a weird feeling of Deja Vu about this bug I'm trying to squash where it's like the replacing ability gets run multiple times.
(If I replace one Setting Into Motion event with 3 SIM events, I get six SIMs in game. If I replace one with two, I get three. If I replace one with one, I get one.)

NOT REALLY EDIT: If I make the replacement an activated ability, I get 42 SIMs. :|

ACTUAL EDIT: Whew, found the problem. All previous schemes triggered on *any* schemes being set in motion.They didn't actually get set in motion again.
Non-ongoing schemes must from now on specify that they trigger on themselves being set in motion

Re: Implementing variants

PostPosted: 04 Dec 2012, 10:40
by moomarc
Just a heads-up that I've changed getDefinedPlayer so that Opponent returns all opponents (uses addAll(...getOpponents()) instead of add(sa.getActivatingPlayer().getOpponent()). I did this for cards like Words of Wisdom, to make the "each other player" part functional in multiplayer where it was previously just making the first opponent draw.

Is there any reason this wasn't done before or are there any scenarios I should check? I could just add a new defined player type for EachOtherPlayer, but couldn't think of any time Opponent should only return the first player.

Edit: Oh, and I posted here and committed to the Schemes thread because I did this mostly for Embrace My Diabolical Vision scheme. On a side not there are decently trimmed images available now for set and non-set downloads of Archenemy cards.

Re: Implementing variants

PostPosted: 04 Dec 2012, 13:19
by friarsol
marc, shouldn't each other player be more like Player.notSelf?

Re: Implementing variants

PostPosted: 04 Dec 2012, 13:29
by moomarc
friarsol wrote:marc, shouldn't each other player be more like Player.notSelf?
That makes sense, thanks for pointing it out. Either way, I have come across another place where Opponent wasn't interacting correctly in multiplayer. For cards like Black Vise, the list of opponents to choose from only has one opponent without the modification.

Re: Implementing variants

PostPosted: 04 Dec 2012, 15:09
by friarsol
moomarc wrote:
friarsol wrote:marc, shouldn't each other player be more like Player.notSelf?
That makes sense, thanks for pointing it out. Either way, I have come across another place where Opponent wasn't interacting correctly in multiplayer. For cards like Black Vise, the list of opponents to choose from only has one opponent without the modification.
Yea I think the change never happened to keep things simple until we could slowly migrate cards multiplayer.

Each other player may actually be Player.Other (or maybe Player.notYou) Self is used for cards.

Re: Implementing variants

PostPosted: 04 Dec 2012, 19:46
by moomarc
friarsol wrote:
moomarc wrote:
friarsol wrote:marc, shouldn't each other player be more like Player.notSelf?
That makes sense, thanks for pointing it out. Either way, I have come across another place where Opponent wasn't interacting correctly in multiplayer. For cards like Black Vise, the list of opponents to choose from only has one opponent without the modification.
Yea I think the change never happened to keep things simple until we could slowly migrate cards multiplayer.

Each other player may actually be Player.Other (or maybe Player.notYou) Self is used for cards.
Okay, I decided to go with Player.Other (and just tweaked the Player.Opponent so that it returns false if the player is not hostile towards you.) I also reverted my earlier change to Opponent in getDefinedPlayers, and everything seems to be working fine still. Once the branch is merged I'll start going through the existing Defined$Opponent cases and test them in multiplayer, fixing where necessary. Going to be slow, and I'm expecting to have a bit less free time over the next while, but it will be good to finally get it done.

I'm loving the variants so thanks to all involved!

Re: Implementing variants

PostPosted: 04 Dec 2012, 20:39
by Sloth
moomarc wrote: Once the branch is merged...
Isn't the branch ripe for merging already? I don't see any problems.

Re: Implementing variants

PostPosted: 04 Dec 2012, 20:56
by Hellfish
The case against reintegration would be that
1) You can't specify default avatars/scheme decks without notepadding the deck file.
2) Minor point, but since Teams & Shared Team Turns Option aren't implemented we technically don't have proper Archenemy yet. Also,Supervillain Rumble would be nice(and easy).

I don't mind of you guys would rather see it in a public beta for public testing sooner,though. :)

Re: Implementing variants

PostPosted: 04 Dec 2012, 21:01
by friarsol
Hellfish wrote:The case against reintegration would be that
1) You can't specify default avatars/scheme decks without notepadding the deck file.
2) Minor point, but since Teams & Shared Team Turns Option aren't implemented we technically don't have proper Archenemy yet. Also,Supervillain Rumble would be nice(and easy).

I don't mind of you guys would rather see it in a public beta for public testing sooner,though. :)
I don't think point 2 is worth waiting for (and may be larger than you imagine with shared team turns).

And point 1 isn't major as far as snapshots go. We'll definitely want that soon, but I think the more eyes that can get on the base stuff the better.

Re: Implementing variants

PostPosted: 04 Dec 2012, 21:05
by moomarc
Sloth wrote:
moomarc wrote: Once the branch is merged...
Isn't the branch ripe for merging already? I don't see any problems.
I'm inclined to think its ready. Only thing I can think of that I forgot to mention before is that in Archenemy games it seems that you're getting an additional 10 life per opponent instead of per opponent after the first.