GateKeeper 3.x Documentation
Peter Hyde/Bartholomew Nov ‘16-Feb '20
Contents
What is GateKeeper?	1
How to use GateKeeper	2
Short version	2
Long version (more explanation of what’s going on, and special cases)	3
Gate Reconciliation & Report	8
Configuring GateKeeper for an event	9
Booking Data	10
Registry Data	11
Other configuration settings and management operations	11
Editing GateKeeper.INI   (for advanced users/support staff only)	15
Bookings CSV file format details	15
Hardware Requirements	24
To Do (possible features in future versions)	25

What is GateKeeper?
GateKeeper is designed to:
•	Simplify and speed up the tasks required of Gate staff
•	Lessen the chance of sign-in errors and omissions by inexperienced or overloaded staff
•	Reduce the fuss needed to prove someone’s SCA membership – local membership cards become moot, though in some cases an alternate form of ID may be required
•	Help with optional gate activities like t-shirt distribution and chore reminders
•	Provide a detailed Gate Report which the steward can use to reconcile attendance and on-the-spot payments for their Event Report, which the Reeve can use to calculate site, Kingdom Levy and Event Membership fees
•	Provide the relevant incorporation with an electronic record of attendance and - where jurisdiction allows - event memberships/indemnities
GateKeeper does not replace the need for prior planning, a Gate process manual and/or training, printed copies of relevant rules & schedules etc. for viewing, and whatever forms your local SCA incorporation says must still be completed on paper, such as sign-ins for minors. If in doubt, check!
How to use GateKeeper
Short version
Identify yourself as the current Gate person by entering your name in the GateKeeper name field – you won’t be able to complete any sign-ins until this has been done.
A person arrives at gate. You:
•	Ask them their (mundane) surname and type some or all of it into the Filter box
•	You’ll quickly find them in the left-hand (Bookings) table – unless of course they didn’t book*
•	You’ll also find them in the right-hand Registry table – unless they have never been a SCANZ or SCAA member**
•	Once you’ve clicked on the correct record in both tables, the Event member button may turn red – that means they don’t have a current local membership, even if they provided a membership number when they made their booking. The Affiliate member button will also be red, and can be clicked if they have produced a current membership card from another SCA incorporation, e.g. the US. Click whichever button applies; it will turn a bold green.
•	(Australia only) Even though they may be a current member, their indemnity may be expired, in which case the the Indemnity button will be red and you’ll need to click that also.
•	Now look for any red fields in the area below those buttons – each of these fields indicates an action that is required to sign them in, such as a parent completing a Minor sign-in form, paying unpaid attendance fees (including possibly an event membership fee), handing them a souvenir that they ordered, signing them up for a meal plan chore, etc. Click on each of these fields when the task is completed – it will turn green.
•	Review the Booking Details fields on the left for any additional relevant information, such as the fact they made a bunkroom booking (tell them how to find their bunkroom), or perhaps some additional information in a Booking Note, etc. If any of the detail fields seems to be truncated, hover the mouse over it to see the full information.
•	Once you’re happy and there are no red fields or buttons left on the form, click the Save button to complete the sign-in process. Sign-in information will be instantly saved to the Gate Report file and then GateKeeper will clear things up so you can start at the top with the next person.
* If they didn’t book for the event, use the Casual/Walkup button to record their casual attendance and calculate the payment due. (If you can spot and select a record for them in the Registry table first, you'll  save some data entry effort!)
** if GateKeeper can’t find them using the Booking record’s membership number (if any), their name and their SCA name, they probably aren’t in the Registry for NZ or Australia. But typing errors – especially membership numbers! - and name variations do happen, so you can always eyeball the Registry records yourself (e.g. by sorting by last name and then scrolling) – just click on the correct record if you find it, then continue per normal.

GateKeeper’s Sign-in tab, where almost all the action happens

Long version (more explanation of what’s going on, and special cases)
First you filter - note that the filter operates on more than just the mundane name – portions of their email address, SCA name and even membership number can be used instead. The filter works on BOTH tables at once but primarily on the booking table at left - see why later on. Normally you'd focus on the booking table - as soon as you see your person, click on their record to select it.
At this point GateKeeper will try to find a Registry record for this person also, if it exists. It will first search by membership number if there's one provided in the booking record (assuming they got it right!). If that fails, it will try to search by exact First Name and Last Name. If that fails, it will try to search by SCA Name.
If any of those searches succeed, the matching record in the registry table will be selected and coloured GREEN to indicate that there is a perfect match. If you believe it is WRONG for any reason, e.g. two people called John Smith, an incorrect membership number, duplicate/out-of-date membership records (it happens!) or whatever, then you can manually search for and select a different Registry record – note that clicking on column titles such as Last name will let you sort by that column, which can be handy for this situation.
 If Gatekeeper cannot find a match, it tries to place the Registry table in roughly the right place (e.g. someone with the same surname) and colours the selected record RED to indicate that it is NOT a perfect match and may in fact be wrong. You can then manually find the correct record if one is there.
When you manually select a record in the Registry table, it turns green (though possibly not the Mem# and Expiry columns, which will remain red if it is an expired membership).
Where no match exists or if a Registry record is selected but the membership has expired, then they’re not actually a current member. In such cases the Event member and Affiliate member buttons are both red, indicating that you need to click one of them to continue the sign-in process.
The fact that the Registry table is also filtered when you type text into the filter (i.e. not just the Booking table) can be handy for a casual walk-up who happens to be a current or former member. Even though they don't have a booking, they'll show up in the Registry table - select their row there, then click the Casual/Walkup button to complete the task - it will capture their Registry details to save you some data entry work, and of course will recognise their membership if it is current.
Additional notes about buttons and required fields:
•	If you select a record in either table and then change your mind, either select a different (correct) record, or cancel out completely using the Cancel button, or the ESC key or by clicking the green label next to the filter box. All of these clear the filter and selected records so that you can start again. If you’ve already entered some potentially-important data such as Affiliate details or Gate Notes, you’ll get a confirmation dialog before the cancel happens.

•	If you click the Event member button, a confirmation dialog appears. In Australia, this will remind you to have them fill out a paper event membership form. In New Zealand, the dialog permits them (not you!) to accept SCA NZ event and membership rules. GateKeeper will also assess whether an additional Event Membership fee is due. This will only be the case if they are a walk-up with no current membership, or if they provided a membership number (and hence paid no event membership fee) at booking time - but it turns out their membership is now invalid or expired. Everyone else gets a free pass, including (in New Zealand) all minors. If an Event Membership fee is due, it will appear as a red Funds Owed field, with the fee added to any existing Funds Owed total (if there already is something due from the booking itself). If they provide evidence of having recently paid for a membership, hold down the SHIFT key when you click the Event member button – this will stop the event membership fee from being charged.

EEvent member confirmation dialogs – NZ (top) and Australia
•	If you click the Affiliate member button, a small form will appear asking you for their membership number and origin, and reminding you to check their membership expiry date (if it’s expired, sign them in as an event member). No event membership fee is collected for current affiliate members.

Affiliate member form

•	In Australia, the Indemnity button may require action if they are a current member with an expired indemnity – including any visitor from an affiliate such as SCA NZ. Click the button to see the reminder below:

Indemnity reminder dialog

•	If you click the Casual/Walkup button, the booking table is ignored and a small form appears to collect the information required for an on-the-spot sign-in and payment calculation. This information varies from event to event. If they are a current or former member, you can reduce the amount of data entry required for this by first using the filter to find and select their Registry record before clicking this button. Note that the main information produced by this form, including the payment required, is presented in three editable fields near the bottom. This means you can edit those fields to allow for special cases not covered by the form’s predefined logic. Example: Pre-event or Overnight stays at Festival. Edit these fields to describe such cases in a consistent way and have the correct price. Also remember you can also use Gate Notes if you think it’s a good idea to record more information about their booking. At large events that might be such as emergency contact information and/or the name of their campsite - useful if, for example, you have recorded their car registration and later need to track them down!
 
Casual/Walkup booking form
Other operations, hints and special cases

•	The Event Info button provides any event-specific guidelines or other background information that the steward thinks might be helpful to you. For the sample event (Gate War), there’s also  helpful descriptions of the special training cases in the sample data. Definitely worth reading.
•	Do you need a unique Gatekeeper transaction number to enter into Square or some other EFTPOS system? Look at the record # on the Save button (bottom left) when it’s active/ready to be clicked. (If you’re going to pay for several people using one such transaction, it’s best to combine all their Gate record numbers, e.g. A23,A24,A25).
•	Do you need to record a transaction number from the EFTPOS system? If you turn on the Collect transaction number checkbox on the Settings tab, the data entry field show below will appear each time you select EFTPOS as a payment method (if you have to check several people in before doing the EFTPOS transaction, put  "see below" in the first few records).            
•	Do you need to alter the “Funds owed” (or “Refund due”) amount before you save the record? Hold down the Shift key and click one of the radio buttons below the amount amount –this will display an edit box where you can change it:
	
•	Clear the filter to start again by clicking on the green “Filter” label, by pressing ESC or by clicking the Cancel button at the bottom right of the form.
•	You want to Save but a red field is keeping the Save button disabled? Normally you’d just take the appropriate action to turn that field green. But, for example, perhaps you don’t want to mark someone as having paid by clicking the Funds Owed field, because they are actually going to bring you the money in half an hour. You do still want to sign them in though. OK – on your own responsibility, enter a meaningful comment in the Gate Notes field. Once that field contains data, the Save button will be usable, even if one or more of the action fields are still red. In cases such as this, it is up to you to remember to collect the payment, and to manually amend their record later when payment is made (ask the chief Gate Steward to do this, or see the Edit Gate Records description in Other configuration settings and operations below).
•	You want to Save but they forgot to bring their Car Reg with them? Not to worry, Save anyway. Later on you can temporarily turn off the Hide people already signed in checkbox, then find and select that person’s booking record to quickly update their Car Reg (and if needed their Gate Notes field). Note: this only works for people who booked, not Casual/Walkups, sorry!
•	The filter is the usual way to find records in either table, but be aware that you can also sort the tables by different fields by clicking on the column labels. For example, clicking once on Last Name will sort ascending by Last Name (label turns green); click again to sort descending (label turns red) and so on.
•	GateKeeper’s main form is completely resizeable and has many resizeable areas and elements. You can resize those areas by hovering the mouse between different sections of the form (e.g. between the two tables) until it changes to a “splitter” cursor – then click and drag in the desired direction. You can also resize the individual fields within the tables by dragging their title separators. These settings will be remembered when you exit and restart GateKeeper. Although it’s possible to run GateKeeper full screen, that won’t work too well unless your screen resolution is very small, because the important elements will end up very fair apart.
•	When you type into the filter you can effectively see matching or similar details in four distinct places – in the filter itself, in the Bookings grid (if they are there), in the Registry grid (likewise) and in the Booking Details information. Usually the bookings grid has precedence, especially if you have clicked on it after typing into the filter – but of course this will not be the case if you’ve entered a casual booking. Your best way to be sure of who you are dealing with is to look at the Booking Details data, as this reflects what will be saved for this person, regardless of which process caused it to be shown.
•	You might occasionally have multiple people of the same name turn up for an event, e.g. John Smith. Be careful not to either manually select the wrong person in the Registry records, or allow GateKeeper’s default data matching do the same thing – make sure it is definitely the correct person. If Gatekeeper locks onto the wrong person in Registry and, for example, the person who just arrived actually has no membership in the system, you can just select a random non-current member from the Registry grid, then just use the Event Membership or Affiliate Membership button as applicable.
•	The Casual/Walkup form won’t let you click OK until you’ve entered a valid email address and tabbed away from that field, i.e. hit Tab or click on one of the other fields after typing something into the Email field.
•	See that Group sum field near the top of the main form? Most of the time you can ignore it, but it’s a simple and sometimes handy calculator. Let’s say a group of people arrive to check in, and some owe money (or are casuals paying at gate). Click the Group sum value once before saving the first person’s sign-in - it will zero the total, which will then accumulate for each person in the group when you save them. When they’re all signed in, the total showing is what they need to pay for the entire group. Oh dear, did you forget to zero it before you’d signed in the first person? No problem – before signing in the second person, click the Group sum value once to zero it, then click it again to show the value for the last person you signed in, i.e. the first person in the group – subsequent sign-ins will accumulate from that starting value.
•	Want to get the total cash and EFTPOS payments made today (net, i.e. allowing for refunds)? Use the Daily Totals button on the Gate Records form - see Settings tab. The totals will be for the same day as the currently-selected record in the form, so select a different record if you need totals for a different day.

Gate Reconciliation & Report
Each sign-in you save adds a record to the GateKeeper.dat file which is kept in the same folder as the event’s INI file (typically the same folder as the GateKeeper program). Additional timestamped backups of that file are made each time you run the program or click the Gate records button – they are kept in the Backups subfolder.
An Export button in Gate records creates a CSV spreadsheet copy of the data. This is intended to allow the steward to reconcile attendance and on-the-spot payments for their Event Report, to allow the Reeve to verify and calculate Kingdom Levy and Event Membership fees, and to allow the relevant incorporation to have an electronic record of attendance and, where jurisdiction allows, electronic acceptance of event membership conditions.
The spreadsheet exported from Gatekeeper.dat therefore includes at least the following:
Booking ID (generated on the spot for casual attendees)
Mundane Name
SCA Name if any
Member number if any (even if expired; if necessary it will correct booking form value from Registry)
Member status (current member, affiliate member, event member – if the last is set, that also 
indicates that they have accepted local/event membership rules in NZ or completed the paperwork in Australia)
Event membership fee collected (amount)
Booking Type (e.g. Adult Full or Adult Day Sa,Su etc)
Age Category (e.g. 18 and over)
Paid/Refunded at Gate if any (negative for refunds)
How Paid
How Identified (if specified)
Gate Person
Gate Notes
Car registration if collected for this event (if tracking someone down because of an issue with their car, maybe use their booking record to see what campsite they should be in, or look at Gate notes if they are a casual/walkup)

The EXCEL formulae below generate useful totals for reconciliation and event reporting. Note that the quoted portions may need to vary to match original values from your event’s booking data, e.g. the second formula might need to match “Adult” rather than “18 and over” to be fully correct.

Number of attendees for which Event memberships are payable: =COUNTIF(H2:H1500,"Event")
Number of adult attendees for which Kingdom levy is payable:  =COUNTIF(K2:K1500,"Adult")
Value of event memberships collected at gate:  =SUM(I2:I1500)
Net value of all payments/refunds transacted at gate:  =SUM(L2:L1500)
Net value of cash transactions at gate: =SUMIF(M2:M1500,"Cash",L2:L1500)  - vary for “EFTPOS” etc

Note: a complete set of gate records should be sent to your Reeve so they can store it in the Reeve dropbox for the requisite period (typically three years for NZ, probably longer in Australia). In Australia, the Constable may require a copy also.

Configuring GateKeeper for an event
There are three main pre-event preparation steps:
1.	 tweaking GateKeeper’s configuration to match this event’s booking data format
2.	 getting up-to-date Bookings and Registry data in place so that GateKeeper can use it
3.	after you’ve tested/learned/trained with GateKeeper, and have the final booking data in place, the final step is to use the Go Live button on the Setup tab to get everything shipshape for live use at your event – if you’re using multiple computers to run GateKeeper, do this for each computer in turn.
The first task is mildly complicated and initially will be done for each event by Bartholomew or one of the Gatekeeper team – email gatekeeper at lochac.sca.org to request their support. Try to get this done at least a couple of months ahead of the event – basically as soon as the booking data’s file format is known. As time goes on and people become more familiar with GateKeeper, suitably-adept members of your event team may be able to do this job by looking at existing examples and applying the detailed information in the Editing GateKeeper.INI section of this document. For all but the most complex events, it’s usually just a matter of tuning a few simple configuration settings in GateKeeper.INI file, then testing the resulting logic against a decently-varied sample of your booking data. Minor tweaks to the booking data may also be required so that GateKeeper can make enough sense of it.
The second task can be done at any convenient time that you have a reliable internet connection on the computers running GateKeeper - even at the event. Try to get the final, ready-to-use booking data CSV file in place as soon as possible after bookings close, so that you can do some final testing, familiarisation and staff training. And try to get hold of the latest Registry data while you’ve got reliable internet and are quite close in time to the event, e.g. the night before. Both tasks are explained in more detail below.
GateKeeper’s Setup tab – hold down Ctrl and Shift to see the tab label, then click it!

Booking Data

Regardless of how booking are originally made and stored, It’s quite common for a booking deputy to maintain a local “master” spreadsheet of the event’s bookings which is steadily built up from all the data provided by your booking system, and which allows you to make local changes, e.g. for cancellations and amendments. You may also add useful columns to it, such as “Booking notes” or “Amount owed”, to handle and describe normal real-life situations that your policies allow for. It is this spreadsheet which you’ll provide for GateKeeper, so it helps to finalise its format – which columns, which names, what kind of values – quite early in the booking process, then provide a copy to whoever is configuring GateKeeper for you.
GateKeeper requires that booking data be provided in the form of a comma-delimited (CSV) file, such as those exported from Excel. It needs to have a single title row at the very top, then desirably just one record per attendee - and definitely no more than one attendee per record! GateKeeper does have ways to manage multiple-records-per-person (e.g. one line for personal information, another for booking information), but it’s complicated!
When GateKeeper is first configured for your event, the person doing that may ask you to make minor format or value changes that might be needed in the booking data itself, but hopefully this should be minimal or non-existent. GateKeeper is not crucially dependent on, for example, the locations of columns in a booking spreadsheet. But of course your booking records do have to contain enough of the right information for GateKeeper to do its job, and with field names and values that make enough sense to support that. As already noted, this configuration work needs to happen a month or more ahead of your event.
Then, once bookings for your event have closed and you've recorded any last-minute payment etc. information, prepare a final comma-delimited file from your spreadsheet for GateKeeper. This may be as simple as using the Save-As function in Excel – select “CSV – (MSDOS)” as the file format. Then:
•	Copy that file to the GateKeeper computer
•	Run GateKeeper, hold down Ctrl and Shift to see the Setup tab and select the tab 
•	Click the Browse button next to the Booking Records CSV field. Locate and select your newest CSV file.
•	If no problems are found, i.e. the file conforms to all the rules specified for it in GateKeeper.INI, you’ll be able to select the Sign-In tab again and see the booking information in the Bookings table.
•	GateKeeper will remember the filename and location and use it every time you load the application. You can always replace the CSV file with a later version containing more up-to-date data. Unless its filename changes, you won’t need to do the above steps again - just copy the updated file into place while GateKeeper is not running, then run it.
•	Just before the event, you’ll probably use the Go Live button to clear away any dummy sign-in records that accumulated from your testing, and to lock things down for live use. Among other processes, this will optionally replace the booking CSV with an encrypted version – that’s fine, so long as you have your own backup of the CSV should you require one, or can easily make another!
Registry Data
GateKeeper knows how to fetch the latest information from the Registry databases for both SCA Ltd (Australia) and SCANZ (NZ). Therefore all you need to do is run GateKeeper on a machine with an internet connection, hold down Ctrl and Shift to see the Setup tab, select it, then click the flashing “Fetch” button.
Generally speaking, it is always safe to do a Fetch, which is why the button will flash at you whenever you visit the Setup tab. If the internet connection is working, the latest Registry data will be fetched and saved locally for future use. If it is not working for some reason, the existing copy of the data will be preserved for continued use (though it may of course be out of date if it was last fetched weeks or months ago). If you have a patchy internet connection, there is a small risk that GateKeeper will only get a partial copy of the database – that’s why it’s best to do your final Fetch from a known-good connection just before the event.
Note that GateKeeper may not see recent membership sign-ups or renewals that haven't yet been processed by the Registrar. And the Registrar doesn't process new transactions on a daily basis – especially if they might themselves be busy preparing for or travelling to the same event! Therefore, especially for big events, it is an excellent idea to remind all attendees to check at least one week before your event and make sure that their memberships are current. See the Expired button info below - it helps you to do this. If they don't renew, or leave it too late, they may arrive to find that GateKeeper insists that they sign in (and pay extra) as an event member – even if they have provided what was a current membership number at the time they made the booking several months ago.
Other configuration settings and management operations
On the Setup tab (see and access it by holding down the Ctrl and Shift keys!) you will find the following additional settings and operations:
•	For privacy reasons, the Registry unlock code is required to provide time-limited access to Registry information. If yours has expired, or will do so shortly, contact gatekeeper at lochac.sca.org to get an updated code that extends past the closing date of your event. For US events, put 'USA' (no quotes) to disable AU/NZ Registry access.
•	The Event-specific info doc field allows you to specify a briefing document which the steward has prepared for use by gate staff, for example a Gate Process Manual (though they really should have a printed copy of that also). The document is accessed with the Event Info button on the Sign-in tab. The contents are event-dependent and completely up to the steward. Be aware that the TYPE of document must be one which can be read on the gate computer(s). For example, don’t make it a .doc file or .pdf file unless there is known to be a reader for those file formats on the gate computer. Very safe bets would be either .rtf (which you can easily save-as from Word) or .txt files.
•	The Collect car registrations checkbox allows for their collection when people sign in; they are stored in the Gate records file and you can use the filter provided on the Gate records form to find one if necessary. Use the owners’s booking record (via the main form’s filter) to find their campsite if required, or look in Gate Notes for a casual/walkup.
•	The Expired button can save time at gate, and also save attendees money! It generates a report listing the email addresses of all those who provided valid local membership numbers with their booking, but whose membership has expired. The report includes sample text for an email to send them to remind them to renew before the event, to avoid having to take out an event membership. Use this report at least one and preferably two weeks before the event starts. If offers to do a Fetch first, to ensure that your Registry information is fully up to date. See the screenshot below for an idea of its output – it’s up to you to use the email addresses and sample email text to actually contact the people concerned. Please do so in a way that doesn’t expose all the email addresses to each recipient (normally, you do this with a distribution list in your email client, or by pasting up to 10 email addresses at a time in the BCC field of your email). Note that for group bookings, the membership number which GateKeeper flags may not be that of the person who made the booking (who gets the email).

Sample output from the Expired button (obscured and cropped)

•	The Go Live button is best used after you’ve got the final booking data, and soon before you open bookings – it gives you a set of optional steps such as doing a final Registry fetch, clearing the Gate records file (e.g. if you have been running tests or training) and it also encrypts the CSV file. See the screenshot below.

Go Live dialog – risky operations like the first one do get additional confirmation prompts
•	The Using in Australia checkbox. This changes some of the GateKeeper’s behaviours – including the settings below it – to allow for differences between SCA NZ and SCA Ltd policies. You can also mix and match the remaining settings manually if sensible and desired.
•	Event membership/insurance fee – currently $2 in New Zealand and $5 in Australia
•	Minors also pay Event Membership/insurance fee – true in Australia
•	Require the attendee’s ID method to be specified – probably true in Australia – this makes the “How was this person identified?” field on the Sign-in tab a required action
•	The Save transformed/pruned spreadsheets checkbox is only used during testing of Gatekeeper with new booking spreadsheets; it’s ignored when off, or once you go live.
Finally:
The Gate records button is provided to allow manual tweaking of the sign-in records. The most common case for this might be if someone completes sign-in, but had to go away to check their car registration or get payment that needs to be made, etc. Or to correct details they got wrong in their booking, such as membership number. EDIT WITH CARE! 

Gate records form – note the Export button

Result of clicking the Gate records form’s Export button
If you need to delete a duplicate sign-in record, press Ctrl+Del (there will be a confirmation before the deletion happens).
Note: the Cancel button or the top-right X button cancel all edits or deletions you’ve done since this form opened (there is a confirmation dialog beforehand so you aren’t likely to do this accidently). The Save button is the only way to save all your changes, no matter how many or how few.
Extra safety is provided by the fact that a timestamped copy of the sign-in data file is made in the Backups subfolder every time you click this button, and also every time that GateKeeper is run. (If something goes badly wrong during an edit, it’s up to you to exit GateKeeper, find the appropriate backup and copy it over the the damaged Gatekeeper.dat file, then restart).

Editing GateKeeper.INI   (for advanced users/support staff only)

Note: if you have any difficulty saving Gatekeeper.INI or your CSV file, ensure that your Gatekeeper folder is not under c:\Program Files but instead in some less-sensitive location, e.g. c:\Gatekeeper.
While the Setup tab in GateKeeper provides several setup and country-specific configuration options for regular use, the first and most important task required to make GateKeeper usable for a given event is to customise it for the booking records and prices used for the event. This is done by editing GateKeeper.INI, a simple text file which lives in the same folder as the GateKeeper program. Edit with care while Gatekeeper is not running, otherwise your changes might be lost. Test thoroughly!
GateKeeper requires that the event’s booking records can be provided in a comma-delimited (CSV) file, with a single column title row, then one (preferably!) or perhaps two adjacent rows per attendee. It at least requires that booking data can be fairly readily converted into that format, e.g. from a spreadsheet or the output of an online database. If you can find a way to reliably make that conversion at least twice - once early on for configuration and testing, then again for the complete and final set of master booking records once bookings close - then GateKeeper can be used for your event.
Before getting into details, here are some basic rules for the INI file:
1.	all lines starting with a semicolon are comments
2.	case is generally not important but column names with commas in them are bad
3.	all settings in the INI file belong in named sections, such as [Transforms]
4.	the order of distinct sections in the INI file is totally unimportant
5.	some sections contain individually-numbered items, one per row e.g. Action1=something. While it’s not important that the numbers are sequential, it does matter that they differ. For example, if you have two Action1 rules in the [ActionFields] section, only one of them will have any effect.
6.	Make sure the rule you’re working on is in the right section, and don’t muck with settings in undocumented sections unless you are very confident about what you’re doing.
7.	To make testing easier when working with multiple events, you can run Gatekeeper with an ini file as a parameter, e.g. make a shortcut like this: Gatekeeper.exe d:\data\Gatekeeper-MyEvent.INI – not only will Gatekeeper look at that INI in that location, it will also use that location as the default for storing sign-in records and their backups and will look there for the csv file and event-specific rtf file if no other path is specified for them. It still stores the Registry data and expects to find this Gatekeeper.rtf file in the same folder as Gatekeeper.exe, as neither of these are event-specific.
Bookings CSV file format details

See the italicised comment at the start of the Booking Data section regarding the value of maintaining a master spreadsheet, and generating a CSV file from it.
This file provided must start with a single title row - the field names provided by that row will referenced by settings in the GateKeeper.INI file. The exact field names and field orders are not important apart from some minor restrictions noted below. Likewise, the values (e.g. Yes/No vs True/False vs 1/0 vs None etc.) aren't that important either, so long as they are used consistently. But the presence and function of certain fields is vital, and some other fields are at least desirable.
Field & column name restrictions: these must not contain commas, nor the string “[+]”, which can be used by GateKeeper settings to combine two fields, e.g. first and last names – see the example in Booking Grid Fields below. It’s desirable but usually not essential that field names don’t start with “!” or “$”, both of which are used for pattern matching.
Bearing in mind that the actual field names in the CSV file can be different from those used below, the fields that GateKeeper is most interested in are:
1.	A single Name field for the attendee’s legal name. If your booking system captures separate last name, first name fields, Gatekeeper can combine them into a single field during processing. In its INI file, GateKeeper calls this field Mundane Name.
2.	Several other required fields, including SCA Name (can be empty), Member Number (ditto for non-members), Age Category, Booking Type, Balance Owed (if any; negative if a refund is due) Email and Booking ID (a unique identifier).
Of these, only Age Category and Booking Type aren’t obvious. The former is likely to be something similar to "18 and over", "15 to 18", "under 15", etc. and needs to differentiated enough to convey two pieces of information to GateKeeper - a way to distinguish Minors from Adult attendees, and (possibly) different pay-at-gate pricing levels for casual attendees of different ages. Booking Type is merely a descriptive field for passing through to the final GateKeeper report - for example "Adult Full" for a full event booking, or "Adult Day" for someone who just booked for a day or two. If, for example, your booking data provides both the Adult/Minor information and the Full/Daytrip information in a single field, it’s possible that some complex conversion features provided by GateKeeper can split this out into separate columns (this is done for the Festival’s booking data) – see Transforms below.
3.	Many soft fields - some of which might support required check-in actions and some of which are just for display/reminder purposes for the gate staff. None of these are required; you'll configure those which you want for this event and ignore those you don't. Possible examples are Meal Plan - perhaps so you can ask those who are booked for that to choose a meal-plan chore or pass them a special entry token -  souvenir actions (so you can remind gate staff to pass them the specific souvenir(s)), and equipment bookings.

The soft fields are divided into two categories - reminders, and actions. For reminders, you can have as many as you want, freely based on any field from the CSV file - for example, a reminder could be a note that someone is attending this event for the first time, therefore perhaps give them a thorough briefing. Reminders are simply displayed in the bottom-left hand summary panel and, if the gate staff ignores one, it’s just too bad.
In contrast, action fields require the gate staff to click on each action, to indicate that a related task has been carried out. These actions include Minor sign-in and Owed/Refund fields, both of which use values taken from the required fields mentioned in (2) above. But actions can also include chore allocation, souvenir dispensing and so on - basically, the things most likely to be forgotten by both the attendee and gate staff if there wasn’t some kind of action-confirmation step provided.

Think of actions as an essential-item checklist, whereas reminders are “they’ll probably remember anyway” or nice to know stuff. It’s a judgement call as to whether something belongs in one list or the other, and that may vary considerably from event to event.
The way GateKeeper connects the fields it needs to know about with the fields provided by the bookings CSV file is very simple - via a series of lookup lists contained in special sections in GateKeeper.INI. There is one lookup list for each of the different functions that GateKeeper needs to accomplish. Each section is introduced below - note that none of the fieldnames or other values used in those sections are case sensitive.
Booking Grid Fields
This section defines the required fields which appear in GateKeeper‘s (top-left) booking grid. For each line in the [BookingGridFields] section of GateKeeper.INI, the left-hand value is the internal field name used by GateKeeper, and must be exactly as shown. The right-hand value, after the equals sign, is the name of the relevant column from the booking CSV file.
While Mundane Name, Member Number and Age Category (as a way to tell adults from minors) are absolutely essential, you could actually get away with defining the others as referencing empty columns in the CSV file. That said, a Booking ID (at least) is desirable for reporting, and it's not hard to generate one using Excel or some such, assuming your standard booking process didn't provide one.
Example:
[BookingGridFields]
; this is a comment - below is an example of how to combine fields – a space will be inserted
Mundane Name=First Name[+]Last Name 
SCA Name=SCA Name
Member Number=Membership No
Booking Type=Site Fee
Age Category=Age
Email=Email
Booking ID=ID Code

You can only use one [+] operator per line, i.e. you can combine two columns but not three.
Casual Field Names
This section defines the fields that you'll use for recording casual (walk-up) bookings at the gate, assuming your event allows them. While GateKeeper is not a booking system - most importantly, it does not have provision to do online payments etc. - it does allow information including fees for day-trip attendees to be calculated and recorded when they arrive. The assumption is that they are paying in cash and/or via a separate live-payment process, e.g. a portable EFTPOS terminal.
Almost all the field names in this section directly match those listed in the [BookingGridFields] section, because they represent the essential information. None are optional! So if there is no Owed (or equivalent) field in the booking data, either add one or re-use another field which Gatekeeper isn’t using – this approach is fine because nothing is written to the booking data file itself.
Example:
[CasualFieldNames]
Mundane Name=Legal Name
Member Number=Membership No
Booking Type=Site Fee
Age Category=Age
Email=Email
Booking ID=ID Code
Owed=Balance Owed

Casual Prices
Like Casual Fieldnames, this section supports casual bookings. It allows GateKeeper to offer per-day pricing options based on age and also determine what Booking Type ends up in the report, e.g. "Adult Day F,Sa " or "Child Full" or whatever.
The Days row is required if you permit per-day sales. It defines which days to offer, including specials such as “Fri tourney only”, pre-event days (e.g. “Pre-Th”) or anything sold & priced on a daily basis. You should put “double quotes” around any Days entry which contains spaces.
For each of the remaining rows, the left-hand value should preferably match one used in the Age Category (or equivalent) column in the booking spreadsheet, but mainly be descriptive enough for the gate person to select the correct pricing and Adult/Minor split. The values on the right start with the label for the booking type – enough to define Adult/Minor per the Minor rule for ActionFields below. Subsequent values are the full event price, followed by the price for each of the single days in the Days list. Make sure you enter enough values – Gatekeeper does not sanity check this.
Example:
[CasualPrices]
Days=F,Sa,Su
; first price in each row below is for Full event, then a price for each day above
18 and over=Adult,55,15,25,20
16 or 17=Child,55,15,25,20
5 to 15=Child,35,10,15,10
Under 5=Child,0,0,0,0

Enter a full event price of ‘n/a’ for rows which for which you don’t want to support this option. You can do that for day prices also; they’ll just be evaluated as zero if selected.
Sometimes events require more elaboration. For example, you may need to cater for family entry or catering options. Before you go down the path of trying to create rules for lots of special types of casual entrants, work out how many people will be in each of the less-usual types. If it’s fewer than half a dozen, you’re almost certainly better to only offer the most common pricing options in this table. Then train gate staff to complete the Casual/Walkup form with one of trhe standard options, but before OKing the form to modify the three editable fields it generates to match their true status. Alternatively, leave those fields as-is during data entry but subsequently manually edit their Gatekeeper record to contain the correct price and a meaningful description.
With that cautionary advice clearly understood, the way to get pricing variants is to add extra rows to cater for more Age/Type combinations, e.g.
18 and over including feast=45,75,Adult

Note that, in such cases, you probably also have to change the Minor definition in ActionFields, because, for example, you can no longer use the “!18 and over” match to determine which people are minors. Instead, use “!$18 and over” to do a partial match.
Once you've got your full set of casual pricing rules in, run a lot of tests of casual walkups to ensure they are working ok and recording good info. Then resign yourself to the fact there may only be a few casuals after all that thought and work.

Action fields
As noted above, the special actions defined in this section usually require a click confirmation by the gate staff before a sign-in can be completed. And, unlike the previous sections, there is also some optional logic defining whether or not the field should be displayed and, if so, how it should be displayed.
For example, it should not be necessary to click on the Minor sign-in field if the attendee is an adult, and it should not be necessary to click on a souvenir field if they didn't order one of them. And if a souvenir action is required, it might help to have explanatory text around the field contents rather than (say) just a T-Shirt size.
None of the actions are compulsory - if you are sure you don't need a particular action, just leave that line out of the section in the INI file. On the other hand, you can't create a dozen new action fields at will, the way you can for reminder fields - there are the three fixed actions (Owed, Minor and Car Reg) and up to six others that you can define as required.
The left-hand value in each row is the internal action name - it must be one of Owed, Minor, Car Reg and Action1 to Action 6. The right-hand values are the field name from the CSV file and - apart from Car Reg - an optional rule which determines whether or not to display it, and an optional display format.
Example of an action:
Action2=TShirt,!None,T-Shirt size: %s
In the above example, TShirt is the column name from the CSV file, !None is the rule, and T-Shirt size: %s is the display format. If the rule is empty or omitted the action will always be displayed. And if the display format is empty or omitted the field value from the CSV file will be displayed as-is, with no additional text or formatting. The optional %s in the display format simply means "put the field value from the CSV file here".
Rule syntax is very simple. Normally, you might specify a value which indicates when the action should be displayed, for example MealPlan,Adult,Sign up for meal plan chore(s) means that a chores-related action will only appear if the Meal Plan order was for an adult. Alternatively, you can specify a value which means the action will always be displayed unless that value is present. For example, Age,!18 and over,Minor: %s - do paper Minor sign-in means that the Minor action will appear any time the CSV's Age field contains something other than the "18 and over" value (which denotes an adult) - even including if the field is empty.
A special case is illustrated by Owed=Balance Owed,! which means the Owed action will appear any time the Balance Owed column in the CSV file is not empty – you can read the ! character as "not" to make more sense of this.
The rules can be tweaked as required to suit the actual data that was stored by your booking process. But the rule system has its limits - for example, there is no provision for either "a" or "b" tests for a particular rule, nor can you match for the presence or absence of commas. Therefore some minor data massaging may be required to make sure that GateKeeper's simple match/doesn't match and is present/is empty rule logic can be used.
Example:
[ActionFields]
Minor=Age,!18 and over,Minor: %s - do paper Minor sign-in
Action1=Meal Plan,Adult,Sign up for meal plan chore(s)
Action2=TShirt,!None,T-Shirt: %s
Action3=Market Wallet,Yes,Market Wallet: %s
Action4=ID Code,!,Hand over an event token
; Car Reg is a special case – it just copies info from the Rego field in bookings
Car Reg=Rego

Or, for Festival you could use the line below, where the $ symbol means “contains”:
Minor=Ticket Type,$Child,Minor: %s - do paper Minor sign-in

You can combine the ! and $ operators, in which case ! must always go first, e.g. “!$Adult” means “does not contain Adult”. A ! with no data after it means “not nothing” (i.e. there is some data present). A $ with no data means “contains nothing” – which would lead to no data being shown, therefore the line would never appear. And !$ with no data after it means “contains something”, i.e. it means exactly the same as a ! all by itself.

Reminder Fields
You can have as many reminder fields as you want, subject to the vertical screenspace on the computer(s) used at gate. But remember that, if you are wanting the gate staff to actually attend to them and perhaps do something a little differently if they are present, fewer is better.
For reminder fields, the left-hand value defines the boldface label that will be given to the reminder row on the left-hand summary panel. The right-hand value is the same as for action fields - a CSV column name, an optional rule that defines whether the value of that column should be shown and an optional display format to use if it is shown (most reminders won't need one, because of the helpful label).
If the rule fails, the entire reminder row is omitted.
Example:
[ReminderFields]
Special crew token=Crew,Yes
Daytripping for=Days,!, %s Days
Bunkroom=Bunkroom,Yes
Meal Plan=Meal Plan,!None
Feast=Feast,!None
Tents=No Tents Required,!
Mattress Pair=Mattress,Yes
Shuttle Bus to airport=Shuttle Bus To,!None
Comments=Comments,!
Booking Notes=Notes,!

Row Selections
Some source spreadsheets such as those from TryBooking may have lots of extraneous rows for elements of bookings not handled by GateKeeper. Or they may contain a calculations and notes section at the end which of course needs to be ignored by GateKeeper when it is importing booking records. Or perhaps simply a bunch of blank lines that you don’t want to have to remove by hand.

To deal with this, use the optional Row Selections section – if it is omitted or has no rules, GateKeeper will assume that all non-empty rows are valid data.

Examples:
[RowSelections]  	- for CF
Include1=Date,!     - ok for CF master booking spreadsheet as Date column is empty in the stats section

[RowSelections]   		- for Festival
Include1=Section,All Tickets 	- ignores merchant stall, equipment and bunkroom bookings

Notes:
1.	The Row selection doesn’t affect the original CSV file stored on disk - just the internal copy used by GateKeeper to present the Booking table
2.	If you have multiple Include settings (Include1, Include2 etc), each of them is applied in turn to each row to see if it should be included – the same as a logical OR
3.	Regardless of any RowSelections settings you might have, a row which has an empty Mundane Name will always be omitted
4.	RowSelections are processed after the [Transforms] section described below, if any. And both sections are ignored once the booking data’s CSV has been replaced by an encrypted (and already-processed) copy by using the Go Live button.

Transforms
Most events won’t need this section. But if you need to use it, it’s likely to be helping you avoid the need for extensive manual format-changing or row-merging operations to get your bookings data into a format that GateKeeper can read.

In the [Transforms] section of the INI file, three different transformation types are supported – CombineColumns, MatchReplace, CombineRows. See the Festival examples later in this section for an idea of how each one is used.

CombineColumns creates new columns which are either a simple copy of a single existing column or a concatenation (with an inserted space) of two columns. The new columns are named and can then be used in subsequent operations or by the column-assignment rules in [BookingGridFields] etc. General format:
CombineColumns1=NewColName,FromColName1{,FromColName2}  - FromColName2 is optional
MatchReplace has several nuances and allows for arbitrary (even empty) strings to be found and replaced throughout each row, or throughout a specified column, or allows a specified column’s contents to be replaced in toto if the match string is found within it. General format:

MatchReplace1=MatchData,ReplaceData,{{$}MatchCol}   – the match is not case sensitive!
MatchData can start with a $ to imply a partial match as opposed to a total match – it’s only meaningful to omit it if you’ve also specified a MatchCol. If you don’t specify a MatchCol, the partial match and replace will take place throughout each row of the CSV file. If you do specify a MatchCol, the match and replace only occurs within that column. Finally, if you have a $ prefix before the MatchCol name, then the entire contents of MatchCol will be replaced in toto by ReplaceData, as opposed to a partial match-and-replace being done with only MatchData being replaced by ReplaceData wherever it appears in MatchCol.

CombineRows is a real workhorse – be aware that it deletes rows from GateKeeper’s internal copy of the booking data. The idea is that where the original booking data has multiple rows per person, CombineRows will let you copy specific booking information from later booking rows for the same person back to their first row. GateKeeper will then only see that row.  To take a concrete example, if your booking system records one row for each day a person books, you could combine all the days together in the Days column in the first row, removing all the other rows.  General format:

CombineRows1=IndexCol,MatchCol,MatchData,AppendFromCol,AppendToCol
IndexCol is a column whose contents allow you to uniquely identify all rows that belong to the same person. It might be a booking ID, or their name (but be aware that different people can have the same name! If booking IDs are repeated, e.g. for group bookings, it’s probably best to first use CombineCol create a new column which combines the booking ID and the person’s name, and use that new column as the IndexCol.
MatchCol defines a column you’re looking in to decide whether to append some information from this booking row to the person’s first row. MatchData defines what you’re looking for in Matchcol – it can have a $ prefix indication that it a partial match is ok, e.g. $Day. Be very aware that the sort order of data within MatchCol will strongly affect how various CombineRow rules play out. Such sorting must be done before the CSV is seen by Gatekeeper - CombineRows won’t even bother looking for a match if we’re only on the first row!
Once a match succeeds, AppendFromCol defines the origin of the data you’re adding, and AppendToCol defines where it’s being added.
Below are some examples worked up for Festival 2017 (they may not be current now):
[Transforms]
; the first CombineColumns makes a new Unique ID column from the Booking ID and Legal name columns
CombineColumns1=Unique ID,Booking ID,Ticket Data: Legal Name
CombineColumns2=Age,Ticket Type    	- makes a copy of the Ticket Type column called Age
MatchReplace1=$C,Child,$Age 	– totally replaces any  Age values containing C with (only) “Child”
MatchReplace2=$FM1,Child? (fmly ticket),$Age
MatchReplace3=$A,Adult,$Age 	– totally replaces any  Age values containing A with (only) “Adult”
; CombineRows1 looks for multiple rows with the same Unique ID and where the later row(s) contain Day in 
; the Ticket Type column.  If any are found, the Day attending data of the later row(s) are added
; to the column of the same name in the first row – the later rows are removed. Yes, it’s that complex.
CombineRows1=Unique ID,Ticket Type,$Day,Ticket Data: Day attending during Festival,Ticket Data: Day attending during Festival
CombineRows2=Unique ID,Ticket Type,$PE1,Ticket Data: Night attending pre-event,Ticket Type
CombineRows2=Unique ID,Ticket Type,$NM,Ticket Type,Ticket Type

Notes:
1.	Transforms don’t affect the original CSV file stored on disk - just the internal copy used by GateKeeper to present the Booking table
2.	Regardless of the rule numbering, all Transform rules are processed in the order they are presented in the [Transforms] section. Some, like MatchReplace and CombineRows, may be very dependent on the order in which they are processed.
3.	If you get unexpected results, look very carefully at your rules and how they work in sequence and combination. For example, my first version of MatchReplace2 changed the Age column value to “Child? (family ticket)” – which was all very well except that the “a” in “family” became an unwanted trigger which caused MatchReplace3 to change the column value to “Adult!”
4.	The Transforms section is processed before the [RowSelections] section described above. And both sections are ignored once the booking data’s CSV has been replaced by an encrypted (and already-processed) copy by using the Go Live button.

Other INI file sections
Certain other sections in the INI file are maintained automatically by Gatekeeper, either to store internal settings such as window or columns widths, or to store settings that you make within the user interface itself. Examples of such sections are TfmGateKeeperMain, BookingColumns, RegistryColumns and MiscSettings – don’t touch them. The corollary is that these sections will be altered when you run Gatekeeper – therefore you should be sure to exit your text editor before running the app, and restart your edit session for Gatekeeper.ini only after exiting Gatekeeper itself. NB: The edRawBookingsInfo setting stores the filename and path of the bookings CSV file. It is highly desirable that this not include any path if you are going to copy your Gatekeeper installation to a different computer with possibly a different path. Edit manually if necessary during such transfers.
Testing Your Configuration
Once you’re got your INI file to the point that Gatekeeper loads without telling you that certain spreadsheet columns are missing, you’re ready to do some more in-depth testing. The main areas to watch for are:
•	Does the membership number get recognised ok so that the member’s record is properly linked from Registry, and is their current vs event membership vs non-member status correctly understood?
•	Are the various tests for “Owed”, “Minor”all behaving as they should, i.e. do the action fields or reminders show up?
•	Select the first person booked and use the down-arrow to manually scroll to the very end of the bookings – if you get there with no “out of bounds” errors, then all the required columns are probably present (but see below)
•	Use the casual booking button for an existing person in the membership database (not one who booked) – are the calculations correct? No error messages when you click the OK button? For minors, are they recognised correctly on the main form?  Make sure the gate staff know how to use this button and form for casual bookings, especially if there are nuances for different days, non-standard booking types, etc. 
•	Save a few records then use the Gate Records button to check that the saved information is correct.

Hardware Requirements
GateKeeper is designed to run on any Windows laptop or PC made since, say, 2008 – or even a virtual Windows emulator. At an event, you are likely to prefer a laptop that can provide at least a few hours of working battery life unless you have a guaranteed power supply. An external mouse is strongly recommended, rather than relying on a laptop’s touchpad.
Gatekeeper does not require an internet connection while at the event.
Screen readability is the most important consideration – GateKeeper’s form size and layout is very configurable and, unless the event has lots of action fields which therefore require extra screen height, it will work ok at a screen resolution as small as 900 x 550 - but that’s not likely to be very readable on an old 10” netbook screen with tiny pixels! After screen size, screen contrast and brightness is the next most important issue, especially if your gate location is outside on a bright day, and/or under a coloured tent.
Disk space requirements are minimal – you’ll get away with just 5MB (not 5GB!) free for the application and data, but do ensure there’s some extra free space before you install it, as Windows itself can casually eat tens of megabytes on is system drive when you’re not looking.
As already mentioned, an internet connection is not required during operation; it is desirable during setup (though even that can be worked around if necessary, by using a different  PC to get the Registry data that you’ll need, then copying it across via USB stick or whatever).
It is possible to run GateKeeper on multiple PCs at once to avoid bottlenecks at gate. This will have four consequences you need to be aware of, all very minor:
1.	GateKeeper generates a Gate report in a file called GateKeeper.dat which is accumulated on each PC independently, and from which you can export a CSV spreadsheet. After the event, the event steward will need to use Notepad or Excel to manually merge the CSV files exported from each of the GateKeeper machines.
2.	Because of (1) above, if a person is checked in on machine A, then later comes back to add or change information  (e.g. providing car registration data), this will of course need to happen on the same machine.
3.	GateKeeper uses the information in GateKeeper.dat to indicate whether someone has previously checked in. But if they checked in on another machine, that indication won’t appear.
4.	On the Setup tab is a dropdown selection called Unique Sign-in ID prefix – on the second and subsequent PCs, change this to B, C or D, just to ensure the Sign-in IDs generated by each PC will be distinct. Not a big deal if you forget to do this.

To Do (possible features in future versions)

These relate to minor/rare cases not covered in the current version – and may not be in future either but feedback is welcome.
•	Likely: a little extra info in the Reconciliation section of this manual about doing the revised Kingdom levy calculations from 2020 onwards. You can use the Date field in Gate Records to see when someone actually signed in and do the “how many days” calculation based on that.
•	I’d like to add digital sign-in for event memberships and minor forms to speed up the process for such cases. This would depend on the SCA Ltd Board and SCA NZ Committee approving business rules for the validity, collection and storage of such information – most likely by a post-event automated uploading process to a central repository. That might take a while to approve…
•	Integration with Square or a similar online payment system intended for common use – this may be possible to lessen the separate data-entry that is otherwise required