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.
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:
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.
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.
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
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
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.
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: