What's next: Lizzie v0.4

[featurecat]

Hi all,

I'm glad so many of you are enjoying Lizzie. She has big dreams for the future! I'm sorry there have been some bugs / issues, but so happy to see contributions coming in (special thanks to @dfannius and @cngoodboy - I appreciate it).

I am quite busy during the week, so my development often happens during the weekend. Sorry that I can't address every issue immediately - I try to do that during the weekends. I would appreciate any help I can get! I'm anxious to incorporate all the proposed PR changes as soon as possible and fix several of the issues, based on your feedback. You can expect a release some time this weekend.

What's new in 0.4

• most or all of the PRs will be merged. This includes variations in the sgf from @dfannius and plug-in support from @cngoodboy, as well as several bug fixes/features/customizations based on your issues. If you have a PR idea please do submit it by Saturday :)
• Lizzie will now give you a proper error message if you are not using the correct Leela Zero binary, instead of silently failing
• Release will include all the dlls necessary for Windows.
• More elements of the gui will be customizable
• Handicap game support
• Probably Lizzie will become more useful for loading / saving the analysis.
• Use system default look and feel for dialog boxes, instead of the Java Swing UI.

After 0.4

One of my main reasons for creating Lizzie was that I wanted an interface that automatically pairs you against an AI of equivalent level. This means that Play mode will be enhanced. You can expect:

• Probably: play/analyze with a ladder-conscious Leela Zero. This means that a 5 kyu won't be able to beat a 5 dan network just by exploiting a ladder. This makes the rating system more stable.
• Each network will have a self-play elo rating from zero.sjeng.org, and I will try to loosely map the elo ratings to kyu-dan system rankings.
• By playing against the system, you will be assigned your own self-play elo rating which can be mapped to a kyu-dan ranking.
• Play in automatch, which pairs you against a suitable opponent within ~n rating points and adjusts your rating according to the result.
• Choose to play against a specific ranked opponent in an unranked game, with desired handicap/time settings.
• Keep track of Leelaz's thoughts during the game, for better analysis afterward (including graphs and an overview of your mistakes, from the perspective of your opponent network and the best network). This means we will probably add support for reading Leela Zero log files.
• Better menu system to support above features.

I hope you continue to enjoy learning and playing with Lizzie :)

[wonsiks]

Looking forward to see her soon... Thanks always~

[icespike-x]

Looking Nice, and I 'll add theme for cunstomize GUI

[dfannius]

Thank you for the great tool! I'm excited to see where it goes.

[jillybob]

https://www.reddit.com/r/cbaduk/comments/7jx8tv/the_ranking_of_lzero/

Here is an accurate table of strength for Leela Zero over time. Special thanks to /u/kityanhem for keeping track.

[featurecat]

Should be really helpful, thanks

[bochen2027]

what about blockchain support

[featurecat]

https://www.reddit.com/r/ProgrammerHumor/comments/89ze1y/slide_about_blockchains/

[featurecat]

unfortunately I haven't had the time to finish release this weekend, which means I intend to release next weekend. thanks for being patient :)

[crayzok]

I'm waiting for the handicap mode :) thx!

[bittsitt]

Please let us know if there is a way for us to assist :)

[dfannius]

Seconded! I have some code that I am holding off on writing because I figure there's a big atomic change coming soon that would cause lots of conflicts.

[featurecat]

Okay! All of your pull requests have been merged - thank you for submitting them. We have a few TODOs to fix before we should continue, in no particular order:

~1. Fix this bug: after playing moves, for a split second or possibly longer, the colors are inverted.~ dfannius ~2. Fix the winrate graph jumpiness during play-mode~ featurecat ~3. Fix the graphical overlap between winrate graph and board~ bittsitt ~4. Make copying variations from ALT c to CTRL c, ALT v to CTRL v.~ bittsitt ~5. Fix the following bug: play some moves, ctrl c, ctrl v. go back to start, play different moves, ctrl c -> messes up game tree and Leelaz's evaluations are wrong.~ magically fixed ~6. Make next-move be conscious of different variations/branches of the current move~ not sure what I meant by this, seems fine ~7. Make winrate graph be conscious of variations / current variation. Currently, with a few variations going on, the winrate graph can actually extend onto the board itself.~ mostly fixed

8. Refactor code. Lots of different people = lots of different coding styles.
9. Find and fix more bugs. I could only test for a few minutes. But there are guaranteed to be some more bugs.
10. Fix the spacing for coordinates margins. I think we can have a lower margin but draw the coordinate text so that it's aligned to the outer edge of the board.
11. Add special lizzie versioning to the Leelaz executable so we can inform the user they are not using lizzie
12. Add a "loading" text as Leela Zero is starting up. Possibly indicate if it is doing the tuning process or not; possibly display its last outputted line instead.
13. Under some circumstances, Leela Zero seems to have a different position in mind than the actual board position. It would be nice to get to the bottom of this. ~14. Fix #94~ featurecat ~15. When hovering over a new branch, it looks like the shadows are re-drawn. they get a lot darker.~ featurecat
14. Make navigating the variations tree easier -> 16a. indicate which moves on the board are which moves in the tree, 16b. make up/down go backwards/forwards in a variation, and left/right switch branches
15. Add option to make branch stones appear different (transparent, maybe)

Help is requested for these changes! It would be especially helpful if you could announce which number you are tackling in this thread, and please only work on one at a time. In the PR merging there are often a few extra changes like refactoring the code in random spots. Please don't do this as it makes merging harder. Please submit all refactors as a separate PR; you can submit as many PRs as you want. I will make a CONTRIBUTING file later to set some guidelines.

Until we release the next version, we are in feature-freeze: you're free to submit new feature PRs, but I won't merge them until after 0.4 is released. They would then make it into 0.5. Bug-fix PRs will be merged speedily; sorry I haven't been the best at merging your PRs up until now, but I am learning :)

I will be implementing these changes as well over the next couple days. Looking forward to any help I can get :). Once we finish all or most of these, I will release the next version.

[dfannius]

Great! I'm happy to take point on 1 and have some thoughts in issue #78. Some other issues I may have more thoughts on once I try out the new code. For instance, it would be nice to have a better game tree than the one I hacked in (maybe there already is); I was trying to make the fewest possible changes to the existing code at the time.

As far as coding style goes, I was trying to match the coding style of the existing code, which I think is best practice on any project, even if there were some things that bugged me a little. I think @featurecat should be able to impose whatever style they want. I would like to see the really long lines brought under 100 characters though.

I have a few other things I was waiting on until all the merging happened:

• option to always display win rate from Black's perspective (I have this always on locally)
• remember what directory we last loaded an SGF from, at least within a session if not between sessions
• saveable option for Leela Zero variation display (first thing I do every session is turn it off)
• SGF parsing doesn't always work for games with variations in them already

but all of them (except maybe the last) can wait until after 0.4, as you say.

[dfannius]

Item 1 is fixed with #93.

[bittsitt]

I can fix 3, but a bigger bug is that the variationtree and winrate now overlaps. I suggest we move winrate to other side of board so that it is on top of the winrate graph. I can do these two in PR maybe as they are closely tied to each other?

I would also like to rotate it 90 degrees as I think that looked better (as suggested by isty2e in #30), and it will fit better when on top of winrate graph (I think). I can do this in a separate PR(?)

Should there also be a separate hotkey to toggle the display of these two (I suggest one key to toggle both)?

Everything should be made prettier, but that can wait I guess.

[featurecat]

Sure. I actually meant both of those with 3, worded it incorrectly. 90 degrees is what I had in mind! perfect. it's fine to do this in the same pr.

A hotkey would be nice. We can always add more and then gather all hot keys into menu items when we have too many hot keys.

[icespike-x]

@bittsitt I can fix the variantions bug

[bittsitt]

I've fixed 4 as well, will make PR.

[bittsitt]

@cngoodboy Excellent! I wasn't able to reproduce the error here... Might need to fix #94 first, currently if you add a variation, it becomes the main branch so it messes up everything.

[featurecat]

@cngoodboy Which # is that?

[featurecat]

adding on a bit

18. variations with lower playout counts shouldn't overwrite variations with higher playout counts in the winrate graph

[bittsitt]

I assumed cngoodboy was referring to 7.

As for 18, I had actually added code for taking playout counts into account. However, with the brief testing I did, I got the impression that leelaz remembered previous playouts so that when moving back in time, the playout count for the best move was always higher. Therefore, I removed that part of the code.

It is possible that I didn't add enough moves to my game and that is why I didn't see it? Do you have a quick way to reproduce it? How does it manifest itself?

As a side note, I've been thinking that it would be very useful to store winrate and playout count in the sgf (along with name and version of program that made them). However, Leela zero is already very strong and will only become stronger, and I'm not sure how much more valuable it is to get the opinion of a 15 dan (let's pretend this one needs to think 1 minute on every move) instead of 13 dan (that only needs 3 seconds). Pros might be interested (and I'm guessing a lot of pros will start using Lizzie), but.. well, not sure. We could e.g. simply store it in the comments. (This is really a separate issue).

[dfannius]

A couple more things I would like to see in 0.4:

• build instructions (#46, #86). I'm happy to do this by adding a little section to the README if that's okay.
• I personally don't think Lizzie should output all of its communications with Leela Zero to stdout by default; it makes the program feel less clean. Can we disable it, or make it an option?

[featurecat]

@dfannius a) Yes, please :)

b) OK, agreed.. It should still be an option because it's useful for troubleshooting and debugging

[featurecat]

Currently adding some last minute ~bugs~ features... then we're releasing. Any last minute concerns? Release tomorrow.

[pcengine]

@featurecat I really appreciate your hard work, and I'm even more interested in your future plan (those things you've mentioned in the after 0.4 part). May I ask a rough estimation when can we expect to see those automatch/autopairing stuff?

[bittsitt]

I had a quick look at showing the winrate variation as a dashed line in addition to the main trunk line, and it was easier than feared. However, it currently disappears a bit when you have a full game your looking at, so I'm a bit uncertain. Might help if the main trunk is made dashed instead (e.g.), but I don't have more time at the moment.

I think we need to fix the lizze.properties thing though, if not, everybody will have a crashing program when they upgrade. I don't think I have time to look at that today unfortunately (at least, can't promise anything).

[dfannius]

I agree with @bittsitt; it would suck for people upgrading to have it immediately crash. I can take a look at it this morning since it's mostly my fault. I think if we just have a default config (we can refactor this code out from Config::createNewConfig) and then merge in the one we read from the file, that'll be okay for now (although it will mean people won't automatically be alerted that the new properties exist and can be changed).

[dfannius]

The properties issue (#108) is fixed with PR #116. Everything I wanted for 0.4 is now in!