KGS Issue - CR Marks on Moves

   

This page discusses the issue that KGS inserts a circle marker for every move in the SGF file.

Users agree or disagree on this feature as follows: + - - - - - - - - - - - - - - - - -

Table of contents

See also

as a sidenote, we should be talking about the current move, not the last move; so this in se is already guaranteeing confusion.

Initial Discussion

axd: Please implement a decent focus marker. Now, the SGF circle marker is misused for this, clobbering the sgf file with superfluous information and making it difficult to find back real markers (because there are applications that make finding back markers easy, BTW). Otherwise, cGoban should be consistent and also put a square marker when showing ko! (yes, it is a user setting, independent of the game, I know.). Debugging needs to be done in this area anyway, because apparently there is a possibly related bug when reviewing uploaded games: not long ago, I had the chance to be able to follow a review given by Guo Juan, but I had difficulties following the replay because it was almost impossible to see where the moves would pop up. This was a very frustrating experience.

it seems reasonable that some people may wish to see what was the last move
Absolutely.
and that CR can be used for this.
I agree with axd, misused is the right word.
I do not really understand what you mean by focus marker,
Marking a point (last move, ko, etc) in the context of the application. The SGF file format doesn't "care" what node is the "current" one, an application like a SGF viewer does (because the user told it to show the position at that node). That's the reason why marking the last move (the "current" node) is the job of the application, not of the file format (moreover it ought to be easy to implement, specially in OOP). Conclusion: those CR markers should never be in the SGF record, they serve no valid purpose and are an annoyance (increased file size, troubles with other viewers/editors/you name it, etc).
nor do I understand the Guo Juan sentence. I see nothing wrong with the current implementation which I have been happy to use for a long time without any problems and can see no or little merit in the application examing the sgf tree to produce visual indications of future and past plays.
see my previous comment above.
  • Ah I see now thank you. Given the way the system currently works this may well be non trivial to implement, although it does seem to me rather trivial in essence. The idea that CR is going to be an annoyance amuses me I'm afraid, but I take the point about portability. Of course as all applications must be able to implement CR I don't actually see why it will cause any severe problems (unless possibly on palm Go if the app runs out of memory, but the time recording would be an issue there too)

...and this was the start of the discussion on this page:


CR Marks on Moves

wms: KGS puts CR[..] marks on moves. This seems to really drive some people nuts. I do it because something else has driven me nuts in the past: I'd be reading over an SGF file, and see a comment like "The move with the red dot should be elsewhere...", and I wouldn't see any red dot! The problem is that every SGF editor was free to pick a different "last move" mark. This is fine, except that it is natural for the person making the SGF file to talk about the marks on the board descriptively, so the SGF standard as it is pretty much guarantees that comments will not match what people see.

In short, you're filling SGF files with CR[] marks just because of the stupidity or carelessness of some authors. By the way, what makes you think that the move with the red dot was the last one ? If there's a mistake somewhere, it's in that sentence, not in the SGF specs or in the SGF viewers/editors. If that person wants to distribute SGF files to be viewed with other software than his/her, (s)he should be aware of (at least) some of the specifics of the file format, e.g. "red dot" is not a SGF mark and thus, (s)he shouldn't reference that "object" in any comment.

Yes, I do, and I persist. Exactly the same way I consider people authoring HTML without thinking of Lynx users.

then you are a prime example of somebody who should have nothing to do with user interfaces. The natural thing to do is write about what you see;

I strongly disagree. Or else, you're assuming that everybody has the same hard- and softwares.

authors of user interfaces should try to encourage people to do what comes naturally, not call them stupid or careless.

The most natural way to reference something like the last move is to call it "last move".

That is the whole reason for me todo this.

My solution is to place a "CR" mark at each move. According to SGF, any "implied" marks (like a mark to show the last move) must be overridden by an explicit mark from the file;

Please give a pointer, I've been browsing the FF[4] specs for half-an-hour and couldn't find it.

thus, any SGF editor that supports the standard properly will show a small circle over the last move, no matter what the original programmer decided to use as their own personal last move mark. That means that if you use CGoban 2 to make an SGF file, you can talk about what is on the board, and you can be sure that when somebody else gets the file, they will see what you described as long as their SGF editor follows the SGF spec.

The specs do not need to say anything about it !

so the creator of an SGF file cannot (without adding explicit marks, as I do) guarantee that the viewers of a file will see what was intenteded!

That's the job of the author, not of the editor !

The complaints I get about this are generally:

So basically, I see it as a choice between having comments that don't fit what you see, or else making some editors get confused about whether nodes have markup or not. I would say that it is far more important to have the comments fit the board, so I choose to add "CR[]" marks to each node.

A better solution would be for the SGF spec to explicitly state what mark should be placed at the last move made. Until it does, I will continue to put "CR[]" marks on the board.

wms: I don't think that this discussion will end. I keep looking at it not as a file format, but as trying to build a tool that lets people build SGF files. I don't give a flying **** what goes into the file as long as it fits the SGF standard. I provide an easy way for the current move to be marked; with circles, and I ensure that it will be marked that way when other people view the file with potentially different (but, like CGoban, standard-compliant) editors/viewers. Any editor that fits the standard will correctly show the file, with a circle on the current move. If this infuriates you, to have circles as the current move, then fine, don't make files with CGoban, it's that easy. When I get a file that doesn't have circles, do I get mad? No, I add them if I want them, I leave them if it doesn't matter. If I got a file with triangles for the current move, would I care? No, not at all. So you can argue until your fingers fall off about "wasted properties" in the SGF file, or "subverting the circle mark for your own uses," or whatever - I just don't care. Only if you can talk about better presentation to the end user will I even really listen, and apparently the anti-CR people will only listen to arguments about their own view of how SGF marks should be interpreted, which really doesn't interest me enough to discuss.

axd: You have built an excellent tool. But other tools exist too, and have a few possibilities you were not aware of. You should give a lot of **** for what goes into a file because it is used by an awful lot of people. Nobody can prevent you from using yet other existing markers to suit you, as this will all fit the current SGF standard. At least you should provide an option to disable the automatic generation of CR markers, and give this option to people who want to follow your idea and use it like that. Of course every editor will show the CR, but you don't seem to understand that cGoban is polluting SGF files with this CR marker. Yes indeed, we are running in circles. (pardon the pun). You state that you add them if you want to, but your choice is not the Go communities' choice; you have no right to unilaterally impose this on a community. BUT you cannot leave them away if you don't want them (as you write), because it is your application that automatically generates the markers, without any way for the author to prevent this. At least you should make this an option, not a built-in feature. I am talking about a better representation beacause I am presenting a better alternative, proven by experience: the focus marker , just as in any other editor. I think it is a modest, simple, straightforward proposal, in which I am spending a lot of energy, meanwhile knowing that it is fundamentally correct and does not deserve to be defended so heavily. We are still living in a democracy, you can behave like a dictator in the KGS universe, or can prove that you are open to decent proposals. I had hoped this would not become personal, but it is obvious that you do not want to listen to rational argumentation.


MK Hi. I can see people get emotionally involved in this discussion. This should be not so. We should work towards a most universal tool. SGF is not only used to view games, it can also be used for other purposes, like printing a game automatically from the game record. I find it more difficult to print a game from a record created by CGoban because those CR[] marks make the move numbers invisible. To put it bluntly, Hibiscus or sgf2misc print not move numbers, but circles with every move. So it is necessary to remove those CR[] manually or automatically, which is time consuming. As far as I understood from the discussion the prime and most reason for using CR[] everywhere is to force a universal way to refer to current move. But shouldn't people just say "current move" or "last move" instead of "the move marked with a circle"?
wms: What people should do, in my opinion, is simply write what they want in their game and not worry about details of SGF implementation. Any system that requires non-programmers to learn minutae like "don't refer to what you see on the screen as far as the current move goes, it may be different in other viewers" is a broken system to me. If people want to say "current move," fine. If they want to describe what they see, that should also be fine. ...

nando: Then, don't make the last move marker a static one (see my comment above), make the stone blink for half a second, or use a rapidly disappearing red dot, whatever. If it's not there, the user won't be tempted to reference it and will probably prefer to place an explicit marker if he needs to reference something.


axd: this is a very interesting, but different topic for discussion; the solution is probably to introduce hyperlinking concepts in the SGF specs. You are right about the difficulties inherent of the current SGF implementation. But qualifying SGF as broken because of these problems is wrong, because the advantages far outweigh these limitations; we have been using SGF for a long while now, and people are aware of the limitations, which are not that huge, by the way. Note that worrying about cGoban's use of the CR marker is not an SGF implementation detail. It is all fine what people want, but a tool should not insert superfluous markers in a file. Period. If the author wishes so, (s)he will do that. ... As for printing - the CR[] mark is clearly listed as a non-inherited markup, in other words it should only affect the node that contains it. If you tell a tool to print a certain node, I have a hard time seeing why a properly working tool would show circles from earlier nodes. If you are using the "FG[]" (figure start) attribute instead, then as long as the figure contains only the node that you want to print, again you should end up with just one circle.

axd: just as a sidenote, MultiGo allows to filter away specific properties from a file, such as CR markers.
wms: Sounds like an excellent, flexible approach to me!

dnerra: I think the problem is that the .sgf standard does not talk at all about how the game should be displayed in an sgf viewer. (Should there be a "last move" mark? Should there be a last move mark if the last stone was added with AB[]? Nevertheless: wms, what is really irritating is that a when viewing a game created with a different sgf editor, there is no last move mark at all displayed; this means it looks different than in any other sgf viewer, and is IMHO a bigger problem than the one you are solving with adding the CR's. Couldn't there be a last move marker by default (if there is no special markup property in the .sgf file)? This has nothing to do with SGF-standard zealotry, but is just about avoiding confusing user experience.

rmsp: I don't play on KGS (in part) because it was a pain in my butt to print kifu from the games to take to my lessons, due to the same problem as described above by MK. Instead, I just play on IGS. Why should I have to insert another step, with another editor, to be able to send the SGFs into sgf2misc? Every little annoyance counts, and it seems that this one is more than little to more than a few people.

crux: My main gripe is that cgoban doesn't by default show a last move marker for files created with other SGF editors, making it pretty much useless as an SGF viewer (no, I don't want to click on "Mark Moves" every time I load a file). I have less strong opinions about adding superfluous CR markers, I only find it useless and bizarre but so far it's never been actively harmful. I object to the principle though, breaking software in order to babysit users.

baby axd: If it is a big problem, wms can simply state that the design of cGoban does not easily allow for such a change. I can fully understand that, and that, I'm afraid, would end the discussion. Full stop! However, if it can be easily corrected, if it is only a matter of principle, I think that community inputs deserve attention rather than kling to one's own principles. I can understand that people can defend their prinicples against a whole world if necessary - I'm also of that breed of persons, but reason must prevail at all times; if a rational reasoning leads to the inevitable conclusion, if real-life evidence shows the principle is wrong, then it is time to rethink one's principle.


Gronk: Couldn't this problem be solved at the other end? By this I mean, couldn't the SGFs be stored (and downloadable) without CR markers. Then, if someone badly needed to have them (for clarity of comments I guess), then couldn't a tool be made available on the KGS site that would process a specified SGF and stick in all the CR markers? Or, vice versa, couldn't a tool be made to strip them out? Either way is a bother for someone but not everyone can be satisfied all the time. Anyway, in my experience, I can almost always get the meaning of comments in SGFs even if there are small problems like missing or incorrect symbols. Moreover, if the missing/wrong symbol is supposed to be on the last move, this is almost always my first guess as to what the comment might be about ('cause it is natural to comment on the last move, typically). And, this is all we're talking about! This small inference is rarely that hard to do for humans. I don't worry about the very few cases where this is hard to do (really, are there any?) because life is too short to bother about it.


Chris Hayashida: I always found that the SGF files from KGS/CGoban2 were annoying because of the circles. I also found that the other SGF editors (Panda Egg, PilotGOne) also have their issues. I can understand wms's point: the CR for each move makes the view the same, whatever editor you use. axd... but again, CR is designed for the use of the user, not for applications, so wms' point of view is wrong. I'm sorry I'm repeating myself, but wms'point of view cannot be justified.

I have found it annoying when viewing an SGF file from somewhere else (say, for a GTL review) and then having to figure out where the current move is.) Would it be so hard to implement the marking of the current move as an option? Could the presence (or absence) of the CR be determined when the file is saved in the editor? I'm sure there are other issues when downloading the files from the webserver, though.

Anyway, here is my answer:

 #!/usr/bin/perl
 #
 # sgfstrip.pl
 # by Chris Hayashida
 #
 # Usage: perl sgfstrip.pl <input filename> > <output filename>
 #
 # This script removes the CR and time tags from the KGS SGF
 # files. It can also accept input from standard input and send
 # output to standard output.
 while (<>) {
     s/CR\[..\]//g;
     s/WL\[.*?\]//g;
     s/BL\[.*?\]//g;
     print;
 }

This Perl script will remove the CR, and WL/BL (time) tags from the SGF file. I had a version that also did comments (C tag) so that I could load SGF files from KGS et al. into PilotGOne.

Hope this helps someone.


uxs: I must agree with most other people here: the CR marks seem non-standard and as such incompatible with most other applications that handle SGF-files.

The problems are two-fold:

  1. SGF-files created by KGS contain, for other editors and viewers, superfluous CR markers
  2. In an SGF-file created by a different application, Cgoban doesn't by default show the last move; the user has to use the "mark moves" function first. This function inserts a marker on each move to indicate that move. (This is the big one for me because I download lots of files from DGS.)

In effect, SGF-files created by Cgoban all contain, for every single move, 2 different ways to indicate what the last move is. An example from a random game:

;W[ce]CR[ce]
;B[be]CR[be]
;W[bd]CR[bd]
;B[cc]CR[cc]

I'm sure that any reasonable person would agree that this is rather silly.

A much better way would be to just leave the CR marks out and change the option "Mark moves" to something like "Indicate last move", which would just show a mark on the last move, without changing the SGF-file.

If however WMS is so stubborn that he insists on being the odd one out in the SGF-world, I request that he creates an option for Cgoban that creates the CR marks by default for SGF-files that don't have them, because having to "mark moves" each time is quite annoying.


About this page

(Sebastian:) This discussion was originally moved from KGS Wishlist / File Handling. The page was named "KGS/SGF Details", and it was preceeded by the headline "FAQ on How KGS & CGoban 2 Use SGF". apparently with the intention to include related issues. axds initial request seemed indeed to point in that direction, but from his later contributions it is evident that his actual point were the CR marks. Since the issue grew very big it deserves a page on its own. If other KGS/SGF issues crop up we should create a general page and include a link to this page there.


This is a copy of the living page "KGS Issue - CR Marks on Moves" at Sensei's Library.
(OC) 2004 the Authors, published under the OpenContent License V1.0.
[Welcome to Sensei's Library!]
StartingPoints
ReferenceSection
About