Results 1 to 9 of 9

Thread: Sorting a Deck Causes it to Have a New GUID

  1. #1

    Sorting a Deck Causes it to Have a New GUID

    First time poster. Long time Python programmer and I am really enjoying Lua, TTS, and this forum!

    I have a deck of 39 cards -- 3 of which are End of Deck (EOD) marker cards. Reading other posts it sounded like I needed to add these EOD cards to keep the deck container from "disappearing" when the next to last "usable" card was drawn from it.

    After shuffling the deck, I search it to find the 3 EOD cards, I remove the EOD cards, raise the deck above the board, place the EOD cards under the raised deck, and then drop the deck on top of them -- after doing this, the deck no longer has the same GUID and of course its Name and Description fields are now blank.

    It seems that my method of searching and sorting is to blame here. Is there a way of moving the 3 EOD cards to the bottom of the deck that does not effectively cause the deck object to change into a new/different object?

    Thanks

  2. #2
    Welcome to the community urenoiro

    It might be because you are effectively adding a shuffled deck . . . to a 3 card EOD deck thus merging 2 decks together. if you were to place your shuffled deck on your EOD cards one at a time it should avoid this I think.

    Not a very elegant solution though

  3. #3
    Join Date
    May 2016
    Posts
    1,072
    Also, I am not 100% on this, but I think whatever card or deck is on the bottom when they combine determines which the deck is created on. So having a card or cards on the bottom may reform the deck no matter what, but maybe only when combining a whole deck, not one by one (Like Lucky seven suggests to try)

    If lucky's method doesn't work, then I would recommend using a timer and re-obtaining the deck (and re applying its name) and updating the deck GUID in the script. It is a complicated solution though so hopefully you can avoid it.

  4. #4
    I haven't really looked at this before.

    But playing around with a deck of cards, splitting and joining them in different ways whilst checking the GUID's produced.

    It looks like you retain the original GUID of a deck if its placed on top of a single card.

    but loses it if you place it on a deck of 2 or more cards then the GUID of the bottom deck is used for the new stack of cards.

    then I would recommend using a timer and re-obtaining the deck (and re applying its name) and updating the deck GUID in the script. It is a complicated solution though so hopefully you can avoid it.
    whilst this might be more complicated to set up I imagine it will give you something a bit more pleasing to look at than adding your bottom cards one at a time to retain your GUID. So it might be worth considering going down this route if no other solution presents itself

  5. #5
    Thanks for the quick response Lucky Seven and Mr Stump.

    My observations correlate with Lucky Seven's experimentation -- I observe the raised deck to still have the original GUID and it is not until the deck drops onto the 3 EOD cards that it changes GUIDs.

    I am effectively re-acquiring the new deck and updating its Name and Description after the sort, which works, but then of course the new GUID must be maintained. I think I prefer this over dropping the deck on a single card and then raising it up for the next card, etc.

    I was confused by this effect at first because I had the sorting code attached to the deck itself rather than in Global as it is now. So that when the deck changed GUIDs I was editing a script attached to the old GUID not the new GUID.

    I appreciate the feedback. Thanks. At least I understand what is going on now.

  6. #6
    Well, my curiosity got the better of me, and I had to try an algorithm that did NOT cause the GUID to change.

    Lucky Seven is quite correct. If I drop the raised deck on only a single card, then the GUID does not change -- its funny to watch the deck raising and lowering on each card -- but it works. The GUID does not change.

  7. #7
    It's a bit frustrating dealing with this, but I started getting away from using guids with cards when I can, simply because of this.

    The methods are many, and most have been discussed on this forum.

    I personally use scripting zones to find and reacquire any decks that have been dissolved, in a similar manner that MrStump is referring to. This way the only guids I ever manually write into the script are those of the script zones -- the deck guids are dynamically obtained and carried in memory, and ultimately are expendable. And when I need to, I use placeholder objects (like a player mat) under the deck to move around the scripted zone when dropped so the decks can stay mobile.

    But it all depends on the game, how the decks are used, and which method you think is the most efficient workaround... until they overhaul how decks are handled (which might be never -- i think it's low priority because of how much would have to be changed in their oldest code to make it happen).

  8. #8
    I agree scripting zones work well for reacquiring decks that have changed GUIDs. Does this mean that a script (associated with a deck) is lost when the GUID of the deck changes?

  9. #9
    Think of the deck as it's own object -- just a bag with the cards stored in it. When it destroys (draw to last card, dropped on another deck, etc), the object destroys : name, description, guid, scripts, etc on that deck also destroy.

    One thing you can do though, similar to reacquiring GUIDs for a deck, you can also then set variables for that new deck -- name, description, and the scripts on it. Can't remember the variable name off the top of my head but it's in the documentation for objects.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •