...that's one in 26 packs instead of 53 twice as much as expected, I used random incorrectly?Indeed, updating the number and trying again gave 20 nonfoil and 1 foil Specials.

ratio of other cards in the second batch was also correct, VMA testing complete.

Next, Time Spiral....is crashing. "No cards were found on sheet, TimeSpiral TSP". I haven't touched that, though. Did you? ...You sure did. You moved splitting the string from AFTER generating the sheetkey to before. That's not going to work, it uses that variable and needs it unsplitted. Using a simpler string splitting code is a great idea. Moving lines elsewhere however is never a good idea.

368 rares, 727 Uncommons, 1072 commons.That's odd, it's as if Rare and Uncommon slots were separate, even though they are shared....I have to assume even though the ratio of U to R is 3 to 1, the number of them are not equal, so the overall result is closer to 1 to 2. To prove this, I compare the nonfoils : 659 rares for 1341 uncommons. Indeed, this is the correct ratio, there are more rares in the set than uncommons.

Skipping Masques - it's a generic set with no interesting slots to test for.

This is closer to what's expected tho the RNG still favors uncommons over commons, the difference is only 7 now if counting lands (which do consume the common roll).

...speaking of consuming common rolls. I think that's not the best idea. I'm going to rewrite that part so each type gets it's own chance instead of being a subset of commons. This method results in 1/2/2/1 in Time Spiral for example (R/U/C/S) when I believe it should be 1/2/3/1.

So far so good, it seems! Thanks for catching up on the accidentally moved split! Once your updated code is fully ready and work out the remaining kinks, please post the patch here, I'll take a look tomorrow.

P.S. Yes, if you can decouple the special/basic land chances from everything else it'll make the code cleaner and more intuitive to tweak, so please do that if possible

Moving the chance for specials outside of commons is done.Also investigated the net a bit more for foil basic lands, I think the most reliable I found was "basic lands are printed on the foil common sheet, one of each type", that makes the chance 20/130 in a 110 common card set.

So...test Conspiracy, huh. Have no idea what that set should contain but let's do it.

1000 packs yield :

9 Mythics, 31 rares, 75 uncommons, 109 commons.

That's twice the expected mythic rares, the rest look fine.Another roll, 10k packs, 33 Mythics, which is correct. The first was just a lucky pull.However...I don't think whatever appears in the "Draft matters" slot will be able to become foils...nor do I think these cards are even supported by Forge at the moment so that's fine I guess? I believe I didn't get those cards, not even the nonfoils. Yeah there are a bunch of warnings for unsupported cards being removed.Eventually if these cards do get support, they will need to have a foil slot roll case defined for them like DFC and Timeshifted.

Either way, what can work, works, so here it is, the completed, tested patch file :

PS : I believe we should integrate this, as we don't know enough to add more details at the moment, and it's a huge progress.

Later, there will be more to do, but these will be hard to figure out (not the code, but the actual contents of products) :-find better information about foil chances in various special slots-investigate if foil basic lands appear in only packs that had a basic land slot, or all large sets that have basic lands, or all sets, in case of small sets, replaced by the block's large set lands. I honestly don't remember this one - it's most likely not the first but I have no idea if it's the second or third.-investigate foil ratios in nonbooster products, (tournament packs) and implement the guaranteed foil basic land in precon decks of certain editions.-Investigate the chance of pulling a foil alter art Planeshift card, and implement that (making sure they are always foil, as that's how it worked.)

Rating filters shouldn't be very hard to integrate, I'll take a look at them next, but they need the actual star sprites, and I'm not really a GUI coder, so we might need someone else's assistance to get that project fully ready for integration. As for the code itself, I'll take a look when the opportunity presents itself.

Did anyone actually made some star sprites for it? If not, should I? (Probably won't look as good as the mana symbols though.)...might be best to just search for "star" in google and pick whatever looks appropriate.

We have a star sprite already in Forge which is used for favoriting decks and stuff (there's an empty star and a filled yellow star). If you can hook that up somehow to your code and display one to five stars (or unfilled/filled stars depending on the rating), would be nice. I haven't really touched that part of the code though, so I have no idea how exactly to accomplish that (and whether it is even straightforward enough to use that sprite for the purpose). But that's an idea for you to potentially explore EDIT: Check out FSkinProp.IMG_STAR_* constants for the definitions of those two sprites I mentioned above.

Well, I can display one. One to five, not really.It works like this : You define a constant which defines the image - It has a filename and a rectangle within that file. Then specify that constant for the filter.So if we want one to five, we need to actually have a group of 5 of those in the image. Or, dig out the code parts that display in the filter and make this an exception which would be a pretty ugly hack.I believe the best option is to simply add the images we want into the Sprite_icons.jpg file at an unused spot, or even better use a new file. (This would only work for the default skin though. Not sure what happens if an image is missing from an optional skin, if it reverts to the default that's fine.)

If that's acceptable, we can have a rating of 1 display an unfilled star and the rest a filled star but that's not very informative.

Nice!I know for a fact that if an unused spot in sprite_icons.jpg is used, it'll correctly handle the skins too (if the relevant fragment is not in the sprite_icons.jpg of a custom skin, then it'll be loaded from the default skin file instead). Also, I know that generally skin-based files are loaded from the default skin if they're absent in the custom skin.

And this is the image file you have to add to skins/default, eclipse failed to include this in the patch file, unfortunately patches only support plain text files it seems.

sprite_favicons.png (8.76 KiB) Viewed 975 times

From what I saw in the code, this shouldn't affect skins, albeit it might not come with the ability to override the icons in custom skins either. I didn't dig that deep into it to tell - we can worry about that if someone actually requests that as a feature

Ok, a ton of effort went into reformatting the code here, but I think I finally got this.Please use this reformatted variant for your further modifications and please try to stick to the code formatting style that is used.

Now, I identified several issues with the code while testing it:

1. Even though the rating filters are meant to be used in quest mode, it is possible to enable the relevant filter in other modes (e.g. Constructed). If this is done and one of the star rating icons is activated, the game crashes. The expected behavior is, ideally, for the rating filter not to appear at all in any game mode where it would do nothing and/or crash.

2. It is only possible to rate cards while they are in the inventory, but it's not possible to assign ratings to cards when they are in your deck. While not critical, it's definitely not very convenient, especially considering that the personal rating filter is available in the deck portion of the editor.

3. The "1 star rating" icon is nearly invisible on the default theme (and most likely on any other dark-colored theme), maybe a thin white outline around the star would help (the same color as the number), otherwise it'd be invisible on the dark background and only the number "1" will be seen.