I guess when things get into the weeds regarding CORS, it’s a good time to have a split. CORS is some sort of arcane magic to navigate.
17 thousand-ish nodes is perfectly manageable within an SGF file. That’s about a quarter of the size of KJD and probably better curated, especially for recent developments. I think that we should just scrape the data out of OJE (at a regulated pace) and compose an SGF file.
The solution that @okonomichiyaki is working on to use the KJD SGF can then almost immediately be repurposed for the OJE data, but just plugging in that new SGF.
One benefit of using live OJE integration is that it will be immediately up to date when new variations are added. On the other hand whatever we used to scrape the data could be used to update relatively easily
I have pushed a basic implementation checking the dictionary…however I realized that Kogo’s dictionary is copyrighted. (I guess it’s the commentary that is copyrighted?) Normally I might be a little bit cavalier but, now that I’ve actually looked at some variations, I can see what people mean about it being out of date, even some of the very simple 3-3 invasions appear to be missing
So I’ve left this feature underneath the debug flag, and included a “dictionary” file with a single joseki in it, for the purpose of testing. Also the checker doesn’t prevent you from submitting, just includes a message
edit: looking into scraping the OJE joseki tree now
What’s currently going on with your live version? Did you add a second BesoGo contained just to load the joseki dictionary? It would be cleaner to just call the SGF parsing utilities to load an SGF into a gameRoot (game tree) object, and handle that behind the scenes. No need to make a second copy of the interface, and that will mess up layout issues.
Multiple boards are fully supported, and I guess if everything is hidden, it probably wouldn’t matter for layout issues. I haven’t properly documented using sub-components of BesoGo by themselves, but it should be doable. Hence, maybe the quickest and easiest way is to just do what you are doing by creating a second full BesoGo instance (you can drop the panels at least, to avoid duplicating the hints panel and submit button) and keep it hidden.
By the way, I looked at your live version of the fill mode https://okonomichiyaki.github.io/josekle/fill.html and it seems that some other changes seems to have broken the responsiveness of that design. What do you think about making the fill mode the default (used for index.html)?
There are still some minor tweaks that I think are worth doing for the fill mode design, such as:
Give a bit more space to the tree panel, rather than the hints panel.
Automatically scroll the hints panel as it gets too long.
Adjust the resizing the shrink the height of the board, when in portrait mode with a very squarish aspect ratio, to avoid there not being enough space for the control, tree, and hint panels.
I think it’s a good idea, but I also think we should get rid of the other versions (real, dark, ) or consolidate with switching by a query parameter or something, it’s a bit annoying to maintain multiple versions, for the prototype stage
Yes, definitely, those other themes should definitely just be switchable with a parameter (and maybe some sort of button later, to avoid the user have to mess with the URL). I just put theme separate as a quick proof-of-concept of what other themes would look like.
Changing the CSS file on the fly already works to change the theme. On my BesoGo main project page, it shows an example with that. The only thing not supported is toggling the “realistic” stones and shadows on and off. Currently, those are loaded as an option when BesoGo is initialized, and there’s no way to change it after the fact, while preserving board state. However, I think it should be fairly straight-forward for me to add a hook into the editor object to allow this be toggled live.
should be fixed now, although I have been seeing GH pages take a while to refresh.
Meanwhile, I have gotten to the stage of coding where I ran into a weird problem eating an hour of time…
after disabling IPv6, my scraper is starting to work for a minute I thought I broke OGS. I have a basic version working, but in order to avoid swamping OJE API going to refactor a bit
I just made a pull request to fix some issues with the fill.html mode. I also adjusted the layout of that a bit and added auto-scrolling of the hints panel.
Should we also go live by replacing index.html with fill.html?
By default, when you backtrack, you’ll see red letters “A”, “B”, … on the board that show the location(s) of the next move and variations thereof in the tree. The button on the right turns those off/on. The button on the left switches between showing variations that are children vs variations that are siblings of the current move.
Perhaps both of those buttons, as well as the jump backward/forward 10 moves buttons (double triangles left/right), and the toggle coordinates buttons could be removed.
By the way, I noticed this weird bug, which is only visible at certain viewport ratios that shorten the height of the main BesoGo container, when using the “fixed” fill mode:
In theory one could restrict the number of moves you’re allowed make so you don’t just put a stone in every spot and guess it in two.
Although I guess that’s really only an issue if one sees it as competitive, or if one wants to play it efficiently, with the best strategy, which would probably be to play everywhere on the first try to get the outline.
Another idea might be to assign a score to the whole attempt.
I’m not exactly sure of the best way, like should it be a point for green, half a point for purple and -1 for white in guesses (except you could farm points by getting more right than wrong in the sequence). Maybe -2 for a white? Could there a points penalty for going longer than the sequence or too short instead?
It might be an idea that could be potentially easier than restricting what people are allowed submit, although it might require some fine tuning is the downside.
I think the optimum would be allowing submission of any joseki, or any set of n moves which constitute the first n moves of at least one joseki, and restricting the length of guesses to the length of the target joseki.
I think the plan is to restrict guesses to sequences present in the OJE.
I’ve currently scraped good/ideal sequences from OJE up to a depth of 7. I’m continuing to download data slowly, depending on how long it takes, I might push the changes which checks the dictionary up to the data I have, but probably not restrict guesses yet, just print a message if the guess is not in the dictionary
I like the idea of scoring based on greens/purples, although I feel like some of the points gained would be due to luck.
With unlimited guesses, the score could just be the number of guesses it took to get it right
I’m curious if folks think we should show the number of moves in the target joseki, before even the first guess? With unlimited guesses, it’s not too hard to figure out how many moves are in the target, however it does feel a little random at first
Another idea is to count length of sequences guessed against some sort of quota for number of guesses, if we also impose some sort of maximum guess limit. Then, if we say have 6 guesses, and the length of the solution is 8 moves, then a 12 move guess counts for 1.5 guesses.
However, overall, the game is not meant to be competitive, so I like keeping things flexible to allow people to play however they like. Even when we implement input checking by default, I think it would be nice to allow an easy mode that allows for arbitrary guesses. People should be able to choose what parameters they prefer to play with.
for a minute I thought I broke OGS. I have a basic version working, but in order to avoid swamping OJE API going to refactor a bit
. Even more since i understand now all of them.