A note on abstraction
As part of making the calendar portable, most scripts are "abstracted" so that they use the fields mapped on your "Source No X" layouts. This makes it easy for you to point the calendar at your own data tables without having to edit every field reference in every script.
However, once you have integrated the calendar into your own file, you don't really need to keep up the abstraction. For example, if you have a field called "Priority" in your events table and want to make sure that when you create a new event this field is always set to "1", you can just use a regular SetField script step... you don't need to use SetFieldByName as you no longer need the calendar to be portable.
(OK, you'd probably do this priority thing with an auto-enter calc, but you get the idea.)
If you're only using one source for your events, that's all there is to it. If you're using multiple sources, you may need to test which source is active so you know which field to set, etc. The active source is recorded as $$sc_SourceNoLoaded.
That said, if you want to follow along and use variables, the following notes will help you keep track of what the variable names are.
What variables are available when editing events?
When working with a particular source in the calendar we load the facts of that source to global variables (those variables beginning $$). If you need to know the name of a particular variable, you have two options:
In addition, the script "Load Source Settings at Startup..." loads a few variables about the table occurrence name of the selected source like $$sc_SourceTableOccurenceName. These are broken out by repetition so the table occurrence name for source no. 2 is $$sc_SourceTableOccurenceName.