JannLee accepted the crazyhouse challenge !

[Vinvin20]

The match will be play on Lichess, Saturday 6pm GMT.
Conditions : 10 games, time control 3m+2s.

I'll manually operate the latest SF-zh on my computer (6*4GHz) inside Chrome, using a couple of moves from Lichess opening book.
I'll manage the time myself : around 10 seconds/move in the opening and around 5 sec/move in the middlegame.

JannLee account : https://fr.lichess.org/@/JannLee
My account : https://fr.lichess.org/@/Vinvin

For information , JannLee beat SF-zh (0.5 sec / 1 core) , score 8-2 , 3 weeks ago, video here : https://www.youtube.com/watch?v=VTNAHmlQDXA

[ianfab]

Thanks for arranging this, it will be very interesting to see how it will go. If there is no bug/regression, I think Stockfish will crush him, because the improvements since last time and the longer time control should amount to 400-600 Elo compared to the 8-2 defeat. Unfortunately, I won't be able to watch it live (ironically, because I will be playing chess), but I am looking forward to watching the games on lichess or youtube afterwards.

How many nodes per second do you get with your machine (e.g. in the starting position)?

[Vinvin20]

How many nodes per second do you get with your machine (e.g. in the starting position)?

Around 4900-5000 knodes/s

[ianfab]

Thank you. Well, this should be more than enough, but let's see...

[isaacl]

pnacl performance is significantly lower than a native build. Why not type the moves or use a uci board to run stockfish natively?

But if you insist on chrome, I'd suggest Chrome Canary. There's a performance improvement that hasn't reached stable channel yet.

[Vinvin20]

pnacl performance is significantly lower than a native build.

Last time I check with Chess, SF was around 30% slower on PNACl (that's around -30 Elo), not a big lost.

Why not type the moves or use a uci board to run stockfish natively?

I didn't found an easy way to set up Stockfish in a graphical interface ( Winboard ? ) yet.

[Vinvin20]

Stream will be here : https://www.youtube.com/watch?v=wkowG9AmGUs

[ianfab]

@Vinvin20 XBoard with the most recent UCI2WB adapter works well for me with Stockfish, so I think it should also work in Winboard. You can even play variants that are not supported by XBoard itself, but by Stockfish (like horde chess).

[Vinvin20]

Is there some doc to explain step-by-step how to interface SF-zh and WB ?
I will be quite busy until the match.

[sf-x]

Winboard-AA package from H.G.M. works out of the box for me (after replacing engine with 32-bit one).. See Stalkchess forum.

[Vinvin20]

I would want to get a compilation of SF-zh for Windows 64Bits too ...

[sf-x]

#131 (comment)

[Vinvin20]

Thanks, I got it !

[ddugovic]

I'll try to figure out how to compile bee468b for Windows from my Linux PC... I've spent hours before with no luck.

As far as I know, latest "stable" release tested at 120s + 1.2s and at ? + ?s is bee468b.

[scchess]

What's the best GUI for SF crazyhouse?

[ddugovic]

Good question. The only compliant GUI I'm aware of is http://lichess.org/ as I have not tested whether WinBoard now supports UCI.

I've heard something about CuteChess but I am unfamiliar.

[scchess]

That's bad because it's not easy to hook up a new variant engine with the web server... Is there anything we can do?

[ddugovic]

Yes, I'd appreciate help figuring out, "Does Stockfish work with CuteChess?" However, CuteChess' readme states:

The GUI doesn't have a binary release at this time.

so it looks like simply installing CuteChess could be a struggle for non-developers.

Alternatively, maybe it's possible to connect cutechess-cli to my FICS clone at relaychess.org:5000 and use WinBoard-4.5TM.exe GUI to connect to the same server and play the games that way.

[alwey]

@ddugovic: Which platform (OS) is to be used for cutechess / cutechess-cli?

[scchess]

@alwey cutechess-cli has binary for all major platforms. But the GUI doesn't work. We have a framework for playing automatic matches, but very hard for a human player to try the engine.

[ianfab]

XBoard/Winboard usually works well with Stockfish as explained in this comment. For testing, however, I do not want to rely on a GUI and hence use scripts.

[ianfab]

Even though 90% of the discussion in the last weeks is about crazyhouse, it is only one of many supported variants and for convenience I want to have one solution for all with regard to testing patches. That is why have not switched to CuteChess yet, although I have tried it once for crazyhouse and it worked well.

To avoid confusion: This post refers to a deleted comment.

[alwey]

@ianfab : I am just working on cutechess support for Threecheck, Horde (both ready for PR and review: today or tomorrow), Suicide, Giveaway, Anti (these still have some issues).

Using own scripts is good, cutechess might then be an additional tool.

[ianfab]

@alwey Thanks, that is good news.

[alwey]

@ianfab : You are welcome. I will have to discuss with maintainers of cutechess on one hand and with you and the other developers here some details (regarding compatibility, extensibilty). For example there may be a variant name mismatch threecheck and 3check. Cutechess currently is all too strict by requiring all engines to use exactly the same variant name. This is a known open issue in the list.

[ianfab]

There have been some discussions on FENs, move strings, variant names, UCI option names, etc. and there is a consensus with @HGMuller on most parts with respect to compatibility to XBoard/Winboard. Since there are only very few standards for variants, compatibility between different engines and GUIs often is difficult to achieve.

[alwey]

@ianfab: Exactly: I followed the discussion with @HGMuller. He suggested to use an extended FEN format for three-check with reverse counters after the en passant field (like 3+3). To use backward counters is a clever idea. Stockfish uses this type of FEN now. Lichess uses forward counters appended to the FEN (like +0+0). I used the backwards counters (3+3) but I suggest to put them behind the standard FEN so you have upwards compatibility with standard chess data. You can use standard data, books etc. The cutechess reader can read Lichess format, HGM/Stockfish format and this proposed cutechess work format.

[ddugovic]

@Vinvin20 I'm glad to see you have it; I'm testing WinBoard right now using instructions from #151 which suggest there is a problem! (Sorry my attention is somewhat divided between 14 open issues.)

[HGMuller]

Op 12/3/2016 om 6:35 PM schreef Daniel Dugovic:

@Vinvin20 <https://github.com/Vinvin20> I'm glad to see you have it; I'm testing WinBoard right now using instructions from #151 <#151> which suggest there is a problem! (Sorry my attention is somewhat divided between 14 open issues.)

Note you should use a very recent version of UCI2WB, which implements the UCI_Variant option. I created a package with WinBoard, UCI2WB and Stockfish-variant, downloadable from http://hgm.nubati.net/WinBoard-AA.zip . This is pre-configured to use UCI2WB as primary adapter for all UCI engines, with Stockfish-variant registered as one of the selectable engines. One thing that is not yet fully operational is that WinBoard does not yet read or write the checks-counter field in 3check FENs. I am still working on that. This shouldn't cause any problems if you just play 3check from the standard opening position. But it would if you set up different position, and try to play from there. The GUI does not have a way to enter the remaining number of checks in Edit Position mode anyway; I still have to think up some method for that. H.G.

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#147 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVNwNrd7w387oRhIy8hGJU1CYCu5d5AHks5rEahPgaJpZM4LBwke>.

[Vinvin20]

The time control was changed just after first game (lost on time) to 5m+15s.
SF-zh won 6-0 !
Video here : https://www.youtube.com/watch?v=uP3nHtK2ndw

I finally used the PNaCl (Chrome) version. Not enough time to test .exe and WB interface.

[alwey]

@HGMuller Hello, regarding 3check FEN counter field: You suggested to put the reverse counters after the en passant field. Would it not be better to append the field to the standard FEN (compatibility with older data from standard variant)? I am just implementing three-check for cutechess (actually N-check).

[HGMuller]

Op 12/3/2016 om 9:30 PM schreef alwey:

@HGMuller <https://github.com/HGMuller> Hello, regarding 3check FEN counter field: You suggested to put the reverse counters after the en passant field. Would it not be better to append the field to the standard FEN (compatibility with older data from standard variant)? I am just implementing three-check for cutechess.

I would prefer the ply counter and the move number to be the last two fields of any FEN, because those are the fields that would be omitted in an EPD. Putting fields behind them would require skipping those when parsing an EPD. Normally fields that are specific to a certain variant come between the side-to-move and ply-counter fields. Such as the virginity and e.p. fields in Chess, which are lacking in FENs for Xiangqi or Shogi. It would be good to require a certain order of the optional fields, however, as they might not always be recognizable from their form. In particular when they degenerate into a dash, as is the standard for virginity and preceding-move fields in Chess. OTOH one might argue that dashes can be ignored, so that you don't have to know for what field they were. If we agree that missing fields imply the default value (e.g. no castling rights, no e.p. rights, no pieces in hand, an infinite number of checks to go...) this would not be a problem. As long as all the fields can be unambiguously identified from their form. E.g. hand pieces enclosed in [ ], one or more concatenated square numbers indicating the essential aspects of the preceding move (e.p., requiring more than a single square in Berolina, or 'iron Lion' in Chu Shogi), a concatenation of letters the relevant virginity information for the pieces on the mentioned files (castling, Seirawan gating), two numbers connected by a + sign the remaining number of checks, etc. I think there is little to be gained by making it such that FEN parsers that do not recognize a certain optional field can find the ply counter and move number in the expected place. FEN parsers will be either pedantic, and then they will complain anyway if something follows the move number, or they will just give up or misinterpret unexpected stuff (like reading the remaining checks as ply counter and move number). But not having the right ply counter or move number in 3check is just a minor inconvenience compared to not having the check count. So it would never work acceptably with FEN parsers that do not recognize this field, no matter how backward-compatible you try to make it.

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#147 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVNwNg0PltHtFBz9nNdexp5OhPPmkx-Zks5rEdFrgaJpZM4LBwke>.

[alwey]

@HGMuller : Thank you very much. This rationale is a good guide. I asked you because the earlier these topics are discussed the easier to avoid incompatible implementations and double work.

[HGMuller]

Op 12/4/2016 om 2:18 AM schreef alwey:

@HGMuller <https://github.com/HGMuller> : Thank you very much. This rationale is a good guide. I asked you because the earlier these topics are discussed the easier to avoid incompatible implementations and double work.

Since you seem to be working on variants for CuteChess, allow me to make a sugestion: If you support the XBoard 'setup' command and the UCI equivalent "info string variant XXX startpos FEN" used by Stockfish-variant, there is hardly any need to add any specific support for variants like Racing Kings, King of the Hill and Horde. These just use normal Chess rules for as long as the game lasts, starting from a non-standard position (and for KOTH not even that). All that is needed is to allow the engine to provide the start position through 'setup' / 'info string variant' in response to selection of the variant. This would make a GUI automatically support any variant of this kind, without the need to have any prior knowledge of this variant programmed into it. Alterative game-termination conditions, as in KOTH or Racing Kings, are not a problem with XBoard engines, as these can declare game end by themselves through 1-0 or 0-1 commands,and there is no need for the GUI to know about it until it happens. Note that UCI engines can do a similar thing by sending "score mate 1" (engine wins) or "score mate 0" (engine already checkmated) in the PV info for the bestmove. So all the GUI has to do to play, say, Horde, is (1) realize that it might not use orthodox Chess rules because the 'UCI_Variant' option was exercised, so that (2) it should trust the engine when it indicates game end through a mate score, and (3) not get confused by absence of a King in its own checkmate detection. A note on variants: WinBoard protocol defines a lot of 'standard variants', many of which I consider to be legacy variants, which really should never have been independent variants at all. E.g. 'nocastle', which is just normal Chess from a different initial position that happens to have no castling rights. It was only made into a variant because XBoard at the time did not keep track of castling rights, and thus had to be told in an alternative way that castling was not allowed, rather than through the initial-position FEN. Slightly less obvious, Chess960 is just normal Chess from a different position with a generalized castling rule that is upward-compatible with the FIDE rule. That the rule is in use follows from the presence of castling rights for Kings or Rooks on non-standard locations in the initial position. This type of ('Fischer') castling can in principle be used in any variant, without the need to define a new variant for it. Threecheck could also considered to belong in this category. If we recognize winning by checks as a general mechanism, and the number of remaining checks needed to win will be reported in the FEN when it is non-infinite, it becomes a property of the initial position rather than defining an independent variant. This approach 'unifies' Chess, Chess960, Threecheck, KOTH, and Racing Kings (and most FICS/ICC 'Wild' games), the only difference being the start position. All that is needed is to always allow Fischer castling when the engine specifies rights for it in the FEN, always declare win-by-checks, but set the required number to infinite when it is not specified in the setup FEN, and consider a side without King never to be in check. (To not interfere with

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#147 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVNwNuIoPAqUTrhYnM2kbSyNp9NW6xJcks5rEhTjgaJpZM4LBwke>.

[alwey]

@HGMuller Thank you for these observations.

First I have to say that I am not owner of the cutechess project. I am an interested user, a contributor. I have no deep insights into most parts of this project. I am contributing when I feel that a functionality is missing or when I found a problem. Also I am a quite lazy guy, so I use as much of functionality and code and symmetries as possible.

The nature of cutechess is twofold. At the core there is a library. Two applications make use of this library: The CLI (cutechess-cli for engine-engine matches) and the GUI (cutechess supporting engine and human players). The library currently supports UCI engines, xboard v2 and xboard v1 engines.

The two applications work as arbiters and check move legality. They do not trust engines and they do not trust players. When cutechess says a game is lost then it is lost. The GUI has a helper function to indicate legal moves for a position.

The GUI also can import games and positions and maintain a game database. So cutechess has to deal with external data and older data from various sources.

If cutechess imports a game, e,g, a lichess.org RacingKings game it extracts the variant name and knows which rules to apply. RacingKings - no checks allowed, setup without pawns, finishing on eighth rank wins with one chance for black to get level. I have not implemented more than this.

Sometimes code reuse does not work immediately, e.g. Horde Chess has no white king. This is illegal in chess. White is dead. I can not enter a Horde starting position, Cutechess will check for the king fields - game over. So I have to generalise the king assertion in the base classes (WesternBoard in this case) and prepare an override to give Horde Chess a chance. Override the assertion with WhiteKingsCount == 0; BlackKingsCount == 1. But wait - there is Dunsany's Chess. The main difference is the starting position. And there is the original Horde Chess with a black horde, so generalise again: WhiteKingsCount + BlackKingsCount == 1.

Every time such a generalisation enters the base classes this is an example for the general chess you mentioned. But: cutechess is an arbiter, and it will check rules not in general but in detail for a variant.
So some changes will enter the base classes but some specialities will then enter the variant classes.
Which part enters the base and which enters the variant is a case of negotiation with the project owners, @ilaripih and @artoj. The check counting rule (3check) would be an example for this.

So cutechess difficulties /wrt to some of your suggestions arise from some of its base functionalities:

• arbiter function (rules check and track game status)
• human interaction
• import, export, storage and presentation of game data

Best regards - an Xboard fan.

[ilaripih]

Thanks @alwey that's actually a very accurate description of the CuteChess internals. The main point is that CuteChess must fully understand the variant, and variant support must not be dependent on engines; otherwise these variants would be second-class citizens in several ways.

But these are implementation details that don't need to be standardized. PGN/FEN is another matter, and @HGMuller makes a good point about the ply counter and move number that I hadn't thought of - they should be the last two tokens in any FEN because they can be omitted. In CuteChess this probably means that the base class FEN methods may need some refactoring to make it easy to support new variants via subclassing, but it shouldn't be that difficult.

And the requirement that all engines must use the same variant names is an easily solved problem.

[HGMuller]

Op 12/4/2016 om 4:09 PM schreef Ilari Pihlajisto:

Thanks @alwey <https://github.com/alwey> that's actually a very accurate description of the CuteChess internals. The main point is that CuteChess must fully understand the variant, and variant support must not be dependent on engines; otherwise these variants would be second-class citizens in several ways.

Isn't that an exaggeration? If a variant only differs from orthodox Chess by having a different initial position, either a loaded PGN game would provide the position through its FEN tag, or the engine could provide it through the setup command. Everything else would work exactly as in a variant the engine did know. So what would be 'second class'? Also, the "no King = finished game" rule seems a rather counter-productive deviation from FIDE rules. According to the latter you can only lose (except for externel reasons such as clocks or misbehavior) when you are in check, and if you have no King you obviously cannot be in check. No variant I know has the "no King = lost" rule. Several have no King, however. (And in some variants capturing a King = win.) WinBoard unintentionally applied the "no King = lost" rule too, but I changed that to make it more generally useful.

And the requirement that all engines must use the same variant names is an easily solved problem.

I am not against this, but OTOH I did not think it is my place to enforce XBoard (CECP) standards on UCI. Some of the CECP variant names are poor, or even outright ridiculous (e.g. fischerandom with a single 'r'). If UCI engines want to indicate variant 'normal' as 'chess', and 'fischerandom' as 'chess960', I can relate to that. The UCI_Variant option could appear in the Engine Settings dialog of a GUI that does not implement it as a UCI standard option, so there is something to be said for having sensible names appear in the combobox menu for it. There is no reason why people should not play King of the Hill or Racing Kings in ChessBase or Shredder GUIs. The PGN Variant tag is more of a problem, however, as this really should be standardized. But if I had to choose between 'chess960' or 'fischerandom'...

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#147 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVNwNmhA682GEXL3F8ZRZu9XBHZF5NzHks5rEteRgaJpZM4LBwke>.

[ilaripih]

Isn't that an exaggeration? If a variant only differs from orthodox
Chess by having a different initial position, either a loaded PGN game
would provide the position through its FEN tag, or the engine could
provide it through the setup command. Everything else would work exactly
as in a variant the engine did know. So what would be 'second class'?

I don't think it's an exaggeration because adding new variants to CuteChess is usually quite easy and doesn't require a lot of code. To add a new variant that only differs from FIDE chess by name and starting FEN, this is enough:

class LIB_EXPORT FooBarBoard : public StandardBoard
{
	public:
		// Inherited from StandardBoard
		virtual Board* copy() const { return new FooBarBoard(*this); }
		virtual QString variant() const { return "foobar"; }
		virtual QString defaultFenString() const { return "foobar_fen"; }
};

Also, the "no King = finished game" rule seems a rather
counter-productive deviation from FIDE rules. According to the latter
you can only lose (except for externel reasons such as clocks or
misbehavior) when you are in check, and if you have no King you
obviously cannot be in check. No variant I know has the "no King = lost"
rule. Several have no King, however. (And in some variants capturing a
King = win.) WinBoard unintentionally applied the "no King = lost" rule
too, but I changed that to make it more generally useful.

There's really no "no king = finished game" rule in CuteChess. It's rather "white and/or black doesn't have exactly one king in the given FEN => reject FEN as invalid" rule.

I am not against this, but OTOH I did not think it is my place to
enforce XBoard (CECP) standards on UCI.

I actually meant that CuteChess can easily adapt to the situation where a variant has several aliases. It's not a nice thing, especially if new aliases keep popping up for the same variant, but at this point it may be the only realistic option.

[HGMuller]

Op 12/5/2016 om 7:07 AM schreef Ilari Pihlajisto:

I don't think it's an exaggeration because adding new variants to CuteChess is usually quite easy and doesn't require a lot of code. To add a new variant that only differs from FIDE chess by name and starting FEN, this is enough: ...

Well, whether being a "second-class citizen in many ways" is an exaggeration is an independent question from how easily this could be cured. That there is an easy cure usually doesn'tmake a patient much worse off. But the proposed "easy solution" requirescoding and recompilation, which the bulk of the users would consider totally incomprehensible. A far easier solution would be to configure the GUI to start games from a position supplied by the user, e.g. in a .fen file. Most users would be able to do that, and I suppose that is possible in CuteChess too. Nevertheless people experienceit as pretty cumbersome to have to create a file with positions.

There's really no "no king = finished game" rule in CuteChess. It's rather "white and/or black doesn't have exactly one king in the given FEN => reject FEN as invalid" rule.

OK, thanks for clearing that up; I was just going by what the other guy had explained. Nevertheless, isn't this a /needless/ degradation of the use fulness? You might want to flag such a condition as a likely error, but it seems a warning would be sufficient.

…

I am not against this, but OTOH I did not think it is my place to enforce XBoard (CECP) standards on UCI. I actually meant that CuteChess can easily adapt to the situation where a variant has several aliases. It's not a nice thing, especially if new aliases keep popping up for the same variant, but at this point it may be the only realistic option. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#147 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVNwNqVEs5qLJTcuIxwtUFiPJgapYMUUks5rE6oSgaJpZM4LBwke>.

[ilaripih]

But the proposed "easy solution" requirescoding and recompilation, which
the bulk of the users would consider totally incomprehensible. A far
easier solution would be to configure the GUI to start games from a
position supplied by the user, e.g. in a .fen file. Most users would be
able to do that, and I suppose that is possible in CuteChess too.
Nevertheless people experienceit as pretty cumbersome to have to create
a file with positions.

I actually thought about it at some point that it would be cool if new variants could be added via a simple config file. But I found it a lot easier for myself to just write the code. I realize that random users can't then easily add new variants but that's okay.

OK, thanks for clearing that up; I was just going by what the other guy
had explained. Nevertheless, isn't this a /needless/ degradation of the
use fulness? You might want to flag such a condition as a likely error,
but it seems a warning would be sufficient.

Well, after the n-check variant changes by @alwey this check can be reimplemented (even removed completely) by variants that have kingless positions.

[alwey]

Yes, actually I implemented Antichess (Losing Chess), Giveaway and Suicide Chess before Horde. Here the kings can be captured and removed. Pawns can promote to King. Some issues remain. Possibly @ilaripih already found the solution while fixing a Horde problem ...

[HGMuller]

I just updated the package at http://hgm.nubati.net/WinBoard-AA.zip . It now contains a WinBoard version that does keep track of the number of checks, and writes it in the FEN in the N+M format after the e.p.field whenever N or M are set to a finite value. (Which would normally only be in 3checks, unless you loaded a FEN that specified such values with the aid of this field in another variant.) On input the FEN reader would also understand the +N+M format begind the full-move number. It also fixes a problem with legality checking of input moves in variants with mandatory capture (Giveaway!), which I had apparently broken at some point. For those that did not use the WinBoard-AA package, but downloaded UCI2WB directly from http://hgm.nubati.net/UCI2WB.exe : The UCI2WB in the package was already updated compared to the latter, which had a problem with hanging engines when you closed the GUI while the engine was thinking. The one in the WinBoard-AA package had that fixed. I now also updated the bare UCI2WB.exe, so it is in sync with the WinBoard-AA package. One question: Wahat is variant 'relay' on Stockfish? Is that supposed to work? When I select that variant, adplay e2-e4 to set Stockfish thinking, it crashes after reaching a depth of 6 ply.

[ddugovic]

@HGMuller Sorry, my relay variant support is incomplete and I have now disabled it. (I don't recall how I enabled it while fixing issues but enabling it was unintentional.)

[ddugovic]

@HGMuller FYI when I connect to my VICS at relaychess.org:5000, the following examine commands (fixed in my VICS server instance) display a normal board:

ex b seirawan
ex b seirawan 0
ex b wild seirawan

[HGMuller]

In the communication log (winboard.debug) for such a mishap it shows that the ICS fails to print the variant name with the move list. The normal procedure is that the ICS first sends board + holdings when you create a game, without indicating what variant it is. Because of 8x8 and a following holdings command, WinBoard guesses Crazyhouse, and then requests a move list. In the header of such a list, the ICS should mention the variant, in a sentence like "... Unrated seirawan/0 match, initial time ...". In this case there is just "... Unrated match, initial time ...", the variant name (obtained from game_globals.garray[g].variant, in movesToString(), in gamedb.c) is apparently an empty string, while it is supposed to be initialized to <category>/<board> when the game is created. Because there is no recognizable variant name in the move-list header, WinBoard 'recognizes' it as variant normal, and switches back to 8x8. As far as WinBoard is concerned, the move-list header is the final authority. Op 12/5/2016 om 7:37 PM schreef Daniel Dugovic:

…

@HGMuller <https://github.com/HGMuller> FYI when I connect to my VICS at relaychess.org:5000, the following |examine| commands (fixed in my VICS server instance) display a normal board: |ex b seirawan ex b seirawan 0 ex b wild seirawan | — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#147 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVNwNvBDsVUg26DW6nN2l0_BoIs6Um6mks5rFFn0gaJpZM4LBwke>.

[niklasf]

Closing this since the match is over and a new one is coming up: #171. If I missed anything it's probably best to open new tickets for any remaining issue at this point.