//20071212 // This is a corrected version of the file posted as OA1v1_availability.txt. This file adheres to the current syntax rules for entering availability. I think I have finalized the rules (or come close). I will detail them later. // BTW, this is a comment # This is another comment. Either of these comment types could go at the end of a line after non comment text. Everything before "//" or "#" is assumed non comment. Everything after is taken to be a comment... until the end of line. OpenArena 1 vs 1 // I haven't decided on the precise words yet but likely the parsing will be lenient and attempt to identify this name with one of the possible tournament. Not sure yet. // The tournament name comes before all the data that applies to the tournament. It takes effect until a new tournament name is encountered or the end of file. These tournament boundaries are introduced by a name (eg, "OpenArena 1 vs 1") on a line by itself. For now, do not put punctuation at the end of the line. This detail may change later. // During the part of the file where no tournament is in scope (maybe even for the whole file), it will be assumed that we are putting in *default* availability data which would apply to any participant with no availability data for the particular tournament in question. // Note, extra lines are fine anywhere in file or they can be missing altogether; however, the parser (as planned) will expect some things to be on a lines by themselves (this is different than what was stated earlier in replies). That would constitute part of the spec. I will define the spec more clearly at a later point in time (probably after the tool is built and working). In the meantime, I will produce another sample file with many examples and comments. // Note, also that we can have only one (official) file for the entire gamefest (hurrah). This is very convenient on admins and on users that want to supply a fix to their information. It also works out really nicely with the client-side javascript because all that is needed is an updated file to exist. The user copies all the text from that file and enters it into the proper location on the tool gui. Then hits "submit" "apply" (whatever) and gets to use the tool with the latest and most up to date info availble almost as if it were being served by the server (assuming the text file is up to date). There is the step of copy/paste.. but that is about the best I think I can do now without accessing the server. Considering all the clicking that will go on as the tool is used, requiring a copy/paste to initialize things seems not much of a burden. The real gain though is in the maintenance of a single text file, which is not in javascript (ie easier to understand and read), to cover all the important availability data of the whole gamefest. // The new rules should allow us to enter virtually any avail data in a fairly intuitive, consistent, and unambiguous fashion (fingers crossed). KIAaze: +1 //fine A sun-sat mon-fri 18-22 //This line is legal but has redundant info. sun-sat would cover every single day so mon-fri is redundant. w1zrd: +2 //fine A allweek //fine, but note that this is a special shorthand for "A everyday allday". Note the day component and the time component. Thunder_PT: +0 //fine. "-0" would also work. A tue 17:30-20 wed 15-22 thu 11-20 fri 18:30-0:30 sat 14-0:30 sun 15-21:45 //fine Phenax: -5 //fine A mon-fri 16-23 sat-sun 12-23 //fine vostorga: -6 //fine A allweek 17-22 //fine, but I plan on issuing a warning for this as it has redundant info. It means every hour of the week. Perhaps you intended to say "A everyday 17-22". Note. I am explaining the current rules. Perhaps you correctly relied on the draft I provided in the earlier post. Ignore that. I should soon provide a file with lots of examples based on the current design for the parser/tool. *********** Everything from here down is a comment. This section is marked off by 5 or more '*' appearing on a line by itself with nothing else (eg, no spaces; only the equiv of eoln). Comments should be minimized (preferably zero), but this section is ideal for putting in availability details that do not conform to the rules or which the data entry person could not figure out how to do (ie, "help").