Environmental Elements

This is where scenario-specific environmental aberrations are loaded into the scenario. This includes about anything that's outside of a force player (Red or Blue) control. This leads to certain things that would normally be considered non-environmental (e.g. A prescripted nuclear explosion) as being included in this list whenever the event should occur regardless of player actions.

Options:

Prescripted Weather

This selection presents the Pre-Scripted Weather Event Form that lists the Scenario Weather to Edit. Elements that can be edited are:

A New Weather Area may be created by selecting the button. The Weather Area, Time, Location Form appears on which the user may fill-in the:

The user may select Pick Area from Map and pick the area from the screen instead of loading the initial weather area by hand.

Nuclear/Bio/Chem (NBC) Detonations

This interface is to create explosions that you ALWAYS want to happen. They should not be associated with the actions of any scenario element since the attack should fail if the asset is destroyed before the attack. The initial purpose to this interface was to include terrorist attacks. If the bomb is to be delivered by a scenario element (e.g. A bomber or missile), then create that asset and define the attack as a mission (or operational task).

This selection presents the Scenario Warhead(s)List Form with the Select Scenario/Warhead Record to Edit.  These are the NBC events that are to occur regardless of the activities or presence of any scenario element. If an NBC attack is to be made by an entity modeled in the scenario (e.g. A ballistic missile) DO NOT load the event here. If loaded here the detonation will occur regardless of whether the carrier (in this case the ballistic missile) survives.

  Select Scenario/Warhead Record to Edit lists the:

The user can also select the Add New Warhead/Detonation Time bar to add a new explosion to the scenario.  This brings up the Creating New Warhead/Detonation Time Form . This form lists:

Intelligence Reports

This interface allows the user to create prescripted intelligence reports (free format) to be delivered throughout the scenario. This selection presents the Environment Intelligence Reports Form that lists the Intelligence Record to Edit.  Each report has six elements:

Selecting one report causes the Intelligence Report Time, Location Form to appear with the Scenario Name listed and several elements to edit:

Not all fields apply to all messages. That's OK.

The text of the intelligence report is also displayed on the form under Full Text of Intelligence Report.

A new Intelligence Report may be added by clicking on the Add Intelligence Report bar which causes the Intelligence Report Time, Location Form to appear and the data may be filled-in.

Region Flush - ICBM Alert

The Region Flush option allows the user to prescript a massive airbase flush at a specified time. The reason this option is included under the Environmental Elements is that initially this was presumed to be driven by a massive ballistic missile attack external to the original ADISC2 application. Since ballistic missiles are now fully incorporated into FORCES, the option is not generally used anymore. But it's still kept in case any users want to experiment with air operations under an unmodeled missile attack.

This selection presents the Region Flush Form that lists the Scenario Record to Edit along with the Scenario Name and the Creator.  Selecting a scenario causes the Region Flush - ICBM Alert Form to appear. The name of the scenario selected is listed along with a line on which the Flush Time (minutes) may be typed. A negative value can be entered to cancel an alert.

Communications Environment

This interface is used for notional ground combat communications studies. This selection causes the Communications Environment to appear. The name of the scenario selected is listed along with two lines on which the user can enter:

Ground Movement Performance

This option permits the user to specify the performance of ground units over various terrain. This information is used along with the platform descriptions (which have off-road movement information and traction type) to determine achievable movement rates over various terrain and weather conditions.  Selection brings up a window with five elements effecting Movement Rate.

The Movement Rate vs Weather table defines the reduction in vehicular movement with poor weather. This selection causes the Table Description Form to appear with information on the overview of a table function to reduce the achievable speed according to the desired speed and the current weather (which follows the standard 0-10 JFORCES weather scale).  An Edit button brings up the Independent Variables Form on which the user can Editing Values for: WX Effects on Veh. Speed, Independent Variable: Desired Speed (knots).  This is a standard JFORCES table editing interface, and editing controls are described here.

The Movement Rate vs Terrain table reduces the ground speed of offroad vehicles in accordance with the type of terrain it's traversing.  The type of terrain is defined in the Mission Planner under "Scenario Defn->Critical Regions->Terrain Clutter Data". That interface defines the area of a given type of terrain and the associated terrain index.  This table provides a speed reduction for an off-road vehicle in a given terrain type (identified by the Terrain Type Index).  Selection causes the Table Description Form to appear.  An Edit button brings up the Independent Variables Form on which the user can Editing Values for: Terrain Effects on Veh. Speed, Independent Variable: Desired Speed (knots).  This is a standard JFORCES table editing interface, and editing controls are described here.

TheMovement Rate vs Road Demand is a table of speed reduction of on-road vehicles in congested areas (as measured by the # of onroad vehicles on the road. The Table Description Form provides an Edit button brings up the Independent Variables Form on which the user can Editing Values for: Road Contention Delay, Independent Variable: Desired Speed (knots).  This is a standard JFORCES table editing interface, and editing controls are described here.

The Movement Rate vs Road Damage is a table of on-road vehicle speed reduction as a function of road damage.  This is ONLY used if the TIGER road database is not used (interpret this to mean this table is almost never used) since when damage is recorded in the runtime TIGER database the speed reduction is defined at a more granular level (and consistently with the automated route planner).
If you care to use this data the Table Description Form will appear an Edit button brings up the Independent Variables Form on which the user can Editing Values for: Road Damage Delays, Independent Variable: Desired Speed (knots).  This is a standard JFORCES table editing interface, and editing controls are described here.

The Movement Rate vs Road Gradient is a table of on-road vehicle speed reduction as a function of local gradient. This is ONLY used if the TIGER road database is not used (interpret this to mean this table is almost never used) since the speed values in this data are assumed to already incorporate these factors.  If you care to use this data the Table Description Form will appear with an Edit button brings up the Independent Variables Form on which the user can Editing Values for: Road Damage Delays, Independent Variable: Desired Speed (knots).  This is a standard JFORCES table editing interface, and editing controls are described here.

Building Groups

This interface permits users to define buildings.  The buildings are divided into groups to avoid location problems associated with curved-Earth rendering.  These groups are also referred to as "Squares" since logically they are rectangular areas.  The size of these squares is user-defined, and so can be set in whatever manner the user finds convenient.  So one user could define a building square as a city block in one place and as an entire town in another place.  From a practical standpoint it's not recommended to make any of these squares larger than 10 NM in either direction since after that Earth curvature starts being a problem.  Many squares can coexist in a single scenario, and in fact can overlap (though care should be taken to avoid overlapping the buildings defined within the squares).  

When this interface starts up the list of building squares currently recognized in this scenario or across all scenarios is presented (Example).  If this list comes up empty you'll have to create a new square before proceeding.  A square is defined according to the southwest location, and a name (also called a community, e.g. Littleton, CO).  Only the southwest point is required because the square will automatically expand to accommodate the buildings.

Clicking on the "Edit Building" option for a square will permit you to define new buildings, or delete existing ones. Click here to see a typical building list. Buildings are specified by:

Scrolling to the bottom of this interface permits the user to return to the building square interface (the original interface for this function) or to define a new building.  If the user chooses to define a new building this interface will be presented.  Basically, this interface is pretty simple, just fill in the blanks for the attributes listed above.  The only part of this interface that requires some description is the option to "Compute Building Footprint from Map Picks".  Before describing it, I should mention that the intent of this interface is to aid users who have loaded an aerial photo into the map and wish to identify buildings from this photo by "point-and-click" approach.  This button makes that possible assuming the the following procedure is used.

First, the user must understand the orientation of the points that will be used.  This diagram indicates the internal representation of buildings and the order the points must be picked:

Building orientation diagram