A note on abstraction
As part of making the calendar portable, most scripts are "abstracted" so that they use the fields mapped on your "Calendar Source Data" layout. 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.)
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 your source like $$sc_SourceTableOccurenceName.