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.
- IanDavis: I struggle to understand your remarks. CR usage is described as Marks the given points with a circle.,
- Exactly, it does not say Marks the last move.
- 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)
- MK This is a piece of code from one game: (;W[lp]CR[lp](;B[qq]CR[qq];W[pq]CR[pq];B[qp]CR[qp]... and so on. As is clearly seen with every move there goes a CR[] mark. I can't see any reason for that and the drawback is that SGF created with CGoban doesn't work well with other applications like Hibiscus or sgf2misc on Gobase when it comes to printing an SGF. I think it is a bug. Is the reason for keeping those CR's to show a circle marking the last move? Isn't it easy to find a workaround so that the SGF file is more useable?
...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.
- If you call "writing about what the screen shows" a mark of stupidity or carelesseness of some authors,
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.
- Dang. I just looked, I couldn't find it either. It was either in an ealier spec that isn't there, or else my memory is playing tricks. In any case, you are right on this point - the spec does not say that explicit marks should override implicit ones.
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.
- axd The standard does not mention how to use the CR (let alone use it properly - see Symbols), nor does it impose that proper use of the standard implies to show a small circle over the last move.
- wms: Right! That's exactly the problem! The spec doesn't say at all how to mark the current move,
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 !
- axd: SGF editors have a far more powerful way to refer to the current move, using the focus marker; furthermore, if the creator of an SGF even remotely thinks there might be uncertainty or confusion, several markers are at his/her disposition to clarify things if needed. When you are explaining/reviewing a game over a traditional board, you don't keep your finger on the last played stone to guarantee that your opponent knows about which move you are talking. This is not an argument to hijack CR. Current editors have the perfect means to highlight the last/current move. I don't see in how more wordings I can put this.
- From the guy who shouldn't toy with GUIs : axd just almost described what is the real solution to last move markers. A static marker is not a "natural" thing, but it's unfortunately the so called "solution" chosen by most software authors. It might not be too much of a problem for users accustomed to go servers and softwares, but a static marker is disturbing and might very well help beginners in keeping the bad habit of "following" opponents moves, instead of looking at the big picture. A definitely better solution is to (optionally) let the played stone blink for a short moment when it's played, and add an easily accessible "show last move" button in the toolbar (best, with a simple keyboard shorcut). Another advantage would be that SGF file creators would be less tempted to use piece of sentences like "red dot" and would be probably more inclined to place a CR[] marker and naturally reference it as the circled stone.
The complaints I get about this are generally:
- It makes things look ugly, because my SGF editor puts both the circle and a red triangle/cross/whatever is used for the last move mark!
- Answer: This is a legitimate issue. I thought that the spec said that explicit marks should override implicit, but I could not find anything like that!
- It makes the SGF files so big!
- Answer: In a 300 move file, it will add 1.8KB to the file. I don't see this as a big deal. Disk space and network space are quite cheap, even with millions of games (like KGS has) the extra "CR[]" marks are inconsequential.
- axd yes, but the information added is pure noise.
- wms: Adding newlines in the file could also be seen as pure noise. Do you complain about them too?
- axd: No. I complain about cGoban hijacking the CR marker for its own purpose. The SGF format does not refrain the user from inserting as much newlines as (s)he likes.
- Answer: In a 300 move file, it will add 1.8KB to the file. I don't see this as a big deal. Disk space and network space are quite cheap, even with millions of games (like KGS has) the extra "CR[]" marks are inconsequential.
- It confuses my editor/viewer because it makes it think that there is a markup on every single move!
- Answer: This is a legitimate issue.
- axd it does not confuse any editor. the editor doesn't care about the CR marks. but it confuses the USER.
- wms: I have no idea what you mean by that.
- axd I'd just like to re-insert a part of my reply that was edited away, somewhat obscuring this thread:"...Furthermore, note that cGoban - afaik - is the only editor with this problem." (See page history for details)
- Answer: This is a legitimate issue.
- If you upload a non CGoban SGF file, the last move marker is missing because of the CGoban handling of the last move...sometimes difficult when showing and commenting a non KGS game.
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.
- Tzad: I think you are making it a much greater problem than it really is that comments are correct in respect to how the current move is marked. It is a much greater problem that you are not able to use some features of other SGF editors, like go to the next move with markings etc. because the SGF file is polluted.
- axd It is important that reviewers are aware of the inherent problems linked to comments in SGF files, typically when referring to moves/locations/variations (a solution would be to introduce a hyperlink concept in the SGF spec, this would get rid of this problem). A similar issue exists with sibling versus child branches: one must be aware that referring to branches can be problematic when viewed with a different-style editor (even if some styles are not recommended, see also
http://www.red-bean.com/sgf/user_guide/#variations). Furthermore, referring to the "last move" is implicit because the comment in a node refers to "that" node (which is at that moment the last move) unless references are made to other moves.
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.
- axd: OK. then I will advocate from now on, specially because cGoban does not want to give in (while all other editors have no problem) to introduce the new SGF FOCUS MARKER (FM) property. It will be used to indicate the last move (while this is totally unnecessary, while the concept of "last move" has no meaning in a SGF file, as it is implicitly the last move of the file). and cGoban will be the first to introduce this FM property. Note that the SGF format allow anyone to introduce new properties as long as you respect (...) the existing ones, so nobody will complain about the new property, because editors are supposed (this is part of the SGF file format) to be able to handle unknown properties. SGF users ar kindly requested to prove/disprove this property, which we will then add to the standard.
- wms: Wow, you totally don't get it. FM wouldn't solve what I'm solving with CR at all. It's not the marking that I care about - it is that the appearance of the mark is specified. FM, as you proposed, does not do that.
- axd Tthe problem is that what you claim to be a solution, is perceived by others as a nuisance. The problem you are trying to tackle is solved long ago in other editors. "FM, as you proposed, does not do that." So you are imposing a standard (on the use of CR) upon others? BUT FM WOULD solve the problem - because it is exactly the idea of FM - showing the last move. Just imagine that you would decide to hijack the SQ (square) because you would like eveyrbody to see where a Ko occurs; would you then also afterward claim that you solved a problem, and therefore would impose a meaning of a symbol on the SGF editor community, saying that "anyway, that's final"? It shouldn't be difficult to duplicate the code currently using CR, and replace it with code generating FM, and having FM display a circle; you would be able to continue using your circle everywhere, and nobody would complain about cGoban's use of CR. But that's the real problem: CR is probably too deeply rooted in cGoban's working.
- axd: I'm very sorry, but deciding to use the CR mark because a reviewer referred to his editor's using of a red dot to mark his "last" move is a gross mistake. I don't know in how many other ways I can put this. It is obvious that placing a CR mark in every move is overkill, and adds totally useless information in a SGF file - for the very simple reason that it is present EVERYWHERE; if it wasn't, then maybe cGoban would have a case. I used the word "misuse" to describe this situation, but "hijacking" is even closer to the point.
- Anon: Think about this differently. People put marks on the board for reference purposes. cgoban2 says it wants its users to always be able to reference certain moves through the use of a marker, and inserts the markers accordingly.
- axd: With all respect for this great application, it is my opinion that wms does not want to follow the idea behind the CR mark, which was certainly not designed to be used a THE focus, but as AN additional focus tool. I think wms is showing a gross disrespect for the format by insisting in this evil direction :-), and I think the only reason wms keeps insisting on the rightness of his decision is - I am afraid - because removing the use of CR in his application has too many side effects rather than because of a so-called lacune in the SGF format; otherwise I can't see what the problem would be.
- axd: This "feature" is even a nuisance when downloading non-KGS files in a teaching session: because of the then-missing CR markers, it is almost impossible to follow the session, as one can easily miss the placement of the next stone. Therefore this is another - and this time heavyweight - (didactic) argument pro reviewing this use of the CR marker.
- Vesa I'll join the critics here. WMS has invented a weird use for CR[] markup and insists on that. Normally SGF editors highlight the current move without polluting the SGF file with nonsense markups. ("Last move made" - huh?)
- Vesa Circle is one possible markup for highlighting a commented stone or group (a stone breaking the ladder, a group in danger). Now this symbol is hijacked and cannot be used as originally intended.
- wms: At the time I settled on CR[] to mark the current move, it was the least used markup by far in books and online files - CR and TR (and MA) were much more common. It had no original intent. All the markups were simply there to indicate markup of some kind. If you use cgoban to build on SGF file, then you will be using CR as markup to indicate current move. If you don't want to use CR to indicate current move, then don't use CGoban. I don't see the problem, I'm not hijacking anything, just trying to make an SGF editor that will let people easily build files that will look as intended on other SGF editors.
- Vesa The problem is not that I use cGoban as a SGF editor, I have made another choice of a good SGF editor. The problem comes from the game records in Kiseido Go Server, which are polluted with the CR[] markups. I don't like the CR[] markups but every single game I download for study from KGS contains those. Because of this peculiar implementation, now every SGF editor should have a function "clean KGS markups". (Actually, now that I think of it, what a handy feature that'd be :)
- axd: I can understand that CR seemed useful because underused. but forgetting that other editors have features that enable users to quickly step to nodes containing markers; by adding CR everywhere, you effectively cripple other editors. Now, you state "If you don't want to use CR to indicate current move, then don't use CGoban": but I have no choice! I never wanted to use CR for that purpose, I don't even want my file to contain references to the current move becasue I know that every editor (but one) has this by design. Actually you are the only one that uses CR for this. PLEASE show some understanding for the abstract idea that littering CR throughout a file equates to adding superfluous information in a file, just be humble among the SGF user community, admit you are wrong in this matter (except from the point of view of people solely using cGoban, they do not know better), and try to give the CR marker back the only meaning it has always had: NONE: every author is free to use it for whatever it might be useful. There is a purely academic matter involved here, it's a matter of principle. You can permit yourself to admit this, your application is still a reference as far as I know this. By choosing to ignore this plea - more, to maintain you are on the right track, the only thing you will have proven is your indifference for an abstract idea (to avoid littering a file with superfluous information). I'm sorry to use such strong wordings, but I know I am right because my reasoning is right and most people will support me.
- axd: but finally, please explain how you will solve the problem of uploading SGF files that do not conform to your specification, therefore giving focus problems for the KGS/cGoban audience?
- wms: Try the "mark moves" menu item, under the "options" menu/button. Problem solved! See how well I can explain things? PS - axd - you keep confusing "current move" with "focus". They are two totally different things. CGoban and KGS mark the current move with a circle. They do not mark focus, the user must do that by hand if they want. Why do you insist on mixing the two?
- axd: Ah. OK - I didn't know about that one. It is stil strange to see a command that becomes unavailable once used. In the context of this discussion, it is for me yet another indication of the inherent problem behind your decision.
- Tzad: This can be a source of other problems as well. Suppose a SGF file is made using some other editor, and the author is using the circle symbol for some other purpose. Then in the commentaries he refers to "the stone marked by a circle". But then someone loads the SGF file in the cgoban2 editor and by habit click on "mark moves" because he wants to see which move is current. Then you will have a lot of confusion on those nodes where there are 2 circles instead of 1 as it was in the original SGF file. And then this modified SGF file is saved, and used somewere else or given to someone. Then your cgoban2 editor has caused a good commented SGF file to be broken.
- axd: I'm not sure if the SGF norm allows TWO circles at the same time in a node; also, I'm not sure if cGoban2 generates circles while reviewing a game - I think it's rather when recording a game. wms will confirm this.
- Tzad: The SGF norm allows up to 361 circles at the same time in a node on a 19x19 board. When reviewing a game, you can use the "Mark move" option in cGoban2 to fill the SGF file with CR marks, and get just the same result as when it records a game. You can also use the circle tool to add additional CR's of your own choice.
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.
Harleqin: Your script will only work in the intended way if no other CR have been manually inserted. It should instead only remove those CR that just repeat the move info. This, of course, will also break when someone marks a group that includes the current move and begins marking with that stone...
This CR use is a primitive hack from any programmers view. The issue wms is addressing can only be solved by including the shape of the "current move" marker in the standard, not by abusing the sgf language.
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:
- SGF-files created by KGS contain, for other editors and viewers, superfluous CR markers
- 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]
- ;B[be]CR[be]
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.
mgoetze: Yes, I would like this option too. Currently, the CGoban/KGS CRs seem to annoy two categories of people: those who use CGoban as their primary SGF viewer with external data, and those who use a different primary SGF viewer with data generated by KGS. (OK, and maybe a third group: the SGF purists. But I think this group is rather small.) At least for the first group this would be relatively easy to fix... just don't force me to click "mark moves" every time I load a game... the code is already there apparently, I just want to be able to invoke it automatically.
Darron Shaffer I agree with most of the posters on this page. An additional irritation is that move numbering works the same way. I see this as a muddling of data representation and presentation. I'd prefer to have an option like "show last move as -> normal/circle/square/star/blinking". Wouldn't that be enough of a hint to game commentators that the display is not standardized? Also, it's surprising to new users that requesting that the most recent move be marked modifies the game record.
axd: For those that succeeded in reading all this, have a look at the case of wms versus WinMGT concerning SGF in KGS Issue Kogos Joseki Dictionary.
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.