David Bethel
	This is a basic description of how the order editer parser.cfg works. The parser is composed of a number of templates that describe how certain sections of text are processed. The parser starts in the first template looking for all the strings described by ther extractors there. If it find any of these strings then the data is extracted and it is possible to run one or more templates on the extracted data. In each template there are the following elements Comments Variables Templates Extractors Extractor Prints Prints Processes Creates GroupPrints Most of the parser is brute force and is a work in progress. Each of the above will be described in the posts below.
David Bethel
	General Points All text is enscapulated by "" characters and it is not possible to represent these in the parser expressions - this was not fixed as HTML can use the ' char in place of " Comments Comments are any line that starts with a #, and it is ignored by the parser Variables These are definitions of global lists of variables that will be used to hold data. They are all strings and must start with a '$' character. The are not a single item of data but rather a list that is added to each time data is extracted into them. Variables used in extractors that are not declared are considered local and can only be used in the extractor or the first lvl of template call from the extractor. There is a long list of variables that are used to store the info that is placed into the database by the order editor. They are defined Variable="$<name>",0;
David Bethel
	Templates Templates encapsulate extractors, processes, prints, creates and group prints. There are no global extractots they are all local to a template. The first template in teh parser.cfg file is called by the parser and the rest of the templates run when extractors call them after the extractor finds a match. Templates are defiend Template="<Name>"; All other definitions between a template define and the next template define (or the end of the file) are considered part of the template. Prints Prints are either a plain piece of text or a collection of variables + text that prints at a specific point when a template is run. Prints before the 'Extractor=' defines print when the template is entered, prints after the 'Extractor=' defines print when the template is finished. There is also a print that occurs straight after an extractor is matched. Prints are defined Print="<any text>$<any variable><any text>......"; Prints that run straight after an extractor are required to be placed after the extractor in the parser file with a different define eg Extractor="<Match>$Var"; ExtPrint="We matched $Var"; <This is a work in progress i will add more later>
Steve-Law
	While these "manuals" on the parser are great, would it be possible for you to give an actual practical example of using (changing) the parser.cfg? For example, something that is relatively simple, but quite "generic", how about an explantion of how you would go about adding a list of all starbases/outposts present on a planet onto that planet's htm file. Something I'm wanting to do, but also an example that would lead to many other similar additions and generally help us understand the way it all works. By taking us through the process step by step with comentary, it would greatly help those of us interested in "cracking the parser" (maybe its just me at the moment but it will be a powerful tool once we can start making additions etc. :) (Obviously, your time permitting of course :) Thanks David anyway :)
Lord Scrimm
	I agree that an example would be helpful - just to get a better idea of what is happening "under the hood". My suggestion would be for a way to change the Scanned Position Extractor and Print so that it shows the Aff associated with all the hundreds of ships/starbases/outposts I've scanned to date. It gets REALLY confusing trying to use that data when there is no contextual information associated with it. ie: Position Dragon Tongue (xxxx) - was that a FET ship/starbase or a HVE one? Showing it at FET Dragon Tongue (xxxx) would help alot for tracking/posting purposes Cheers, Rich Fanning aka Lord Lawrence Scrimm CIA Director of Regional Operations
Steve-Law
	I agree that would be really useful, but the way I understand it, the Match text (STARBASE, OUTPOST, SHIP, PLAFTORM) appears after the aff tag, but the extractor (?) will only pick up the text AFTER the match. I may be wrong but this seems to be a case where the parser can't make that change.
Lord Scrimm
	That's why I thought it would be a good example - it adds in functionality and definitions I was thinking that in order to do this, it would require a local variable designed to match and extract the Aff Flag, then combine it with the variables following. However, based upon my initial look, this "appears" to require the Aff to be defined in the actual parser rather than the cfg. At work now and don't have the parser.cfg in front of me atm. This is what I remember on trying to hack the parser though. Cheers, Rich Fanning aka Lord Lawrence Scrimm CIA Director of Regional Operations
Steve-Law
	Hmm. I see where you are going - capture the aff flag with a separate match and hold the variable until the position type extractor. Problem is (as I see it) that there is nothing consistently preceeding a position in a scanned list. e.g. Scanned: DEN SHIP FINDER EXTREME (?????) - {20 Normal Hulls} Courier Class Explorer {No Armour} Controlled by ?????@????? CIA OUTPOST FOOTHOLD (?????) - {2-4} 20 kMus DEN SHIP DRAGONFANG (?????) - {75 Heavy Hulls} Broadsword Class Heavy Cruiser {Heavy Armour} The match to capture the AFF flags would be different for each one. You could try and check for every possible instance, but as soon as you get the controlled by line you have no way to predict what the text is going to be.
Kurik
	Hiya I would like examples as well. I am quite prepared to hack my way through the cfg file butIn order to have a chance of gettign anythign to work I need examples please! Cheers Phil
Steve-Law
	I've had a play around and I'm 99% convinced that you can't add the AFF to the ship name. This will need a change to the Order Editor's parse, or the turn print out. (Or a pre-processor that moves the AFF flag to after the position label, i.e. DEN SHIP Wolfie(1234) => SHIP DEN Wolfie(1234) ) Someone, maybe even me if I get time, may be able to write that pre-processor, but it's far from an ideal solution. If there are any other players who think this change to the editor itself would be useful, please speak up.
Kragnost
	Would players find it acceptable for the results to show: SHIP DEN Wolfie (1234) STARBASE DEN Aslan (1665) rather than the current: DEN SHIP Wolfie (1234) DEN STARBASE Aslan (1665) if so then this might be the easiest solution to getting Aff tags into parsed information. Could the parse.cfg file be modified then to produce position information for the data.cfg as: Wolfie (DEN) Aslan (DEN) because having DEN Aslan, DEN Wolfie, etc in position lists is going to make the position name dropdown lists very unhelpful if people press the first letter to jump to what they're looking for as 'A' and 'W' will no longer work for the example positions.
Kragnost
	I know the parser currently ignores anything that already exists in the data.cfg but could an enhancement be made so that if the "name" of a position changes it is listed as something that is a candiate for being updated. If we take it that Aff tags are included in positions name we could have the following example: I do a deal with the DOM and DEN Skypoint (1824) becomes DOM Skypoint (1824) I would like the parser to let me know and give me the chance to update the information maybe listed on the parse dialog as: Skypoint [DEN] (1824) -> Skypoint [DOM] (1824) Thus I have the option of updating for the new name or leaving it as it is. Without the aff tags being part of the name the same holds true if a position is renamed.
Steve-Law
	QUOTE (Kragnost @ Jul 10 2003, 11:13 AM) Could the parse.cfg file be modified then to produce position information for the data.cfg as: Wolfie (DEN) Aslan (DEN) As best as I can make out (with the functions already used) it wouldn't allow this. Everything between SHIP (STARBASE, etc) and "(" would be put into $Ship_Name The parser would need extra user functions for that sort of thing. For example, using the format as it is: "DEN SHIP Wolfie(1234)" You'd need something like: PreExtractor="$AFF SHIP"; Extractor="SHIP $Ship_Name($Ship_Number)"; Process="Merge", "$Ship_Name", "$Ship_Name [$AFF]"; The PreExtractor to match text and grab the text before it, put it into the $AFF variable. Then something like the "Merge" function to combine two variables in whatever format you want. ("$Ship_Name [$AFF]" would give Wolfie [DEN] (1234); "$AFF $Ship_Name" would give DEN Wolfie (1234), etc.) Even if these functions were added it probably wouldn't work without other changes to the way the parser works - if I understand how the variables are being used - but without seeing the source I'm only guessing at all of this. (Sorry if I lost most of you there :)
Kragnost
	I don't know how much of a pain a "pre-extractor" would be but the requirement for one can be avoided as already described. The need for a "merge" function prob. cannot be avoided as I don't think remembering positions as "AFF Position_name" will be acceptable. If the ability to merge strings can be provided the processing then becomes: Extractor="SHIP $AFF $Position_Name($Ship_Number)"; Process="Merge", "$Ship_Name", "$Position_Name [$AFF]"; Unless of course the parser needs somthing it can detect between the AFF tag and the start of the position name.
Steve-Law
	Actually, I don't think a merge type function would work, so maybe a one off setting somewhere where you could set the name format.
Steve-Law
	Has any progress been made on this whole position name / aff flag parser thing? If not, it looks like I'm going to have to make that pre-parser program after all... (Has anyone been doing anything interesting with the parser that they want to share?)
David Bethel
	i doubt any changes to the parser will be made for a while. I do intend to improve it but there are other things to do first.