Re: game info properties
> MV[player:move]The players should be introduced in the root, thereby get an
automatic ordering 0,1,2,.., and referred to by their numbers
to keep the file length short: E.g. player_2 plays at fh:
But is this at all necessary? So far I have only seen fixed
order of players during an entire game. So introducing this
order once in the root should be enough. Then just use MV[fh].
Why do we have B and W at all, except for backward compability?
To allow dull variations like black may move once twice?
> On the other hand think about peopleDo you suspect that programs would manage DT[played after Qing aera]
> maintaining large archives, and using scripts or other programs
> to manage them. Let's take dates (DT) as an example.>
> I agree that any date that can be given in ISO format should
> be listed that way, e.g. "1998-03-02" instead of "March 2nd, 98".
> But there are dates that can't be listed as ISO as the example
> "played in early Qing eara" shows.
correctly if used for interpretation rather than citation? I severely
doubt this. Also not every program will swap YYYY, MM, DD fields in
a window to a misc_text_interpretation_date field. So whether
non-interpretable data are in GC or DT is immaterial, ALA SGF allows it.
I can also live with a non-standard DT option (everything that is not
> What John Fairbairn suggested (and what I find quite reasonable)This should be fine for all. Besides it resolves current misuses:)
> is that we should have mandatory formats for information that
> can be strictly defined, such as game-results or (western) dates.
> But that we allow "non-standard" information in these game-info
> properties as well, such as DT[early quing eara], but only in those
> cases which are not covered by the specification.
> it might fall into the "it's-so-rare-that-who-cares"It is not that rare. Molasses ko at a Japanese game end would be.
> category :o)
On a related matter, IMO programmers should be much more careful
in evaluating life and death at the game end, if at all. I have
seen advanced CG programs that score the human opponent's live
groups as dead and do not allow manual correction, etc.
- At 02:29 PM 12/10/98 +0100, you wrote:
>From: Arno Hollosi <ahollosi@...-graz.ac.at>I allow arbitraty text in the date field, since lots of old files
>here are some questions that came up in emails
>with Jan and John Fairbairn.
> How do we record a certain period of time?
> E.g. Played from 1998-01-09 to 1998-04-12
> How do we record "played in early Qing era"?
have strange date formats. In my GUI I have 4 fields:
Year ____ Month _____ Day _____ Date ________
If I recognize the date and can convert it to yyyy-mm-dd format,
I do so, and display it in the year/month/day fields. If I can't
recognize it, I display it in the date field. If the user starts a game and
uses the year/month/day fields I use that data, but the user can still enter
arbitrary text in the fourth field.
>I treat the TM property as arbitrary text and let user type whatever he
> How do we record players having different times?
> E.g. pro vs. amateur
> Should we merge TM & OT (and remove OT), as TM is one
> of the entries which is most often not formated according
> to the specs?
(like "10 hours each", or "1 minute, plus 10 moves per 10 minutes").
I don't use the OT property.
>I have no objection to HA.
> Should we allow HA?
> How do we record traditional handicaps?
> E.g. "sen-ai-sen" (BBW)
Traditional handicaps cover more than one game, and an sgf file is a single
think using comments is good enough for this. "In this game XXX played
black, with BBW
handicap used over several games".
>I would use PB and PW, listing all of the black player's names in PB. I
> How do we record rank and names of players of
> a rengo or team go game?
think about the
format from the GUI point of view. I don't want to clutterup the interface
with extra text
fields for player names when they are hardly ever used. The names can be
so there no reason not to put the entire black team's names there.
>I would leave the result off and explain it using a comment.
> Is RE[Void] a good expression for unfinished games?
> (think of all the possible causes why the game was
> not finsihed)
> How do we record a game where both players lost?
>I didn't add possible solutions to that problems, because
>I'm curious about the ideas you come up with.
>Help support ONElist, while generating interest in your product or
>service. ONElist has a variety of advertising packages. Visit
>http://www.onelist.com/advert.html for more information.
>Sent through the SGF mailing list at http://www.onelist.com/
>SGF spec: http://www.sbox.tu-graz.ac.at/home/h/hollosi/sgf/
>Moderator: Arno Hollosi <ahollosi@...>