Forge version 1.5.34

[Chris H.]

Tentative target release date: I need to fix my new dev system before I can give an estimate.

[KrazyTheFox]

Alright, I'm getting this change in early so there's plenty of time for testing.

I've committed a change to the way foils are generated. Previously the game would select a printSheet at random from the collection of sheets a booster pack was generated with, then from that sheet it would select a random card. This results in an uneven distribution of card rarities. Basic lands are much more likely to be pulled than they should be, commons aren't nearly common enough, and rares/mythics are actually less common than they should be. Additionally, if I'm correct, sheets with multiples of the same cards would also have that probability factored in (a sheet with 1 basic land and 45 rare lands would be 45 times more likely to generate a foil rare land).

The changes I've implemented collects one of each card from each printSheet and then uses that full list to select a single card from. This results in an equal chance of each card to be selected. As far as I've been able to tell, this is how foils are selected in real boosters.

I've run a simulation that generates 100 million foils using both Forge's old method and the new one, using the set Zendikar as a sample source.

Zendikar stats:

Code: Select all

# of Commons:   101     (43.16%)
# of Uncommons: 60      (25.64%)
# of Rares:     53      (22.65%)
# of Mythics:   15      (06.41%)
# of Basics:    5       (02.14%)


Old method:

Code: Select all

25.00%   Commons:        24,998,341
25.00%   Uncommons:      25,001,545
19.48%   Rares:          19,478,013
05.52%   Mythics:         5,518,816
25.00%   Basics:         25,003,285


New method:

Code: Select all

43.16%  Commons:        43,156,114
25.64%  Uncommons:      25,640,971
22.65%  Rares:          22,654,572
06.41%  Mythics:         6,411,294
02.14%  Basics:          2,137,049


You can see how the foil distribution is now extremely close to the expected number.

If anyone has any other statistics on how the rarity in foils should be distributed, please let me know so I can further update this before the next release.

[drdev]

For anyone who hasn't taken the time to look through the Forge Decks subforum, I can tell you that gos has done an incredible job maintaining zip files of practically every single deck ever posted on a MTG column. I've long wanted to make it easier to download, view, and play these decks without having to do it manually. Plus, for many that have downloaded these types of bulk decks, they would see a significant performance hit on startup, to which we often encouraged them to delete some decks.

I'm happy to share that, after getting inspired today, I have added Net Decks support to both the desktop and mobile versions to make downloading, viewing, and playing these decks extremely easy.

Note that the category names and urls of the zip files are stored in two new files under res/lists/: net_decks.txt and net_decks_commander.txt. This should make it easy for non-developers who want to contribute decks to make them easy to download for our users.

Let me know if I missed any good deck categories or you have any other thoughts on this enhancement.

Thanks.
-Dan

[Agetian]

I'm happy to share that, after getting inspired today, I have added Net Decks support to both the desktop and mobile versions to make downloading, viewing, and playing these decks extremely easy.

This is a sweet enhancement! Great job, Dan, and thanks for your work!

- Agetian

[Hanmac]

the content downloader should be fixed or the missing images provided as extra packages ...

Sets i cant download with the downloader:

• BNG
• C13
• C14
• CNS
• DDM
• DDN
• JOU
• KTK
• M15
• MBP
• PC2
• V14

that does also count for the single images that are unique to this sets

and what do you guys think of my idea to use the reminder images for the backgrounds of the Morph and Manifested cards?

[Fizanko]

That's a great feature drdev !
Often new people have difficulty to find where to put their .dck files, that will be very helpful to them.

[moomarc]

the content downloader should be fixed or the missing images provided as extra packages ...

Sets i cant download with the downloader:

• BNG
• C13
• C14
• CNS
• DDM
• DDN
• JOU
• KTK
• M15
• MBP
• PC2
• V14

that does also count for the single images that are unique to this sets

and what do you guys think of my idea to use the reminder images for the backgrounds of the Morph and Manifested cards?

If any of these sets have been released by the CCGHQ team, please just PM me with the direct links for the HQ fulls. I'll try get around to processing them for Forge, hopefully next weekend. I don't have free time during the week, but if someone could provide the links, I should be able to make time in between work and moving.

Also, Sol, would you please email me the details again for the pet art you want updated. Sorry, got hectic at work and then just lost in the abyss of emails past.

[KrazyTheFox]

Alright, guys, I've been looking at adding token downloading to my high res image downloader, but the way Forge handles file names and lists for those tokens appears to be rather inconsistent (one example being some cards not listing token file names while others do). Is anyone opposed to me working out a better system for this?

[Xitax]

The token naming scheme is intentional. I don't want to revisit it.

If no token name is present in the card script, then the token chosen is "default". If a token name is specified, then the token name is chosen for a specific set. Usually the first printing of a vanilla-ish token is default.

But disregarding pedantic arguments over which tokens should be default or not, now that WoTC is printing tokens for everything that needs one, there should be no need to ever revisit the old tokens, many of which never had an official printing.

But to answer your programming question, the formula for a token name (if it is not specified) is formulaic, so you should be able to figure it out easily.

[KrazyTheFox]

The token naming scheme is intentional. I don't want to revisit it.

If no token name is present in the card script, then the token chosen is "default". If a token name is specified, then the token name is chosen for a specific set. Usually the first printing of a vanilla-ish token is default.

But disregarding pedantic arguments over which tokens should be default or not, now that WoTC is printing tokens for everything that needs one, there should be no need to ever revisit the old tokens, many of which never had an official printing.

But to answer your programming question, the formula for a token name (if it is not specified) is formulaic, so you should be able to figure it out easily.

The unspecified tokens are sorta easy (but still a pain), yes, but it's the specified ones that throw a wrench into the works. I'll work around it, I suppose, but I just think it could be done better (for example, not having to specify a name at all).

[elcnesh]

I've just made a huge commit (r28719); sorry I couldn't split it up, but all the changes were interlocked in some files (like Card), so I just did it all in once to prevent compile errors. Some remarks:

• The code for continuous effects requires some cleanup in the applying and removing of those effects; however I first want to verify that it all works as it should according to game rules right now. Have tested many complex interactions of Humility, Opalescence, March of the Machines, Enchanted Evening and Mycosynth Lattice, and it all seems to work exactly as the rules specify. More testing is always welcome though!
• The colour code has been refactored to match other parts of the code. Only one thing I was wondering is why the colour changes are stored in a CardState and not in a Card. I think that if you make a creature blue and then turn it face-down, the face-down creature is also blue, which would definitely make the changes (not the base colour) a Card property. Any thoughts?
• For reference: the tracker for a particular TrackableObject can be null, in which case it treats itself as never being frozen.

[Marek14]

I've just made a huge commit (r28719); sorry I couldn't split it up, but all the changes were interlocked in some files (like Card), so I just did it all in once to prevent compile errors. Some remarks:

• The code for continuous effects requires some cleanup in the applying and removing of those effects; however I first want to verify that it all works as it should according to game rules right now. Have tested many complex interactions of Humility, Opalescence, March of the Machines, Enchanted Evening and Mycosynth Lattice, and it all seems to work exactly as the rules specify. More testing is always welcome though!
• The colour code has been refactored to match other parts of the code. Only one thing I was wondering is why the colour changes are stored in a CardState and not in a Card. I think that if you make a creature blue and then turn it face-down, the face-down creature is also blue, which would definitely make the changes (not the base colour) a Card property. Any thoughts?
• For reference: the tracker for a particular TrackableObject can be null, in which case it treats itself as never being frozen.

Important interactions of continuous effects are also multiple changes of land subtypes, for example Conversion + Phantasmal Terrain.

Face-down creatures should retain anything that's not from the card itself, so color changes are included.

Note that I was testing a deck using Magnetic Web and Gorilla Berserkers, and it didn't work correctly together (Gorilla Berserkers had a magnet counter, so did one opponent's creature, and he didn't block -- he should be forced to block Gorilla Berserkers with that creature plus two others). Is that because you didn't get to finalize the blocking code yet?

It was this deck -- seems like fun deck for testing similar interactions:

Code: Select all

[metadata]
Name=AttractiveBeefyBees.deq
[general]
Constructed
[main]
4 Gorilla Berserkers
4 Magnetic Web
1 Gaea's Cradle
2 Shivan Phoenix
2 Weatherseed Treefolk
4 Spike Weaver
4 Squirrel Nest
4 Anurid Swarmsnapper
1 Heartbeat of Spring
3 Tide of War
1 Pendelhaven
4 Karplusan Forest
4 Hornet Cannon
4 Kamahl, Fist of Krosa
12 Forest
6 Mountain
[sideboard]


[elcnesh]

Face-down creatures should retain anything that's not from the card itself, so color changes are included.

Thanks, I'll see if I can change that.

Note that I was testing a deck using Magnetic Web and Gorilla Berserkers, and it didn't work correctly together (Gorilla Berserkers had a magnet counter, so did one opponent's creature, and he didn't block -- he should be forced to block Gorilla Berserkers with that creature plus two others). Is that because you didn't get to finalize the blocking code yet?

Yup, unfortunately that's the case... Still haven't been able to come up with an algorithm that's fast enough to work on a large number of creatures while still being correct in corner cases. For blockers this is much harder as one creature can sometimes block multiple attackers, something which is never the case with creatures attacking players/planeswalkers.

[Agetian]

I committed an experimental tweak in r28735 that corrects the draft order for older sets (pre-Mirrodin Besieged) in Quest Draft Tournaments according to this:
http://mtgsalvation.gamepedia.com/Mirrodin_Besieged
I set the date to test against to the date of Scars of Mirrodin, not to the date of Mirrodin Besieged, to account for the fact that e.g. MBS/SOM/SOM format includes Scars of Mirrodin cards (older than Mirrodin Besieged) but has to be drafted in the new order (MBS/SOM/SOM, not SOM/SOM/MBS as would have been the case pre-MBS).

I hope I understood it correctly and it seems to work fine in my tests, but please review and feel free to update if necessary (in case I misunderstood something, for instance).

- Agetian

[KrazyTheFox]

I committed an experimental tweak in r28735 that corrects the draft order for older sets (pre-Mirrodin Besieged) in Quest Draft Tournaments according to this:
http://mtgsalvation.gamepedia.com/Mirrodin_Besieged
I set the date to test against to the date of Scars of Mirrodin, not to the date of Mirrodin Besieged, to account for the fact that e.g. MBS/SOM/SOM format includes Scars of Mirrodin cards (older than Mirrodin Besieged) but has to be drafted in the new order (MBS/SOM/SOM, not SOM/SOM/MBS as would have been the case pre-MBS).

I hope I understood it correctly and it seems to work fine in my tests, but please review and feel free to update if necessary (in case I misunderstood something, for instance).

- Agetian

That looks correct!