CONTENT LINKS
==============
Introduction
viewtopic.php?f=100&t=544#p8984
Atmospheric Conditions
viewtopic.php?f=100&t=544#p8985
Ground Conditions
viewtopic.php?f=100&t=544#p8986
Unit Reinforcements: Prestige Expenditure Computations
viewtopic.php?f=100&t=544#p9676
Unit Entrenchment
viewtopic.php?f=100&t=544#p8987
Unit Initiative In Combat
viewtopic.php?f=100&t=544#p8988
Rugged Defense Likelihood Determination
viewtopic.php?f=100&t=544#p11425
Submarine Class Unit Detection Mechanism
viewtopic.php?f=100&t=544#p11017
===================================================================
The topic's contents may be modified or progressively added upon as time goes by.
===================================================================
INTRODUCTION
=============
This topic should be of interest to Veteran Modders (VMs). It is assumed that the reader is already intimately familiar with the information featured here:
[NP] Introductory Documentation
viewtopic.php?f=100&t=531
[VM] Play System: Complicated Mechanics
[VM] Play System: Complicated Mechanics
Last edited by HexCode on 2021-10-18 18:32, Monday, edited 5 times in total.
ATMOSPHERIC CONDITIONS
ATMOSPHERIC CONDITIONS
========================
Identical atmospheric conditions prevail during an entire scenario turn (i.e., both player half-turns). To this effect, the player directing the Side which moves first is always the beneficiary of exact knowledge as to what atmospheric conditions will prevail during his opponent's half-turn.
Atmospheric conditions are determined by:
a) the Weather Geographical Zone (WGZ); and
b) the Calendar Month
during which scenario events unfold.
Weather Geographical Zones
There is a pseudo-WGZ which is invoked "on-the-fly", as required. There are also THREE (3) full fledged WGZs "traditionally" characterized by progressively increasing, inclement weather conditions. The value assigned to variable "Weather Zone" in file *.PGSCN fully specifies a scenario's WGZ (i.e., 0, 1, 2 or 3).
Fair Weather & Storm Fronts
A typical scenario's duration is subject to strictly alternating periods of
A) Fair Weather; and
B) a Storm Front.
No "gaps" are allowed here. Please note that a scenario may commence with a Storm Front already being present. The Boolean value assigned to variable "Current Weather" in file *.PGSCN controls this feature (i.e., value 1 implies "Fair Weather" while value 0 implies "Storm Front Presence"). Whether a Fair Weather or a Storm Front period, its Average Duration is expressed in full turns.
Throughout its entire duration, a Fair Weather period dictates Clear Skies. The pseudo-WGZ is always blessed with Fair Weather conditions (and, hence, Clear Skies) and no Storm Fronts whatsoever. For full fledged WGZs, a Storm Front period dictates anything but Clear Skies throughout its entire duration !
Precipitation Types
With regard to a typical Storm Front's full turn, there are always TWO (2) individually distinctive and collectively exhaustive possibilities:
1) Overcast Skies; or
2) Precipitation.
The likelihood of Precipitation is the probability complement of the likelihood of Overcast Skies.
When it comes to the very first Precipitation event to manifest itself during a typical Storm Front period, there are always TWO (2) individually distinctive and collectively exhaustive possibilities:
i) Snow; or
ii) Rain.
The likelihood of Snow is the probability complement of the likelihood of Rain. However, that first Precipitation event definitively coins the particular Precipitation type which may be witnessed during the remainder of the current Storm Front period. In other words, one can never experience both Snow and Rain during one and the same Storm Front period. That notwithstanding, one may experience Snow and Rain over the entire course of a scenario !
Data Descriptors
PGF's engine "understands" the following data descriptors:
(I) "Clear Time" = Average Fair Weather Duration (expressed in full turns).
(II) "Storm Time" = Average Storm Front Duration (expressed in full turns).
(III) "Storm Type" = If a first Precipitation event, likelihood that Precipitation (if any) will be Snow and not Rain for the entire duration of the current Storm Front (expressed in percentage terms).
(IV) "Storm Chance" = Likelihood of Precipitation and not Overcast Skies this full turn (expressed in percentage terms).
The values of the preceding variables are embedded within PGF's executable in Tabular Format.
PGF's engine somewhat randomizes duration on the basis of the corresponding Average Duration data.
========================
Identical atmospheric conditions prevail during an entire scenario turn (i.e., both player half-turns). To this effect, the player directing the Side which moves first is always the beneficiary of exact knowledge as to what atmospheric conditions will prevail during his opponent's half-turn.
Atmospheric conditions are determined by:
a) the Weather Geographical Zone (WGZ); and
b) the Calendar Month
during which scenario events unfold.
Weather Geographical Zones
There is a pseudo-WGZ which is invoked "on-the-fly", as required. There are also THREE (3) full fledged WGZs "traditionally" characterized by progressively increasing, inclement weather conditions. The value assigned to variable "Weather Zone" in file *.PGSCN fully specifies a scenario's WGZ (i.e., 0, 1, 2 or 3).
Fair Weather & Storm Fronts
A typical scenario's duration is subject to strictly alternating periods of
A) Fair Weather; and
B) a Storm Front.
No "gaps" are allowed here. Please note that a scenario may commence with a Storm Front already being present. The Boolean value assigned to variable "Current Weather" in file *.PGSCN controls this feature (i.e., value 1 implies "Fair Weather" while value 0 implies "Storm Front Presence"). Whether a Fair Weather or a Storm Front period, its Average Duration is expressed in full turns.
Throughout its entire duration, a Fair Weather period dictates Clear Skies. The pseudo-WGZ is always blessed with Fair Weather conditions (and, hence, Clear Skies) and no Storm Fronts whatsoever. For full fledged WGZs, a Storm Front period dictates anything but Clear Skies throughout its entire duration !
Precipitation Types
With regard to a typical Storm Front's full turn, there are always TWO (2) individually distinctive and collectively exhaustive possibilities:
1) Overcast Skies; or
2) Precipitation.
The likelihood of Precipitation is the probability complement of the likelihood of Overcast Skies.
When it comes to the very first Precipitation event to manifest itself during a typical Storm Front period, there are always TWO (2) individually distinctive and collectively exhaustive possibilities:
i) Snow; or
ii) Rain.
The likelihood of Snow is the probability complement of the likelihood of Rain. However, that first Precipitation event definitively coins the particular Precipitation type which may be witnessed during the remainder of the current Storm Front period. In other words, one can never experience both Snow and Rain during one and the same Storm Front period. That notwithstanding, one may experience Snow and Rain over the entire course of a scenario !
Data Descriptors
PGF's engine "understands" the following data descriptors:
(I) "Clear Time" = Average Fair Weather Duration (expressed in full turns).
(II) "Storm Time" = Average Storm Front Duration (expressed in full turns).
(III) "Storm Type" = If a first Precipitation event, likelihood that Precipitation (if any) will be Snow and not Rain for the entire duration of the current Storm Front (expressed in percentage terms).
(IV) "Storm Chance" = Likelihood of Precipitation and not Overcast Skies this full turn (expressed in percentage terms).
The values of the preceding variables are embedded within PGF's executable in Tabular Format.
PGF's engine somewhat randomizes duration on the basis of the corresponding Average Duration data.
Last edited by HexCode on 2021-05-18 06:11, Tuesday, edited 2 times in total.
GROUND CONDITIONS
GROUND CONDITIONS
===================
Absolute Prerequisite
Atmospheric Conditions
viewtopic.php?f=100&t=544#p8985
Ground Moisture
Ground moisture is represented by the Wetness Level (WL) the integer value of which may range anywhere from ZERO (0) to FIVE (5) inclusive. No values outside the aforesaid range are allowed.
WLs ZERO (0),ONE (1) orTWO (2) trigger dry ground conditions.
WLs THREE (3), FOUR (4) or FIVE (5) trigger wet ground conditions. If the current (or last) Storm Front is (was) a Rain one, the ground is muddy. If, on the other hand, the current (or last) Storm Front is (was) a Snow one, the ground is frozen.
Fair Weather
At the very start of a turn, a determination of Fair Weather (i.e., Clear Skies) for the turn immediately triggers a DEcrease in the WL by TWO (2) notches.
Rain Storm Front
At the very start of a turn, a determination of Overcast Skies (rain Storm Front is on) for the turn immediately triggers a DEcrease in the WL by ONE notch. On the other hand, a determination of Precipitation (i.e., rain) for the turn immediately triggers an INcrease in the WL by TWO (2) notches.
Snow Storm Front
At the very start of a turn, a determination of Overcast Skies (snow Storm Front is on) for the turn leaves the WL value unaffected. On the other hand, a determination of Precipitation (snow) for the turn immediately triggers an INcrease in the WL by TWO (2) notches.
Initialized WL Value & Implication
At the very start of a scenario, PGF's engine always initializes WL with value ZERO (0). This means that the ground can never be muddy / frozen on the first turn; even if it rains / snows. One full turn must pass before WL's value can ever get above 2.
===================
Absolute Prerequisite
Atmospheric Conditions
viewtopic.php?f=100&t=544#p8985
Ground Moisture
Ground moisture is represented by the Wetness Level (WL) the integer value of which may range anywhere from ZERO (0) to FIVE (5) inclusive. No values outside the aforesaid range are allowed.
WLs ZERO (0),ONE (1) orTWO (2) trigger dry ground conditions.
WLs THREE (3), FOUR (4) or FIVE (5) trigger wet ground conditions. If the current (or last) Storm Front is (was) a Rain one, the ground is muddy. If, on the other hand, the current (or last) Storm Front is (was) a Snow one, the ground is frozen.
Fair Weather
At the very start of a turn, a determination of Fair Weather (i.e., Clear Skies) for the turn immediately triggers a DEcrease in the WL by TWO (2) notches.
Rain Storm Front
At the very start of a turn, a determination of Overcast Skies (rain Storm Front is on) for the turn immediately triggers a DEcrease in the WL by ONE notch. On the other hand, a determination of Precipitation (i.e., rain) for the turn immediately triggers an INcrease in the WL by TWO (2) notches.
Snow Storm Front
At the very start of a turn, a determination of Overcast Skies (snow Storm Front is on) for the turn leaves the WL value unaffected. On the other hand, a determination of Precipitation (snow) for the turn immediately triggers an INcrease in the WL by TWO (2) notches.
Initialized WL Value & Implication
At the very start of a scenario, PGF's engine always initializes WL with value ZERO (0). This means that the ground can never be muddy / frozen on the first turn; even if it rains / snows. One full turn must pass before WL's value can ever get above 2.
Last edited by HexCode on 2021-05-18 06:13, Tuesday, edited 2 times in total.
UNIT ENTRENCHMENT
UNIT ENTRENCHMENT
===================
Basics
Units that do not move during their friendly half-turn are assumed to be "digging in", thus further enhancing their defensive stance. Entrenchment is expressed in Levels (ELs). Moreover, each unit class entrenches at a rate specific to that class (UCERs).
When a unit moves out of its hex, it automatically loses all its ELs. However, attacking without moving, mounting / dismounting without moving, resupplying / upgrading without moving and the like preserve the unit's hitherto accumulated ELs.
Each attack on an entrenched unit, whether successful or not in terms of inflicted damage / casualties, reduces its EL by one Level (negative ELs are not allowed).
Higher ELs translate into a defending unit being better able to withstand attacks upon it. Furthermore, they increase the likelihood that a non-ranged ground attacking unit will be subjected to Rugged Defense combat...
Weather conditions do not affect ELs.
Terrain Base & Maximum ELs
Each terrain type is assigned a Terrain Base EL (TBEL). Units starting their friendly half-turn on a hex of a particular terrain type automatically assume that TBEL in all instances where their hitherto attained EL is lower than the aforesaid TBEL. In such instances, the TBEL serves as an EL bonus.
Repeated attacks during a single half-turn upon a defending unit may even reduce the defending unit's EL below the underlying hex's TBEL.
Units can entrench up to a maximum of FIVE (5) ELs over the TBEL dictated by the underlying hex terrain type.
EXCEPTION: Tank class units are only allowed to attain a maximum of TWO (2) ELs irrespective of any other considerations.
TBEL values are hard-coded in PGF's executable. They are:
EL Tracking
A unit's EL is tracked on the basis of Earned Entrenchment Points (EEPs) during the entrenching unit's half-turn(s). Here's the formula:
(EEPs) = (UCER) * (1 + (TBEL))
UCER values are hard-coded in PGF's executable. They are:
A unit which has just been the beneficiary of an EL bonus does not get any additional EEPs for that particular friendly half-turn.
EEPs accumulate from friendly half-turn to friendly half-turn as long as a unit remains stationary on a particular hex and doesn't get attacked. When a unit's EEP total increases to some predetermined value or greater, the unit gains another EL and an equal number of EEPs are immediately subtracted from the unit's EEP running tally.
The "EEP to EL" conversion values correspond to additional ELs successively attained. They follow:
===================
Basics
Units that do not move during their friendly half-turn are assumed to be "digging in", thus further enhancing their defensive stance. Entrenchment is expressed in Levels (ELs). Moreover, each unit class entrenches at a rate specific to that class (UCERs).
When a unit moves out of its hex, it automatically loses all its ELs. However, attacking without moving, mounting / dismounting without moving, resupplying / upgrading without moving and the like preserve the unit's hitherto accumulated ELs.
Each attack on an entrenched unit, whether successful or not in terms of inflicted damage / casualties, reduces its EL by one Level (negative ELs are not allowed).
Higher ELs translate into a defending unit being better able to withstand attacks upon it. Furthermore, they increase the likelihood that a non-ranged ground attacking unit will be subjected to Rugged Defense combat...
Weather conditions do not affect ELs.
Terrain Base & Maximum ELs
Each terrain type is assigned a Terrain Base EL (TBEL). Units starting their friendly half-turn on a hex of a particular terrain type automatically assume that TBEL in all instances where their hitherto attained EL is lower than the aforesaid TBEL. In such instances, the TBEL serves as an EL bonus.
Repeated attacks during a single half-turn upon a defending unit may even reduce the defending unit's EL below the underlying hex's TBEL.
Units can entrench up to a maximum of FIVE (5) ELs over the TBEL dictated by the underlying hex terrain type.
EXCEPTION: Tank class units are only allowed to attain a maximum of TWO (2) ELs irrespective of any other considerations.
TBEL values are hard-coded in PGF's executable. They are:
Code: Select all
Terrain Name TBEL Value
Fortification 4
Non-Naval City 3
Embarkation City 3
Port City 3
Forest 2
Bocage 2
Mountain 2
Rough 1
Port Facility 1
All Other Terrain Types 0A unit's EL is tracked on the basis of Earned Entrenchment Points (EEPs) during the entrenching unit's half-turn(s). Here's the formula:
(EEPs) = (UCER) * (1 + (TBEL))
UCER values are hard-coded in PGF's executable. They are:
Code: Select all
Unit Class Name UCER Value
Infantry 3
Recon 2
Anti-Tank 2
Artillery 2
Air Defense 2
Tank 1
Anti-Aircraft 1
Structure 1
Land Transport 1
All Other Unit Classes 0EEPs accumulate from friendly half-turn to friendly half-turn as long as a unit remains stationary on a particular hex and doesn't get attacked. When a unit's EEP total increases to some predetermined value or greater, the unit gains another EL and an equal number of EEPs are immediately subtracted from the unit's EEP running tally.
The "EEP to EL" conversion values correspond to additional ELs successively attained. They follow:
Code: Select all
Additional EL Attained Conversion Value
First 4
Second 4 + 9 = 13
Third 13 + 9 = 22
Fourth 22 + 9 = 31
Fifth 31 + 9 = 40
Last edited by HexCode on 2021-05-18 06:15, Tuesday, edited 2 times in total.
UNIT INITIATIVE IN COMBAT
UNIT INITIATIVE IN COMBAT
========================
Basics
The first step in any non-ranged combat (including ranged combat between Capital Ship class units, by exception) is to determine which unit gets to "shoot" first ! The determination of a unit's effective (i.e., combat-specific) initiative rating takes into account the following factors:
a) The unit's listed initiative rating;
b) Special unit combinations and circumstances (e.g., Rugged Defense);
c) The hex terrain being contested, if any (i.e., the hex the defending unit is on);
At the end of this intermediate stage, the unit's base initiative rating emerges.
d) The unit's current Experience Level;
e) Air attack on an Air Defense class unit; and,
f) A pseudo-random factor.
At the end of this final stage, the unit's effective initiative rating emerges.
It is extremely important to internalize the following fact; the "attacker" is the unit which initiates combat during its own half-turn and not necessarily the unit that eventually gets to "shoot" first. Consequently, the "defender" is the unit that is the target of the initiated attack irrespective of which unit eventually gets to "shoot" first.
Listed Initiative Rating
There is no "mystery" here. A unit's Listed Initiative Rating is prominently displayed on its Unit (Statistical) Information Screen.
Special Unit Combinations and Combat Circumstances
1) If an Anti-Tank class unit "attacks" a "defending" Tank or Recon class unit, the units' Listed Initiative Ratings are modified as follows:
The Anti-Tank class unit now sports a modified Listed Initiative Rating of ZERO (0);
The Tank or Recon class unit now sports a modified Listed Initiative Rating of NINETY NINE (99).
2) If an Ordinary Rugged Defense occurs, the "attacker" ends up sporting a modified Listed Initiative Rating of ZERO (0).
3) If a Sudden Collision (i.e., Special Rugged Defense, Surprise Contact or Out of the Sun) event occurs, the moving unit ends up sporting a modified Listed Initiative Rating of ZERO (0).
4) Barring Surprise Contact events, when two Capital Ship class units are involved in combat:
The "attacker" ends up sporting a modified Listed Initiative Rating of NINETY NINE (99).
The "defender" ends up sporting a modified Listed Initiative Rating of ZERO (0).
5) Barring Surprise Contact events, when a Submarine class unit is involved in combat:
The "attacker" ends up sporting a modified Listed Initiative Rating of NINETY NINE (99).
The "defender" ends up sporting a modified Listed Initiative Rating of ZERO (0).
Terrain Impact
The hex terrain upon which the "defender" is situated may further lower a unit's (possibly already) Modified Listed Initiative Rating. This is usually referred to as the Terrain Initiative Cap (TIC) effect.
Note: A precise definition for "City" is: Port, Embarkation or Non-Naval City.
If a unit's (possibly already) Modified Listed Initiative Rating is greater than the relevant TIC value, the said unit's initiative rating is now set to equal the relevant TIC value itself.
At this intermediate stage, the unit's base initiative rating emerges.
Current Experience Level Impact
A unit's current Experience Level may further additively modify a unit's hitherto computed Base Initiative Rating. This is usually referred to as the Experience Initiative Bonus (EIB) effect.
Special Case: Air Attack on an Air Defense Class Unit
When an air unit directly "attacks" a "defending" Air defense class unit (not an Anti-Aircraft class unit) both "attacker" and "defender" automatically assume identical, notional, modified Base Initiative ratings to the exclusion of all other considerations.
Pseudo-Random Variation
Finally, the pseudo-random outcome of a 3-sided probabilistic die (d3) is added onto the unit's (possibly already) Modified Base Initiative Rating. Die outcomes 0, 1 and 2 are considered to be equiprobable.
At the end of this final stage, the unit's effective initiative rating emerges.
Grand Comparison
The "attacker's" and "defender's" effective initiative ratings are now compared. The unit with the highest rating gets to "shoot" first. If the units' ratings are identical, the units get to "shoot" at one another simultaneously.
========================
Basics
The first step in any non-ranged combat (including ranged combat between Capital Ship class units, by exception) is to determine which unit gets to "shoot" first ! The determination of a unit's effective (i.e., combat-specific) initiative rating takes into account the following factors:
a) The unit's listed initiative rating;
b) Special unit combinations and circumstances (e.g., Rugged Defense);
c) The hex terrain being contested, if any (i.e., the hex the defending unit is on);
At the end of this intermediate stage, the unit's base initiative rating emerges.
d) The unit's current Experience Level;
e) Air attack on an Air Defense class unit; and,
f) A pseudo-random factor.
At the end of this final stage, the unit's effective initiative rating emerges.
It is extremely important to internalize the following fact; the "attacker" is the unit which initiates combat during its own half-turn and not necessarily the unit that eventually gets to "shoot" first. Consequently, the "defender" is the unit that is the target of the initiated attack irrespective of which unit eventually gets to "shoot" first.
Listed Initiative Rating
There is no "mystery" here. A unit's Listed Initiative Rating is prominently displayed on its Unit (Statistical) Information Screen.
Special Unit Combinations and Combat Circumstances
1) If an Anti-Tank class unit "attacks" a "defending" Tank or Recon class unit, the units' Listed Initiative Ratings are modified as follows:
The Anti-Tank class unit now sports a modified Listed Initiative Rating of ZERO (0);
The Tank or Recon class unit now sports a modified Listed Initiative Rating of NINETY NINE (99).
2) If an Ordinary Rugged Defense occurs, the "attacker" ends up sporting a modified Listed Initiative Rating of ZERO (0).
3) If a Sudden Collision (i.e., Special Rugged Defense, Surprise Contact or Out of the Sun) event occurs, the moving unit ends up sporting a modified Listed Initiative Rating of ZERO (0).
4) Barring Surprise Contact events, when two Capital Ship class units are involved in combat:
The "attacker" ends up sporting a modified Listed Initiative Rating of NINETY NINE (99).
The "defender" ends up sporting a modified Listed Initiative Rating of ZERO (0).
5) Barring Surprise Contact events, when a Submarine class unit is involved in combat:
The "attacker" ends up sporting a modified Listed Initiative Rating of NINETY NINE (99).
The "defender" ends up sporting a modified Listed Initiative Rating of ZERO (0).
Terrain Impact
The hex terrain upon which the "defender" is situated may further lower a unit's (possibly already) Modified Listed Initiative Rating. This is usually referred to as the Terrain Initiative Cap (TIC) effect.
Code: Select all
Terrain Type Initiative Cap Value
City, Mountain 1
Swamp 2
Forest, Bocage, Fortification 3
Rough, Port Facility 5
All Other Terrain Types 99If a unit's (possibly already) Modified Listed Initiative Rating is greater than the relevant TIC value, the said unit's initiative rating is now set to equal the relevant TIC value itself.
At this intermediate stage, the unit's base initiative rating emerges.
Current Experience Level Impact
A unit's current Experience Level may further additively modify a unit's hitherto computed Base Initiative Rating. This is usually referred to as the Experience Initiative Bonus (EIB) effect.
Code: Select all
Unit Experience Initiative Bonus
No Stars 0
1 to 2 Stars +1
3 to 4 Stars +2
All 5 Stars +3When an air unit directly "attacks" a "defending" Air defense class unit (not an Anti-Aircraft class unit) both "attacker" and "defender" automatically assume identical, notional, modified Base Initiative ratings to the exclusion of all other considerations.
Pseudo-Random Variation
Finally, the pseudo-random outcome of a 3-sided probabilistic die (d3) is added onto the unit's (possibly already) Modified Base Initiative Rating. Die outcomes 0, 1 and 2 are considered to be equiprobable.
At the end of this final stage, the unit's effective initiative rating emerges.
Grand Comparison
The "attacker's" and "defender's" effective initiative ratings are now compared. The unit with the highest rating gets to "shoot" first. If the units' ratings are identical, the units get to "shoot" at one another simultaneously.
Last edited by HexCode on 2021-05-18 06:17, Tuesday, edited 2 times in total.
UNIT REINFORCEMENTS: PRESTIGE EXPENDITURE COMPUTATIONS
UNIT REINFORCEMENTS: PRESTIGE EXPENDITURE COMPUTATIONS
=========================================================
Absolute Prerequisites
Unit Reinforcements: Typology
viewtopic.php?f=100&t=543#p9597
Unit Reinforcements: Prestige Costs
viewtopic.php?f=100&t=543#p9633
Computations
1) New Unit Purchases
Step 1.1: PGF's engine does not really need to compute anything here. It simply picks the intended unit type's value which is listed in data column entitled "Cost" (PGF programmer's choice; not mine) in file EQUIPMENT.PGEQP.
Step 1.2: PGF's engine compares the value obtained under Step 1.1 with the current value of the procurer side's Prestige Point Tally (PPT). Insufficiency of currently available Prestige Points (PPs) to "finance" the cost of the requested unit purchase blocks the purchase altogether. Otherwise, the request is implemented.
2) Unit Upgrades
Step 2.1: PGF's engine picks the intended unit type's value which is listed in data column entitled "Cost" in file EQUIPMENT.PGEQP.
Step 2.2: PGF's engine multiplies the value obtained under Step 2.1 by TEN (10).
Step 2.3: PGF's engine divides the value obtained under Step 2.2 by TWELVE (12).
Step 2.4: Because PGF engine's computations are confined to performing integer arithmetic, the value obtained under Step 2.3 is automatically ROUNDED DOWN, if necessary. EXCEPTION: If that value is GREATER THAN ZERO (0) BUT LESS THAN ONE (1), the engine automatically ROUNDS IT UP TO ONE (1).
Step 2.5: PGF's engine compares the value obtained under Step 2.4 with the current value of the procurer side's PPT. Insufficiency of currently available PPs to "finance" the cost of the requested unit upgrade blocks the upgrade altogether. Otherwise, the request is implemented.
3) Unit Over-Strengthening
Step 3.1: PGF's engine checks whether any SF procurement is possible to begin with. This requires the engine to check whether restrictions due to enemy unit adjacency and transportation mode would outright block the procurement request. If not:
Step 3.2: PGF's engine checks whether the unit is currently Under-Strength (i.e. it sports fewer than 10 SFs). If so, the computational process continues with Step 4B.1 in the sequel. Otherwise:
Step 3.3: PGF's engine checks whether the unit's SFs currently in excess of TEN (10) are GREATER THAN OR EQUAL to the unit's current Experience Level (EL). If so, the procurement request is blocked. Otherwise:
Step 3.4: PGF's engine picks the unit type's value which is listed in data column entitled "Cost" in file EQUIPMENT.PGEQP.
Step 3.5: PGF's engine divides the value obtained under Step 3.4 by TWELVE (12).
Step 3.6: Due to integer arithmetic, the value obtained under Step 3.5 is automatically ROUNDED DOWN, if necessary. EXCEPTION: If that value is GREATER THAN ZERO (0) BUT LESS THAN ONE (1), the engine automatically ROUNDS IT UP TO ONE (1).
Step 3.7: PGF's engine compares the value obtained under Step 3.6 with the current value of the procurer side's PPT. Insufficiency of currently available PPs to "finance" the cost of the requested unit over-strengthening blocks the procurement of that single SF altogether. Otherwise, the request is implemented.
4) Strength Factor Replacements
4A) Campaign Inter-Scenario Replacements
Step 4A.1: PGF's engine does not need to do much here; the situation not being an in-game one to begin with. If, in fact, the procurer has opted to receive "free" such replacements, the engine simply restores all of his Under-Strength Core units back to full TEN (10) SF strength status without in as much as touching the procurer side PPT's current value.
4B) Elite Replacements
Step 4B.1: PGF's engine checks the situationally maximum number of SFs which the currently Under-Strength unit might be able to procure, temporarily assuming that it has sufficient PPs to do so. For the purposes of this presentation, "M" will represent the aforementioned number.
Step 4B.2: PGF's engine picks the unit type's value which is listed in data column entitled "Cost" in file EQUIPMENT.PGEQP.
Step 4B.3: PGF's engine multiplies the value obtained under Step 4B.2 by "M".
Step 4B.4: PGF's engine divides the value obtained under Step 4B.3 by TWELVE (12).
Step 4B.5: Due to integer arithmetic, the value obtained under Step 4B.4 is automatically ROUNDED DOWN, if necessary. EXCEPTION: If that value is GREATER THAN ZERO (0) BUT LESS THAN ONE (1), the engine automatically ROUNDS IT UP TO ONE (1).
Step 4B.6: PGF's engine compares the value obtained under Step 4B.5 with the current value of the procurer side's PPT. Insufficiency of currently available PPs to "finance" the full cost of the requested unit's SF Replacements loops the computational process back to Step 4B.3 above where "M" MINUS ONE (M-1) is used instead of "M", and so on and so forth. Ultimately, current PP availability will determine how many Elite SF Replacements (if any) can be "financed". To this effect, PGF's engine will proceed with the requisite implementation.
4C) Regular Replacements
Step 4C.1: PGF's engine divides the value obtained under preceding Step 4B.5 above by FOUR (4).
Step 4C.2: Due to integer arithmetic, the value obtained under Step 4C.1 is automatically ROUNDED DOWN, if necessary. EXCEPTION: If that value is GREATER THAN ZERO (0) BUT LESS THAN ONE (1), the engine automatically ROUNDS IT UP TO ONE (1).
Step 4C.3: PGF's engine compares the value obtained under Step 4C.2 with the current value of the procurer side's PPT. Insufficiency of currently available PPs to "finance" the full cost of the requested unit's SF Replacements loops the computational process back to Step 4B.3 above where "M" MINUS ONE (M-1) is used instead of "M" and so on and so forth. Ultimately, current PP availability will determine how many Regular SF Replacements (if any) can be "financed". To this effect, PGF's engine will proceed with the requisite implementation.
=========================================================
Absolute Prerequisites
Unit Reinforcements: Typology
viewtopic.php?f=100&t=543#p9597
Unit Reinforcements: Prestige Costs
viewtopic.php?f=100&t=543#p9633
Computations
1) New Unit Purchases
Step 1.1: PGF's engine does not really need to compute anything here. It simply picks the intended unit type's value which is listed in data column entitled "Cost" (PGF programmer's choice; not mine) in file EQUIPMENT.PGEQP.
Step 1.2: PGF's engine compares the value obtained under Step 1.1 with the current value of the procurer side's Prestige Point Tally (PPT). Insufficiency of currently available Prestige Points (PPs) to "finance" the cost of the requested unit purchase blocks the purchase altogether. Otherwise, the request is implemented.
2) Unit Upgrades
Step 2.1: PGF's engine picks the intended unit type's value which is listed in data column entitled "Cost" in file EQUIPMENT.PGEQP.
Step 2.2: PGF's engine multiplies the value obtained under Step 2.1 by TEN (10).
Step 2.3: PGF's engine divides the value obtained under Step 2.2 by TWELVE (12).
Step 2.4: Because PGF engine's computations are confined to performing integer arithmetic, the value obtained under Step 2.3 is automatically ROUNDED DOWN, if necessary. EXCEPTION: If that value is GREATER THAN ZERO (0) BUT LESS THAN ONE (1), the engine automatically ROUNDS IT UP TO ONE (1).
Step 2.5: PGF's engine compares the value obtained under Step 2.4 with the current value of the procurer side's PPT. Insufficiency of currently available PPs to "finance" the cost of the requested unit upgrade blocks the upgrade altogether. Otherwise, the request is implemented.
3) Unit Over-Strengthening
Step 3.1: PGF's engine checks whether any SF procurement is possible to begin with. This requires the engine to check whether restrictions due to enemy unit adjacency and transportation mode would outright block the procurement request. If not:
Step 3.2: PGF's engine checks whether the unit is currently Under-Strength (i.e. it sports fewer than 10 SFs). If so, the computational process continues with Step 4B.1 in the sequel. Otherwise:
Step 3.3: PGF's engine checks whether the unit's SFs currently in excess of TEN (10) are GREATER THAN OR EQUAL to the unit's current Experience Level (EL). If so, the procurement request is blocked. Otherwise:
Step 3.4: PGF's engine picks the unit type's value which is listed in data column entitled "Cost" in file EQUIPMENT.PGEQP.
Step 3.5: PGF's engine divides the value obtained under Step 3.4 by TWELVE (12).
Step 3.6: Due to integer arithmetic, the value obtained under Step 3.5 is automatically ROUNDED DOWN, if necessary. EXCEPTION: If that value is GREATER THAN ZERO (0) BUT LESS THAN ONE (1), the engine automatically ROUNDS IT UP TO ONE (1).
Step 3.7: PGF's engine compares the value obtained under Step 3.6 with the current value of the procurer side's PPT. Insufficiency of currently available PPs to "finance" the cost of the requested unit over-strengthening blocks the procurement of that single SF altogether. Otherwise, the request is implemented.
4) Strength Factor Replacements
4A) Campaign Inter-Scenario Replacements
Step 4A.1: PGF's engine does not need to do much here; the situation not being an in-game one to begin with. If, in fact, the procurer has opted to receive "free" such replacements, the engine simply restores all of his Under-Strength Core units back to full TEN (10) SF strength status without in as much as touching the procurer side PPT's current value.
4B) Elite Replacements
Step 4B.1: PGF's engine checks the situationally maximum number of SFs which the currently Under-Strength unit might be able to procure, temporarily assuming that it has sufficient PPs to do so. For the purposes of this presentation, "M" will represent the aforementioned number.
Step 4B.2: PGF's engine picks the unit type's value which is listed in data column entitled "Cost" in file EQUIPMENT.PGEQP.
Step 4B.3: PGF's engine multiplies the value obtained under Step 4B.2 by "M".
Step 4B.4: PGF's engine divides the value obtained under Step 4B.3 by TWELVE (12).
Step 4B.5: Due to integer arithmetic, the value obtained under Step 4B.4 is automatically ROUNDED DOWN, if necessary. EXCEPTION: If that value is GREATER THAN ZERO (0) BUT LESS THAN ONE (1), the engine automatically ROUNDS IT UP TO ONE (1).
Step 4B.6: PGF's engine compares the value obtained under Step 4B.5 with the current value of the procurer side's PPT. Insufficiency of currently available PPs to "finance" the full cost of the requested unit's SF Replacements loops the computational process back to Step 4B.3 above where "M" MINUS ONE (M-1) is used instead of "M", and so on and so forth. Ultimately, current PP availability will determine how many Elite SF Replacements (if any) can be "financed". To this effect, PGF's engine will proceed with the requisite implementation.
4C) Regular Replacements
Step 4C.1: PGF's engine divides the value obtained under preceding Step 4B.5 above by FOUR (4).
Step 4C.2: Due to integer arithmetic, the value obtained under Step 4C.1 is automatically ROUNDED DOWN, if necessary. EXCEPTION: If that value is GREATER THAN ZERO (0) BUT LESS THAN ONE (1), the engine automatically ROUNDS IT UP TO ONE (1).
Step 4C.3: PGF's engine compares the value obtained under Step 4C.2 with the current value of the procurer side's PPT. Insufficiency of currently available PPs to "finance" the full cost of the requested unit's SF Replacements loops the computational process back to Step 4B.3 above where "M" MINUS ONE (M-1) is used instead of "M" and so on and so forth. Ultimately, current PP availability will determine how many Regular SF Replacements (if any) can be "financed". To this effect, PGF's engine will proceed with the requisite implementation.
SUBMARINE CLASS UNIT DETECTION MECHANISM
SUBMARINE CLASS UNIT DETECTION MECHANISM
==========================================
Absolute Prerequisite
Submarine Class Unit Detection
viewtopic.php?f=100&t=543#p11016
Likely Mechanism
1) PGF's engine serially checks all instances of friendly Units / Cities / Airfields / Ports (UCAPs) which may detect a given Enemy Submarine Class unit.
2) Each UCAP is subjected to a P=0.50 probabilistic outcome determination.
3) If the determination's outcome is "Detection", the process immediately terminates with the Enemy Submarine Class unit having just been detected.
4) Otherwise, the next (if any) UCAP is subjected to a P=0.50 probabilistic outcome determination; and so on.
5) If all UCAPs have been subjected to a P=0.50 probabilistic outcome determination without having obtained a "Detection" outcome, the process ends with the Enemy Submarine Class unit remaining undetected.
==========================================
Absolute Prerequisite
Submarine Class Unit Detection
viewtopic.php?f=100&t=543#p11016
Likely Mechanism
1) PGF's engine serially checks all instances of friendly Units / Cities / Airfields / Ports (UCAPs) which may detect a given Enemy Submarine Class unit.
2) Each UCAP is subjected to a P=0.50 probabilistic outcome determination.
3) If the determination's outcome is "Detection", the process immediately terminates with the Enemy Submarine Class unit having just been detected.
4) Otherwise, the next (if any) UCAP is subjected to a P=0.50 probabilistic outcome determination; and so on.
5) If all UCAPs have been subjected to a P=0.50 probabilistic outcome determination without having obtained a "Detection" outcome, the process ends with the Enemy Submarine Class unit remaining undetected.
RUGGED DEFENSE LIKELIHOOD DETERMINATION
RUGGED DEFENSE LIKELIHOOD DETERMINATION
=========================================
Absolute Prerequisites
Unit Entrenchment
viewtopic.php?f=100&t=544#p8987
Unit Class Entrenchment Rate Table
viewtopic.php?f=100&t=551#p9046
Rugged Defense Event Prediction
Whenever an entrenched enemy target is subjected to a non-ranged attack initiated by a unit which is not the beneficiary of Rugged Defense (RD) avoidance privileges, the determination of the likelihood of RD actually happening is computed on the basis of an algebraic formula.
Prediction Formula Variables
Attacker's Experience Level (AExpL)
Attacker's Entrenchment Rate (AEntR)
Target's Entrenchment Level (TEntL)
Target's Experience Level (TExpL)
Target's Entrenchment Rate (TEntR)
Prediction Formula Ratios
Experience Ratio (ExpR) = (TExpL + 2) / (AExpL + 2)
Entrenchment Rate Ratio (EntRR) = (TEntR + 1) / (AEntR + 1)
Prediction Formula
Rugged Defense Percentage Chance = (N/D) * TEntL * ExpR * EntRR
where "N/D" is a calibration fraction. Derived values HIGHER THAN ONE HUNDRED (100) are automatically interpreted as EQUAL TO ONE HUNDRED (100).
Code Computations
PGF's engine does NOT do... high school algebra; rather, it performs integer arithmetic. To this effect:
Numerator = N * TEntL * (TExpL + 2) * (TEntR + 1)
Denominator = D * (AExpL + 2) * (AEntR + 1)
The engine then divides the Numerator value by the Denominator value. The division quotient is ROUNDED DOWN to the nearest integer.
=========================================
Absolute Prerequisites
Unit Entrenchment
viewtopic.php?f=100&t=544#p8987
Unit Class Entrenchment Rate Table
viewtopic.php?f=100&t=551#p9046
Rugged Defense Event Prediction
Whenever an entrenched enemy target is subjected to a non-ranged attack initiated by a unit which is not the beneficiary of Rugged Defense (RD) avoidance privileges, the determination of the likelihood of RD actually happening is computed on the basis of an algebraic formula.
Prediction Formula Variables
Attacker's Experience Level (AExpL)
Attacker's Entrenchment Rate (AEntR)
Target's Entrenchment Level (TEntL)
Target's Experience Level (TExpL)
Target's Entrenchment Rate (TEntR)
Prediction Formula Ratios
Experience Ratio (ExpR) = (TExpL + 2) / (AExpL + 2)
Entrenchment Rate Ratio (EntRR) = (TEntR + 1) / (AEntR + 1)
Prediction Formula
Rugged Defense Percentage Chance = (N/D) * TEntL * ExpR * EntRR
where "N/D" is a calibration fraction. Derived values HIGHER THAN ONE HUNDRED (100) are automatically interpreted as EQUAL TO ONE HUNDRED (100).
Code Computations
PGF's engine does NOT do... high school algebra; rather, it performs integer arithmetic. To this effect:
Numerator = N * TEntL * (TExpL + 2) * (TEntR + 1)
Denominator = D * (AExpL + 2) * (AEntR + 1)
The engine then divides the Numerator value by the Denominator value. The division quotient is ROUNDED DOWN to the nearest integer.