Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSG_SWAP_GRAVE_DECK and MSG_REVERSE_DECK are hardcoded and terrible #375

Open
DyXel opened this issue Apr 24, 2021 · 0 comments
Open

MSG_SWAP_GRAVE_DECK and MSG_REVERSE_DECK are hardcoded and terrible #375

DyXel opened this issue Apr 24, 2021 · 0 comments

Comments

@DyXel
Copy link
Contributor

DyXel commented Apr 24, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant