-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
+Allow asking for draw after opponent asked (Closes #13138) #13182
base: master
Are you sure you want to change the base?
Conversation
Some questions :
in GameDrawOffers, and call it in playerIsMostRecentDrawer (Game.scala) ? 2- Also I couldn't find "case class" having "private var" in the code; should I change that to some other type of class ? Final class maybe ? |
yeah, One way to do it without case class GameDrawOffers(white: Set[Ply], black: Set[Ply], lastColor: Option[Color]) But I'm not sure it's a good idea or not (probably not). |
8071cf9
to
5df084d
Compare
Hi lenguyenthanh and thanks for the review :) ! I didn't know that copy was used that much in relation to case class in Scala, and that it is used that way instead of using mutable variables, good to know ! I changed my commit which I think should be much better now |
~Commit updated in relation to comments
5df084d
to
871c419
Compare
@@ -31,12 +31,16 @@ private[game] object Metadata: | |||
val empty = | |||
Metadata(None, None, None, None, None, analysed = false, GameDrawOffers.empty, rules = Set.empty) | |||
|
|||
case class GameDrawOffers(white: Set[Ply], black: Set[Ply]): | |||
case class GameDrawOffers(white: Set[Ply], black: Set[Ply], lastDrawColor: Option[Color]): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isn't that new lastDrawColor
superfluous? it seems it can be inferred from the existing values - highest ply of the 2 sets
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi,
If you want to limit at once per ply per player a draw request, then yes I could change it to do that.
I thought about using the Sets too at first, but then, just imagine,
On a ply "x" :
1- W offers draw, "x" is added to the white set. B decline the offer.
2- B offers draw, "x" is added to the black set. W decline the offer.
3- Who can now offer ? Because looking at the sets, you have no way of knowing [server-side] who offered last, since (the set maximums) are equals. How can we know which was last ? Then let's say we allow to offer when they are equals (max-ply-offer-W == max-ply-offer-B). Then we still don't have a way of knowing who did the last one server-side (and a player could be double-offering in a row). We could start modifying the sets to represent that it is as if a draw was not done for a player during a ply, but this would cause other problems down the line for sure (plus as the draw offers get normalized/annotated [another issue I created, they aren't always networked/visible when reloading #13183], and they would then be missing.
Imagine the scenario where the position is very complex. W sees it is drawish and offers a draw. B declines immediately. Then realized it is drawish and offers a draw. B then cancel as he thought he was wrong (OR W think he was wrong and decline the offer as he thought he was wrong initially). Then both people realized it's a draw. The game is now forced to progressed with two people wanting to draw. I am not sure this is wanted as explained via refering to the wiki in the issue.
It all comes down to whether we want to allow more than one draw offer per player per ply. I think allowing it gives greater freedom to the player with a not so high complexity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want to limit at once per ply per player a draw request, then yes I could change it to do that.
If we go this road, We should consider FIDE rule, that only allow offer the draw in your turn. But it also has some other special case I think.
But, if we don't want to do that (keep the current behavior), in case of both offer draw at a same Ply. We can make them wait til next ply in order to offer another draw. How does that sound?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm good for whatever; I'd just want the official ruling ^^.
EDIT 27-08-2023 : Still awaiting the official ruling.
RE-EDIT 28-09-2023 : Still awaiting official ruling.
RE-RE-EDIT 23-11-2023 : Still awaiting official ruling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in case of both offer draw at a same Ply. We can make them wait til next ply in order to offer another draw.
I prefer the this approach. It makes sense. keep the current behavior, and doesn't required big changes. So, I guess you can just go for it.
No description provided.