My short answer : I can now load long games, but one Alexander sent to me takes 10 seconds to load in PGN window (parsing, colorisation, etc). This game has a length of 77 kB, so I will set a hard limit at 128kB, any higher value is hardly usable.
Concerning the extra fields in a game, there are 2 kinds : - a field that belongs to the index (like a marker tag). Drawback : it is present for all games, even those that does not need it. Hence it has to be strictly limited and should only be used for short information with a wide usage (a "tactics" bit is ok here) - a free field (like a PGN header [WhiteCountry ...]) is far better for such data and can be searched through the already existing search features of Scid. So right now I see nothing to add to the game index. Pascal 2009/6/30 Alexander Wagner <a.wag...@physik.uni-wuerzburg.de> > Pascal Georges wrote: > > Hi! > > - on average a game takes 200-300 bytes (reference base with some >> annotated games) >> > > This could be, sure. Especially for unannotated games. > > - current Scid's limit is 64kB for a game (this means 30 games can fit >> in a disk block), which with the usual size of a game seems really >> enough for me >> > > - the few examples of very long games I got so far (some time ago) >> were uselessly and artificially long (whispers / kibitz, rarely >> interesting) >> > I think one might most likely hit the wall in case of > commentary in prose, am I right? Just as this text gets no > compression at all, I guess. In that case could one possibly > store textual commentary outside the games blocks to improve > performance and work with some sort of pointer to the > external text? Just an idea, I don't know Scids internal DB > organisation. > > One usecase for "rarely interesting" kibitz/whispers is some > sort of "social aspect" in CC gameplay as I was told about > from some Club members. They really play a game while > chatting with each other. Here "chat" in the sense of > instructural "chat". (I think this could be a usecase in FICS > as well but I do not really play on FICS that much.) > > If yes, what are the other changes to introduce in Scid's >> base format ? Please be very precise and concrete here >> (not "add extra markers to a base" or "cache the most used >> searches"). >> > > Well you name two points ;) A bit more to the point... > > This is just a list it should be checked what's feasable. > But this are points where I stumble upon some limitation in > the current format and in daily use not in esotheric cases > ;) > > In CC I have some game associated metainfomation that would > be suitable for Flags. E.g. there're tournaments with as > well as without engines. Thematic tournaments that start > with a given position (implemented by a move sequence, not > by a FEN, so you can't find them by searching for > nonstandard staring position ;), games that do not allow for > tablebases, stuff like that. To keep record of this kind of > information I think a set of "per base definable flags" > would be helpful. Say an array of user flags that I can > define to a meaning by some sting on the level of a certain > base. I could then define e.g. "no engines" to "baseflag 0" > and set this flag for games without engines and clear it for > games with engines allowed. (Currently, I work around this > by a similar construction that lives in CC code only.) Now > this flag would not make sense outside the CC games base, of > course, therefor it would be some sort of local flag. > > There should definitely be a flag for mode. OTB and CC are > quite different. This also goes with some tag for the time > control. Suggested is the [TimeControl ""] tag in the > header like > > [TimeControl "2592000+86400"] > > (30d + 1 per move for a Fischer clock e.g.) > > Also for my Ref bases I'd really appreciate some flags I > could set. Currently I use combinations of flags for certain > information. (E.g. I set brilliancy + blunder for games I've > an annotation in a book that does not talk about a specific > point in the game but found it remarkable for several > reasons. This works but it is not nice and surely is only a > workarround. And it defies me of marking my personal > brilliancies...) I use flags mainly to speed up searches for > specific informations. Especially, for hooking up my printed > literature with my reference base. > > To keep a refbase up to date it would be worthwile to > support tow additional fields "Source" and "Date added". > Currently, I set those in additional header fields, but I > think this could be more compact if some encoding is used > that refers to some internal authority. > > Concerning Metadata: there's some small company in northern > germany that produces databases which add additional > information to the header like > > [whiteCountry "ENG"] > [whiteTeamCountry "ENG"] > [whiteTeam "II"] > [whiteIccfID "123456"] > [whiteFideID "123456"] > [Source ""] > [SourceDate ""] > > This is most likely not complete. It could be worth while > to look at what's used there these days and support it > adequately. > > Also for hooking up my printed literature (there is a lot, > IMHO it would be worth to take this fact into account) I > found it very convenient to add tags to the header. You may > remember that I currently use [Ref ""] lines for this > followed by [Ref1 ""] and so on if I've a game that is > discussed in several source from differnt perspectives. This > is far from perfect. I admit that I'd greatly appreciate > some numerical flag (unsigned int) that could hook up with > some normalised Note field, like you use it in scientific > literature once you cite another work. Say, the "Evergreen > Game" is discussed by Kasparovs in his series and Burgess' > et al. Now, I'd like to be able to attache some [1] [2] > where [1] gives the full reference of Kasparovs book while > [2] the same for Burgess book. It does not have to be a book > that is referenced here, it could be any note in prose about > common points within a game. > > For a new file format it would be great if it could also > know about some archiving/transport format that consists > only of one single file. This single file could unfold on > the target system to the usual set. (This function is > similar to cbv.) > > One function I missed is already tackeld by the Masks. I'm > not sure if it might not be possible to use the Mask input > also for the caching. Like installing an opening key in CB? > I did never work with CB itself, but as far as I got it I > like the idea to install opening keys (caches for those > openings one is most interested in collecting all games that > are of interest in this area) as well as endings and tactics > or startegic motives. Those "specialised caches" whould be > most helpful for a reference base of course. > > One point I'm not at all clear about is actually concerned > with game metadata again. I wonder if one could not use some > sort of authority records for player/event/site names > instead of the written strings. This would surely have a > larger impact on the structure. However, IMHO it would ease > up the spell checking stuff and one could come up with a > plain soution to find Jussupow - ah in english Yusupov. > Just to give some name I always forget the spelling used... > He would just be 1234567 and Scid could draw the spelling(s) > from the ratings file e.g. (Could be advisable that the > spelling is stored in the DB for the case no rating file is > present.) I use this feature a lot in my daily work with > books and miss it in Scid. (German librarians love authority > records...) > > -- > > Kind regards, / War is Peace. > | Freedom is Slavery. > Alexander Wagner | Ignorance is Strength. > | > | Theory : G. Orwell, "1984" > / In practice: USA, since 2001 > >
------------------------------------------------------------------------------
_______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
