Basic Operation

To run it, execute the program and make sure you've loaded the param file (such as JohnDoe.dpm).  On the Basics tab click "Generate Scenarios" and then click Reports (same as menu Special/Reports) to view the result.  The parameter file is plaintext and can be read with any word processor but I highly advise against updating it that way.

To make the operation clearer in your first trials, on the Reports/Templates tab, select the Normal template, Edit it, and select "IdentAndAct" for "ActTitling".  This will give an unambiguous label for thumbnail narratives in report samples.  Clear labels are probably counterproductive for actual runs.  One example is that participants can see the arena names for drill traffic, and this gives them hints when assigning precedence.

User Interface

The main screen consists of a tabbed notebook, the first tab controlling SET generation and the rest defining data.  Each data screen (except for the Acts and Cascade screens) has the same general layout.  The top of the screen has a list of defined items, and the bottom is used for editing one of those items at a time.  The top-half definition list has an Add button at the right lower edge.

If sequence is under user control, MoveUp and MoveDown buttons are supplied, and the user can click those or an Edit button after selecting one definition line.  If sequence is not under user control, those three additional buttons are not provided, and simply clicking any line opens the Edit panel.  Sequence is under user control for Arenas, because this governs most critical process flow.  Sequence of text blocks is under control mostly for readability in the GUI - it lets you sort the names of text blocks into the sequence they occupy in your reports.  Teams can be sequenced by the user, because when teams reserve arenas as "Playrooms" it happens first-come, first-served and the user controls who's first.  List names, entities on a team, values, scripts and other data is always sorted alphabetically.  (But lists contain data which has user-assigned sequence rules.)

The Edit panel contains the Delete function, and there is no "Are you really positive?" verification dialog for deletes.  The Editing window also has Cancel, Apply and possibly SaveAs buttons on the right, and most Edit windows have a radiobutton component on the top left, for selecting subwindows.

Data Types

"Arenas" define reality spaces.  Think of it like a circus, where multiple arenas are laid out before the audience, but no one can see the whole thing.  Arenas have up to 26 "Acts" which are triggered by outside events, a preplanned script, or by other acts within the arena.  Acts can then trigger other acts in the same or other arenas.  Acts are visible to those entities that have the correct attributes (see below).  Each Act has a text block describing what's going on.  "Text" blocks can also be defined by the SET designer, to insert free form instructions into participant reports at any location.  These can be broadcast, or targeted at specific groups or individuals.  "Lists" are data arrays which can be used to fill in data-references in Act or Text blocks, to flesh out a shell narrative.  Lists can contain names, locations, descriptions, actions, etc, which the drill program will select from pseudo-randomly.  "Values" are user-defined integer value-specifications (height of waves, windspeed, distance) which will have final values calculated during the drill generation.  These are then inserted into Acts or Text blocks. "Entities" are any objects which might be affected by the drill, and need some kind of report on that effect.  A participant is an entity, and his/her house might be one, too.  A vehicle, a building, a piece of radio equipment, a boat, all might be entities.  A "Team" is a group of entities combined to make it easier to define them.

Attributes

Many data types have "attributes".  These function as filters, controlling visibility and execution.  The sum of attributes for any one object is called the "Essence" of that object.  The rule is that one object can see a second object if the second has either no attributes at all, or if it has any one attribute that matches any one attribute in the first.  An object with no attributes can not see any object that has any attributes.  Attributes are edited in the menu Special/Attributes dialog.  An attribute is simply a tag or character string, user-assigned, and it means whatever the user wants it to.

Any data type which allows attributes will have an attribute list as part of its edit GUI.  When editing the attributes for an object, you can also define new ones on the fly.  The following data types have attributes: Text, Arenas, Acts, Teams, Entities.  Text blocks appear in the reports of Entities that can see them ("can see" as defined above).  Arenas are processed for entities that can see them.  Acts are processed the same, and appear in reports using the same logic.  Entities inherit attributes from their teams, and one of the main reasons for defining teams is to give all team members the same attributes by entering them at the team level.

Arenas

Arenas define reality spaces for the program.  Each arena has 26 Acts which are always defined and present, but may be empty.  Arenas are processed from top down, using the order which the user sets in the Acts panel.  Any arena might be disabled, in which case it is not processed at all.  

Arenas can be processed as part of a "common" experience or part of a "private" experience.  When an arena is in the common space, all entities can see it (if they have the proper essence as described above).  One or more teams can "reserve" an arena, claiming it as a "Playroom".  Any number of teams can do this, but whenever an arena is part of any Playroom it can no longer be in the common space.  When an arena is in a private space, only entities on the reserving teams can see it.

Each arena in private space is cloned from the common space, so reserving an arena sets up a parallel reality known only to the reservers (and those who can ViewPoint them).  If 50 participants are on teams that reserve the "Personal" arena, 50 copies are created each with its own process thread, its own data, and its own eventual enable or disable state for its 26 events.  Reserving an arena implicitly reserves every arena that its effects flow to, because the common space can't have a slew of private realities dumping their effects into it.  So reserving an arena potentially reserves a chain of arenas.  The program figures out what needs to be chained at generation time - the designer can see the result.

The Arena GUI indicates what teams have reserved it for their Playroom, and the Team panel indicates what Arenas they have reserved.  Click the Playrooms list under Teams to edit the arena list.  For a fuller explanation of reservations, see the Design discussion.

The "ScanMode" controls how an arena will be scanned for eligible Acts.  As acts are scanned from A to Z, each act might enable or disable other acts in the same arena.  This means that an arena which is scanned multiple times (for a single drill instance) can give different results in each pass.  The typical scan is Sequential, doing a single pass.  CountOnePass will allow up to the user-set maximum acts to be triggered in a single sequential scan.  CountRePass will re-scan the arena until the user-established number of acts have been triggered, or until no more state-changes occur during the pass.  ArmedOnly triggers only Armed acts in a single sequential pass.  DrillNumber uses the drill instance to map into acts, triggering one per drill.  If you call for drills numbered 5 thru 10, for instance, drill 5 is your first drill and will trigger act A, drill 6 is your second and will trigger act B, and so on.  The 27th drill (and subsequent) trigger no acts in such an arena.

  Acts

The Act panel format is unlike any of the other basic data screens.  A drop-down lets you choose the arena you want to view, and a scrollbar then scrolls through the A-Z acts.  The edit window is continually open at the bottom of the screen, and all updates take place immediately.  To edit the effects an event has on other acts, see the Cascade tab.

When providing flyover information in the Cascade screen, the Explore screen or the Mover dialog, each Act uses the first line of user-entered text.  In some cases this is not a good recap of the Act itself, so the user can override that by entering any value in the Note field.  At the top right of the screen is a text line showing what a user will see in the mouse flyover presentation.

References

Text and Act objects contain paragraphs which can refer to data values or to lists.  If any such references are made, those references are listed in the Edit GUI.  See the Syntax discussion.  Values and Lists contain a mirror report, in that the "Refs" radiobutton will show a list of the Text and Act objects that reference these values or lists.  If you are considering changing the definition of a value or list, it's good to check this report to see what you will be affecting.

Viewpoints

Entities always see all text and acts where the entity essence makes the text/act visible (the text/act has no attributes, or any attribute it does have matches an attribute of the entity).  In addition, entities may have "Viewpoints", which can be defined at the Team or the Entity level.  That is, a team can define a viewpoint and each entity on that team will share the viewpoint, or individual entities can define their own viewpoints.

A Viewpoint lets an entity look into the experience of another entity.  This is not something a drill participant can elect to do, but is part of the participant's total experience as designed by the drill designer.  For example, the ham operators would normally be aware (in real life) of whether or not a repeater is working.  In a SET, the repeater is operating within its own private experience of the emergency, with its own power problem, its own antenna failure, etc.  By giving each ham a Viewpoint into that repeater, each ham will know whether the repeater is available, just as he/she normally would in an emergency (by trying to kerchunk the thing).

To edit viewpoints, click the viewpoint list in the team or entity edit panel.  A viewpoint can be into the experience of another team at the team level, which means that the viewpoint owner temporarily inherits attributes of the other team and so can see whatever that team (as a whole) is allowed to see.  The viewpoint can be into another team at the entity level, which means that the viewpoint owner is allowed to peek at the reports of every member of that team and see what is actually reported to those entities.  Or the viewpoint can be into the experience of one or more individually identified entities, which is the same kind of peeking but using a smaller group of targets.  Any individual or team can have any number of viewpoints.

To let all amateur radio operators see the status of all repeaters, the Ham team would normally have a viewpoint into the Repeater team, using the Entity level.  If a husband and wife are both drill participants, both of them could be given a viewpoint into their own house's situation at the entity level.  The house is a dummy participant which can not take action, but by defining it ("HouseHagstrom", for example) you provide a locus for house-related events, and a target for the owners' viewpoints, simulating what might happen in an emergency.  To carry this a step further, you could not give the husband and wife the viewpoint, but instead print out a report for the house itself, and only if the husband or wife were at home (in their drill reality) could they pick up that report and find out what was happening to their house.