Very quick fix to combat puppy-go (i.e. loss of focus). In real life, you also don’t get that indicator.
Of course it should be an option.
That’s all.
Very quick fix to combat puppy-go (i.e. loss of focus). In real life, you also don’t get that indicator.
Of course it should be an option.
That’s all.
I like the idea, but I don’t really agree that it matches real life - in real life you see the person place the stone, unless you are looking the other way at the time.
Maybe to match this, the “last move” indicator should fade quickly on the board… that would be the most equivalent thing for “live” games. I don’t think we could fake it for correspondence games.
GaJ
Do the people you play in real life keep their finger(s) on the stone they played last?
And no, I mean completely disabling it. Display the stone, but not the circle. That way people (yes, barring deaf people ~) could close their eyes, wait for the sound and then assess the situation somewhat objectively. I think it’s very hard for beginners and sometimes even weathered veterans to ignore that pesky circle.
Yeah - I totally agree it’s a really neat idea.
I’m just saying it’s not like in real life It’s better
Potentially this is even a front-end-only change we could do quickly! As far as I can see it should be: maybe that new keen front end developer would take it on as the next cool idea.
@AdamTropp : a nice little feature where you get to work out how to set and get user preferences ;), and also have to dig into the guts of the goban display
I agree. But is hiding it the best option?
I know for sure that, if there was no circle, I would flip back and forth to see where did my opponent actually place his stone.
I’m not strong enough to recall board positions by heart and I think that it’s a good piece of information to know where your opponent is focusing. Even if you don’t want to answer locally. I’d say especially if you don’t want to answer locally.
Knowing which is the last move and choosing to tenuki is something that must be trained too.
“Is that sente?” (Haylee)
How you use it would be up to you.
I’m merely saying that the presence of that circle makes it artificially hard to ignore the move.
Please implement this.
I sympathize that beginners might want to know what was the last move, we’ve all been there. But especially for correspondence game, it is a bit tacky. When planning grand strategies and trying to evaluate impartially the whole board it is so much of a nuisance that I can’t even!
I wouldn’t mind a hide/unhide last-move-indicator switch.
As long as there is a choice to make.
Agreed!
Or a toggle, cycling through show / fade / hide, that works a bit like “Toggle coordinates” - accomodating several options.
Completely agree with the 3 options.
Fade would be great as being the default setting.
Good “new developer” task
Sounds easy… but isn’t this in Goban? I always find that code hard to mess with bc it’s in a different repo. Is there a guide on this?
@BHydden had expressed interest in adding settings for zen mode… Maybe last move indicator could be part of that?
Why is it hard “because it is a separate repo”?
Admittedly, the Goban code is amongst the older code, and has all sorts of flavours of implementation in it. This change also does have the challenge of passing in options from OGS to Goban - non-trivial, I’ll grant
But the repo thing on its own shouldn’t be an obstacle?
You do need to know the yarn link trick - maybe that is the missing piece?
Yes! Took me forever to figure out I can link node_modules! (I don’t come from a js/node background)
But also as you say, goban can be hard to parse. I’m guessing this type of thing wouldn’t be too hard though
I have found the place at runtime in GobanCanvas.ts - there seems to be a promising block of nested if-statements:
/* Draw last move */ if (draw_last_move && this.engine && this.engine.cur_move) {
And this is an interesting line in GobanCore.ts:
this.dont_draw_last_move = !!config.dont_draw_last_move;
but have never seen config
having a value other than undefined.
I would not mind trying my hand at this, but my github-fu might not be up to the task, separate repos and all.
Check out online-go.com repo and make sure you can run local server with npm run dev
(after yarn install
). In theort, http://localhost:8080 gives you a client running your local build pointing at beta OGS.
Check out goban repo
At the root of that repo, do yarn link
At the root of the online-go.com repo, do yarn link goban
when you want to use your local version, and yarn unlink
when you want to revert to using the one that comes via npm/yarn.
HTH
(If you know where to put this doco, after confirming it works, and could update that proper place, that’d be great… if it’s not there already )
Many thanks!
I have one small problem… which might be worth pointing out:
All steps work very well - except the last one: I can run my local build at http://localhost:8080 in general, but once I try to link the local goban repo, it always fails with “Cannot find module ‘goban’ or its corresponding type declarations.”.
Even after fixing a minor issue with the versions in online-go|package.json
, I realised goban-master|package.json
is pointing to a folder “lib”, which is entirely missing from the current github version - if nothing else, it seeks lib/goban.js
, which is nowhere.
This is the relevant snippet:
"main": "lib/goban.js",
"types": "lib/goban.d.ts",
In the runtime, I see that goban.min.js
is pulled from somewhere…
I can try to copy/paste it into a goban.js
into the folder lib
, it seems to be working? - at least, it loads the page.
Ronin, have you also cloned the goban repo?
Edit: once you clone it, you will need to run yarn link
in the goban repo before running yarn link goban
in the main repo. (I think- i am still getting up to speed on npm/yarn/node myself)