You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These two core messages are hardcoded in the sense that they were implemented with very specific functionality in mind and have no room for generic use by other possible effects, MSG_SWAP_GRAVE_DECK is specially bad since it depends on the client state and even without that issue, its handling is very complex design wise.
My proposition is a new message that is fully generic and provides the necessary functionality to implement these two messages (and more) in an effect-agnostic way: MSG_PILE_SPLICE.
uint32 reason; // Core reason for the splices to occur. eg: REASON_EFFECT, REASON_DRAW.
uint32 splice_count; // Numbers of splices to perform, sequentially.// The following data is repeated a number of times equal to splice_count.// From where to splice a pile.
uint8 from_con;
uint32 from_loc;
uint32 from_seq; // 0-index from where to start splicing.
uint32 from_size; // non-0 amount of cards to splice.// Where the splice will be placed in a different pile or the same one.
uint8 to_con;
uint32 to_loc;
uint32 to_seq;
uint8 reverse; // Reverse the spliced sequence before insertion.
With such a message, MSG_REVERSE_DECK would effectively become a in-place splice (both from and to locations are the same), from_size would be the size of the pile we are reversing and reverse would be 1 (true). Additional information (such as the deck top) would be provided by a query.
MSG_SWAP_GRAVE_DECK could be implemented as a number of operations where the graveyard cards are spliced to either the extra deck or main deck depending on where they go, and then a final splice from the main deck to the graveyard.
other messages such as MSG_DRAW (or operations that move several cards at once from different piles) can also be implemented in term of splices, in the case of MSG_DRAW, splicing the top of the deck and inserting it on top of the hand (right most card) reversed would be enough.
I can provide more explanation on how the message would work if interested, although with a little knowledge on how list splicing works it should be enough to understand the structure. Thoughts and opinions appreciated.
The text was updated successfully, but these errors were encountered:
These two core messages are hardcoded in the sense that they were implemented with very specific functionality in mind and have no room for generic use by other possible effects,
MSG_SWAP_GRAVE_DECK
is specially bad since it depends on the client state and even without that issue, its handling is very complex design wise.My proposition is a new message that is fully generic and provides the necessary functionality to implement these two messages (and more) in an effect-agnostic way:
MSG_PILE_SPLICE
.With such a message,
MSG_REVERSE_DECK
would effectively become a in-place splice (bothfrom
andto
locations are the same),from_size
would be the size of the pile we are reversing andreverse
would be 1 (true). Additional information (such as the deck top) would be provided by a query.MSG_SWAP_GRAVE_DECK
could be implemented as a number of operations where the graveyard cards are spliced to either the extra deck or main deck depending on where they go, and then a final splice from the main deck to the graveyard.other messages such as
MSG_DRAW
(or operations that move several cards at once from different piles) can also be implemented in term of splices, in the case ofMSG_DRAW
, splicing the top of the deck and inserting it on top of the hand (right most card) reversed would be enough.I can provide more explanation on how the message would work if interested, although with a little knowledge on how list splicing works it should be enough to understand the structure. Thoughts and opinions appreciated.
The text was updated successfully, but these errors were encountered: