Hide last move indicator

Very quick fix to combat puppy-go (i.e. loss of focus). In real life, you also don’t get that indicator. :stuck_out_tongue:

Of course it should be an option.

That’s all. :slight_smile:


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.



Do the people you play in real life keep their finger(s) on the stone they played last? :astonished:

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 :stuck_out_tongue: It’s better :smiley:

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 :open_mouth:


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.

1 Like

“Is that sente?” (Haylee) :smile:

1 Like

How you use it would be up to you. :slight_smile:

I’m merely saying that the presence of that circle makes it artificially hard to ignore the move.

1 Like

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.

1 Like


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.

1 Like

Good “new developer” task :wink:

1 Like

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 :slight_smile:

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?

1 Like

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

1 Like

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.


(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 :slight_smile: )


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)