Deck.split() weirdness

So, I'm trying to take a deck of cards, split it into piles, and then shuffle one each of another stack of cards into the piles. The split() function is perfect, as I want the piles to end up 90* to each other anyway. So the script works like this so far:

1. Get the two decks from the zones they're sitting in (deck and discard zones)
2. Count the cards in the "discard" deck
3. Split the main deck by that count
4. Move one each of the "discard" cards into each pile
5. Shuffle the piles

So far so good. The game itself expects the "small" plies to be on the bottom. This, with the split() function, is behaving a bit weird though - the counts are a little bizarre. In my test setup (and how the game will start), I have 48 cards in the main deck, with 5 cards to split in from the "discard" deck. This results in splitting the main deck into 5 piles, of 10,10,10,9,9.

I get piles that size, but if I use a for loop to get which index of the resulting table has which counts, I get the following - indexes 1, 2, and 5 have 10 cards, while 3 and 4 have 9. Even more maddeningly, after a fair amount of testing, I find that Index 1 is the second pile from the bottom, while Index 5 is the bottom pile! The piles count UP from the second from the bottom, and wrap around from the top (which is index 4) back to the bottom!

Complicate matters with the fact that the number of cards in either deck could vary during the game (more "deck" cards to split, or more "discard" cards to force more piles to be made), so I'd like to TRY to avoid some sort of hacky solution.

Anyone have any idea what is going on? Any suggestions about how to get things the way I want them? Pastebin with the code: https://pastebin.com/Q7V0y1ET

Solution 1:

My suggestion:

Be liberal in what you accept, and conservative in what you emit.

In other words, make no assumptions about the order and size of stacks.

1. Put the references to the stacks in an array,
2. sort that array by size,
3. Place the elements of the sorted array in that order on top of eachother.

Possible cause (untested!):

These two lines of code jump out at me:

for i=1, splits do
    print(i, " = ", deck1split[i].getQuantity())

Computers usually count from zero. Tabletop-simulator may be trying to 'help' you by wrapping your array indexes for you. It makes sense, index 5 is actually index 0, which is at the bottom of the pile and 10 long. What happens if you countfor i=0, splits-1?

If that works, then a much simpler solution is to count backwards from splits-1 to zero. Mind to test if this works rigorously, with various sizes of pile, both divisible and indivisible by the number of splits.

Solution 2:

I came up with two solutions for this - one clever, one practical.

Clever first:

Get the remainder that will make the split uneven (so remainder=deck1.getQuantity() % splits). If the remainder isn't 0, take that many cards and put them somewhere else (after shuffling, I just put them on top of Deck 2). Split deck one. Return the cards to the appropriate piles (in TTS's weird case, that'd be for i=splits-1, 1, -1 do).

The problem I ran into with this, which did indeed work as desired, is TTS's weird physics with piles of cards on top of each other that want to merge into a single deck. On load of a saved game I would always end up with 2 piles (one straight, one at 90 degrees). I would also sometimes draw a card and have some sort of deck-merge happen between two piles that were otherwise separated by a pile at 90 degrees to them.

This led to the practical (and simple) solution:

Make a secondary container (you can call it "Player Deck Piles" in this case) Split deck 1 appropriately. Load the resulting piles into the container, leaving the bottom one (so, we again use for i=splits-1, 1, -1 do).

You always want one pile in play, and for whatever reason the piles with more cards end up on the bottom (despite the fact that the bottom pile will be the highest index, and the second to the bottom the lowest). Seems to work like a charm.