CONTENT LINKS
==============
Introduction
viewtopic.php?f=100&t=543#p8974
Victory Conditions: Terminology
viewtopic.php?f=100&t=543#p8976
Unit Prestige & Experience Modifiers
viewtopic.php?f=100&t=543#p8977
Unit Collocation Determinants
viewtopic.php?f=100&t=543#p12051
DMCU Mount / Dismount & Movement Capabilities
viewtopic.php?f=100&t=543#p12052
Unit Reinforcements: Typology
viewtopic.php?f=100&t=543#p9597
Unit Reinforcements: Prestige Costs
viewtopic.php?f=100&t=543#p9633
Strength Factor Procurement: Details
viewtopic.php?f=100&t=543#p9879
Unit Reconstitution: Experience Point Dilution
viewtopic.php?f=100&t=543#p11791
City & Port Typology
viewtopic.php?f=100&t=543#p11524
Combatant-Owned Hexes: Properties
viewtopic.php?f=100&t=543#p12143
Completely Unenterable Hexes: Properties
viewtopic.php?f=100&t=543#p12200
Listed & Unlisted Combatants
viewtopic.php?f=100&t=543#p11540
Unit Upgrades & Purchases In-Game: Combatant Pseudo-Tab Display Details
viewtopic.php?f=100&t=543#p11541
Owned Hex Entry: Prestige Point Awards
viewtopic.php?f=100&t=543#p12146
Purchased Unit Placement: Enemy Presence Adjacency
viewtopic.php?f=100&t=543#p11527
Core Unit Deployment: Details
viewtopic.php?f=100&t=543#p11528
Unit Deployment: Boarded Or Not ?
viewtopic.php?f=100&t=543#p11356
Unit Auto-Upgrades
viewtopic.php?f=100&t=543#p11345
"Cheat" Codes
viewtopic.php?f=100&t=543#p8978
Indirect Support Fire
viewtopic.php?f=100&t=543#p8979
Level Bombing - Key Elements
viewtopic.php?f=100&t=543#p14525
Carpet Bombing - Details
viewtopic.php?f=100&t=543#p14526
Strategic Bombing - Details
viewtopic.php?f=100&t=543#p14527
Getting Rid Of Organic Transport
viewtopic.php?f=100&t=543#p9990
Naval Transport: Details
viewtopic.php?f=100&t=543#p11273
Air Transport: Details
viewtopic.php?f=100&t=543#p11446
Unit Embarkation & Disembarkation: Procedural Details
viewtopic.php?f=100&t=543#p11539
Hex Combatant Ownership Agnosticism
viewtopic.php?f=100&t=543#p12050
Transport Point... Overuse
viewtopic.php?f=100&t=543#p11493
Unit Para-Drop Air Drift
viewtopic.php?f=100&t=543#p11396
Transport Mode Classes: Attack Properties
viewtopic.php?f=100&t=543#p11526
Rugged Defense Event Chance
viewtopic.php?f=100&t=543#p11427
Submarine Class Unit Detection
viewtopic.php?f=100&t=543#p11016
Submarine Class Unit Evasion (Part I)
viewtopic.php?f=100&t=543#p11394
Submarine Class Unit Evasion (Part II)
viewtopic.php?f=100&t=543#p11395
Surprise Unit Collisions: Overview
viewtopic.php?f=100&t=543#p8980
Surprise Unit Collisions: Combat Avoidance
viewtopic.php?f=100&t=543#p8981
Surprise Unit Collisions: Port Events
viewtopic.php?f=100&t=543#p8982
Ports: Enemy Naval Target Eviction
viewtopic.php?f=100&t=543#p11781
===================================================================
The topic's contents may be modified or progressively added upon as time goes by.
===================================================================
INTRODUCTION
=============
This topic should be of interest to Veteran Players (VPs). It is assumed that VPs are already intimately familiar with the information featured here:
[NP] Introductory Documentation
viewtopic.php?f=100&t=531
[VP] Play System: Advanced Features
[VP] Play System: Advanced Features
Last edited by HexCode on 2022-06-26 00:27, Sunday, edited 40 times in total.
VICTORY CONDITIONS: TERMINOLOGY
VICTORY CONDITIONS: TERMINOLOGY
=================================
The following terminology is applicable to PGF's victory conditions:
A) Instantaneous Victory may be declared at any point in time during play as a result of certain victory conditions having been met "on the spot". Play immediately ends right there and then.
B) End-Point Victory is declared at the mandated termination point of a "battle's" duration (e.g., a scenario's completed last half-turn) in the absence of a prior Instantaneous Victory event determination and as a result of certain termination victory conditions having been met.
C) Nuanced Victory Conditions may further qualify a Victory / Defeat outcome by making reference to additional performance metric combinations (e.g., effective scenario duration and / or specific objective hexes owned).
PGF sports TWO (2) Instantaneous Victory types:
a1) Early Victory is declared at the very instant a Side's Listed Combatants collectively own all scenario objective hexes.
a2) Automatic Victory is declared at the very instant a Side is left with no units aligned with it on the map whatsoever.
Important: PGF's engine does NOT conduct an Instantaneous Victory check at a half-turn's commencement. It does so every time some unit is eliminated / disbanded or when the ownership status of some Port / Embarkation City / Non-Naval City / Airfield hex actually changes during the half-turn. In addition, the engine also conducts Instantaneous Victory checks when the player proactively ends his half-turn.
PGF sports various End-Point Victory types, strictly based on the objective hex ownership pattern at the scenario's mandated termination point.
Standalone Scenario Play Mode "knows" of only TWO (2) possible victory outcomes:
---- Side-0 Victory
---- Side-1 Victory
PGF sports Nuanced Victory Conditions in Campaign Play Mode only ! Specifically, this mode only "knows" of THREE (3) possible victory outcomes:
---- Side-0 Major Victory
---- Side-0 Minor Victory
---- Side-1 Victory
The first two outcomes represent nuanced gradations of the umbrella "Side-0 Victory" outcome. The criteria here are additional performance metric combinations (i.e., effective scenario duration and / or specific objective hexes owned).
=================================
The following terminology is applicable to PGF's victory conditions:
A) Instantaneous Victory may be declared at any point in time during play as a result of certain victory conditions having been met "on the spot". Play immediately ends right there and then.
B) End-Point Victory is declared at the mandated termination point of a "battle's" duration (e.g., a scenario's completed last half-turn) in the absence of a prior Instantaneous Victory event determination and as a result of certain termination victory conditions having been met.
C) Nuanced Victory Conditions may further qualify a Victory / Defeat outcome by making reference to additional performance metric combinations (e.g., effective scenario duration and / or specific objective hexes owned).
PGF sports TWO (2) Instantaneous Victory types:
a1) Early Victory is declared at the very instant a Side's Listed Combatants collectively own all scenario objective hexes.
a2) Automatic Victory is declared at the very instant a Side is left with no units aligned with it on the map whatsoever.
Important: PGF's engine does NOT conduct an Instantaneous Victory check at a half-turn's commencement. It does so every time some unit is eliminated / disbanded or when the ownership status of some Port / Embarkation City / Non-Naval City / Airfield hex actually changes during the half-turn. In addition, the engine also conducts Instantaneous Victory checks when the player proactively ends his half-turn.
PGF sports various End-Point Victory types, strictly based on the objective hex ownership pattern at the scenario's mandated termination point.
Standalone Scenario Play Mode "knows" of only TWO (2) possible victory outcomes:
---- Side-0 Victory
---- Side-1 Victory
PGF sports Nuanced Victory Conditions in Campaign Play Mode only ! Specifically, this mode only "knows" of THREE (3) possible victory outcomes:
---- Side-0 Major Victory
---- Side-0 Minor Victory
---- Side-1 Victory
The first two outcomes represent nuanced gradations of the umbrella "Side-0 Victory" outcome. The criteria here are additional performance metric combinations (i.e., effective scenario duration and / or specific objective hexes owned).
Last edited by HexCode on 2021-12-11 07:14, Saturday, edited 3 times in total.
UNIT PRESTIGE & EXPERIENCE MODIFIERS
UNIT PRESTIGE & EXPERIENCE MODIFIERS
====================================
PGF's Main Game Settings screen displays sliders, the user-selectable positions of which are intended to modify certain default Prestige and Experience values for each Side.
The Prestige slider can accommodate integer modifications ranging from 0% to 200%.
The Experience slider can accommodate integer modifications within range:
[ -5, -4, -3, -2, -1, 0, 1, 2, 3, 4, 5 ]
Prestige
There is absolutely no need to speculate regarding what default Prestige value(s) the slider was intended (?) to modify. The hard truth is that the slider is a... dud ! It does not do anything ! Factually, it is "there" for purely cosmetic purposes...
Experience
When one tampers with the Experience Modifier settings, he intends to alter the number of Experience Levels (ELs) with which newly purchased units enter the scenario. This sort of tampering does not affect the ELs of the "starting" units (they are considered "already purchased"), nor does it alter the ELs of normal and elite replacements during scenario play. In other words, only unit formations purchased once scenario play actually begins are affected.
Standalone Scenario Play Mode
Experience Modifier settings expressed in hundreds (000s) of points are algebraically combined with the scenario's new unit purchase ELs which are predefined (i.e., "default") in its *.PGSCN file. These predefined values are encountered under the column entitled "New Unit Exp" in the file's Section entitled "Sides".
Irrespective of... algebraic operations, the resulting ELs can never be negative or greater than FIVE (5).
Campaign Play Mode
For the "Non-Campaigning" Side, the Experience Modifier setting works in identical fashion to that applicable to Standalone Play Mode.
However, for the "Campaigning" Side, the Experience Modifier setting directly specifies their new unit purchase EL steadily applicable throughout the entire campaign. Core and Auxiliary unit purchases are identically affected.
Once again, the resulting ELs can never be negative or greater than FIVE (5).
====================================
PGF's Main Game Settings screen displays sliders, the user-selectable positions of which are intended to modify certain default Prestige and Experience values for each Side.
The Prestige slider can accommodate integer modifications ranging from 0% to 200%.
The Experience slider can accommodate integer modifications within range:
[ -5, -4, -3, -2, -1, 0, 1, 2, 3, 4, 5 ]
Prestige
There is absolutely no need to speculate regarding what default Prestige value(s) the slider was intended (?) to modify. The hard truth is that the slider is a... dud ! It does not do anything ! Factually, it is "there" for purely cosmetic purposes...
Experience
When one tampers with the Experience Modifier settings, he intends to alter the number of Experience Levels (ELs) with which newly purchased units enter the scenario. This sort of tampering does not affect the ELs of the "starting" units (they are considered "already purchased"), nor does it alter the ELs of normal and elite replacements during scenario play. In other words, only unit formations purchased once scenario play actually begins are affected.
Standalone Scenario Play Mode
Experience Modifier settings expressed in hundreds (000s) of points are algebraically combined with the scenario's new unit purchase ELs which are predefined (i.e., "default") in its *.PGSCN file. These predefined values are encountered under the column entitled "New Unit Exp" in the file's Section entitled "Sides".
Irrespective of... algebraic operations, the resulting ELs can never be negative or greater than FIVE (5).
Campaign Play Mode
For the "Non-Campaigning" Side, the Experience Modifier setting works in identical fashion to that applicable to Standalone Play Mode.
However, for the "Campaigning" Side, the Experience Modifier setting directly specifies their new unit purchase EL steadily applicable throughout the entire campaign. Core and Auxiliary unit purchases are identically affected.
Once again, the resulting ELs can never be negative or greater than FIVE (5).
Last edited by HexCode on 2021-06-06 19:11, Sunday, edited 4 times in total.
"CHEAT" CODES
"CHEAT" CODES
==============
Prologue
In my opinion, this has always been... semantically unfortunate territory.
Ok, when it comes to "pure" play, one may wish to "cheat"; big deal ! It is only a game...
As far as I am concerned, the so called "Cheat" Codes (CCs) can be very useful tools in the hands of custom content modders wishing to conveniently and effectively test out many, many "things". Moreover, specific CCs may need to be invoked during play in support of prescribed "house rule" implementations (if any).
Clearly, PGF's AI cannot invoke CCs. At the same time, quite a few CCs which a player may invoke do not affect PGF AI's current battlefield realities in any way.
How to Invoke Them
To enter a CC, one has to press [Ctrl+Alt+Shift+C]. A dialog box pops up sporting a single text input field (line). The user, then, types in the particular CC he wishes to trigger.
User input is always case sensitive. In fact, all input should be typed in in lowercase.
In the sequel, #N shall designate an integer to be specified by the user. Depending on the particular CC, #N can be negative.
CC Who's Who
Extremely Useful CCs
turns #N
Adds #N to scenario's current turn count. #N can be negative.
Kindly consult its corresponding Functionality Note below.
prestige #N
Adds #N to current prestige points. #N can be negative.
endscn #N
Immediately ends the current scenario with outcome #N (0=Major Victory, 1=Minor Victory, 2=Defeat (Loss)).
Atmospheric & Ground Condition CCs
weather #N
Sets current atmospheric conditions (0=Clear, 1=Overcast, 2=Rain, 3=Snow).
ground #N
Sets current ground condition (0=Dry, 1=Muddy, 2=Frozen).
Transport Points
#N can be negative.
air #N
Adds #N to currently specified air transport points.
sea #N
Adds #N to currently specified naval transport points.
Unit Slots
#N can be negative.
core #N
Adds #N to currently specified Core slots.
aux #N
Adds #N to currently specified Auxiliaries slots.
Unit Global CCs
Entering the CC again disables this mode.
fog of war
Shows opponent's units on the map (the opponent will not see your units until he enters this CC on his turn).
no zoc
Disables Zones of Control (ZoC) for your units.
uber units
Every attack completely eliminates the opponent's unit.
force retreat
Every attack forces the opponent's unit to retreat.
turbo units
All units move at speed 50.
all eqp
Allows you to buy unit types which become available in the future.
Unit Specific CCs
fuel #N
Sets the selected unit's current, remaining fuel to #N.
ammo #N
Sets the selected unit's current, remaining ammo to #N.
ent #N
Sets the selected unit's current entrenchment to #N.
exp #N
Sets the selected unit's current experience to #N.
str #N
Sets the selected unit's current strength to #N.
Functionality Notes
turns #N
Adds #N to scenario's current turn count. #N can be negative.
PGF attempts to accommodate on-the-fly scenario duration prolongation by allowing a player to invoke this CC. #N represents the number of turns which the player desires to append to the hitherto specified scenario maximum duration (in turns).
Unfortunately, the programming underlying this CC is problematic. The culprit is the data specified in file *.PGSCN under the section entitled "# Per-turn prestige allotments". Unless this section already contains data explicitly and fully covering the desired, prolonged scenario duration, upon attempting to enter bona fide prolonged scenario duration territory, PGF's engine generates a fatal error.
Modders may wish to sufficiently pad the contents of file *.PGSCN under the section entitled "# Per-turn prestige allotments" so as to preemptively take care of all potentially desirable scenario prolongation eventualities.
==============
Prologue
In my opinion, this has always been... semantically unfortunate territory.
Ok, when it comes to "pure" play, one may wish to "cheat"; big deal ! It is only a game...As far as I am concerned, the so called "Cheat" Codes (CCs) can be very useful tools in the hands of custom content modders wishing to conveniently and effectively test out many, many "things". Moreover, specific CCs may need to be invoked during play in support of prescribed "house rule" implementations (if any).
Clearly, PGF's AI cannot invoke CCs.
At the same time, quite a few CCs which a player may invoke do not affect PGF AI's current battlefield realities in any way.How to Invoke Them
To enter a CC, one has to press [Ctrl+Alt+Shift+C]. A dialog box pops up sporting a single text input field (line). The user, then, types in the particular CC he wishes to trigger.
User input is always case sensitive. In fact, all input should be typed in in lowercase.
In the sequel, #N shall designate an integer to be specified by the user. Depending on the particular CC, #N can be negative.
CC Who's Who
Extremely Useful CCs
turns #N
Adds #N to scenario's current turn count. #N can be negative.
Kindly consult its corresponding Functionality Note below.
prestige #N
Adds #N to current prestige points. #N can be negative.
endscn #N
Immediately ends the current scenario with outcome #N (0=Major Victory, 1=Minor Victory, 2=Defeat (Loss)).
Atmospheric & Ground Condition CCs
weather #N
Sets current atmospheric conditions (0=Clear, 1=Overcast, 2=Rain, 3=Snow).
ground #N
Sets current ground condition (0=Dry, 1=Muddy, 2=Frozen).
Transport Points
#N can be negative.
air #N
Adds #N to currently specified air transport points.
sea #N
Adds #N to currently specified naval transport points.
Unit Slots
#N can be negative.
core #N
Adds #N to currently specified Core slots.
aux #N
Adds #N to currently specified Auxiliaries slots.
Unit Global CCs
Entering the CC again disables this mode.
fog of war
Shows opponent's units on the map (the opponent will not see your units until he enters this CC on his turn).
no zoc
Disables Zones of Control (ZoC) for your units.
uber units
Every attack completely eliminates the opponent's unit.
force retreat
Every attack forces the opponent's unit to retreat.
turbo units
All units move at speed 50.
all eqp
Allows you to buy unit types which become available in the future.
Unit Specific CCs
fuel #N
Sets the selected unit's current, remaining fuel to #N.
ammo #N
Sets the selected unit's current, remaining ammo to #N.
ent #N
Sets the selected unit's current entrenchment to #N.
exp #N
Sets the selected unit's current experience to #N.
str #N
Sets the selected unit's current strength to #N.
Functionality Notes
turns #N
Adds #N to scenario's current turn count. #N can be negative.
PGF attempts to accommodate on-the-fly scenario duration prolongation by allowing a player to invoke this CC. #N represents the number of turns which the player desires to append to the hitherto specified scenario maximum duration (in turns).
Unfortunately, the programming underlying this CC is problematic. The culprit is the data specified in file *.PGSCN under the section entitled "# Per-turn prestige allotments". Unless this section already contains data explicitly and fully covering the desired, prolonged scenario duration, upon attempting to enter bona fide prolonged scenario duration territory, PGF's engine generates a fatal error.
Modders may wish to sufficiently pad the contents of file *.PGSCN under the section entitled "# Per-turn prestige allotments" so as to preemptively take care of all potentially desirable scenario prolongation eventualities.
Last edited by HexCode on 2021-10-27 05:15, Wednesday, edited 5 times in total.
INDIRECT SUPPORT FIRE
INDIRECT SUPPORT FIRE
=====================
Indirect Support (Defensive) Fire (ISF) is a rather well known PGF feature. In general, only certain units capable of ranged attacks as well as Fighters can provide ISF. ISF is always involuntary in the sense that it can never be initiated (or voluntarily skipped) by a human player. In its own digital... wisdom, PGF initiates and follows through with all possible ISF phenomena.
Global Clarifications
It is not necessary for a unit providing ISF to be adjacent to the attacking enemy
unit. It is necessary, though, for the unit providing ISF to be adjacent to the friendly unit under attack "requesting" ISF.
Global Rule #1: Units providing ISF are never subjected to enemy "counter-fire".
Global Rule #2: ISF can never be provided in instances where the enemy attack is a ranged one (i.e., attacking Artillery and Capital Ship class as well as Fort units).
Global Rule #3: If a unit, which could, otherwise, provide ISF, runs out of ammunition, quite logically, it cannot engage in ISF.
Ground Unit Clarifications
Only Artillery class units (irrespective of their Shooting Range) can provide ISF to adjacent friendly Ground units being attacked by enemy Ground units. Only Air Defense class units (irrespective of their Shooting Range) can provide ISF to adjacent friendly Surface (i.e., Ground and Naval) units being attacked by enemy Air units.
PGF treats Air Defense class units having a Shooting Range of 0 as if it were, in fact, 1... Moreover, neither Anti-Aircraft class nor Fort units can ever provide ISF.
Ground Unit Rule #1: Subject to its ammunition availability, a Ground unit may participate in the provision of ISF more than once during the course of a half-turn.
Ground Unit Rule #2: If a Ground unit, which could, otherwise, provide ISF, is in a state of being transported, it cannot engage in ISF. Simply put, PGF will not
automatically "dismount" such a unit on its own digital... initiative, even in instances where such action is both possible and desirable from the defender's point of view.
Ground Unit Rule #3: If a Ground unit, which could, otherwise, provide ISF, has no remaining unsuppressed strength points left on-line due to the lasting effects of enemy level bombing action, quite logically, it cannot engage in ISF.
Ground Unit Rule #4: Same Ground class units capable of providing ISF support to an adjacent friendly unit under attack do so sequentially, one combat at a time. Each such combat event takes the outcome of the immediately preceding combat event as a new starting point in the rapidly unfolding battle resolution saga...
Naval Unit Clarifications
Naval Unit Rule #1: Despite the fact that Capital Ship class units engage in ranged attacks, such units cannot ever provide ISF.
Naval Unit Rule #2: Naval units can never be the beneficiaries of ISF provided by friendly Artillery class units, adjacency considerations notwithstanding...
Naval Unit Rule #3: Destroyer class units attacking enemy ground units occupying coastal hexes can never be subjected to enemy artillery-type ISF.
Air Unit Clarifications
Air Unit Rule #1: Only Fighter class units can provide ISF to adjacent friendly units under enemy air attack. Fighter-Bomber units can never provide ISF.
Air Unit Rule #2: Each specific Fighter class unit is allowed one and only one ISF provision (i.e., Interception) per half-turn. The friendly unit supported can be a Ground, Naval or Air one (even Submarine class units can be supported).
Air Unit Rule #3: Fighter class units can never combine their support for purposes of Interception. PGF automatically picks the intercepting unit which is expected to do the most damage to the attacking enemy Air unit.
Air Unit Rule #4: In instances where both Fighter and Air Defense ISF are possible, PGF starts with the resolution of the Fighter interception first. It automatically proceeds, next, with the resolution of Air Defense ISF as a separate battle event, thus, taking the outcome of the preceding Fighter Interception as a new starting point in the rapidly unfolding battle resolution saga...
=====================
Indirect Support (Defensive) Fire (ISF) is a rather well known PGF feature. In general, only certain units capable of ranged attacks as well as Fighters can provide ISF. ISF is always involuntary in the sense that it can never be initiated (or voluntarily skipped) by a human player. In its own digital... wisdom, PGF initiates and follows through with all possible ISF phenomena.
Global Clarifications
It is not necessary for a unit providing ISF to be adjacent to the attacking enemy
unit. It is necessary, though, for the unit providing ISF to be adjacent to the friendly unit under attack "requesting" ISF.
Global Rule #1: Units providing ISF are never subjected to enemy "counter-fire".
Global Rule #2: ISF can never be provided in instances where the enemy attack is a ranged one (i.e., attacking Artillery and Capital Ship class as well as Fort units).
Global Rule #3: If a unit, which could, otherwise, provide ISF, runs out of ammunition, quite logically, it cannot engage in ISF.
Ground Unit Clarifications
Only Artillery class units (irrespective of their Shooting Range) can provide ISF to adjacent friendly Ground units being attacked by enemy Ground units. Only Air Defense class units (irrespective of their Shooting Range) can provide ISF to adjacent friendly Surface (i.e., Ground and Naval) units being attacked by enemy Air units.
PGF treats Air Defense class units having a Shooting Range of 0 as if it were, in fact, 1... Moreover, neither Anti-Aircraft class nor Fort units can ever provide ISF.
Ground Unit Rule #1: Subject to its ammunition availability, a Ground unit may participate in the provision of ISF more than once during the course of a half-turn.
Ground Unit Rule #2: If a Ground unit, which could, otherwise, provide ISF, is in a state of being transported, it cannot engage in ISF. Simply put, PGF will not
automatically "dismount" such a unit on its own digital... initiative, even in instances where such action is both possible and desirable from the defender's point of view.
Ground Unit Rule #3: If a Ground unit, which could, otherwise, provide ISF, has no remaining unsuppressed strength points left on-line due to the lasting effects of enemy level bombing action, quite logically, it cannot engage in ISF.
Ground Unit Rule #4: Same Ground class units capable of providing ISF support to an adjacent friendly unit under attack do so sequentially, one combat at a time. Each such combat event takes the outcome of the immediately preceding combat event as a new starting point in the rapidly unfolding battle resolution saga...
Naval Unit Clarifications
Naval Unit Rule #1: Despite the fact that Capital Ship class units engage in ranged attacks, such units cannot ever provide ISF.
Naval Unit Rule #2: Naval units can never be the beneficiaries of ISF provided by friendly Artillery class units, adjacency considerations notwithstanding...
Naval Unit Rule #3: Destroyer class units attacking enemy ground units occupying coastal hexes can never be subjected to enemy artillery-type ISF.
Air Unit Clarifications
Air Unit Rule #1: Only Fighter class units can provide ISF to adjacent friendly units under enemy air attack. Fighter-Bomber units can never provide ISF.
Air Unit Rule #2: Each specific Fighter class unit is allowed one and only one ISF provision (i.e., Interception) per half-turn. The friendly unit supported can be a Ground, Naval or Air one (even Submarine class units can be supported).
Air Unit Rule #3: Fighter class units can never combine their support for purposes of Interception. PGF automatically picks the intercepting unit which is expected to do the most damage to the attacking enemy Air unit.
Air Unit Rule #4: In instances where both Fighter and Air Defense ISF are possible, PGF starts with the resolution of the Fighter interception first. It automatically proceeds, next, with the resolution of Air Defense ISF as a separate battle event, thus, taking the outcome of the preceding Fighter Interception as a new starting point in the rapidly unfolding battle resolution saga...
Last edited by HexCode on 2021-05-18 06:22, Tuesday, edited 1 time in total.
SURPRISE UNIT COLLISIONS: OVERVIEW
SURPRISE UNIT COLLISIONS: OVERVIEW
===================================
Not About That...
Reasonable familiarity with PGF's Hidden Units "on" checkbox setting ("Fog of War") is assumed. From time to time, a unit effectively ends up its movement phase finding itself adjacent to an enemy unit that has hitherto been hidden (unspotted). It is immaterial whether this has been the result of:
a) The unit having voluntarily cut its movement phase short or having been forced by PGF to stop -- having simply exhausted its effective Movement Allowance (MA), or
b) PGF having put an abrupt stop to the unit's movement upon entering an enemy unit's suddenly revealed Zone of Control (ZoC) without having attempted to actually move into (or through) the hex actually occupied by the said enemy unit.
Most of this post and the immediately two ones to follow are NOT about all that...
What happens though if, under "Fog of War", a unit attempts to enter a hex occupied by a hitherto unspotted enemy unit ? For starters, if the is a surface one and the enemy unit is an air one (or vice versa), well, nothing much ! The opposing units can... peacefully co-exist and, in fact, our moving unit can even go through the said hex unobstructed.
Once again, the remainder of this post and the immediately two ones to follow are NOT about all that...
Opposing Unit Actual Surprise Collisions
A unit attempts to enter a hex occupied by a hitherto unspotted enemy unit and PGF suddenly intervenes and stops it dead in its tracks (so to speak) on a hex adjacent to the hitherto unspotted and presently revealed enemy unit. At that very moment, PGF's behavior would be indistinguishable from the one described under preceding case (b). However, what happens next, if anything, is a bit more interesting...
Combat-Avoiding Surprise Collisions
Not all "Surprise Collision" events necessarily and automatically lead to actual combat ! The following two Global Rules underlie Combat-Avoiding Surprise Collisions:
Global Rule #1: If the hitherto hidden, stationary unit sports either a bracketed or a ZERO (0) combat-relevant Attack value, NO combat ensues.
Global Rule #2: If the hitherto hidden, stationary unit sports ZERO (0) Ammo Points, NO combat ensues.
Combat-Triggering Surprise Collisions
Reasonable familiarity with run-of-the-mill "Rugged Defense" events as they apply to combat between opposing Ground units is assumed. Basically, a "Rugged Defense" event is, more often than not, way more disadvantageous to an attacking ground unit than an equivalent "Ordinary Combat" event.
Combat-Triggering Surprise Collisions tend to result in combat that is way more disadvantageous to the moving unit than in an equivalent "Ordinary Combat" situation. This is a direct extension of run-of-the-mill "Rugged Defense" concepts into surprises involving Ground unit collisions; it is also a further extension into Naval and Air Super-Class unit sudden collisions. The following establishes some Combat-Triggering Surprise Collision terminology:
1) It is a "Rugged Defense" event if the stationary unit is a Ground one.
2) It is a "Surprise Contact" event if the stationary unit is a Naval Super-Class one.
3) It is an "Out of the Sun" event if the stationary unit is an Air Super-Class one.
===================================
Not About That...
Reasonable familiarity with PGF's Hidden Units "on" checkbox setting ("Fog of War") is assumed. From time to time, a unit effectively ends up its movement phase finding itself adjacent to an enemy unit that has hitherto been hidden (unspotted). It is immaterial whether this has been the result of:
a) The unit having voluntarily cut its movement phase short or having been forced by PGF to stop -- having simply exhausted its effective Movement Allowance (MA), or
b) PGF having put an abrupt stop to the unit's movement upon entering an enemy unit's suddenly revealed Zone of Control (ZoC) without having attempted to actually move into (or through) the hex actually occupied by the said enemy unit.
Most of this post and the immediately two ones to follow are NOT about all that...
What happens though if, under "Fog of War", a unit attempts to enter a hex occupied by a hitherto unspotted enemy unit ? For starters, if the is a surface one and the enemy unit is an air one (or vice versa), well, nothing much ! The opposing units can... peacefully co-exist and, in fact, our moving unit can even go through the said hex unobstructed.
Once again, the remainder of this post and the immediately two ones to follow are NOT about all that...
Opposing Unit Actual Surprise Collisions
A unit attempts to enter a hex occupied by a hitherto unspotted enemy unit and PGF suddenly intervenes and stops it dead in its tracks (so to speak) on a hex adjacent to the hitherto unspotted and presently revealed enemy unit. At that very moment, PGF's behavior would be indistinguishable from the one described under preceding case (b). However, what happens next, if anything, is a bit more interesting...
Combat-Avoiding Surprise Collisions
Not all "Surprise Collision" events necessarily and automatically lead to actual combat ! The following two Global Rules underlie Combat-Avoiding Surprise Collisions:
Global Rule #1: If the hitherto hidden, stationary unit sports either a bracketed or a ZERO (0) combat-relevant Attack value, NO combat ensues.
Global Rule #2: If the hitherto hidden, stationary unit sports ZERO (0) Ammo Points, NO combat ensues.
Combat-Triggering Surprise Collisions
Reasonable familiarity with run-of-the-mill "Rugged Defense" events as they apply to combat between opposing Ground units is assumed. Basically, a "Rugged Defense" event is, more often than not, way more disadvantageous to an attacking ground unit than an equivalent "Ordinary Combat" event.
Combat-Triggering Surprise Collisions tend to result in combat that is way more disadvantageous to the moving unit than in an equivalent "Ordinary Combat" situation. This is a direct extension of run-of-the-mill "Rugged Defense" concepts into surprises involving Ground unit collisions; it is also a further extension into Naval and Air Super-Class unit sudden collisions. The following establishes some Combat-Triggering Surprise Collision terminology:
1) It is a "Rugged Defense" event if the stationary unit is a Ground one.
2) It is a "Surprise Contact" event if the stationary unit is a Naval Super-Class one.
3) It is an "Out of the Sun" event if the stationary unit is an Air Super-Class one.
Last edited by HexCode on 2021-10-30 03:34, Saturday, edited 3 times in total.
SURPRISE UNIT COLLISIONS: COMBAT AVOIDANCE
SURPRISE UNIT COLLISIONS: COMBAT AVOIDANCE
===========================================
In the immediately preceding post, I wrote:
Naval Unit Combat Avoidance
The following THREE (3) Combat-Avoiding restrictions are unit class properties which PGF enforces in addition to the two Global Rules stated in the immediately preceding post.
NUCA #1: Any Surprise Collision between a stationary Submarine Class unit and a moving enemy Naval Super-Class unit belonging to a class other than Destroyer avoids combat.
NUCA #2: Any Surprise Collision between a stationary Capital Ship Class unit and a moving enemy Submarine Class unit avoids combat.
NUCA #3: Any Surprise Collision between a stationary Aircraft Carrier or Naval Transport Class unit and a moving enemy Naval Super-Class unit avoids combat.
Air Unit Combat Avoidance
The following Combat-Avoiding restriction is enforced by PGF in addition to the two Global Rules stated in the immediately preceding post.
AUCA: Under atmospheric conditions of Rain or Snow, all Surprise Collisions between opposing air units avoid combat.
===========================================
In the immediately preceding post, I wrote:
What is a combat-relevant Attack capability ? Well, it is situational. Specifically, it is the capability of the stationary unit to hypothetically initiate (or not) actual combat against the moving enemy unit under "normal" combat circumstances. Clearly, a bracketed Attack value points to a stationary unit's inability to hypothetically initiate actual combat.If the hitherto hidden stationary unit sports either a bracketed or a ZERO (0) combat-relevant Attack value, no combat ensues.
Naval Unit Combat Avoidance
The following THREE (3) Combat-Avoiding restrictions are unit class properties which PGF enforces in addition to the two Global Rules stated in the immediately preceding post.
NUCA #1: Any Surprise Collision between a stationary Submarine Class unit and a moving enemy Naval Super-Class unit belonging to a class other than Destroyer avoids combat.
NUCA #2: Any Surprise Collision between a stationary Capital Ship Class unit and a moving enemy Submarine Class unit avoids combat.
NUCA #3: Any Surprise Collision between a stationary Aircraft Carrier or Naval Transport Class unit and a moving enemy Naval Super-Class unit avoids combat.
Air Unit Combat Avoidance
The following Combat-Avoiding restriction is enforced by PGF in addition to the two Global Rules stated in the immediately preceding post.
AUCA: Under atmospheric conditions of Rain or Snow, all Surprise Collisions between opposing air units avoid combat.
Last edited by HexCode on 2021-10-30 03:26, Saturday, edited 3 times in total.
SURPRISE UNIT COLLISIONS: PORT EVENTS
SURPRISE UNIT COLLISIONS: PORT EVENTS
=====================================
A Port City / Facilities hex can accommodate either a Ground or a Naval Super-Class unit but NOT both simultaneously. To this effect, a hitherto hidden, stationary unit occupying such a hex can be subjected to a Surprise Collision by a moving, enemy unit. All instances involving Sudden Collisions between Ground units have already been documented in the two immediately preceding posts; ditto for Sudden Collisions between Naval Super-Class units.
The present post strictly focuses on various types of Surprise Collisions, each involving a Ground and a Naval Super-Class unit (and vice versa) in instances where either stationary unit occupies a Port City / Facilities hex. To the extent that such collisions trigger actual combat, PGF always visually identifies them as "Rugged Defense" events. Also, in certain instances NOT involving actual combat, PGF forces a stationary Naval Super-Class unit to vacate the Port / Facilities hex it has hitherto occupied and displays the message "FLEEING PORT!". If there are no adjacent, unoccupied, terrain-friendly hexes that the Naval Super-Class unit can retreat to, it gets eliminated and PGF displays the message "SHIP IS SCUTTLED!".
Port-Related Unit Combat Avoidance
The following Combat-Avoiding restrictions are unit class properties which PGF enforces in addition to the two very important Global Rules stated two posts up.
PRUCA #1: Any Surprise Collision involving a Submarine Class unit avoids combat.
PRUCA #2: Any Surprise Collision between a stationary Aircraft Carrier or Naval Transport Class unit on one hand and a moving enemy Ground unit on the other avoids combat.
PRUCA #3: Any Surprise Collision between a stationary Destroyer or Capital Ship Class unit on one hand and a moving enemy Infantry, Tank or Recon Class unit on the other avoids combat while forcing the stationary Naval Super-Class unit to retreat at the same time.
=====================================
A Port City / Facilities hex can accommodate either a Ground or a Naval Super-Class unit but NOT both simultaneously. To this effect, a hitherto hidden, stationary unit occupying such a hex can be subjected to a Surprise Collision by a moving, enemy unit. All instances involving Sudden Collisions between Ground units have already been documented in the two immediately preceding posts; ditto for Sudden Collisions between Naval Super-Class units.
The present post strictly focuses on various types of Surprise Collisions, each involving a Ground and a Naval Super-Class unit (and vice versa) in instances where either stationary unit occupies a Port City / Facilities hex. To the extent that such collisions trigger actual combat, PGF always visually identifies them as "Rugged Defense" events. Also, in certain instances NOT involving actual combat, PGF forces a stationary Naval Super-Class unit to vacate the Port / Facilities hex it has hitherto occupied and displays the message "FLEEING PORT!". If there are no adjacent, unoccupied, terrain-friendly hexes that the Naval Super-Class unit can retreat to, it gets eliminated and PGF displays the message "SHIP IS SCUTTLED!".
Port-Related Unit Combat Avoidance
The following Combat-Avoiding restrictions are unit class properties which PGF enforces in addition to the two very important Global Rules stated two posts up.
PRUCA #1: Any Surprise Collision involving a Submarine Class unit avoids combat.
PRUCA #2: Any Surprise Collision between a stationary Aircraft Carrier or Naval Transport Class unit on one hand and a moving enemy Ground unit on the other avoids combat.
PRUCA #3: Any Surprise Collision between a stationary Destroyer or Capital Ship Class unit on one hand and a moving enemy Infantry, Tank or Recon Class unit on the other avoids combat while forcing the stationary Naval Super-Class unit to retreat at the same time.
Last edited by HexCode on 2021-10-30 03:22, Saturday, edited 3 times in total.
UNIT REINFORCEMENTS: TYPOLOGY
UNIT REINFORCEMENTS: TYPOLOGY
================================
In the most general sense, "generalized reinforcements" represent newly acquired or upgraded Strength Factors (SFs) made available to the procurer at some Prestige Point (PP) cost. With respect to a unit, there are FOUR (4) possible reinforcement avenues:
1) New Unit Purchases
The procurer purchases an entire, brand new unit always comprising TEN (10) SFs.
2) Unit Upgrades
The procurer upgrades an existing unit in its entirety, SF for SF. The upgraded unit's SFs reenter the picture with Experience Points (EPs) PRECISELY MATCHING those of the unit's SFs immediately prior to its upgrade. Thus no cumulative EP Dilution whatsoever takes place.
3) Unit Over-Strengthening
The procurer is allowed to purchase just ONE (1) SF to add to an existing unit hitherto sporting TEN (10) OR MORE SFs (i.e., Full-strength OR Over-Strength) provided the intended addition would not have otherwise resulted in a unit whose Over-Strength SFs would be GREATER than the existing unit's current Experience Level (EL) (i.e., number of "Stars"). Over-Strengthening always entails the addition of a single SF which enters the picture with Experience Points (EPs) PRECISELY MATCHING those of the unit's SFs immediately prior to its procurement. Thus no cumulative EP Dilution whatsoever takes place.
4) Strength Factor Replacements
The procurer always purchases the situationally maximum allowable number of SFs to add to an existing unit hitherto sporting LESS than TEN (10) SFs (i.e., Under-Strength).
There are THREE (3) SF Replacement types:
a) Campaign Inter-Scenario
In-between successive scenarios during a Campaign, PGF can be set (or not) to automatically restore all Under-Strength Core units (if any) back to TEN (10) SFs (i)without the procurer incurring any PP cost whatsoever, and (ii) without the reconstituted Core units being subjected to any cumulative EP dilution whatsoever.
Campaign Inter-Scenario Replacements
viewtopic.php?f=100&t=540#p8963
provides further elaboration and more details.
b) Elite
All purchased unit SFs enter the picture with EPs PRECISELY MATCHING those of the existing unit about to be reconstituted. Thus, no cumulative EP Dilution whatsoever takes place.
c) Regular
All purchased unit SFs enter the picture with ZERO (0) EPs (i.e., "green") thereby resulting in the reconstituted unit's cumulative EP Dilution.
================================
In the most general sense, "generalized reinforcements" represent newly acquired or upgraded Strength Factors (SFs) made available to the procurer at some Prestige Point (PP) cost. With respect to a unit, there are FOUR (4) possible reinforcement avenues:
1) New Unit Purchases
The procurer purchases an entire, brand new unit always comprising TEN (10) SFs.
2) Unit Upgrades
The procurer upgrades an existing unit in its entirety, SF for SF. The upgraded unit's SFs reenter the picture with Experience Points (EPs) PRECISELY MATCHING those of the unit's SFs immediately prior to its upgrade. Thus no cumulative EP Dilution whatsoever takes place.
3) Unit Over-Strengthening
The procurer is allowed to purchase just ONE (1) SF to add to an existing unit hitherto sporting TEN (10) OR MORE SFs (i.e., Full-strength OR Over-Strength) provided the intended addition would not have otherwise resulted in a unit whose Over-Strength SFs would be GREATER than the existing unit's current Experience Level (EL) (i.e., number of "Stars"). Over-Strengthening always entails the addition of a single SF which enters the picture with Experience Points (EPs) PRECISELY MATCHING those of the unit's SFs immediately prior to its procurement. Thus no cumulative EP Dilution whatsoever takes place.
4) Strength Factor Replacements
The procurer always purchases the situationally maximum allowable number of SFs to add to an existing unit hitherto sporting LESS than TEN (10) SFs (i.e., Under-Strength).
There are THREE (3) SF Replacement types:
a) Campaign Inter-Scenario
In-between successive scenarios during a Campaign, PGF can be set (or not) to automatically restore all Under-Strength Core units (if any) back to TEN (10) SFs (i)without the procurer incurring any PP cost whatsoever, and (ii) without the reconstituted Core units being subjected to any cumulative EP dilution whatsoever.
Campaign Inter-Scenario Replacements
viewtopic.php?f=100&t=540#p8963
provides further elaboration and more details.
b) Elite
All purchased unit SFs enter the picture with EPs PRECISELY MATCHING those of the existing unit about to be reconstituted. Thus, no cumulative EP Dilution whatsoever takes place.
c) Regular
All purchased unit SFs enter the picture with ZERO (0) EPs (i.e., "green") thereby resulting in the reconstituted unit's cumulative EP Dilution.
Last edited by HexCode on 2021-06-01 01:33, Tuesday, edited 8 times in total.
UNIT REINFORCEMENTS: PRESTIGE COSTS
UNIT REINFORCEMENTS: PRESTIGE COSTS
====================================
Absolute Prerequisite
Unit Reinforcements: Typology
viewtopic.php?f=100&t=543#p9597
Prestige Costs
1) New Unit Purchases
Each unit type is assigned a Listed Procurement Cost (LPC) expressed in Prestige Points (PPs). A unit's LPC value is independent of the unit's Experience Level (EL).
2) Unit Upgrades
Upgrading an existing unit costs:
[LPC * (10 / 12)] PPs
using the LPC value of the intended unit type upgrade. The computation is independent of the actual number of Strength Factors (SFs) to be upgraded.
3) Unit Over-Strengthening
Procuring ONE (1) additional SF for a unit costs:
[LPC / 12] PPs
4) Strength Factor Replacements
a) Campaign Inter-Scenario
The automatic procurement of ONE (1) OR MORE additional SFs for a unit costs:
ZERO (0) PPs
b) Elite
Procuring ONE (1) additional SF for a unit costs:
[LPC / 12] PPs
Oftentimes, it is referred to as the Unit Combat Value (UCV).
c) Regular
Procuring ONE (1) additional SF for a unit costs:
[LPC / 48] PPs
Computational Note
The preceding algebraic presentation aims at establishing the quantitative logic underpinning PP expenditure due to the procurement of unit reinforcements. However, this is not exactly how PGF's code computes "things". The actual code computational steps are covered in great detail here:
Unit Reinforcements: Prestige Expenditure Computations
viewtopic.php?f=100&t=544#p9676
Depicted Information Reliability
Prior to actually procuring any particular reinforcement(s), the human player is provided with depicted information telling him exactly how many SF's he is about to procure and at what PP cost to his side. Specifically:
A) Intended Unit Type Purchase -- Pressing Scenario Panel Button #14 activates the Unit Purchase Pop-up Screen. The PP cost which would be incurred is displayed on the screen's upper-right corner.
B) Intended Unit Type Upgrade -- Pressing Scenario Panel Button #7 activates the Unit Upgrade Pop-up Screen. The PP cost which would be incurred is displayed on the screen's upper-right corner.
C) Intended Unit Elite Replacements & Over-Strengthening -- Hovering over Button #6 activates a tooltip which displays the SFs which would be procured and the corresponding PP cost which would be incurred.
D) Intended Unit Regular Replacements -- Hovering over Button #5 activates a tooltip which displays the SFs which would be procured and the corresponding PP cost which would be incurred.
IMPORTANT: The above information is 100% reliable in the sense that PGF engine's actual implementation of any particular reinforcement request faithfully reproduces the SF and PP cost information as realized outcomes.
====================================
Absolute Prerequisite
Unit Reinforcements: Typology
viewtopic.php?f=100&t=543#p9597
Prestige Costs
1) New Unit Purchases
Each unit type is assigned a Listed Procurement Cost (LPC) expressed in Prestige Points (PPs). A unit's LPC value is independent of the unit's Experience Level (EL).
2) Unit Upgrades
Upgrading an existing unit costs:
[LPC * (10 / 12)] PPs
using the LPC value of the intended unit type upgrade. The computation is independent of the actual number of Strength Factors (SFs) to be upgraded.
3) Unit Over-Strengthening
Procuring ONE (1) additional SF for a unit costs:
[LPC / 12] PPs
4) Strength Factor Replacements
a) Campaign Inter-Scenario
The automatic procurement of ONE (1) OR MORE additional SFs for a unit costs:
ZERO (0) PPs
b) Elite
Procuring ONE (1) additional SF for a unit costs:
[LPC / 12] PPs
Oftentimes, it is referred to as the Unit Combat Value (UCV).
c) Regular
Procuring ONE (1) additional SF for a unit costs:
[LPC / 48] PPs
Computational Note
The preceding algebraic presentation aims at establishing the quantitative logic underpinning PP expenditure due to the procurement of unit reinforcements. However, this is not exactly how PGF's code computes "things". The actual code computational steps are covered in great detail here:
Unit Reinforcements: Prestige Expenditure Computations
viewtopic.php?f=100&t=544#p9676
Depicted Information Reliability
Prior to actually procuring any particular reinforcement(s), the human player is provided with depicted information telling him exactly how many SF's he is about to procure and at what PP cost to his side. Specifically:
A) Intended Unit Type Purchase -- Pressing Scenario Panel Button #14 activates the Unit Purchase Pop-up Screen. The PP cost which would be incurred is displayed on the screen's upper-right corner.
B) Intended Unit Type Upgrade -- Pressing Scenario Panel Button #7 activates the Unit Upgrade Pop-up Screen. The PP cost which would be incurred is displayed on the screen's upper-right corner.
C) Intended Unit Elite Replacements & Over-Strengthening -- Hovering over Button #6 activates a tooltip which displays the SFs which would be procured and the corresponding PP cost which would be incurred.
D) Intended Unit Regular Replacements -- Hovering over Button #5 activates a tooltip which displays the SFs which would be procured and the corresponding PP cost which would be incurred.
IMPORTANT: The above information is 100% reliable in the sense that PGF engine's actual implementation of any particular reinforcement request faithfully reproduces the SF and PP cost information as realized outcomes.
Last edited by HexCode on 2021-11-23 11:58, Tuesday, edited 1 time in total.
STRENGTH FACTOR PROCUREMENT: DETAILS
STRENGTH FACTOR PROCUREMENT: DETAILS
=======================================
Absolute Prerequisite
Units: Replacements & Over-Strengthening
viewtopic.php?f=100&t=531#p9874
Ground & Air Super-Class Units
Algebraic Rules
Upon proactive request and Prestige Point (PP) availability permitting, the maximum number of Strength Factor (SF) Replacements situationally allowable is always automatically granted to a unit.
A) If there are NO adjacent enemy units, sufficient SF Replacements are automatically granted so as to immediately bring the unit up to a full TEN (10) SFs.
B) If there is ONLY ONE (1) adjacent enemy unit, ONLY TWO THIRDS (2/3) of the SF Replacements which would have been granted under preceding point (A) will actually be granted.
C) If there are ONLY TWO (2) adjacent enemy units, ONLY ONE THIRD (1/3) of the SF Replacements which would have been granted under preceding point (A) will actually be granted.
D) If there are THREE (3) OR MORE adjacent enemy units, NO SF Replacements whatsoever will actually be granted.
Computational Illustration
The following concrete example is intended to illustrate how PGF's engine actually computes "things".
Step 0: An Under-Strength unit sporting 5 SFs requests Replacements. Only one (1) enemy unit is adjacent.
Step 1: PGF's engine computes the provisional SF deficit to be equal to
10 MINUS 5 = 5 SFs
Step 2: Due to the enemy unit adjacency specifics, the engine computes
2 TIMES 5 = 10
as an intermediate step.
Step 3: Due to the enemy unit adjacency specifics, the engine, then, computes
10 DIVIDED BY 3 = 3 1/3
still algebraically speaking.
Step 4: Always confined to performing integer arithmetic, the engine ROUNDS the final result DOWN to three (3) SFs.
Full Chart
Without taking into account forced reductions due to possible PP insufficiency, the following table depicts the number of SF Replacements which are being automatically procured under varying degrees of enemy unit adjacency:
Ground Super-Class Units: Special Cases
Desert Terrain
a1) If the Ground Super-Class Unit has AT MOST SEVEN (7) SFs while AT MOST TWO (2) enemy units are adjacent and PP availability permitting, JUST ONE (1) SF will be granted.
a2) If the Ground Super-Class Unit has EIGHT (8) SFs while AT MOST ONE (1) enemy units are adjacent and PP availability permitting, JUST ONE (1) SF will be granted.
a3) All other rules pertinent to Ground Super-Class Units receiving SF Replacements or being Over-Strengthened still apply.
Structure Class Units
b1) Unless such a unit occupies a Non-Naval City hex, NO SF Replacements of any kind will actually be granted.
b2) All other rules pertinent to Ground Super-Class Units receiving SF Replacements or being Over-Strengthened still apply.
Naval Super-Class Units
Naval Super-Class Units may receive SF Replacements or be Over-Strengthened ONLY in Port / Port Facilities / Embarkation City hexes.
Without taking into account forced reductions due to possible PP insufficiency, the following table depicts the number of SF Replacements which are being automatically procured under varying degrees of enemy unit adjacency:
By exception, Naval Transport Class units are subject to the Full Chart (encountered earlier under this post) applicable to Ground / Air Super-Class units.
=======================================
Absolute Prerequisite
Units: Replacements & Over-Strengthening
viewtopic.php?f=100&t=531#p9874
Ground & Air Super-Class Units
Algebraic Rules
Upon proactive request and Prestige Point (PP) availability permitting, the maximum number of Strength Factor (SF) Replacements situationally allowable is always automatically granted to a unit.
A) If there are NO adjacent enemy units, sufficient SF Replacements are automatically granted so as to immediately bring the unit up to a full TEN (10) SFs.
B) If there is ONLY ONE (1) adjacent enemy unit, ONLY TWO THIRDS (2/3) of the SF Replacements which would have been granted under preceding point (A) will actually be granted.
C) If there are ONLY TWO (2) adjacent enemy units, ONLY ONE THIRD (1/3) of the SF Replacements which would have been granted under preceding point (A) will actually be granted.
D) If there are THREE (3) OR MORE adjacent enemy units, NO SF Replacements whatsoever will actually be granted.
Computational Illustration
The following concrete example is intended to illustrate how PGF's engine actually computes "things".
Step 0: An Under-Strength unit sporting 5 SFs requests Replacements. Only one (1) enemy unit is adjacent.
Step 1: PGF's engine computes the provisional SF deficit to be equal to
10 MINUS 5 = 5 SFs
Step 2: Due to the enemy unit adjacency specifics, the engine computes
2 TIMES 5 = 10
as an intermediate step.
Step 3: Due to the enemy unit adjacency specifics, the engine, then, computes
10 DIVIDED BY 3 = 3 1/3
still algebraically speaking.
Step 4: Always confined to performing integer arithmetic, the engine ROUNDS the final result DOWN to three (3) SFs.
Full Chart
Without taking into account forced reductions due to possible PP insufficiency, the following table depicts the number of SF Replacements which are being automatically procured under varying degrees of enemy unit adjacency:
Code: Select all
Unit Number of Adjacent Maximally
Current SFs Enemy Units Procurable SFs
1 0 9
1 1 6
1 2 3
1 3+ 0
2 0 8
2 1 5
2 2 2
2 3+ 0
3 0 7
3 1 4
3 2 2
3 3+ 0
4 0 6
4 1 4
4 2 2
4 3+ 0
5 0 5
5 1 3
5 2 1
5 3+ 0
6 0 4
6 1 2
6 2 1
6 3+ 0
7 0 3
7 1 2
7 2 1
7 3+ 0
8 0 2
8 1 1
8 2 0
8 3+ 0
9 0 1
9 1 0
9 2 0
9 3+ 0Desert Terrain
a1) If the Ground Super-Class Unit has AT MOST SEVEN (7) SFs while AT MOST TWO (2) enemy units are adjacent and PP availability permitting, JUST ONE (1) SF will be granted.
a2) If the Ground Super-Class Unit has EIGHT (8) SFs while AT MOST ONE (1) enemy units are adjacent and PP availability permitting, JUST ONE (1) SF will be granted.
a3) All other rules pertinent to Ground Super-Class Units receiving SF Replacements or being Over-Strengthened still apply.
Structure Class Units
b1) Unless such a unit occupies a Non-Naval City hex, NO SF Replacements of any kind will actually be granted.
b2) All other rules pertinent to Ground Super-Class Units receiving SF Replacements or being Over-Strengthened still apply.
Naval Super-Class Units
Naval Super-Class Units may receive SF Replacements or be Over-Strengthened ONLY in Port / Port Facilities / Embarkation City hexes.
Without taking into account forced reductions due to possible PP insufficiency, the following table depicts the number of SF Replacements which are being automatically procured under varying degrees of enemy unit adjacency:
Code: Select all
Unit Number of Adjacent Maximally
Class Enemy Units Procurable SFs
Submarine 0 2
Destroyer 0 2
Capital Ship 0 1
Aircraft Carrier 0 1
Submarine 1 1
Destroyer 1 1
Capital Ship 1 0
Aircraft Carrier 1 0
Submarine 2+ 0
Destroyer 2+ 0
Capital Ship 2+ 0
Aircraft Carrier 2+ 0
Last edited by HexCode on 2022-10-14 08:07, Friday, edited 6 times in total.
GETTING RID OF ORGANIC TRANSPORT
GETTING RID OF ORGANIC TRANSPORT
==================================
For most practical purposes, PGF treats units having Organic Transport (OT) as virtually inseparable. Still, what if one wants to get rid of a unit's OT in-game ?
Aside from boarding units onto Air Transports, why would anyone want to do such a thing ? Well, there could be custom scenarios where important terrain is inhospitable to Organic Transports; especially when the ground turns muddy...
Possibility #1
If the unit is situationally air-transportable, one may embark it, thereby abandoning its OT.
Possibility #2
The Unit Upgrade Pop-up Screen gets activated. Some upgrade choice other than the current one is selected therein. All OT choices are deselected now. One clicks on the original unit icon on the screen and presses the "UPGRADE" button. The OT is now gone ! The preceding "trick" does not cost a single Prestige Point. Moreover, the just "nominally" upgraded unit can still subsequently "act" in this half-turn !
Not Always Possible
In instances where the unit is neither situationally air-transportable nor upgradable in-game, resorting to rather "esoteric" measures may be the only way to go...
==================================
For most practical purposes, PGF treats units having Organic Transport (OT) as virtually inseparable. Still, what if one wants to get rid of a unit's OT in-game ?
Aside from boarding units onto Air Transports, why would anyone want to do such a thing ? Well, there could be custom scenarios where important terrain is inhospitable to Organic Transports; especially when the ground turns muddy...
Possibility #1
If the unit is situationally air-transportable, one may embark it, thereby abandoning its OT.
Possibility #2
The Unit Upgrade Pop-up Screen gets activated. Some upgrade choice other than the current one is selected therein. All OT choices are deselected now. One clicks on the original unit icon on the screen and presses the "UPGRADE" button. The OT is now gone ! The preceding "trick" does not cost a single Prestige Point. Moreover, the just "nominally" upgraded unit can still subsequently "act" in this half-turn !
Not Always Possible
In instances where the unit is neither situationally air-transportable nor upgradable in-game, resorting to rather "esoteric" measures may be the only way to go...
Last edited by HexCode on 2021-10-12 03:15, Tuesday, edited 1 time in total.
SUBMARINE CLASS UNIT DETECTION
SUBMARINE CLASS UNIT DETECTION
===============================
SSI Says...
From SSI's PG1-DOS manual:
Subroutine Identification
Important: PGF engine's subroutine controlling Submarine Class Unit Detection (SCUD) has NOT yet been identified. To this effect, this post's contents should be viewed as provisional.
Key Detection Observations
A) Enemy Submarine Class Units (ESCUs) which, while stationary, find themselves adjacent to or directly under some friendly unit are immediately and automatically spotted.
B) Automatic detection due to adjacency does NOT apply to friendly Ports / City / Airfield hexes. In fact, an ESCU may be IN a friendly port without it being automatically detected ! It may or not be detected...
C) PGF's engine does NOT continually revisit the ESCU Detection issue throughout the duration of a friendly half-turn. Rather, it makes the requisite probabilistic determination only once at the half-turn's very start. From that point onward, it does not matter an iota whether the ESCU is overflown 1,000 times by friendly Air Super-Class units or comes within the Spotting Range (SR) of a 1,000 friendly Naval Super-Class units...
D) Plenty of experimental evidence suggests that the number of friendly units which could potentially detect an ESCU on the basis of their SRs does matter in the sense that, the more such units in the relevant vicinity, the higher the chance of detection.
E) The same friendly unit can detect more than one ESCUs simultaneously.
F) Friendly Ground Super-Class units can detect ESCUs located inside their SRs !
Proposed Probabilistic Mechanism
Caveats: It is assumed that Unit Strength, Class, Experience, Degree of Relative Proximity to the ESCU and Weather Conditions do NOT affect Detection chances...
Friendly Entities = Friendly Units, Ports, Cities and Airfields.
Let P represent the probability of Detection as it applies to just ONE (1) friendly entity which could potentially spot an ESCU on the basis of its SR. Assuming stochastic (i.e., probabilistic) independence:
With just ONE (1) friendly entity in the relevant vicinity, the probability of the ESCU NOT being detected is (1-P). Consequently, the complementary probability of Detection is [1 - (1-P)] = P
With just TWO (2) friendly entities in the relevant vicinity, the joint probability of the ESCU NOT being detected is [(1-P)*(1-P)]. Consequently, the complementary probability of Detection is {1 - [(1-P)*(1-P)]} = P*(2-P)
And so on algebraically...
Attempted Empirical Verification
Assuming that the chance of Detection (DET) of an ESCU by just one friendly entity on the basis of its Spotting Range (SR) is, indeed, 50% (i.e., P=0.50) and also assuming stochastic (i.e., probabilistic) independence, the following table presents the chance of Detection on the basis of the number of friendly entities in the relevant vicinity of an ESCU:
A number of trials were carried out using the very same situation, every time. In order to safeguard against biases often inherent in an engine serially utilizing the same pseudo-randomization "seed", PGF was closed (i.e., "exit", not just "quit") at the end of each trial and was started again to move on to the next trial. In this manner, every trial was conducted under a different pseudo-randomization "seed".
Friendly Units Only
JUST ONE (1) FRIENDLY UNIT:
After the 80th trial, The "cumulative story" certainly tempts one to conclude that P=0.50 is, indeed, the "true" probability.
JUST TWO (2) FRIENDLY UNITS:
If one were to stop at the 80th trial, the "cumulative story" would certainly tempt him to conclude that P=0.75 is, indeed, the "true" probability. Unfortunately, the rest of the "cumulative story" isn't perfectly reassuring...
Friendly Ports / Cities / Airfields Only
JUST AN AIRFIELD ADJACENCY:
The "cumulative story" certainly tempts one to conclude that P=0.50 is, indeed, the "true" probability.
JUST ONE AIRFIELD AND ONE PORT ADJACENCY:
The "cumulative story's" ups and downs notwithstanding, one would be tempted to conclude that P=0.75 is, indeed, the "true" probability.
Diverse Friendly Entity Mix
JUST ONE FIGHTER CLASS UNIT AND ONE PORT ADJACENCY:
Although not "picture perfect", the "cumulative story" may serve as an "anecdotal" indication that P=0.75 being the "true" probability is plausible.
A Necessary Warning
Credibly conducted statistical analyses testing for P = 0.50 require many more than 100 trials.
===============================
SSI Says...
From SSI's PG1-DOS manual:
Well, that is "something". When it comes to verification guidance, "something" is usually better than "nothing"...Enemy units within your unit's range are automatically spotted except for enemy U-boats, which you have a 50% chance of spotting unless they are adjacent to one of your units.
Subroutine Identification
Important: PGF engine's subroutine controlling Submarine Class Unit Detection (SCUD) has NOT yet been identified. To this effect, this post's contents should be viewed as provisional.
Key Detection Observations
A) Enemy Submarine Class Units (ESCUs) which, while stationary, find themselves adjacent to or directly under some friendly unit are immediately and automatically spotted.
B) Automatic detection due to adjacency does NOT apply to friendly Ports / City / Airfield hexes. In fact, an ESCU may be IN a friendly port without it being automatically detected ! It may or not be detected...
C) PGF's engine does NOT continually revisit the ESCU Detection issue throughout the duration of a friendly half-turn. Rather, it makes the requisite probabilistic determination only once at the half-turn's very start. From that point onward, it does not matter an iota whether the ESCU is overflown 1,000 times by friendly Air Super-Class units or comes within the Spotting Range (SR) of a 1,000 friendly Naval Super-Class units...
D) Plenty of experimental evidence suggests that the number of friendly units which could potentially detect an ESCU on the basis of their SRs does matter in the sense that, the more such units in the relevant vicinity, the higher the chance of detection.
E) The same friendly unit can detect more than one ESCUs simultaneously.
F) Friendly Ground Super-Class units can detect ESCUs located inside their SRs !
Proposed Probabilistic Mechanism
Caveats: It is assumed that Unit Strength, Class, Experience, Degree of Relative Proximity to the ESCU and Weather Conditions do NOT affect Detection chances...
Friendly Entities = Friendly Units, Ports, Cities and Airfields.
Let P represent the probability of Detection as it applies to just ONE (1) friendly entity which could potentially spot an ESCU on the basis of its SR. Assuming stochastic (i.e., probabilistic) independence:
With just ONE (1) friendly entity in the relevant vicinity, the probability of the ESCU NOT being detected is (1-P). Consequently, the complementary probability of Detection is [1 - (1-P)] = P
With just TWO (2) friendly entities in the relevant vicinity, the joint probability of the ESCU NOT being detected is [(1-P)*(1-P)]. Consequently, the complementary probability of Detection is {1 - [(1-P)*(1-P)]} = P*(2-P)
And so on algebraically...
Attempted Empirical Verification
Assuming that the chance of Detection (DET) of an ESCU by just one friendly entity on the basis of its Spotting Range (SR) is, indeed, 50% (i.e., P=0.50) and also assuming stochastic (i.e., probabilistic) independence, the following table presents the chance of Detection on the basis of the number of friendly entities in the relevant vicinity of an ESCU:
Code: Select all
Friendly Detection
Entities Chance (%)
1 50.00
2 75.00
3 87.50
4 93.75
etcFriendly Units Only
JUST ONE (1) FRIENDLY UNIT:
Code: Select all
TRIAL DET ? DETs DET CHANCE
ID
01 1 01 100.00
02 0 01 50.00
03 0 01 33.33
04 1 02 50.00
05 1 03 60.00
06 1 04 66.67
07 0 04 57.14
08 1 05 62.50
09 1 06 66.67
10 0 06 60.00
11 0 06 54.55
12 1 07 58.33
13 0 07 53.85
14 0 07 50.00
15 0 07 46.67
16 0 07 43.75
17 0 07 41.18
18 0 07 38.89
19 1 08 42.11
20 0 08 40.00
21 1 09 42.86
22 0 09 40.91
23 0 09 39.13
24 1 10 41.67
25 0 10 40.00
26 1 11 42.31
27 0 11 40.74
28 1 12 42.86
29 0 12 41.38
30 0 12 40.00
31 1 13 41.94
32 0 13 40.63
33 1 14 42.42
34 1 15 44.12
35 0 15 42.86
36 0 15 41.67
37 0 15 40.54
38 0 15 39.47
39 1 16 41.03
40 1 17 42.50
41 1 18 43.90
42 1 19 45.24
43 0 19 44.19
44 0 19 43.18
45 1 20 44.44
46 0 20 43.48
47 1 21 44.68
48 0 21 43.75
49 0 21 42.86
50 0 21 42.00
51 1 22 43.14
52 0 22 42.31
53 1 23 43.40
54 0 23 42.59
55 1 24 43.64
56 1 25 44.64
57 1 26 45.61
58 0 26 44.83
59 0 26 44.07
60 1 27 45.00
61 1 28 45.90
62 1 29 46.77
63 0 29 46.03
64 0 29 45.31
65 0 29 44.62
66 1 30 45.45
67 1 31 46.27
68 0 31 45.59
69 0 31 44.93
70 1 32 45.71
71 0 32 45.07
72 1 33 45.83
73 1 34 46.58
74 0 34 45.95
75 1 35 46.67
76 1 36 47.37
77 1 37 48.05
78 0 37 47.44
79 1 38 48.10
80 1 39 48.75
81 1 40 49.38
82 1 41 50.00
83 1 42 50.60
84 0 42 50.00
85 1 43 50.59
86 1 44 51.16
87 1 45 51.72
88 0 45 51.14
89 1 46 51.69
90 0 46 51.11
91 0 46 50.55
92 0 46 50.00
93 1 47 50.54
94 1 48 51.06
95 0 48 50.53
96 0 48 50.00
97 0 48 49.48
98 0 48 48.98
99 1 49 49.49
100 1 50 50.00JUST TWO (2) FRIENDLY UNITS:
Code: Select all
TRIAL DET ? DETs DET CHANCE
ID
01 1 01 100.00
02 1 02 100.00
03 1 03 100.00
04 0 03 75.00
05 1 04 80.00
06 1 05 83.33
07 1 06 85.71
08 1 07 87.50
09 1 08 88.89
10 1 09 90.00
11 1 10 90.91
12 1 11 91.67
13 1 12 92.31
14 0 12 85.71
15 1 13 86.67
16 1 14 87.50
17 1 15 88.24
18 1 16 88.89
19 1 17 89.47
20 1 18 90.00
21 0 18 85.71
22 1 19 86.36
23 1 20 86.96
24 0 20 83.33
25 0 20 80.00
26 1 21 80.77
27 1 22 81.48
28 0 22 78.57
29 1 23 79.31
30 1 24 80.00
31 1 25 80.65
32 1 26 81.25
33 0 26 78.79
34 1 27 79.41
35 0 27 77.14
36 1 28 77.78
37 1 29 78.38
38 1 30 78.95
39 1 31 79.49
40 1 32 80.00
41 1 33 80.49
42 1 34 80.95
43 1 35 81.40
44 0 35 79.55
45 1 36 80.00
46 0 36 78.26
47 0 36 76.60
48 0 36 75.00
49 1 37 75.51
50 0 37 74.00
51 1 38 74.51
52 1 39 75.00
53 1 40 75.47
54 0 40 74.07
55 1 41 74.55
56 1 42 75.00
57 1 43 75.44
58 1 44 75.86
59 1 45 76.27
60 1 46 76.67
61 1 47 77.05
62 1 48 77.42
63 0 48 76.19
64 1 49 76.56
65 1 50 76.92
66 1 51 77.27
67 0 51 76.12
68 1 52 76.47
69 1 53 76.81
70 1 54 77.14
71 0 54 76.06
72 1 55 76.39
73 0 55 75.34
74 0 55 74.32
75 1 56 74.67
76 0 56 73.68
77 1 57 74.03
78 1 58 74.36
79 0 58 73.42
80 1 59 73.75
81 1 60 74.07
82 1 61 74.39
83 0 61 73.49
84 0 61 72.62
85 0 61 71.76
86 1 62 72.09
87 0 62 71.26
88 1 63 71.59
89 1 64 71.91
90 1 65 72.22
91 0 65 71.43
92 1 66 71.74
93 0 66 70.97
94 1 67 71.28
95 1 68 71.58
96 0 68 70.83
97 0 68 70.10
98 1 69 70.41
99 0 69 69.70
100 0 69 69.00Friendly Ports / Cities / Airfields Only
JUST AN AIRFIELD ADJACENCY:
Code: Select all
TRIAL DET ? DETs DET CHANCE
ID
01 0 00 00.00
02 0 00 00.00
03 1 01 33.33
04 1 02 50.00
05 0 02 40.00
06 1 03 50.00
07 0 03 42.86
08 1 04 50.00
09 0 04 44.44
10 0 04 40.00
11 0 04 36.36
12 1 05 41.67
13 0 05 38.46
14 1 06 42.86
15 1 07 46.67
16 0 07 43.75
17 1 08 47.06
18 1 09 50.00
19 1 10 52.63
20 0 10 50.00
21 1 11 52.38
22 0 11 50.00
23 0 11 47.83
24 1 12 50.00
25 1 13 52.00
26 1 14 53.85
27 1 15 55.56
28 0 15 53.57
29 0 15 51.72
30 1 16 53.33
31 0 16 51.61
32 0 16 50.00
33 1 17 51.52
34 0 17 50.00
35 1 18 51.43
36 0 18 50.00
37 1 19 51.35
38 0 19 50.00
39 1 20 51.28
40 1 21 52.50
41 1 22 53.66
42 1 23 54.76
43 1 24 55.81
44 1 25 56.82
45 1 26 57.78
46 1 27 58.70
47 0 27 57.45
48 0 27 56.25
49 1 28 57.14
50 1 29 58.00
51 0 29 56.86
52 0 29 55.77
53 1 30 56.60
54 0 30 55.56
55 1 31 56.36
56 0 31 55.36
57 0 31 54.39
58 0 31 53.45
59 0 31 52.54
60 1 32 53.33
61 1 33 54.10
62 1 34 54.84
63 0 34 53.97
64 1 35 54.69
65 1 36 55.38
66 0 36 54.55
67 1 37 55.22
68 0 37 54.41
69 0 37 53.62
70 0 37 52.86
71 0 37 52.11
72 1 38 52.78
73 0 38 52.05
74 1 39 52.70
75 1 40 53.33
76 0 40 52.63
77 1 41 53.25
78 1 42 53.85
79 1 43 54.43
80 0 43 53.75
81 1 44 54.32
82 0 44 53.66
83 1 45 54.22
84 0 45 53.57
85 1 46 54.12
86 0 46 53.49
87 0 46 52.87
88 1 47 53.41
89 1 48 53.93
90 0 48 53.33
91 0 48 52.75
92 0 48 52.17
93 0 48 51.61
94 1 49 52.13
95 1 50 52.63
96 0 50 52.08
97 0 50 51.55
98 1 51 52.04
99 0 51 51.52
100 0 51 51.00JUST ONE AIRFIELD AND ONE PORT ADJACENCY:
Code: Select all
TRIAL DET ? DETs DET CHANCE
ID
01 1 01 100.00
02 1 02 100.00
03 1 03 100.00
04 1 04 100.00
05 0 04 80.00
06 1 05 83.33
07 1 06 85.71
08 1 07 87.50
09 1 08 88.89
10 1 09 90.00
11 0 09 81.82
12 0 09 75.00
13 1 10 76.92
14 1 11 78.57
15 1 12 80.00
16 1 13 81.25
17 0 13 76.47
18 1 14 77.78
19 0 14 73.68
20 1 15 75.00
21 1 16 76.19
22 1 17 77.27
23 0 17 73.91
24 0 17 70.83
25 1 18 72.00
26 1 19 73.08
27 1 20 74.07
28 0 20 71.43
29 1 21 72.41
30 1 22 73.33
31 0 22 70.97
32 1 23 71.88
33 1 24 72.73
34 0 24 70.59
35 1 25 71.43
36 1 26 72.22
37 0 26 70.27
38 1 27 71.05
39 1 28 71.79
40 0 28 70.00
41 1 29 70.73
42 1 30 71.43
43 1 31 72.09
44 0 31 70.45
45 1 32 71.11
46 1 33 71.74
47 1 34 72.34
48 0 34 70.83
49 1 35 71.43
50 0 35 70.00
51 0 35 68.63
52 1 36 69.23
53 1 37 69.81
54 0 37 68.52
55 1 38 69.09
56 0 38 67.86
57 0 38 66.67
58 1 39 67.24
59 1 40 67.80
60 1 41 68.33
61 1 42 68.85
62 0 42 67.74
63 1 43 68.25
64 0 43 67.19
65 1 44 67.69
66 0 44 66.67
67 1 45 67.16
68 1 46 67.65
69 1 47 68.12
70 1 48 68.57
71 1 49 69.01
72 1 50 69.44
73 1 51 69.86
74 1 52 70.27
75 1 53 70.67
76 1 54 71.05
77 0 54 70.13
78 1 55 70.51
79 1 56 70.89
80 1 57 71.25
81 1 58 71.60
82 1 59 71.95
83 1 60 72.29
84 1 61 72.62
85 1 62 72.94
86 1 63 73.26
87 1 64 73.56
88 0 64 72.73
89 1 65 73.03
90 1 66 73.33
91 1 67 73.63
92 0 67 72.83
93 1 68 73.12
94 1 69 73.40
95 1 70 73.68
96 1 71 73.96
97 0 71 73.20
98 1 72 73.47
99 0 72 72.73
100 1 73 73.00Diverse Friendly Entity Mix
JUST ONE FIGHTER CLASS UNIT AND ONE PORT ADJACENCY:
Code: Select all
TRIAL DET ? DETs DET CHANCE
ID
01 1 01 100.00
02 1 02 100.00
03 1 03 100.00
04 1 04 100.00
05 1 05 100.00
06 1 06 100.00
07 0 06 85.71
08 1 07 87.50
09 0 07 77.78
10 1 08 80.00
11 1 09 81.82
12 1 10 83.33
13 1 11 84.62
14 1 12 85.71
15 1 13 86.67
16 1 14 87.50
17 1 15 88.24
18 1 16 88.89
19 0 16 84.21
20 1 17 85.00
21 0 17 80.95
22 1 18 81.82
23 1 19 82.61
24 1 20 83.33
25 1 21 84.00
26 1 22 84.62
27 1 23 85.19
28 1 24 85.71
29 0 24 82.76
30 1 25 83.33
31 1 26 83.87
32 0 26 81.25
33 1 27 81.82
34 1 28 82.35
35 1 29 82.86
36 1 30 83.33
37 0 30 81.08
38 1 31 81.58
39 1 32 82.05
40 1 33 82.50
41 1 34 82.93
42 0 34 80.95
43 1 35 81.40
44 0 35 79.55
45 0 35 77.78
46 0 35 76.09
47 1 36 76.60
48 1 37 77.08
49 1 38 77.55
50 1 39 78.00
51 1 40 78.43
52 1 41 78.85
53 1 42 79.25
54 1 43 79.63
55 1 44 80.00
56 1 45 80.36
57 1 46 80.70
58 1 47 81.03
59 1 48 81.36
60 1 49 81.67
61 1 50 81.97
62 1 51 82.26
63 1 52 82.54
64 1 53 82.81
65 1 54 83.08
66 1 55 83.33
67 1 56 83.58
68 1 57 83.82
69 1 58 84.06
70 1 59 84.29
71 1 60 84.51
72 1 61 84.72
73 1 62 84.93
74 1 63 85.14
75 1 64 85.33
76 0 64 84.21
77 1 65 84.42
78 1 66 84.62
79 1 67 84.81
80 0 67 83.75
81 0 67 82.72
82 1 68 82.93
83 0 68 81.93
84 1 69 82.14
85 1 70 82.35
86 1 71 82.56
87 1 72 82.76
88 0 72 81.82
89 0 72 80.90
90 1 73 81.11
91 1 74 81.32
92 1 75 81.52
93 0 75 80.65
94 1 76 80.85
95 1 77 81.05
96 1 78 81.25
97 1 79 81.44
98 0 79 80.61
99 1 80 80.81
100 0 80 80.00A Necessary Warning
Credibly conducted statistical analyses testing for P = 0.50 require many more than 100 trials.
NAVAL TRANSPORT: DETAILS
NAVAL TRANSPORT: DETAILS
=========================
Absolute Prerequisite
Naval Transport: Units Embarking & Disembarking
viewtopic.php?f=100&t=531#p9364
Capability
Naval Transport Units (NTUs) automatically become available / visible when naval-transportable Ground units embark onto them at a Port, Port Facility or Embarkation City; they are NOT purchased. Similarly, NTUs automatically disappear from sight whenever the transported units disembark onto some non-prohibited Ground terrain. A Boolean setting coded in file EQUIPMENT.PGEQP renders (or not) a unit naval-transportable.
Naval Transport (NT) of naval-transportable Ground units is a temporary state of affairs made possible by the presence of available (i.e., free) Naval Transport Points (NTPs) out of an abstract pool of such points the size of which is coded into a typical scenario's file *.PGSCN.
Embarkation
A) To embark, a Ground unit must already be situated on a Port, Port Facility or Embarkation City hex at the start of its movement phase. Contrary to a certain general impression, the ownership status of the hex the unit occupies is immaterial (i.e, neutralized or enemy owned hexes are ok !). Embarkation is NOT allowed immediately following a ground unit's movement phase.
B) There are NO enemy unit adjacency, weather, fuel or ammo availability restrictions to embarkation whatsoever. Obviously, though, when it comes to an Embarkation City, at least one adjacent, unoccupied sea hex must be available for the unit to meaningfully embark onto.
C) Upon embarkation, organic (ground) transport units always accompany the Ground units they are organically attached to.
D) Embarkation strictly preserves the transported units' ammo and experience stats.
E) When a Ground unit embarks onto a NT, ONE (1) NTP is immediately subtracted from the pool of available (free) scenario NTPs. If no such NTPs are available (free), embarkation is NOT allowed.
F) Upon embarkation, NTUs are free to commence their sea movement phase immediately.
En Route
1) En Route, NTUs are NOT subject to any weather or fuel availability restrictions whatsoever.
2) With a couple of notable exceptions, a transported unit's ammo stat remains unchanged while en route. However, should its NTU remain stationary in a hex during one entire half-turn, ammo resupply DOES take place as per the normal resupply rules applicable to ground units !
3) With one notable exception, a transported unit's experience stat remains unchanged while en route. However, if its NTU gets attacked en route, the transported unit's experience stat DOES permanently change.
4) Transported units are almost totally subject to their NTUs' listed specifications. To this effect, they share the fate of their NTUs in identical manner and proportion if attacked while en route.
It is worth noting that, while en route and under enemy attack, a NTU utilizes its transported unit's experience stat ! To boot, under enemy air attack, to the extent that the NTU sports a positive Air Attack value, it shoots back at the attacking enemy air unit by expending its transported unit's ammo ! Most importantly, any losses in a NTU's strength automatically translate into losses of its transported unit's strength, one for one. Such losses can NEVER be replaced while en route.
5) If a NTU gets eliminated due to enemy attacks en route, the transported unit gets eliminated too. Most importantly, the NT pool point gets lost for the duration of the scenario (it is NOT added back to the abstract pool) ! This is similar to losing a unit that cannot be purchased during a scenario...
Disembarkation
a) To disembark onto some non-prohibited Ground hex, a transported ground unit must already be located on an adjacent hex at the start of its NTUs movement phase. Exceptionally, if the NTU is already on a Port City / Facilities hex, the transported unit is allowed to disembark onto that very same hex as well. Disembarkation is NOT allowed immediately following its NTU's movement phase.
The following terrain types (i.e., Underlying Terrain Representations) are prohibited:
Completely unenterable (aka "Neutral") hexes are prohibited as well.
b) There are NO unit adjacency, weather, fuel or ammo availability restrictions to disembarkation whatsoever.
c) Disembarking transported units onto Ground hexes strictly preserves their hitherto strength, ammo availability and experience stats.
d) When a transported unit lands onto some Ground hex, ONE (1) NTP is immediately added back to the pool of available scenario NTPs, thus becoming available (free) again for possible future in-game use.
e) Disembarking units onto neutralized or enemy owned hexes can trigger immediate ownership changes as per the normal unit class rules.
f) Disembarked units CANNOT move any farther, engage in combat or receive
replacements immediately following disembarkation.
=========================
Absolute Prerequisite
Naval Transport: Units Embarking & Disembarking
viewtopic.php?f=100&t=531#p9364
Capability
Naval Transport Units (NTUs) automatically become available / visible when naval-transportable Ground units embark onto them at a Port, Port Facility or Embarkation City; they are NOT purchased. Similarly, NTUs automatically disappear from sight whenever the transported units disembark onto some non-prohibited Ground terrain. A Boolean setting coded in file EQUIPMENT.PGEQP renders (or not) a unit naval-transportable.
Naval Transport (NT) of naval-transportable Ground units is a temporary state of affairs made possible by the presence of available (i.e., free) Naval Transport Points (NTPs) out of an abstract pool of such points the size of which is coded into a typical scenario's file *.PGSCN.
Embarkation
A) To embark, a Ground unit must already be situated on a Port, Port Facility or Embarkation City hex at the start of its movement phase. Contrary to a certain general impression, the ownership status of the hex the unit occupies is immaterial (i.e, neutralized or enemy owned hexes are ok !). Embarkation is NOT allowed immediately following a ground unit's movement phase.
B) There are NO enemy unit adjacency, weather, fuel or ammo availability restrictions to embarkation whatsoever. Obviously, though, when it comes to an Embarkation City, at least one adjacent, unoccupied sea hex must be available for the unit to meaningfully embark onto.
C) Upon embarkation, organic (ground) transport units always accompany the Ground units they are organically attached to.
D) Embarkation strictly preserves the transported units' ammo and experience stats.
E) When a Ground unit embarks onto a NT, ONE (1) NTP is immediately subtracted from the pool of available (free) scenario NTPs. If no such NTPs are available (free), embarkation is NOT allowed.
F) Upon embarkation, NTUs are free to commence their sea movement phase immediately.
En Route
1) En Route, NTUs are NOT subject to any weather or fuel availability restrictions whatsoever.
2) With a couple of notable exceptions, a transported unit's ammo stat remains unchanged while en route. However, should its NTU remain stationary in a hex during one entire half-turn, ammo resupply DOES take place as per the normal resupply rules applicable to ground units !
3) With one notable exception, a transported unit's experience stat remains unchanged while en route. However, if its NTU gets attacked en route, the transported unit's experience stat DOES permanently change.
4) Transported units are almost totally subject to their NTUs' listed specifications. To this effect, they share the fate of their NTUs in identical manner and proportion if attacked while en route.
It is worth noting that, while en route and under enemy attack, a NTU utilizes its transported unit's experience stat ! To boot, under enemy air attack, to the extent that the NTU sports a positive Air Attack value, it shoots back at the attacking enemy air unit by expending its transported unit's ammo ! Most importantly, any losses in a NTU's strength automatically translate into losses of its transported unit's strength, one for one. Such losses can NEVER be replaced while en route.
5) If a NTU gets eliminated due to enemy attacks en route, the transported unit gets eliminated too. Most importantly, the NT pool point gets lost for the duration of the scenario (it is NOT added back to the abstract pool) ! This is similar to losing a unit that cannot be purchased during a scenario...
Disembarkation
a) To disembark onto some non-prohibited Ground hex, a transported ground unit must already be located on an adjacent hex at the start of its NTUs movement phase. Exceptionally, if the NTU is already on a Port City / Facilities hex, the transported unit is allowed to disembark onto that very same hex as well. Disembarkation is NOT allowed immediately following its NTU's movement phase.
The following terrain types (i.e., Underlying Terrain Representations) are prohibited:
Code: Select all
Terrain UTR
Types Designations
Bodies of Water 04h, 05h, 06h, 07h
Rough Desert 22h
Escarpment 23h, 24hb) There are NO unit adjacency, weather, fuel or ammo availability restrictions to disembarkation whatsoever.
c) Disembarking transported units onto Ground hexes strictly preserves their hitherto strength, ammo availability and experience stats.
d) When a transported unit lands onto some Ground hex, ONE (1) NTP is immediately added back to the pool of available scenario NTPs, thus becoming available (free) again for possible future in-game use.
e) Disembarking units onto neutralized or enemy owned hexes can trigger immediate ownership changes as per the normal unit class rules.
f) Disembarked units CANNOT move any farther, engage in combat or receive
replacements immediately following disembarkation.
Last edited by HexCode on 2021-10-20 05:58, Wednesday, edited 4 times in total.
UNIT AUTO-UPGRADES
UNIT AUTO-UPGRADES
====================
Absolute Prerequisite
Unit Upgrade & Purchase Pop-up Screens
viewtopic.php?f=100&t=531#p9210
Enemy Presence Adjacency
A Land unit may be upgraded in-game while situated on a City / Port hex provided no enemy unit is adjacent to or directly over the hex / unit.
How to Auto-Upgrade
A friendly unit gets Auto-Upgraded as follows:
One selects the friendly unit he wishes to upgrade by clicking on it. He then presses the second rightmost button in Row 2 depicted in the Scenario Panel (the button depicts two armored vehicle silhouettes of different sizes). As a result, the Unit Upgrade Pop-up Screen gets activated. All one has to do is press the "UPGRADE" button, provided its pseudo-LED color is GREEN (denoting action feasibility).
Auto-Upgrade Consequences
A) Whenever feasible, a unit Auto-Upgrade does NOT cost a single Prestige Point.
B) Such a "nominally" upgraded unit can still subsequently "act" in this half-turn !
C) An Auto-Upgraded unit is automatically resupplied on the spot to the max !
Auto-Upgrade Infeasibility
A greyed out "UPGRADE" button denotes action infeasibility. The following situations render unit Auto-Upgrades infeasible:
1) The selected unit does NOT appear at all as a purchasable option within the Unit Purchase Pop-up Screen (e.g., "prototype" Unit Type not widely available at first).
2) Negative Accumulated Prestige.
The reader may wish to consult
Negative Prestige Points
viewtopic.php?f=100&t=540#p9993
to familiarize himself with this rather "advanced", versatile functionality.
A Couple of Useful Auto-Upgrade Types
a ==>
Getting Rid Of Organic Transport
viewtopic.php?f=100&t=543#p9990
Suppose, for instance, one wants to deploy (in Campaign Play Mode) an air transportable unit having organic transport in a boarded state. To do so, he has to get rid of the unit's organic transport prior to the unit's actual deployment. He does so as per the contents of the immediately preceding, linked post.
b ==>
Point (C) above points to essentially en passant Unit Resupply. To this effect, unit Auto-Upgrades can be especially useful in instances where fast moving Land units need to travel significant distances in a hurry...
====================
Absolute Prerequisite
Unit Upgrade & Purchase Pop-up Screens
viewtopic.php?f=100&t=531#p9210
Enemy Presence Adjacency
A Land unit may be upgraded in-game while situated on a City / Port hex provided no enemy unit is adjacent to or directly over the hex / unit.
How to Auto-Upgrade
A friendly unit gets Auto-Upgraded as follows:
One selects the friendly unit he wishes to upgrade by clicking on it. He then presses the second rightmost button in Row 2 depicted in the Scenario Panel (the button depicts two armored vehicle silhouettes of different sizes). As a result, the Unit Upgrade Pop-up Screen gets activated. All one has to do is press the "UPGRADE" button, provided its pseudo-LED color is GREEN (denoting action feasibility).
Auto-Upgrade Consequences
A) Whenever feasible, a unit Auto-Upgrade does NOT cost a single Prestige Point.
B) Such a "nominally" upgraded unit can still subsequently "act" in this half-turn !
C) An Auto-Upgraded unit is automatically resupplied on the spot to the max !
Auto-Upgrade Infeasibility
A greyed out "UPGRADE" button denotes action infeasibility. The following situations render unit Auto-Upgrades infeasible:
1) The selected unit does NOT appear at all as a purchasable option within the Unit Purchase Pop-up Screen (e.g., "prototype" Unit Type not widely available at first).
2) Negative Accumulated Prestige.
The reader may wish to consult
Negative Prestige Points
viewtopic.php?f=100&t=540#p9993
to familiarize himself with this rather "advanced", versatile functionality.
A Couple of Useful Auto-Upgrade Types
a ==>
Getting Rid Of Organic Transport
viewtopic.php?f=100&t=543#p9990
Suppose, for instance, one wants to deploy (in Campaign Play Mode) an air transportable unit having organic transport in a boarded state. To do so, he has to get rid of the unit's organic transport prior to the unit's actual deployment. He does so as per the contents of the immediately preceding, linked post.
b ==>
Point (C) above points to essentially en passant Unit Resupply. To this effect, unit Auto-Upgrades can be especially useful in instances where fast moving Land units need to travel significant distances in a hurry...
Last edited by HexCode on 2021-11-13 06:35, Saturday, edited 1 time in total.
UNIT DEPLOYMENT: BOARDED OR NOT ?
UNIT DEPLOYMENT: BOARDED OR NOT ?
===================================
Absolute Prerequisite
Turns, Weather & Core Unit Deployment
viewtopic.php?f=100&t=531#p9299
Preliminaries
Kindly allow me to quibble with SSI's usage of a couple of... English prepositions.
--- SSI's documentation often makes reference to "such and such surface unit being IN such and such hex". In my opinion, the expression "such and such surface unit being ON such and such hex" is way clearer.
--- SSI's documentation often makes reference to "such and such air unit being ON such and such hex". Once again, I deem the expression "such and such air unit being OVER such and such hex" to be more to the point. Of course, air units situated directly OVER Airfield hexes or friendly Aircraft Carrier Class units could be viewed as being ON such hexes...
Campaigns: Core Unit Deployment
While in Campaign Play Mode, a human player has the option of deploying his Core units within specified Deployment Zones before the first turn of each constituent scenario actually commences.
Placing a unit ONTO or OVER a particular map hex requires that one first clicks the unit's icon in the Undeployed Unit Listing Ribbon Panel and then clicks the desired map hex in the highlighted Deployment Zone. To abort a unit's placement, one right-clicks the hitherto placed unit. This removes it from the map and puts it right back in the Undeployed Unit Listing Ribbon Panel.
Boarded or Not ?
How does one deploy one or more of his Core Units in a Dismounted / Embarked state ?
1) Land units enjoying Organic Transport are always placed ON map hexes in a Dismounted state.
2) Land units (with or without Organic Transport) can be placed ON "Body of Water" (i.e., Coast, Sea, Ocean etc) hexes provided:
a) The Unit Types are naval-transportable; the relevant entries under file EQUIPMENT.PGEQP column entitled "Can Have Sea Transport" need to be coded with the Boolean value ONE (1).
b) There are free Naval Transport Points which would serially and automatically accommodate Unit Deployments in an Embarked state.
3) Land units (with or without Organic Transport) can be placed OVER map hexes provided:
A) The Unit Types are both air-transportable and paradrop-capable; the relevant entries under file EQUIPMENT.PGEQP columns entitled "Can Have Air Transport" and "Can Paradrop" need both to be coded with Boolean values of ONE (1)
B) There are free Air Transport Points which would serially and automatically accommodate Unit Deployments in an Embarked state.
C) Their Organic Transports (if any) need to be gotten rid of prior to the actual unit placements. This is accomplished as per the contents of
Getting Rid Of Organic Transport
viewtopic.php?f=100&t=543#p9990
D) If the Unit Types are naval-transportable as well, as long as there are free Naval Transport Points, attempting to place such units OVER "Body of Water" hexes will result in the units automatically being granted Naval Transports ON the very same designated hex instead !
===================================
Absolute Prerequisite
Turns, Weather & Core Unit Deployment
viewtopic.php?f=100&t=531#p9299
Preliminaries
Kindly allow me to quibble with SSI's usage of a couple of... English prepositions.
--- SSI's documentation often makes reference to "such and such surface unit being IN such and such hex". In my opinion, the expression "such and such surface unit being ON such and such hex" is way clearer.
--- SSI's documentation often makes reference to "such and such air unit being ON such and such hex". Once again, I deem the expression "such and such air unit being OVER such and such hex" to be more to the point. Of course, air units situated directly OVER Airfield hexes or friendly Aircraft Carrier Class units could be viewed as being ON such hexes...
Campaigns: Core Unit Deployment
While in Campaign Play Mode, a human player has the option of deploying his Core units within specified Deployment Zones before the first turn of each constituent scenario actually commences.
Placing a unit ONTO or OVER a particular map hex requires that one first clicks the unit's icon in the Undeployed Unit Listing Ribbon Panel and then clicks the desired map hex in the highlighted Deployment Zone. To abort a unit's placement, one right-clicks the hitherto placed unit. This removes it from the map and puts it right back in the Undeployed Unit Listing Ribbon Panel.
Boarded or Not ?
How does one deploy one or more of his Core Units in a Dismounted / Embarked state ?
1) Land units enjoying Organic Transport are always placed ON map hexes in a Dismounted state.
2) Land units (with or without Organic Transport) can be placed ON "Body of Water" (i.e., Coast, Sea, Ocean etc) hexes provided:
a) The Unit Types are naval-transportable; the relevant entries under file EQUIPMENT.PGEQP column entitled "Can Have Sea Transport" need to be coded with the Boolean value ONE (1).
b) There are free Naval Transport Points which would serially and automatically accommodate Unit Deployments in an Embarked state.
3) Land units (with or without Organic Transport) can be placed OVER map hexes provided:
A) The Unit Types are both air-transportable and paradrop-capable; the relevant entries under file EQUIPMENT.PGEQP columns entitled "Can Have Air Transport" and "Can Paradrop" need both to be coded with Boolean values of ONE (1)
B) There are free Air Transport Points which would serially and automatically accommodate Unit Deployments in an Embarked state.
C) Their Organic Transports (if any) need to be gotten rid of prior to the actual unit placements. This is accomplished as per the contents of
Getting Rid Of Organic Transport
viewtopic.php?f=100&t=543#p9990
D) If the Unit Types are naval-transportable as well, as long as there are free Naval Transport Points, attempting to place such units OVER "Body of Water" hexes will result in the units automatically being granted Naval Transports ON the very same designated hex instead !
SUBMARINE CLASS UNIT EVASION (Part I)
SUBMARINE CLASS UNIT EVASION (Part I)
====================================
Prima's PG Official Strategy Guide Says...
Subroutine Identification
Important: PGF engine's subroutine controlling Submarine Class Unit Evasion (SCUE) has NOT yet been identified. To this effect, this post's contents should be viewed as provisional.
Key Evasion Observations
A) Enemy Submarine Class Units (ESCUs), while stationary, may find themselves being targets of attempted Friendly Destroyer Class Unit (FDCU) proximity attacks.
B) Unsuccessful, attempted attacks against ESCUs do NOT result in actual combat. PGF's engine just momentarily flashes the following onscreen message: "SUBMARINE EVADES!".
C) In the past, it has been suggested that friendly T-Boat Unit Types (UTs) are more likely to actually hit ESCUs as compared to "plain vanilla" Destroyer UTs.
Simple Probabilistic Mechanism
Caveats: It is assumed that Unit Strength, Experience and Weather Conditions do NOT affect Evasion chances...
Let P represent the probability of Evasion (EVS). According to Prima's Guide, the chance of an ESCU evading an attempted attack upon it is 50% (i.e., P=0.50).
Attempted Empirical Verification
A number of trials were carried out using the very same situation, every time. In order to safeguard against biases often inherent in an engine serially utilizing the same pseudo-randomization "seed", PGF was closed (i.e., "exit", not just "quit") at the end of each trial and was started again to move on to the next trial. In this manner, every trial was conducted under a different pseudo-randomization "seed".
Friendly "Plain Vanilla" Destroyer Unit
The "cumulative story" certainly tempts one to conclude that P=0.50 might, indeed, be the "true" probability.
Friendly T-Boat Unit
The "cumulative story" most certainly tempts one to conclude that P=0.50 is, indeed, the "true" probability.
By the way, it does NOT appear that T-Boat UTs are more (or less) likely to hit ESCUs...
A Necessary Warning
Credibly conducted statistical analyses testing for P = 0.50 require many more than 100 trials.
====================================
Prima's PG Official Strategy Guide Says...
Well, that is "something". When it comes to verification guidance, "something" is usually better than "nothing"...When submarines are fired on, there is a chance that they'll evade the attack completely by submerging. They have a 50 percent chance to evade enemy destroyer class ship attacks...
Subroutine Identification
Important: PGF engine's subroutine controlling Submarine Class Unit Evasion (SCUE) has NOT yet been identified. To this effect, this post's contents should be viewed as provisional.
Key Evasion Observations
A) Enemy Submarine Class Units (ESCUs), while stationary, may find themselves being targets of attempted Friendly Destroyer Class Unit (FDCU) proximity attacks.
B) Unsuccessful, attempted attacks against ESCUs do NOT result in actual combat. PGF's engine just momentarily flashes the following onscreen message: "SUBMARINE EVADES!".
C) In the past, it has been suggested that friendly T-Boat Unit Types (UTs) are more likely to actually hit ESCUs as compared to "plain vanilla" Destroyer UTs.
Simple Probabilistic Mechanism
Caveats: It is assumed that Unit Strength, Experience and Weather Conditions do NOT affect Evasion chances...
Let P represent the probability of Evasion (EVS). According to Prima's Guide, the chance of an ESCU evading an attempted attack upon it is 50% (i.e., P=0.50).
Attempted Empirical Verification
A number of trials were carried out using the very same situation, every time. In order to safeguard against biases often inherent in an engine serially utilizing the same pseudo-randomization "seed", PGF was closed (i.e., "exit", not just "quit") at the end of each trial and was started again to move on to the next trial. In this manner, every trial was conducted under a different pseudo-randomization "seed".
Friendly "Plain Vanilla" Destroyer Unit
Code: Select all
TRIAL EVS ? EVSs EVS CHANCE
ID
01 0 00 00.00
02 1 01 50.00
03 1 02 66.67
04 1 03 75.00
05 1 04 80.00
06 0 04 66.67
07 1 05 71.43
08 0 05 62.50
09 0 05 55.56
10 1 06 60.00
11 0 06 54.55
12 1 07 58.33
13 1 08 61.54
14 0 08 57.14
15 0 08 53.33
16 0 08 50.00
17 0 08 47.06
18 1 09 50.00
19 1 10 52.63
20 0 10 50.00
21 0 10 47.62
22 1 11 50.00
23 1 12 52.17
24 1 13 54.17
25 0 13 52.00
26 0 13 50.00
27 1 14 51.85
28 0 14 50.00
29 0 14 48.28
30 0 14 46.67
31 0 14 45.16
32 1 15 46.88
33 0 15 45.45
34 1 16 47.06
35 1 17 48.57
36 0 17 47.22
37 1 18 48.65
38 0 18 47.37
39 0 18 46.15
40 0 18 45.00
41 0 18 43.90
42 1 19 45.24
43 1 20 46.51
44 1 21 47.73
45 1 22 48.89
46 1 23 50.00
47 0 23 48.94
48 0 23 47.92
49 0 23 46.94
50 1 24 48.00
51 1 25 49.02
52 1 26 50.00
53 0 26 49.06
54 1 27 50.00
55 1 28 50.91
56 0 28 50.00
57 0 28 49.12
58 0 28 48.28
59 1 29 49.15
60 1 30 50.00
61 1 31 50.82
62 0 31 50.00
63 1 32 50.79
64 1 33 51.56
65 1 34 52.31
66 0 34 51.52
67 0 34 50.75
68 1 35 51.47
69 1 36 52.17
70 1 37 52.86
71 0 37 52.11
72 0 37 51.39
73 1 38 52.05
74 1 39 52.70
75 1 40 53.33
76 1 41 53.95
77 0 41 53.25
78 1 42 53.85
79 0 42 53.16
80 0 42 52.50
81 1 43 53.09
82 1 44 53.66
83 0 44 53.01
84 0 44 52.38
85 1 45 52.94
86 0 45 52.33
87 1 46 52.87
88 0 46 52.27
89 1 47 52.81
90 1 48 53.33
91 1 49 53.85
92 1 50 54.35
93 0 50 53.76
94 1 51 54.26
95 1 52 54.74
96 1 53 55.21
97 1 54 55.67
98 1 55 56.12
99 0 55 55.56
100 0 55 55.00Friendly T-Boat Unit
Code: Select all
TRIAL EVS ? EVSs EVS CHANCE
ID
01 1 01 100.00
02 1 02 100.00
03 1 03 100.00
04 1 04 100.00
05 0 04 80.00
06 1 05 83.33
07 1 06 85.71
08 1 07 87.50
09 1 08 88.89
10 1 09 90.00
11 1 10 90.91
12 0 10 83.33
13 0 10 76.92
14 1 11 78.57
15 1 12 80.00
16 0 12 75.00
17 0 12 70.59
18 1 13 72.22
19 0 13 68.42
20 0 13 65.00
21 0 13 61.90
22 0 13 59.09
23 1 14 60.87
24 0 14 58.33
25 1 15 60.00
26 0 15 57.69
27 0 15 55.56
28 0 15 53.57
29 0 15 51.72
30 0 15 50.00
31 1 16 51.61
32 0 16 50.00
33 0 16 48.48
34 1 17 50.00
35 1 18 51.43
36 1 19 52.78
37 1 20 54.05
38 1 21 55.26
39 0 21 53.85
40 1 22 55.00
41 0 22 53.66
42 0 22 52.38
43 0 22 51.16
44 1 23 52.27
45 1 24 53.33
46 1 25 54.35
47 1 26 55.32
48 1 27 56.25
49 0 27 55.10
50 0 27 54.00
51 0 27 52.94
52 0 27 51.92
53 0 27 50.94
54 1 28 51.85
55 0 28 50.91
56 0 28 50.00
57 0 28 49.12
58 1 29 50.00
59 1 30 50.85
60 0 30 50.00
61 1 31 50.82
62 0 31 50.00
63 1 32 50.79
64 1 33 51.56
65 1 34 52.31
66 0 34 51.52
67 0 34 50.75
68 0 34 50.00
69 1 35 50.72
70 1 36 51.43
71 0 36 50.70
72 0 36 50.00
73 1 37 50.68
74 1 38 51.35
75 0 38 50.67
76 0 38 50.00
77 1 39 50.65
78 0 39 50.00
79 1 40 50.63
80 0 40 50.00
81 0 40 49.38
82 1 41 50.00
83 1 42 50.60
84 0 42 50.00
85 0 42 49.41
86 0 42 48.84
87 1 43 49.43
88 1 44 50.00
89 0 44 49.44
90 0 44 48.89
91 1 45 49.45
92 1 46 50.00
93 1 47 50.54
94 1 48 51.06
95 1 49 51.58
96 1 50 52.08
97 0 50 51.55
98 0 50 51.02
99 0 50 50.51
100 1 51 51.00By the way, it does NOT appear that T-Boat UTs are more (or less) likely to hit ESCUs...
A Necessary Warning
Credibly conducted statistical analyses testing for P = 0.50 require many more than 100 trials.
SUBMARINE CLASS UNIT EVASION (Part II)
SUBMARINE CLASS UNIT EVASION (Part II)
====================================
Prima's PG Official Strategy Guide Says...
Subroutine Identification
Important: PGF engine's subroutine controlling Submarine Class Unit Evasion (SCUE) has NOT yet been identified. To this effect, this post's contents should be viewed as provisional.
Key Evasion Observations
A) Enemy Submarine Class Units (ESCUs), while stationary, may find themselves being targets of attempted Friendly Tactical Bomber Class Unit (FTBCU) bombing attacks.
B) Unsuccessful, attempted attacks against ESCUs do NOT result in actual combat. PGF's engine just momentarily flashes the following onscreen message: "SUBMARINE DIVES!".
Simple Probabilistic Mechanism
Caveats: It is assumed that Unit Strength, Experience and Overcast Skies do NOT affect Evasion chances...
Let P represent the probability of Evasion (EVS). According to Prima's Guide, the chance of an ESCU evading an attempted attack upon it is 75% (i.e., P=0.75).
Attempted Empirical Verification
A number of trials were carried out using the very same situation, every time. In order to safeguard against biases often inherent in an engine serially utilizing the same pseudo-randomization "seed", PGF was closed (i.e., "exit", not just "quit") at the end of each trial and was started again to move on to the next trial. In this manner, every trial was conducted under a different pseudo-randomization "seed".
Friendly Tactical Bomber Class Unit
Hmm... I just do not know. The "cumulative story" kind of tempts me to speculate that the "true" probability might be P=7/10...
A Necessary Warning
Credibly conducted statistical analyses testing for P = 0.75 require many more than 100 trials.
====================================
Prima's PG Official Strategy Guide Says...
Well, that is "something". When it comes to verification guidance, "something" is usually better than "nothing"...When submarines are being bombed, there is a chance that they'll evade the attack completely by submerging. They have a 75 percent chance to evade enemy tactical bomber class attacks...
Subroutine Identification
Important: PGF engine's subroutine controlling Submarine Class Unit Evasion (SCUE) has NOT yet been identified. To this effect, this post's contents should be viewed as provisional.
Key Evasion Observations
A) Enemy Submarine Class Units (ESCUs), while stationary, may find themselves being targets of attempted Friendly Tactical Bomber Class Unit (FTBCU) bombing attacks.
B) Unsuccessful, attempted attacks against ESCUs do NOT result in actual combat. PGF's engine just momentarily flashes the following onscreen message: "SUBMARINE DIVES!".
Simple Probabilistic Mechanism
Caveats: It is assumed that Unit Strength, Experience and Overcast Skies do NOT affect Evasion chances...
Let P represent the probability of Evasion (EVS). According to Prima's Guide, the chance of an ESCU evading an attempted attack upon it is 75% (i.e., P=0.75).
Attempted Empirical Verification
A number of trials were carried out using the very same situation, every time. In order to safeguard against biases often inherent in an engine serially utilizing the same pseudo-randomization "seed", PGF was closed (i.e., "exit", not just "quit") at the end of each trial and was started again to move on to the next trial. In this manner, every trial was conducted under a different pseudo-randomization "seed".
Friendly Tactical Bomber Class Unit
Code: Select all
TRIAL EVS ? EVSs EVS CHANCE
ID
01 1 01 100.00
02 1 02 100.00
03 0 02 66.67
04 1 03 75.00
05 0 03 60.00
06 1 04 66.67
07 0 04 57.14
08 1 05 62.50
09 1 06 66.67
10 0 06 60.00
11 1 07 63.64
12 1 08 66.67
13 1 09 69.23
14 1 10 71.43
15 1 11 73.33
16 0 11 68.75
17 0 11 64.71
18 1 12 66.67
19 0 12 63.16
20 1 13 65.00
21 0 13 61.90
22 1 14 63.64
23 1 15 65.22
24 1 16 66.67
25 1 17 68.00
26 1 18 69.23
27 1 19 70.37
28 0 19 67.86
29 1 20 68.97
30 1 21 70.00
31 1 22 70.97
32 0 22 68.75
33 1 23 69.70
34 1 24 70.59
35 1 25 71.43
36 0 25 69.44
37 1 26 70.27
38 0 26 68.42
39 0 26 66.67
40 1 27 67.50
41 1 28 68.29
42 1 29 69.05
43 1 30 69.77
44 0 30 68.18
45 1 31 68.89
46 0 31 67.39
47 1 32 68.09
48 0 32 66.67
49 0 32 65.31
50 0 32 64.00
51 1 33 64.71
52 1 34 65.38
53 0 34 64.15
54 1 35 64.81
55 0 35 63.64
56 1 36 64.29
57 1 37 64.91
58 1 38 65.52
59 1 39 66.10
60 1 40 66.67
61 1 41 67.21
62 0 41 66.13
63 1 42 66.67
64 1 43 67.19
65 1 44 67.69
66 1 45 68.18
67 1 46 68.66
68 0 46 67.65
69 1 47 68.12
70 1 48 68.57
71 1 49 69.01
72 1 50 69.44
73 1 51 69.86
74 0 51 68.92
75 1 52 69.33
76 1 53 69.74
77 1 54 70.13
78 1 55 70.51
79 0 55 69.62
80 0 55 68.75
81 1 56 69.14
82 1 57 69.51
83 0 57 68.67
84 0 57 67.86
85 0 57 67.06
86 1 58 67.44
87 1 59 67.82
88 0 59 67.05
89 0 59 66.29
90 1 60 66.67
91 1 61 67.03
92 1 62 67.39
93 1 63 67.74
94 1 64 68.09
95 1 65 68.42
96 0 65 67.71
97 1 66 68.04
98 1 67 68.37
99 1 68 68.69
100 1 69 69.00A Necessary Warning
Credibly conducted statistical analyses testing for P = 0.75 require many more than 100 trials.
UNIT PARA-DROP AIR DRIFT
UNIT PARA-DROP AIR DRIFT
========================
SSI's PG1-DOS Manual Says...
Prima's PG Official Strategy Guide Says...
Subroutine Identification
Important: PGF engine's subroutine controlling unit Paradrop Air Drift (PAD) has NOT yet been identified. To this effect, this post's contents should be viewed as provisional.
The Finer Points...
A) If the designated "drop zone" is an airfield hex, there is NO air drift whatsoever.
B) Given an actual para-drop "scatter" event, all non-prohibited, adjacent hexes are equiprobable for the purposes of pseudo-randomly determining the landing hex.
C) The following terrain types (i.e., Underlying Terrain Representations) are prohibited:
Completely unenterable (aka "Neutral") hexes are prohibited as well.
Simple Probabilistic Mechanism
Caveats: It is assumed that Unit Strength, Experience and Weather Conditions do NOT affect Air Drift chances...
Let P represent the probability of a para-dropped Unit Actually Drifting (UAD). According to Prima's Guide, the chance of that happening is 50% (i.e., P=0.50).
Attempted Empirical Verification
A number of trials were carried out using the very same situation, every time. In order to safeguard against biases often inherent in an engine serially utilizing the same pseudo-randomization "seed", PGF was closed (i.e., "exit", not just "quit") at the end of each trial and was started again to move on to the next trial. In this manner, every trial was conducted under a different pseudo-randomization "seed".
Designated "Drop Zone": The Hex Directly Below
Not picture perfect but it is certainly plausible that the "true" probability might actually be P=0.50.
Designated "Drop Zone": An Adjacent Hex
Even less picture perfect. Could it be that the "true" probability might actually be P=0.40 ?
A Necessary Warning
Credibly conducted statistical analyses testing for P = 0.50 require many more than 100 trials.
========================
SSI's PG1-DOS Manual Says...
Pretty... laconic !Paratroops may select the hex their air transport is in or any adjacent land hex as their drop zone, and are subject to potential drifting away from the selected drop zone.
Prima's PG Official Strategy Guide Says...
Now that is much better ! Most importantly, the preceding offers one some welcome verification guidance. There is a 50% chance of a para-dropped unit landing as intended or not...A Paratrooper or Ranger unit, unlike other air-transported units, can disembark from its transport in any unoccupied (except by an air unit), non-ocean hex directly under or adjacent to the hex over which the air transport begins its turn. It is, nevertheless, subject to potential "scatter" when it drops.
Here is how the process works:
1) When you want to disembark a Paratroop or Ranger unit from an air transport, you may select as your targeted "drop zone" either the hex the air transport is over or any adjacent hex. However, land hexes occupied by surface units and "body of water" hexes (e.g., Ocean) can never serve as designated "drop zones".
2) Once the desired "drop zone" is selected, the air-dropped unit has a 50% chance of landing on that hex. To this effect, the unit also has a 50% chance of landing on some randomly selected, non-prohibited, adjacent hex.
3) After air-dropping, a unit's turn is over. It cannot fight or move during the turn in which it drops.
It is important to internalize that an air-dropped unit can land back on the air transport's original hex or as much as two hexes away from it !
Subroutine Identification
Important: PGF engine's subroutine controlling unit Paradrop Air Drift (PAD) has NOT yet been identified. To this effect, this post's contents should be viewed as provisional.
The Finer Points...
A) If the designated "drop zone" is an airfield hex, there is NO air drift whatsoever.
B) Given an actual para-drop "scatter" event, all non-prohibited, adjacent hexes are equiprobable for the purposes of pseudo-randomly determining the landing hex.
C) The following terrain types (i.e., Underlying Terrain Representations) are prohibited:
Code: Select all
Terrain UTR
Types Designations
Bodies of Water 04h, 05h, 06h, 07h
Rough Desert 22h
Escarpment 23h, 24hSimple Probabilistic Mechanism
Caveats: It is assumed that Unit Strength, Experience and Weather Conditions do NOT affect Air Drift chances...
Let P represent the probability of a para-dropped Unit Actually Drifting (UAD). According to Prima's Guide, the chance of that happening is 50% (i.e., P=0.50).
Attempted Empirical Verification
A number of trials were carried out using the very same situation, every time. In order to safeguard against biases often inherent in an engine serially utilizing the same pseudo-randomization "seed", PGF was closed (i.e., "exit", not just "quit") at the end of each trial and was started again to move on to the next trial. In this manner, every trial was conducted under a different pseudo-randomization "seed".
Designated "Drop Zone": The Hex Directly Below
Code: Select all
TRIAL UAD ? UADs UAD CHANCE
ID
01 0 00 00.00
02 1 01 50.00
03 0 01 33.33
04 1 02 50.00
05 1 03 60.00
06 1 04 66.67
07 0 04 57.14
08 0 04 50.00
09 0 04 44.44
10 1 05 50.00
11 0 05 45.45
12 0 05 41.67
13 0 05 38.46
14 1 06 42.86
15 1 07 46.67
16 0 07 43.75
17 1 08 47.06
18 0 08 44.44
19 0 08 42.11
20 1 09 45.00
21 0 09 42.86
22 0 09 40.91
23 1 10 43.48
24 0 10 41.67
25 1 11 44.00
26 1 12 46.15
27 1 13 48.15
28 0 13 46.43
29 1 14 48.28
30 0 14 46.67
31 0 14 45.16
32 1 15 46.88
33 1 16 48.48
34 0 16 47.06
35 1 17 48.57
36 0 17 47.22
37 1 18 48.65
38 0 18 47.37
39 0 18 46.15
40 1 19 47.50
41 0 19 46.34
42 1 20 47.62
43 1 21 48.84
44 0 21 47.73
45 1 22 48.89
46 1 23 50.00
47 1 24 51.06
48 0 24 50.00
49 0 24 48.98
50 0 24 48.00
51 1 25 49.02
52 1 26 50.00
53 1 27 50.94
54 0 27 50.00
55 1 28 50.91
56 0 28 50.00
57 0 28 49.12
58 0 28 48.28
59 1 29 49.15
60 1 30 50.00
61 0 30 49.18
62 0 30 48.39
63 1 31 49.21
64 0 31 48.44
65 0 31 47.69
66 1 32 48.48
67 1 33 49.25
68 1 34 50.00
69 1 35 50.72
70 0 35 50.00
71 0 35 49.30
72 1 36 50.00
73 0 36 49.32
74 1 37 50.00
75 0 37 49.33
76 0 37 48.68
77 0 37 48.05
78 0 37 47.44
79 1 38 48.10
80 0 38 47.50
81 0 38 46.91
82 0 38 46.34
83 0 38 45.78
84 1 39 46.43
85 0 39 45.88
86 1 40 46.51
87 1 41 47.13
88 0 41 46.59
89 0 41 46.07
90 1 42 46.67
91 0 42 46.15
92 0 42 45.65
93 1 43 46.24
94 0 43 45.74
95 0 43 45.26
96 0 43 44.79
97 0 43 44.33
98 1 44 44.90
99 0 44 44.44
100 1 45 45.00Designated "Drop Zone": An Adjacent Hex
Code: Select all
TRIAL UAD ? UADs UAD CHANCE
ID
01 0 00 0.00
02 0 00 0.00
03 0 00 0.00
04 1 01 25.00
05 0 01 20.00
06 0 01 16.67
07 0 01 14.29
08 1 02 25.00
09 1 03 33.33
10 0 03 30.00
11 1 04 36.36
12 0 04 33.33
13 0 04 30.77
14 1 05 35.71
15 0 05 33.33
16 1 06 37.50
17 0 06 35.29
18 1 07 38.89
19 1 08 42.11
20 1 09 45.00
21 1 10 47.62
22 0 10 45.45
23 1 11 47.83
24 1 12 50.00
25 0 12 48.00
26 0 12 46.15
27 1 13 48.15
28 0 13 46.43
29 0 13 44.83
30 1 14 46.67
31 1 15 48.39
32 0 15 46.88
33 1 16 48.48
34 0 16 47.06
35 1 17 48.57
36 0 17 47.22
37 1 18 48.65
38 0 18 47.37
39 0 18 46.15
40 1 19 47.50
41 1 20 48.78
42 0 20 47.62
43 0 20 46.51
44 1 21 47.73
45 1 22 48.89
46 0 22 47.83
47 1 23 48.94
48 1 24 50.00
49 0 24 48.98
50 0 24 48.00
51 1 25 49.02
52 0 25 48.08
53 0 25 47.17
54 1 26 48.15
55 0 26 47.27
56 0 26 46.43
57 0 26 45.61
58 0 26 44.83
59 0 26 44.07
60 0 26 43.33
61 0 26 42.62
62 1 27 43.55
63 0 27 42.86
64 0 27 42.19
65 0 27 41.54
66 0 27 40.91
67 0 27 40.30
68 1 28 41.18
69 0 28 40.58
70 0 28 40.00
71 1 29 40.85
72 0 29 40.28
73 0 29 39.73
74 1 30 40.54
75 1 31 41.33
76 0 31 40.79
77 0 31 40.26
78 0 31 39.74
79 1 32 40.51
80 1 33 41.25
81 0 33 40.74
82 1 34 41.46
83 0 34 40.96
84 1 35 41.67
85 0 35 41.18
86 1 36 41.86
87 0 36 41.38
88 0 36 40.91
89 1 37 41.57
90 1 38 42.22
91 0 38 41.76
92 0 38 41.30
93 1 39 41.94
94 0 39 41.49
95 1 40 42.11
96 0 40 41.67
97 1 41 42.27
98 0 41 41.84
99 1 42 42.42
100 0 42 42.00A Necessary Warning
Credibly conducted statistical analyses testing for P = 0.50 require many more than 100 trials.
RUGGED DEFENSE EVENT CHANCE
RUGGED DEFENSE EVENT CHANCE
=============================
Rugged Defense Events
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, there is a chance of RD actually happening.
Prima's PG Official Strategy Guide essentially covers the information appearing here:
Rugged Defense Likelihood Determination
viewtopic.php?f=100&t=544#p11425
Kindly review it before continuing !
That is certainly "something". When it comes to verification guidance, "something" is usually much better than "nothing"...
Subroutine Identification
Important: PGF engine's subroutine controlling Rugged Defense Likelihood Determination & Execution (RDLD&E) has NOT yet been identified. To this effect, this post's contents should be viewed as provisional.
Calibration Fraction Value
(N/D) is the calibration fraction. Prima's value is (5/1). The currently proposed value is (10/3).
Prior to initiating combat, a player has the option to consult the "Extended combat prediction" information displayed on a pop-up screen. The screen gets activated upon invoking the keyboard / mouse cursor combination [Ctrl+Click], where one clicks the intended target. PGF engine's computed RD chance (if any) is featured as part of the detailed information displayed.
Extensive experimentation has revealed that the calibration fraction value which is exactly consistent with PGF engine's displayed RD predictions is, indeed, (10/3).
Simple Probabilistic Mechanism
Let P represent the probability of a particular RD event actually happening. Its complement (1-P) represents the probability of that particular RD event NOT actually happening.
The engine rolls an electronic, HUNDRED-SIDED DIE (d100) to determine the probabilistic outcome. As per Prima, a die roll value HIGHER THAN [100 * (1-P)] would trigger a RD event.
Attempted Empirical Verification
Are PGF's probabilistic outcomes in lock step with its displayed predictions ?
Consider a Tank Class unit sporting two (2) Experience stars initiating an attack against an enemy Infantry Class target sporting one (1) Experience star and being the beneficiary of four (4) Entrenchment Levels. Employing Unit Class Entrenchment Rate values embedded in PGF's unmodified executable
ExpR = (1 + 2) / (2 + 2) = 3/4
EntRR = (3 + 1) / (1 + 1) = 2/1
one derives
Proposed Prediction Formula:
Rugged Defense % Chance = (10/3) * 4 * (3/4) * (2/1) = (10*4*3*2) / (3*4*1)
= 20
A number of trials were carried out using the very same situation, every time. In order to safeguard against biases often inherent in an engine serially utilizing the same pseudo-randomization "seed", PGF was closed (i.e., "exit", not just "quit") at the end of each trial and was started again to move on to the next trial. In this manner, every trial was conducted under a different pseudo-randomization "seed".
The "cumulative story" certainly tempts one to conclude that P=0.20 might, indeed, be the "true" probability.
A Necessary Warning
Credibly conducted statistical analyses testing for P = 0.20 require many more than 100 trials.
=============================
Rugged Defense Events
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, there is a chance of RD actually happening.
Prima's PG Official Strategy Guide essentially covers the information appearing here:
Rugged Defense Likelihood Determination
viewtopic.php?f=100&t=544#p11425
Kindly review it before continuing !
That is certainly "something". When it comes to verification guidance, "something" is usually much better than "nothing"...
Subroutine Identification
Important: PGF engine's subroutine controlling Rugged Defense Likelihood Determination & Execution (RDLD&E) has NOT yet been identified. To this effect, this post's contents should be viewed as provisional.
Calibration Fraction Value
(N/D) is the calibration fraction. Prima's value is (5/1). The currently proposed value is (10/3).
Prior to initiating combat, a player has the option to consult the "Extended combat prediction" information displayed on a pop-up screen. The screen gets activated upon invoking the keyboard / mouse cursor combination [Ctrl+Click], where one clicks the intended target. PGF engine's computed RD chance (if any) is featured as part of the detailed information displayed.
Extensive experimentation has revealed that the calibration fraction value which is exactly consistent with PGF engine's displayed RD predictions is, indeed, (10/3).
Simple Probabilistic Mechanism
Let P represent the probability of a particular RD event actually happening. Its complement (1-P) represents the probability of that particular RD event NOT actually happening.
The engine rolls an electronic, HUNDRED-SIDED DIE (d100) to determine the probabilistic outcome. As per Prima, a die roll value HIGHER THAN [100 * (1-P)] would trigger a RD event.
Attempted Empirical Verification
Are PGF's probabilistic outcomes in lock step with its displayed predictions ?
Consider a Tank Class unit sporting two (2) Experience stars initiating an attack against an enemy Infantry Class target sporting one (1) Experience star and being the beneficiary of four (4) Entrenchment Levels. Employing Unit Class Entrenchment Rate values embedded in PGF's unmodified executable
ExpR = (1 + 2) / (2 + 2) = 3/4
EntRR = (3 + 1) / (1 + 1) = 2/1
one derives
Proposed Prediction Formula:
Rugged Defense % Chance = (10/3) * 4 * (3/4) * (2/1) = (10*4*3*2) / (3*4*1)
= 20
A number of trials were carried out using the very same situation, every time. In order to safeguard against biases often inherent in an engine serially utilizing the same pseudo-randomization "seed", PGF was closed (i.e., "exit", not just "quit") at the end of each trial and was started again to move on to the next trial. In this manner, every trial was conducted under a different pseudo-randomization "seed".
Code: Select all
TRIAL RD ? RDs RD CHANCE
ID
01 0 00 00.00
02 1 01 50.00
03 0 01 33.33
04 0 01 25.00
05 1 02 40.00
06 0 02 33.33
07 0 02 28.57
08 1 03 37.50
09 0 03 33.33
10 0 03 30.00
11 0 03 27.27
12 1 04 33.33
13 0 04 30.77
14 0 04 28.57
15 0 04 26.67
16 0 04 25.00
17 0 04 23.53
18 1 05 27.78
19 1 06 31.58
20 0 06 30.00
21 0 06 28.57
22 0 06 27.27
23 0 06 26.09
24 0 06 25.00
25 0 06 24.00
26 1 07 26.92
27 0 07 25.93
28 0 07 25.00
29 0 07 24.14
30 0 07 23.33
31 0 07 22.58
32 0 07 21.88
33 0 07 21.21
34 1 08 23.53
35 0 08 22.86
36 0 08 22.22
37 0 08 21.62
38 1 09 23.68
39 0 09 23.08
40 0 09 22.50
41 1 10 24.39
42 0 10 23.81
43 0 10 23.26
44 0 10 22.73
45 1 11 24.44
46 0 11 23.91
47 0 11 23.40
48 1 12 25.00
49 0 12 24.49
50 0 12 24.00
51 0 12 23.53
52 1 13 25.00
53 0 13 24.53
54 0 13 24.07
55 0 13 23.64
56 0 13 23.21
57 1 14 24.56
58 0 14 24.14
59 0 14 23.73
60 0 14 23.33
61 0 14 22.95
62 0 14 22.58
63 0 14 22.22
64 1 15 23.44
65 0 15 23.08
66 0 15 22.73
67 0 15 22.39
68 0 15 22.06
69 0 15 21.74
70 0 15 21.43
71 0 15 21.13
72 0 15 20.83
73 0 15 20.55
74 1 16 21.62
75 0 16 21.33
76 0 16 21.05
77 0 16 20.78
78 0 16 20.51
79 0 16 20.25
80 1 17 21.25
81 0 17 20.99
82 0 17 20.73
83 1 18 21.69
84 0 18 21.43
85 0 18 21.18
86 0 18 20.93
87 0 18 20.69
88 0 18 20.45
89 1 19 21.35
90 1 20 22.22
91 0 20 21.98
92 0 20 21.74
93 0 20 21.51
94 0 20 21.28
95 0 20 21.05
96 1 21 21.88
97 0 21 21.65
98 0 21 21.43
99 1 22 22.22
100 0 22 22.00A Necessary Warning
Credibly conducted statistical analyses testing for P = 0.20 require many more than 100 trials.
AIR TRANSPORT: DETAILS
AIR TRANSPORT: DETAILS
======================
Absolute Prerequisite
Air Transport: Units Boarding & Landing
viewtopic.php?f=100&t=531#p9378
Capability
Air Transport Units (ATUs) automatically become available / visible when air-transportable Ground units board them at Airfields; they are NOT purchased. Similarly, ATUs automatically disappear from sight whenever the transported units land onto some non-prohibited Ground terrain. A Boolean setting coded in file EQUIPMENT.PGEQP renders (or not) a unit air-transportable.
Air Transport (AT) of air-transportable Ground units is a temporary state of affairs made possible by the presence of available (i.e., free) Air Transport Points (ATPs) out of an abstract pool of such points the size of which is coded into a typical scenario's file *.PGSCN.
Boarding
A) To board an AT, a Ground unit must already be situated on an Airfield hex at the start of its movement phase. Contrary to a certain general impression, the ownership status of the Airfield hex the unit occupies is immaterial (i.e, neutralized or enemy owned Airfield hexes are ok !). Boarding an AT is NOT allowed immediately following a ground unit's movement phase.
B) There are NO enemy unit adjacency, weather, fuel or ammo availability restrictions to boarding an AT whatsoever. Obviously, though, the air space directly over the Airfield must be empty of air units for the unit to actually board an AT.
C) Upon boarding an AT, organic (ground) transport units (if any) must be abandoned.
D) Boarding an AT strictly preserves the transported units' ammo and experience stats.
E) When a Ground unit boards an AT, ONE (1) ATP is immediately subtracted from the pool of available (free) scenario ATPs. If no such ATPs are available (free), boarding an AT is NOT allowed.
F) Upon boarding an AT, ATUs are free to commence their air movement phase immediately.
En Route
1) En Route, ATUs are NOT subject to any weather or fuel availability restrictions whatsoever.
2) With one notable exception, a transported unit's ammo availability stat remains unchanged while en route. However, should its ATU remain stationary over a hex during one entire half-turn, ammo resupply DOES take place as per the normal resupply rules applicable to ground units !
3) With one notable exception, a transported unit's experience stat remains unchanged while en route. However, if its ATU gets attacked en route, the transported unit's experience stat DOES permanently change.
4) Transported units are almost totally subject to their ATUs' listed specifications. To this effect, they share the fate of their ATUs in identical manner and proportion if attacked while en route.
It is worth noting that, while en route and under enemy attack, an ATU utilizes its transported unit's experience stat ! To boot, under enemy air attack, to the extent that the ATU sports a positive Air Attack value, it shoots back at the attacking enemy air unit by expending its transported unit's ammo ! Most importantly, any losses in an ATU's strength automatically translate into losses of its transported unit's strength, one for one. Such losses can NEVER be replaced while en route.
5) For greater certainty, losses in an ATU's Strength Factors CANNOT be replaced even if the unit is located directly over a friendly Airfield hex or Body of Water hex on which a friendly Aircraft Carrier Class unit is situated !
6) If an ATU gets eliminated due to enemy attacks en route, the transported unit gets eliminated too. Most importantly, the AT pool point gets lost for the duration of the scenario (it is NOT added back to the abstract pool) ! This is similar to losing a unit which cannot be purchased during a scenario...
Air Landing
a) For Air Landing purposes, ATUs are NOT subject to any unit lateral adjacency, weather, fuel or ammo availability restrictions whatsoever.
b) To Air Land, a transported ground unit must already be located directly over a vacant Airfield hex at the start of its ATU's movement phase. If so, the transported unit is then allowed to Air Land onto that very same Airfield hex as well. Air Landing is NOT allowed immediately following its ATU's movement phase.
c) Air Landing transported units onto Airfield hexes strictly preserves their hitherto strength, ammo availability and experience stats.
d) When a transported unit lands onto an Airfield hex, ONE (1) ATP is immediately added back to the pool of available scenario ATPs, thus becoming available (free) again for possible future in-game use.
e) Air Landing units onto neutralized or enemy owned Airfield hexes can trigger immediate ownership changes as per the normal unit class rules.
f) Air Landed units CANNOT move any farther, engage in combat or receive
replacements immediately following their Air Landing.
Para-Drops
Kindly consult
Unit Para-Drop Air Drift
viewtopic.php?f=100&t=543#p11396
======================
Absolute Prerequisite
Air Transport: Units Boarding & Landing
viewtopic.php?f=100&t=531#p9378
Capability
Air Transport Units (ATUs) automatically become available / visible when air-transportable Ground units board them at Airfields; they are NOT purchased. Similarly, ATUs automatically disappear from sight whenever the transported units land onto some non-prohibited Ground terrain. A Boolean setting coded in file EQUIPMENT.PGEQP renders (or not) a unit air-transportable.
Air Transport (AT) of air-transportable Ground units is a temporary state of affairs made possible by the presence of available (i.e., free) Air Transport Points (ATPs) out of an abstract pool of such points the size of which is coded into a typical scenario's file *.PGSCN.
Boarding
A) To board an AT, a Ground unit must already be situated on an Airfield hex at the start of its movement phase. Contrary to a certain general impression, the ownership status of the Airfield hex the unit occupies is immaterial (i.e, neutralized or enemy owned Airfield hexes are ok !). Boarding an AT is NOT allowed immediately following a ground unit's movement phase.
B) There are NO enemy unit adjacency, weather, fuel or ammo availability restrictions to boarding an AT whatsoever. Obviously, though, the air space directly over the Airfield must be empty of air units for the unit to actually board an AT.
C) Upon boarding an AT, organic (ground) transport units (if any) must be abandoned.
D) Boarding an AT strictly preserves the transported units' ammo and experience stats.
E) When a Ground unit boards an AT, ONE (1) ATP is immediately subtracted from the pool of available (free) scenario ATPs. If no such ATPs are available (free), boarding an AT is NOT allowed.
F) Upon boarding an AT, ATUs are free to commence their air movement phase immediately.
En Route
1) En Route, ATUs are NOT subject to any weather or fuel availability restrictions whatsoever.
2) With one notable exception, a transported unit's ammo availability stat remains unchanged while en route. However, should its ATU remain stationary over a hex during one entire half-turn, ammo resupply DOES take place as per the normal resupply rules applicable to ground units !
3) With one notable exception, a transported unit's experience stat remains unchanged while en route. However, if its ATU gets attacked en route, the transported unit's experience stat DOES permanently change.
4) Transported units are almost totally subject to their ATUs' listed specifications. To this effect, they share the fate of their ATUs in identical manner and proportion if attacked while en route.
It is worth noting that, while en route and under enemy attack, an ATU utilizes its transported unit's experience stat ! To boot, under enemy air attack, to the extent that the ATU sports a positive Air Attack value, it shoots back at the attacking enemy air unit by expending its transported unit's ammo ! Most importantly, any losses in an ATU's strength automatically translate into losses of its transported unit's strength, one for one. Such losses can NEVER be replaced while en route.
5) For greater certainty, losses in an ATU's Strength Factors CANNOT be replaced even if the unit is located directly over a friendly Airfield hex or Body of Water hex on which a friendly Aircraft Carrier Class unit is situated !
6) If an ATU gets eliminated due to enemy attacks en route, the transported unit gets eliminated too. Most importantly, the AT pool point gets lost for the duration of the scenario (it is NOT added back to the abstract pool) ! This is similar to losing a unit which cannot be purchased during a scenario...
Air Landing
a) For Air Landing purposes, ATUs are NOT subject to any unit lateral adjacency, weather, fuel or ammo availability restrictions whatsoever.
b) To Air Land, a transported ground unit must already be located directly over a vacant Airfield hex at the start of its ATU's movement phase. If so, the transported unit is then allowed to Air Land onto that very same Airfield hex as well. Air Landing is NOT allowed immediately following its ATU's movement phase.
c) Air Landing transported units onto Airfield hexes strictly preserves their hitherto strength, ammo availability and experience stats.
d) When a transported unit lands onto an Airfield hex, ONE (1) ATP is immediately added back to the pool of available scenario ATPs, thus becoming available (free) again for possible future in-game use.
e) Air Landing units onto neutralized or enemy owned Airfield hexes can trigger immediate ownership changes as per the normal unit class rules.
f) Air Landed units CANNOT move any farther, engage in combat or receive
replacements immediately following their Air Landing.
Para-Drops
Kindly consult
Unit Para-Drop Air Drift
viewtopic.php?f=100&t=543#p11396
TRANSPORT POINT... OVERUSE
TRANSPORT POINT... OVERUSE
===========================
Preliminaries
Elsewhere in the Library:
Let "ee" stand for the number of friendly units currently finding themselves in an Embarked state. Then
ee = "MM" MINUS "ff" = MM - ff
A content designer is certainly free to preposition units in an Embarked state in excess of what "MM" would "justify" (i.e., ee > MM). If so,
ff = MM - ee
becomes NEGATIVE. This is exactly what PGF's engine will display. There is a straightforward interpretation here; namely, a "side" has somehow managed to "borrow" additional Transport capabilities. In other words, a NEGATIVE "ff" is akin to a wartime... debt in kind !
By the way, as long as "ff" remains NON-POSITIVE, NO in-game friendly unit Embarkations whatsoever will be allowed. Basically, unit Disembarkations sufficiently (i.e., algebraically) increasing "ff" so as for it to finally enter POSITIVE territory have to take place FIRST.
No, One Can't Get Away With...
... the wishful "claim" about to follow !
Momentarily revisiting:
Any such losses will be reducing "MM"; tough ! In fact, "MM" could even end up in NEGATIVE territory and be displayed as such ! 
Non-Positive Values
Non-positive "ff" and / or "MM" values prohibit any in-game friendly unit Embarkations whatsoever.
===========================
Preliminaries
Elsewhere in the Library:
Prepositioned... ViolatorsGoing from left to right, locate the SECOND (2nd) button in Row 1 depicted in the Scenario Panel. The button depicts a Naval Transport silhouette with two yellow arrows over it pointing away in opposite directions. This is the Embark / Disembark button.
When one hovers the mouse cursor over the aforesaid button, the tooltip shows the number of Transport Points (TPs) currently unutilized (i.e., "free") (ff) as well as the maximum number of TPs allocated to his side (MM) for the duration of the scenario. Air and Naval TP data are listed and managed separately. The common presentation format is:
Sea / Air transports: ff/MM
The "free" TPs constitute the current TP "pool". When one Embarks a unit, ONE (1) TP is subtracted from the "pool" (if available). If the "pool" is empty, the Embark / Disembark button is grayed out. When one Disembarks a unit, ONE (1) TP is added back to the "pool".
Important: TPs lost due to combat cannot be replaced in-game; they are gone for good !
Let "ee" stand for the number of friendly units currently finding themselves in an Embarked state. Then
ee = "MM" MINUS "ff" = MM - ff
A content designer is certainly free to preposition units in an Embarked state in excess of what "MM" would "justify" (i.e., ee > MM). If so,
ff = MM - ee
becomes NEGATIVE. This is exactly what PGF's engine will display. There is a straightforward interpretation here; namely, a "side" has somehow managed to "borrow" additional Transport capabilities. In other words, a NEGATIVE "ff" is akin to a wartime... debt in kind !
By the way, as long as "ff" remains NON-POSITIVE, NO in-game friendly unit Embarkations whatsoever will be allowed. Basically, unit Disembarkations sufficiently (i.e., algebraically) increasing "ff" so as for it to finally enter POSITIVE territory have to take place FIRST.
No, One Can't Get Away With...
... the wishful "claim" about to follow !
Momentarily revisiting:
What about "claiming" that the TP losses "should" apply to the "borrowed" ones FIRST, thereby leaving "MM" unmolested ? Well, PGF's engine will have none of that !TPs lost due to combat cannot be replaced in-game; they are gone for good !
Any such losses will be reducing "MM"; tough ! In fact, "MM" could even end up in NEGATIVE territory and be displayed as such ! Non-Positive Values
Non-positive "ff" and / or "MM" values prohibit any in-game friendly unit Embarkations whatsoever.
CITY & PORT TYPOLOGY
CITY & PORT TYPOLOGY
======================
Absolute Prerequisite
Underlying Terrain Representations
viewtopic.php?f=100&t=550#p9031
Definitive Terminology
As per above, there are THIRTY NINE (39) individually defined terrain types (UTRs).
1) PORT FACILITIES @ = @ UTR "08" ; decimal 8
2) NON-NAVAL CITY @ = @ UTR "15" ; decimal 21
3) EMBARKATION CITY @ = @ UTR "1D" ; decimal 29
4) PORT CITY @ = @ UTR "25" ; decimal 37
Aggregate Terrain Type Assignment
PGF's engine goes through a 2-step internal process which aggregates the 39 individually defined terrain types (UTRs) into 12 collectively constituted Aggregate Terrain types. For details, the reader may wish to consult
Internally "Summarized" Terrain Typology
viewtopic.php?f=100&t=547#p8997
PGF features the following Aggregate Terrain Types of contextual relevance:
City (00h) ==>
UTRs: Airfield (13h), City (15h)
Port (0Bh) ==>
UTRs: Port Facilities (08h), Embarkation City (1Dh), Port City (25h)
Assigning Embarkation Cities to the "Port" Aggregate Terrain type as opposed to the "City" one is quite unfortunate. For example:
Embarkation City Naval... Haven
viewtopic.php?f=100&t=555#p9105
is directly attributable to the above assignment.
Potential Differentiation Basis
PGF's engine utilizes its Aggregate Terrain Typology for the most part... Nevertheless, PGF's executable contains
Terrain Base Entrenchment Level Table
viewtopic.php?f=100&t=551#p9045
Terrain Initiative Cap Table
viewtopic.php?f=100&t=551#p9047
These tables do NOT observe the Aggregate Terrain Typology. Instead they accommodate data separately for each one of the 39 UTRs. Therefore, there IS a technical basis for potential differentiation here.
By the way, unless one hex-edits PGF's executable, the Table data therein are exactly SSI's.
======================
Absolute Prerequisite
Underlying Terrain Representations
viewtopic.php?f=100&t=550#p9031
Definitive Terminology
As per above, there are THIRTY NINE (39) individually defined terrain types (UTRs).
1) PORT FACILITIES @ = @ UTR "08" ; decimal 8
2) NON-NAVAL CITY @ = @ UTR "15" ; decimal 21
3) EMBARKATION CITY @ = @ UTR "1D" ; decimal 29
4) PORT CITY @ = @ UTR "25" ; decimal 37
Aggregate Terrain Type Assignment
PGF's engine goes through a 2-step internal process which aggregates the 39 individually defined terrain types (UTRs) into 12 collectively constituted Aggregate Terrain types. For details, the reader may wish to consult
Internally "Summarized" Terrain Typology
viewtopic.php?f=100&t=547#p8997
PGF features the following Aggregate Terrain Types of contextual relevance:
City (00h) ==>
UTRs: Airfield (13h), City (15h)
Port (0Bh) ==>
UTRs: Port Facilities (08h), Embarkation City (1Dh), Port City (25h)
Assigning Embarkation Cities to the "Port" Aggregate Terrain type as opposed to the "City" one is quite unfortunate. For example:
Embarkation City Naval... Haven
viewtopic.php?f=100&t=555#p9105
is directly attributable to the above assignment.
Potential Differentiation Basis
PGF's engine utilizes its Aggregate Terrain Typology for the most part... Nevertheless, PGF's executable contains
Terrain Base Entrenchment Level Table
viewtopic.php?f=100&t=551#p9045
Terrain Initiative Cap Table
viewtopic.php?f=100&t=551#p9047
These tables do NOT observe the Aggregate Terrain Typology. Instead they accommodate data separately for each one of the 39 UTRs. Therefore, there IS a technical basis for potential differentiation here.
By the way, unless one hex-edits PGF's executable, the Table data therein are exactly SSI's.
Last edited by HexCode on 2021-10-29 22:26, Friday, edited 1 time in total.
TRANSPORT MODE CLASSES: ATTACK PROPERTIES
TRANSPORT MODE CLASSES: ATTACK PROPERTIES
===========================================
Preliminaries
Units belonging to some Transport Mode Class (TMC) usually appear as "containers" of transported friendly units. However, they can also appear solo (i.e., as "non-containers") in their own right. In this latter case, the units may serve as representations of land, sea, even air "convoys".
Who's Who
Organic Transport Class (15d)
Air Transport Class (16d)
Naval Transport Class (17d)
where d stands for "decimal".
Attack Properties
1) Units belonging to some TMC OTHER THAN the Organic Transport one are prohibited from attacking enemy Soft, Hard or Naval Targets irrespective of any positive Soft, Hard or Naval Attack values they may sport.
2) If attacked by an enemy Air Super-Class unit, a unit belonging to some TMC which sports a positive (bracketed) Air Attack value is allowed to engage the enemy unit initiating the attack.
===========================================
Preliminaries
Units belonging to some Transport Mode Class (TMC) usually appear as "containers" of transported friendly units. However, they can also appear solo (i.e., as "non-containers") in their own right. In this latter case, the units may serve as representations of land, sea, even air "convoys".
Who's Who
Organic Transport Class (15d)
Air Transport Class (16d)
Naval Transport Class (17d)
where d stands for "decimal".
Attack Properties
1) Units belonging to some TMC OTHER THAN the Organic Transport one are prohibited from attacking enemy Soft, Hard or Naval Targets irrespective of any positive Soft, Hard or Naval Attack values they may sport.
2) If attacked by an enemy Air Super-Class unit, a unit belonging to some TMC which sports a positive (bracketed) Air Attack value is allowed to engage the enemy unit initiating the attack.
PURCHASED UNIT PLACEMENT: ENEMY PRESENCE ADJACENCY
PURCHASED UNIT PLACEMENT: ENEMY PRESENCE ADJACENCY
=====================================================
Absolute Requirement
Units: Upgrades & Purchases
viewtopic.php?f=100&t=531#p9917
SSI Says...
SSI's PG1-DOS manual states:
The Rules
A) It is NOT enemy Unit Class BUT RATHER enemy Target Type adjacency which determines purchased unit placement feasibility.
B) Laterally / vertically adjacent enemy units which have been assigned Air / Naval Target Types are ineffective in blocking purchased unit placement; reason being, PGF's play system DOES NOT consider such units to actually occupy "their" hexes. Yesteryear's SSI documentation seems to be in agreement.
C) Purchased Ground units CANNOT be placed on hexes exhibiting terrain which would be inaccessible to them (i.e., "unenterable") during such units' normally envisaged movement phase (e.g., Sea, Rough Desert, Muddy Swamp etc).
Note: As one keeps on digging deeper and deeper into purchases of Structure Class & Naval Super-Class units all "normal" unit placement bets are off...
=====================================================
Absolute Requirement
Units: Upgrades & Purchases
viewtopic.php?f=100&t=531#p9917
SSI Says...
SSI's PG1-DOS manual states:
There is a subtle semantic difference here. Mere enemy presence is NOT good enough. One or more enemy units have to occupy "their" hexes.Purchase units with Prestige Points and place them in or adjacent to friendly cities / {ports} (if land units) and on friendly airfields (if air units) . . . where there is no adjacent hex occupied by an enemy {unit}.
The Rules
A) It is NOT enemy Unit Class BUT RATHER enemy Target Type adjacency which determines purchased unit placement feasibility.
B) Laterally / vertically adjacent enemy units which have been assigned Air / Naval Target Types are ineffective in blocking purchased unit placement; reason being, PGF's play system DOES NOT consider such units to actually occupy "their" hexes. Yesteryear's SSI documentation seems to be in agreement.
C) Purchased Ground units CANNOT be placed on hexes exhibiting terrain which would be inaccessible to them (i.e., "unenterable") during such units' normally envisaged movement phase (e.g., Sea, Rough Desert, Muddy Swamp etc).
Note: As one keeps on digging deeper and deeper into purchases of Structure Class & Naval Super-Class units all "normal" unit placement bets are off...
CORE UNIT DEPLOYMENT: DETAILS
CORE UNIT DEPLOYMENT: DETAILS
==============================
Absolute Requirement
Turns, Weather & Core Unit Deployment
viewtopic.php?f=100&t=531#p9299
Note: Standalone Scenario Play Mode sports NO (Core) Unit Deployment Phase.
Delayed Unit Deployment
A player does NOT have to deploy his entire Core Complement on the map. He can freely refrain from deploying one or more such units until later (as the scenario unfolds) or not at all. No matter, PGF's engine perfectly preserves such "dormant" units until the human player decides to deploy them at some point in the future in this or any other subsequent campaign scenario. So, this is NOT at all a case of "use them or lose them".
PGF' engine allows delayed unit deployment to just the hexes available at the very start of the scenario.
1) Core units which are deployed onto the map prior to the actual start of a scenario ARE NOT considered to have "acted" due to the deployment act itself.
2) Core units which are deployed onto the map at any other time ARE considered to have "acted" due to the deployment act itself.
Whether delayed or not, a Core unit's deployment onto some map hex can be preceded by an appropriate Upgrade event.
The preceding realities and capabilities allow a player to make informed decisions at the intersection of:
a) Possible Prestige scarcity;
b) A unit's current ability to survive on the battlefield; and
c) The enticing prospect of future, more powerful upgrade choices.
Naval Unit... Deployment
Naval Super-Class units can certainly be part of the Core complement. When it comes to their Deployment though, PGF's engine behaves in a totally terrain... agnostic manner. Namely, a player has full freedom to place his naval units anywhere within the Deployment Zone; no questions asked, no complaints whatsoever !! Incidentally, placing such units on land hexes adjacent to Body of Water or Port or Port City / Facilities hexes DOES enable these units to commence moving normally in-game.
==============================
Absolute Requirement
Turns, Weather & Core Unit Deployment
viewtopic.php?f=100&t=531#p9299
Note: Standalone Scenario Play Mode sports NO (Core) Unit Deployment Phase.
Delayed Unit Deployment
A player does NOT have to deploy his entire Core Complement on the map. He can freely refrain from deploying one or more such units until later (as the scenario unfolds) or not at all. No matter, PGF's engine perfectly preserves such "dormant" units until the human player decides to deploy them at some point in the future in this or any other subsequent campaign scenario. So, this is NOT at all a case of "use them or lose them".
PGF' engine allows delayed unit deployment to just the hexes available at the very start of the scenario.
1) Core units which are deployed onto the map prior to the actual start of a scenario ARE NOT considered to have "acted" due to the deployment act itself.
2) Core units which are deployed onto the map at any other time ARE considered to have "acted" due to the deployment act itself.
Whether delayed or not, a Core unit's deployment onto some map hex can be preceded by an appropriate Upgrade event.
The preceding realities and capabilities allow a player to make informed decisions at the intersection of:
a) Possible Prestige scarcity;
b) A unit's current ability to survive on the battlefield; and
c) The enticing prospect of future, more powerful upgrade choices.
Naval Unit... Deployment
Naval Super-Class units can certainly be part of the Core complement. When it comes to their Deployment though, PGF's engine behaves in a totally terrain... agnostic manner. Namely, a player has full freedom to place his naval units anywhere within the Deployment Zone; no questions asked, no complaints whatsoever !! Incidentally, placing such units on land hexes adjacent to Body of Water or Port or Port City / Facilities hexes DOES enable these units to commence moving normally in-game.
UNIT EMBARKATION & DISEMBARKATION: PROCEDURAL DETAILS
UNIT EMBARKATION & DISEMBARKATION: PROCEDURAL DETAILS
=======================================================
Absolute Prerequisites
Naval Transport: Units Embarking and Disembarking
viewtopic.php?f=100&t=531#p9364
Air Transport: Units Boarding and Landing
viewtopic.php?f=100&t=531#p9378
Abbreviations
TU @==@ "Transport Unit"
NTU @==@ "Naval Transport Unit"
ATU @==@ "Air Transport Unit"
Unit Embarkation / Boarding
Unit Locations On the Map
Units Embarking onto NTUs must be on Embarkation City, Port City or Port Facilities hexes. Units Boarding ATUs must be on Airfield hexes. In all instances, the units must NOT have "acted" yet.
Unit Selection
In order to Embark / Board a unit onto a TU one has to select it FIRST by clicking on its icon. Selecting it triggers the display of all land hexes that the unit can reach either on its own (LIGHT GREEN color) or via its Organic Transport (PALE YELLOW color) (if any).
Pressing the Button
One must press the Scenario Panel's Embark/Disembark button to get the unit Embarkation / Boarding going. Upon pressing that button, the unit icon changes to a TU one simultaneously triggering the display of all hexes the unit can reach via its TU (LIGHT GREEN color) or can immediately turn around and Disembark / Land onto (PALE YELLOW color).
Units enjoying Organic Transport capabilities must abandon their enabling "container" units prior to Boarding.
An Air Unit already situated directly above an Airfield hex renders Boarding through it infeasible.
Unit Follow-up Movement Is Optional
A player always has the option NOT to move his unit at all but rather to leave it in a "hanging" Embarked / Boarded state and proceed with other actions on the map. He does so by RIGHT-clicking anywhere on the map. He may choose to return to his unit later on during the same half-turn and do something with it or not return to it at all. Units in a "hanging" Embarked / Boarded state are NOT considered to have "completely acted" yet.
Unit Follow-up Movement
By clicking on one of the LIGHT GREEN colored hexes, the unit provisionally attempts to move to that hex in an Embarked / Boarded state. RIGHT-clicking anywhere on the map renders the unit's provisional movement permanent and the unit is finally considered as having "acted".
Unit Status Restoration Is Impossible
Unlike PGF's unit Mount/Dismount feature the invocation of which is NOT considered to be "acting", once a unit gets Embarked / Boarded, it CANNOT revert back to its state prior to Embarkation / Boarding "on the spot" without actually "acting" (i.e., Disembarking / Landing).
Unit Disembarkation / Landing
Unit Locations On the Map
Units Disembarking from NTUs must be on Body of Water, Embarkation City, Port City or Port Facilities hexes. Units Landing from ATUs must be OVER Airfield hexes; units enjoying para-drop capabilities are considerably less restricted in their choice of Landing hex. In all instances, the units must NOT have "acted" yet.
Unit Selection
In order to Disembark / Land a unit from a TU one has to select it FIRST by clicking on the TU's icon. Selecting it triggers the display of all hexes the unit can reach via its TU (LIGHT GREEN color) or can Disembark / Land onto (PALE YELLOW color).
Unit Disembarkation / Landing Is Optional
A player always has the option NOT to Disembark / Land the unit but rather to leave it in its hitherto Embarked / Boarded state and proceed with other actions on the map. He does so by RIGHT-clicking anywhere on the map. He may return to his unit later on during the same half-turn and do something with it or not return to it at all.
Unit Disembarkation / Landing: Quick vs. Thorough
One can certainly Disembark / Land a transported unit by clicking on one of the PALE YELLOW colored hexes. However, some suitable hexes the transported unit could potentially Disembark / Land onto MAY NOT be indicated. To render such hexes available for unit Disembarkation / Landing purposes one has to press the Scenario Panel's Embark / Disembark button.
Clicking on one of the PALE YELLOW colored hexes immediately Disembarks the unit onto the hex and displays the unit's icon. At this point, the unit is considered as having irreversibly "acted".
Surface units already located on hexes render those hexes situationally unsuitable for unit Disembarkation / Landing purposes.
Unit Status Restoration Is Impossible
Unlike PGF's unit Mount/Dismount feature the invocation of which is NOT considered to be "acting", once a unit gets Disembarked / Landed, it CANNOT revert back to its state prior to Disembarkation / Landing; it has already "acted".
=======================================================
Absolute Prerequisites
Naval Transport: Units Embarking and Disembarking
viewtopic.php?f=100&t=531#p9364
Air Transport: Units Boarding and Landing
viewtopic.php?f=100&t=531#p9378
Abbreviations
TU @==@ "Transport Unit"
NTU @==@ "Naval Transport Unit"
ATU @==@ "Air Transport Unit"
Unit Embarkation / Boarding
Unit Locations On the Map
Units Embarking onto NTUs must be on Embarkation City, Port City or Port Facilities hexes. Units Boarding ATUs must be on Airfield hexes. In all instances, the units must NOT have "acted" yet.
Unit Selection
In order to Embark / Board a unit onto a TU one has to select it FIRST by clicking on its icon. Selecting it triggers the display of all land hexes that the unit can reach either on its own (LIGHT GREEN color) or via its Organic Transport (PALE YELLOW color) (if any).
Pressing the Button
One must press the Scenario Panel's Embark/Disembark button to get the unit Embarkation / Boarding going. Upon pressing that button, the unit icon changes to a TU one simultaneously triggering the display of all hexes the unit can reach via its TU (LIGHT GREEN color) or can immediately turn around and Disembark / Land onto (PALE YELLOW color).
Units enjoying Organic Transport capabilities must abandon their enabling "container" units prior to Boarding.
An Air Unit already situated directly above an Airfield hex renders Boarding through it infeasible.
Unit Follow-up Movement Is Optional
A player always has the option NOT to move his unit at all but rather to leave it in a "hanging" Embarked / Boarded state and proceed with other actions on the map. He does so by RIGHT-clicking anywhere on the map. He may choose to return to his unit later on during the same half-turn and do something with it or not return to it at all. Units in a "hanging" Embarked / Boarded state are NOT considered to have "completely acted" yet.
Unit Follow-up Movement
By clicking on one of the LIGHT GREEN colored hexes, the unit provisionally attempts to move to that hex in an Embarked / Boarded state. RIGHT-clicking anywhere on the map renders the unit's provisional movement permanent and the unit is finally considered as having "acted".
Unit Status Restoration Is Impossible
Unlike PGF's unit Mount/Dismount feature the invocation of which is NOT considered to be "acting", once a unit gets Embarked / Boarded, it CANNOT revert back to its state prior to Embarkation / Boarding "on the spot" without actually "acting" (i.e., Disembarking / Landing).
Unit Disembarkation / Landing
Unit Locations On the Map
Units Disembarking from NTUs must be on Body of Water, Embarkation City, Port City or Port Facilities hexes. Units Landing from ATUs must be OVER Airfield hexes; units enjoying para-drop capabilities are considerably less restricted in their choice of Landing hex. In all instances, the units must NOT have "acted" yet.
Unit Selection
In order to Disembark / Land a unit from a TU one has to select it FIRST by clicking on the TU's icon. Selecting it triggers the display of all hexes the unit can reach via its TU (LIGHT GREEN color) or can Disembark / Land onto (PALE YELLOW color).
Unit Disembarkation / Landing Is Optional
A player always has the option NOT to Disembark / Land the unit but rather to leave it in its hitherto Embarked / Boarded state and proceed with other actions on the map. He does so by RIGHT-clicking anywhere on the map. He may return to his unit later on during the same half-turn and do something with it or not return to it at all.
Unit Disembarkation / Landing: Quick vs. Thorough
One can certainly Disembark / Land a transported unit by clicking on one of the PALE YELLOW colored hexes. However, some suitable hexes the transported unit could potentially Disembark / Land onto MAY NOT be indicated. To render such hexes available for unit Disembarkation / Landing purposes one has to press the Scenario Panel's Embark / Disembark button.
Clicking on one of the PALE YELLOW colored hexes immediately Disembarks the unit onto the hex and displays the unit's icon. At this point, the unit is considered as having irreversibly "acted".
Surface units already located on hexes render those hexes situationally unsuitable for unit Disembarkation / Landing purposes.
Unit Status Restoration Is Impossible
Unlike PGF's unit Mount/Dismount feature the invocation of which is NOT considered to be "acting", once a unit gets Disembarked / Landed, it CANNOT revert back to its state prior to Disembarkation / Landing; it has already "acted".
Last edited by HexCode on 2022-04-23 19:21, Saturday, edited 1 time in total.
LISTED & UNLISTED COMBATANTS
LISTED & UNLISTED COMBATANTS
=============================
Listed Combatants -- Aligned Owned Hexes / Formally Aligned Units
Listed Combatants (LCs) are specified in scenario definition files *.PGSCN under the section entitled "Nations". The first column on the left entitled "Flag" displays the LC index IDs. The adjacent column on its immediate right entitled "Side" displays the Boolean settings "formally" assigning to each such LC membership to either one of the two Sides (neutrality is impossible). Hexes owned by LCs are often referred to as Aligned Owned Hexes (AOHs). Units owned by LCs are often referred to as Formally Aligned Units (FAUs).
PGF's engine requires the Listed presence of at least one Combatant aligned with Side 0 and at least one Combatant aligned with Side 1. This is foundational to the underlying programming !
Unlisted Combatants -- Non-Aligned Owned Hexes / Nominally Aligned Units
Hexes owned by Unlisted Combatants (UCs) (if any) are present at scenario's commencement and / or in-game. Their Combatant Ownership Representation (COR) index IDs are encountered in binary files *.SET (Section 4) and / or *.PGSAV (Section 7).
Units owned by UCs (if any) are encountered in scenario definition files *.PGSCN under the Section entitled "Units". The adjacent columns entitled "Side" and "Flag" display the "nominally" assigned, Boolean, Side-specific alignment (neutrality is impossible) and COR index ID corresponding to each such unit.
Hexes owned by UCs are often referred to as Non-Aligned Owned Hexes (NOHs). Units owned by UCs are often referred to as Nominally Aligned Units (NAUs).
Side Alignments: Extremely Important Clarification
From an underlying programming perspective, Side Alignment specifications encountered under file *PGSCN -- Sections entitled "Nations" and "Units" respectively are independent of one another; they control altogether different play system aspects.
=============================
Listed Combatants -- Aligned Owned Hexes / Formally Aligned Units
Listed Combatants (LCs) are specified in scenario definition files *.PGSCN under the section entitled "Nations". The first column on the left entitled "Flag" displays the LC index IDs. The adjacent column on its immediate right entitled "Side" displays the Boolean settings "formally" assigning to each such LC membership to either one of the two Sides (neutrality is impossible). Hexes owned by LCs are often referred to as Aligned Owned Hexes (AOHs). Units owned by LCs are often referred to as Formally Aligned Units (FAUs).
PGF's engine requires the Listed presence of at least one Combatant aligned with Side 0 and at least one Combatant aligned with Side 1. This is foundational to the underlying programming !
Unlisted Combatants -- Non-Aligned Owned Hexes / Nominally Aligned Units
Hexes owned by Unlisted Combatants (UCs) (if any) are present at scenario's commencement and / or in-game. Their Combatant Ownership Representation (COR) index IDs are encountered in binary files *.SET (Section 4) and / or *.PGSAV (Section 7).
Units owned by UCs (if any) are encountered in scenario definition files *.PGSCN under the Section entitled "Units". The adjacent columns entitled "Side" and "Flag" display the "nominally" assigned, Boolean, Side-specific alignment (neutrality is impossible) and COR index ID corresponding to each such unit.
Hexes owned by UCs are often referred to as Non-Aligned Owned Hexes (NOHs). Units owned by UCs are often referred to as Nominally Aligned Units (NAUs).
Side Alignments: Extremely Important Clarification
From an underlying programming perspective, Side Alignment specifications encountered under file *PGSCN -- Sections entitled "Nations" and "Units" respectively are independent of one another; they control altogether different play system aspects.
Last edited by HexCode on 2021-12-11 09:15, Saturday, edited 8 times in total.
UNIT UPGRADES & PURCHASES IN-GAME: COMBATANT PSEUDO-TAB DISPLAY DETAILS
UNIT UPGRADES & PURCHASES IN-GAME: COMBATANT PSEUDO-TAB DISPLAY DETAILS
==================================================================
Absolute Prerequisites
Unit Upgrade & Purchase Pop-up Screens
viewtopic.php?f=100&t=531#p9210
Units: Upgrades & Purchases
viewtopic.php?f=100&t=531#p9917
Listed & Unlisted Combatants
viewtopic.php?f=100&t=543#p11540
Combatant Pseudo-Tab Availability
1) The Unit Purchase Pop-up Screen displays the Combatant "flag pseudo-tabs" (traversing them from left to right) in the order of vertical appearance in files *.PGSCN under the section entitled "Nations"; NOT on the basis of Combatant ID index order.
2) A scenario map must feature at least ONE (1) City, Port or Airfield hex owned by a Listed Combatant (LC) for its corresponding "flag pseudo-tab" to be displayed on the Unit Purchase Pop-up Screen. Consequently, units CANNOT be purchased in-game on behalf of a Combatant who does not meet the aforesaid "minimum" requirement unless and until some prepositioned unit owned by the Combatant assumes the ownership of a hitherto enemy-owned City / Port / Airfield hex.
The above mentioned "minimum" requirement does NOT apply to LC-owned unit upgrades in-game. The Unit Upgrade Pop-up Screen is always accessible in principle.
3) "Flag pseudo-tabs" corresponding to Unlisted Combatants (UCs) are NEVER displayed on the Unit Purchase Pop-up Screen. In other words, units belonging to such UCs can NEVER be purchased in-game.
The Unit Upgrade Pop-up Screen is always accessible in principle for the purposes of upgrading UC-owned units in-game.
==================================================================
Absolute Prerequisites
Unit Upgrade & Purchase Pop-up Screens
viewtopic.php?f=100&t=531#p9210
Units: Upgrades & Purchases
viewtopic.php?f=100&t=531#p9917
Listed & Unlisted Combatants
viewtopic.php?f=100&t=543#p11540
Combatant Pseudo-Tab Availability
1) The Unit Purchase Pop-up Screen displays the Combatant "flag pseudo-tabs" (traversing them from left to right) in the order of vertical appearance in files *.PGSCN under the section entitled "Nations"; NOT on the basis of Combatant ID index order.
2) A scenario map must feature at least ONE (1) City, Port or Airfield hex owned by a Listed Combatant (LC) for its corresponding "flag pseudo-tab" to be displayed on the Unit Purchase Pop-up Screen. Consequently, units CANNOT be purchased in-game on behalf of a Combatant who does not meet the aforesaid "minimum" requirement unless and until some prepositioned unit owned by the Combatant assumes the ownership of a hitherto enemy-owned City / Port / Airfield hex.
The above mentioned "minimum" requirement does NOT apply to LC-owned unit upgrades in-game. The Unit Upgrade Pop-up Screen is always accessible in principle.
3) "Flag pseudo-tabs" corresponding to Unlisted Combatants (UCs) are NEVER displayed on the Unit Purchase Pop-up Screen. In other words, units belonging to such UCs can NEVER be purchased in-game.
The Unit Upgrade Pop-up Screen is always accessible in principle for the purposes of upgrading UC-owned units in-game.
Last edited by HexCode on 2021-11-27 06:31, Saturday, edited 9 times in total.
PORTS: ENEMY NAVAL TARGET EVICTION
PORTS: ENEMY NAVAL TARGET EVICTION
====================================
A Very Special Situation
When
--- A Ground unit
--- Of a certain Class
--- Sporting a positive Naval Attack value
--- NOT having run out of Ammo
attempts to
--- Attack an enemy Naval Target
--- Situated on a Port City / Facilities hex
--- In a Non-Ranged manner
NO actual combat takes place; instead, the enemy Naval Target is automatically dislodged from its Port City / Facilities hex.
If NO adjacent, empty hex can be retreated to as per the enemy Naval Target's Movement Type capabilities, the enemy Naval Target gets eliminated on the spot.
Specifics
1) Only Infantry, Tank and Recon Class units can dislodge enemy Naval Targets from Port City / Facilities hexes.
2) Enemy Submarine Class Naval Targets CANNOT be dislodged; period !
3) The enemy Naval Target's Movement Type determines the possible hexes the enemy Naval Target could be retreated to. If the Movement Type is NOT Naval, Body of Water hexes CANNOT be retreated to (advanced modding).
4) When it comes to an enemy Naval Target which is a Dual-Mode, Composite unit, it is its active Mode instance which triggers "Port Eviction" events (advanced modding). However, the hexes that the unit is allowed to be retreated to are governed by the "transported" unit's Movement Type, not that of the "Transport".
An Extraordinary, Surprising Finding
When an Infantry / Tank / Recon Class unit:
A) Possessing Ranged Attack capabilities, and
B) NOT being adjacent to the enemy Naval Target which is situated on a Port City / Facilities hex
attempts to dislodge the enemy Naval Target in "Make-Believe Ranged Attack" fashion, NO actual combat takes place. Instead, the enemy Naval Target gets "scuttled" (i.e., eliminated) on the spot irrespective of the existence of empty, terrain-suitable hexes the enemy Naval Target could otherwise be retreated to... !!!
====================================
A Very Special Situation
When
--- A Ground unit
--- Of a certain Class
--- Sporting a positive Naval Attack value
--- NOT having run out of Ammo
attempts to
--- Attack an enemy Naval Target
--- Situated on a Port City / Facilities hex
--- In a Non-Ranged manner
NO actual combat takes place; instead, the enemy Naval Target is automatically dislodged from its Port City / Facilities hex.
If NO adjacent, empty hex can be retreated to as per the enemy Naval Target's Movement Type capabilities, the enemy Naval Target gets eliminated on the spot.
Specifics
1) Only Infantry, Tank and Recon Class units can dislodge enemy Naval Targets from Port City / Facilities hexes.
2) Enemy Submarine Class Naval Targets CANNOT be dislodged; period !
3) The enemy Naval Target's Movement Type determines the possible hexes the enemy Naval Target could be retreated to. If the Movement Type is NOT Naval, Body of Water hexes CANNOT be retreated to (advanced modding).
4) When it comes to an enemy Naval Target which is a Dual-Mode, Composite unit, it is its active Mode instance which triggers "Port Eviction" events (advanced modding). However, the hexes that the unit is allowed to be retreated to are governed by the "transported" unit's Movement Type, not that of the "Transport".
An Extraordinary, Surprising Finding
When an Infantry / Tank / Recon Class unit:
A) Possessing Ranged Attack capabilities, and
B) NOT being adjacent to the enemy Naval Target which is situated on a Port City / Facilities hex
attempts to dislodge the enemy Naval Target in "Make-Believe Ranged Attack" fashion, NO actual combat takes place. Instead, the enemy Naval Target gets "scuttled" (i.e., eliminated) on the spot irrespective of the existence of empty, terrain-suitable hexes the enemy Naval Target could otherwise be retreated to... !!!
Last edited by HexCode on 2021-11-18 01:46, Thursday, edited 1 time in total.
UNIT RECONSTITUTION: EXPERIENCE POINT DILUTION
UNIT RECONSTITUTION: EXPERIENCE POINT DILUTION
===============================================
Preliminaries
Strength Factor Procurement: Details
viewtopic.php?f=100&t=543#p9879
features a rather exhaustive coverage of the topic. Enemy unit adjacency, extremely limited Prestige Point availability or some other play system rule might not allow for the full reconstitution of a unit on the spot. To this effect, an under-strength unit may
--- either be fully reconstituted to TEN (10) Strength Factors (SFs)
--- or be partially reconstituted to LESS THAN TEN (10) SFs
during a single turn.
Normal Replacements always dilute a reconstituted unit's Experience Point Rating (EPR) in that the thusly reconstituted unit's EPR is lower than its EPR immediately prior to reconstitution.
The Formula
On the basis of exact results obtained via extensive experimentation, the Experience Point Dilution formula actually utilized by PGF's engine has been "deciphered". Nevertheless, the relevant subroutine has NOT yet been identified.
IEPR = Initial Experience Point Rating
PSF = Procured Strength Factors
REPR = Resulting Experience Point Rating
REPR = IEPR * [1 - (PSF/10)]
Clearly, the more Procured SFs, the more pronounced the Experience Point Dilution Effect.
Because PGF's engine engages in integer arithmetic, the formula assumes the following computationally-friendly form:
REPR = [IEPR * (10 - PSF)] / 10
with all results being ROUNDED DOWN.
Algebraic Operations
RBEPR = Resulting Baseline Experience Point Rating
PEPR = Procured Experience Point Rating
RSF = Resulting Strength Factors
ISF + PSF = RSF ==> PSF = RSF - ISF
Algebraically substituting PSF:
REPR = IEPR * {1 - [(RSF - ISF)/10]} = IEPR * (ISF/10) + IEPR * [1 - (RSF/10)]
Symbolically:
REPR = RBEPR + PEPR
Formula Interpretations
RBEPR = IEPR * (ISF/10)
hypothetically applies to a unit's full reconstitution effected on the spot. This is a "Baseline" situation where the Procured SFs enter the scene "Green" (i.e., PEPR = 0).
PEPR = IEPR * [1 - (RSF/10)]
applies to a unit's partial reconstitution effected on the spot. This is a situation where the Procured SFs enter the scene with a positive EPR (i.e., PEPR > 0).
Partially Reconstituted Units: Key Implications
1) Partial reconstitution of a unit is accomplished via Normal Replacements which are NOT "Green" (i.e., PEPR > 0). This effect amounts to Experience Point Dilution Retardation.
2) The smaller the resulting size of a partially reconstituted unit, the larger the Experience Point Rating of the Procured SFs.
===============================================
Preliminaries
Strength Factor Procurement: Details
viewtopic.php?f=100&t=543#p9879
features a rather exhaustive coverage of the topic. Enemy unit adjacency, extremely limited Prestige Point availability or some other play system rule might not allow for the full reconstitution of a unit on the spot. To this effect, an under-strength unit may
--- either be fully reconstituted to TEN (10) Strength Factors (SFs)
--- or be partially reconstituted to LESS THAN TEN (10) SFs
during a single turn.
Normal Replacements always dilute a reconstituted unit's Experience Point Rating (EPR) in that the thusly reconstituted unit's EPR is lower than its EPR immediately prior to reconstitution.
The Formula
On the basis of exact results obtained via extensive experimentation, the Experience Point Dilution formula actually utilized by PGF's engine has been "deciphered". Nevertheless, the relevant subroutine has NOT yet been identified.
IEPR = Initial Experience Point Rating
PSF = Procured Strength Factors
REPR = Resulting Experience Point Rating
REPR = IEPR * [1 - (PSF/10)]
Clearly, the more Procured SFs, the more pronounced the Experience Point Dilution Effect.
Because PGF's engine engages in integer arithmetic, the formula assumes the following computationally-friendly form:
REPR = [IEPR * (10 - PSF)] / 10
with all results being ROUNDED DOWN.
Algebraic Operations
RBEPR = Resulting Baseline Experience Point Rating
PEPR = Procured Experience Point Rating
RSF = Resulting Strength Factors
ISF + PSF = RSF ==> PSF = RSF - ISF
Algebraically substituting PSF:
REPR = IEPR * {1 - [(RSF - ISF)/10]} = IEPR * (ISF/10) + IEPR * [1 - (RSF/10)]
Symbolically:
REPR = RBEPR + PEPR
Formula Interpretations
RBEPR = IEPR * (ISF/10)
hypothetically applies to a unit's full reconstitution effected on the spot. This is a "Baseline" situation where the Procured SFs enter the scene "Green" (i.e., PEPR = 0).
PEPR = IEPR * [1 - (RSF/10)]
applies to a unit's partial reconstitution effected on the spot. This is a situation where the Procured SFs enter the scene with a positive EPR (i.e., PEPR > 0).
Partially Reconstituted Units: Key Implications
1) Partial reconstitution of a unit is accomplished via Normal Replacements which are NOT "Green" (i.e., PEPR > 0). This effect amounts to Experience Point Dilution Retardation.
2) The smaller the resulting size of a partially reconstituted unit, the larger the Experience Point Rating of the Procured SFs.
HEX COMBATANT OWNERSHIP AGNOSTICISM
HEX COMBATANT OWNERSHIP AGNOSTICISM
=======================================
Contrary to certain received impressions, the actual Combatant Ownership status of City / Port / Airfield hexes is immaterial when it comes to friendly units:
a) Being Upgraded in-game.
b) Embarking onto Naval Transports.
c) Boarding Air Transports.
Enemy owned or neutralized hexes do just fine !
=======================================
Contrary to certain received impressions, the actual Combatant Ownership status of City / Port / Airfield hexes is immaterial when it comes to friendly units:
a) Being Upgraded in-game.
b) Embarking onto Naval Transports.
c) Boarding Air Transports.
Enemy owned or neutralized hexes do just fine !
UNIT COLLOCATION DETERMINANTS
UNIT COLLOCATION DETERMINANTS
===============================
Unit Collocation Restrictions
In the now distant past, SSI informed the hobby that, in-game:
a) No TWO (2) Ground / Naval Super-Class units can ever be located ON the same hex.
b) No TWO (2) Air Super-Class units can ever be located OVER the same hex.
c) ONE (1) Ground / Naval Super-Class unit and ONE (1) Air Super-Class unit can be accommodated ON / OVER the same hex, respectively.
Important: If one attempts to violate the above restrictions by suitably editing the contents of scenario file *.PGSCN, thereby specifying "duplicate" map hex coordinates applicable to prepositioned units he intends to collocate, PGF's engine goes through an automatic, serial, sorting process which unceremoniously discards units intended for "illegal" collocation.
Unit Collocation Sole Determinant
It turns out that, as far as PGF's engine is "concerned":
--- NEITHER Unit Class
--- NOR Movement Type
have anything to do with the ability to collocate units.
RATHER:
It is TARGET TYPE which solely matters. Specifically:
1) NO TWO (2) Soft / Hard / Naval Targets can ever be located ON the same hex.
2) NO TWO (2) Air Targets can ever be located OVER the same hex.
3) Up to ONE (1) Soft / Hard / Naval Target and ONE (1) Air Target can be accommodated ON / OVER the same hex, respectively.
===============================
Unit Collocation Restrictions
In the now distant past, SSI informed the hobby that, in-game:
a) No TWO (2) Ground / Naval Super-Class units can ever be located ON the same hex.
b) No TWO (2) Air Super-Class units can ever be located OVER the same hex.
c) ONE (1) Ground / Naval Super-Class unit and ONE (1) Air Super-Class unit can be accommodated ON / OVER the same hex, respectively.
Important: If one attempts to violate the above restrictions by suitably editing the contents of scenario file *.PGSCN, thereby specifying "duplicate" map hex coordinates applicable to prepositioned units he intends to collocate, PGF's engine goes through an automatic, serial, sorting process which unceremoniously discards units intended for "illegal" collocation.
Unit Collocation Sole Determinant
It turns out that, as far as PGF's engine is "concerned":
--- NEITHER Unit Class
--- NOR Movement Type
have anything to do with the ability to collocate units.
RATHER:
It is TARGET TYPE which solely matters. Specifically:
1) NO TWO (2) Soft / Hard / Naval Targets can ever be located ON the same hex.
2) NO TWO (2) Air Targets can ever be located OVER the same hex.
3) Up to ONE (1) Soft / Hard / Naval Target and ONE (1) Air Target can be accommodated ON / OVER the same hex, respectively.
DMCU MOUNT / DISMOUNT & MOVEMENT CAPABILITIES
DMCU MOUNT / DISMOUNT & MOVEMENT CAPABILITIES
===============================================
Absolute Prerequisite
Dual-Mode, Composite Units
viewtopic.php?f=100&t=540#p8965
DMCUs: Mount / Dismount Capabilities & Restrictions
A DMCU's Currently Passive Mode can only be rendered Active ON / OVER a hex that would be situationally accessible by the Currently Passive unit and vice versa.
Taking SSI's "flagship" content and its emulations, consider the rather illustrative situation where an Infantry Class unit having Half-Tracked Organic Transport somehow finds itself on a Swamp hex under Muddy Ground Conditions.
a) If the Infantry Class unit is already Passive (i.e., Mounted), PGF's engine DOES allow it to be rendered Active via on-the-spot Dismounting.
b) If, on the other hand, the Infantry Class unit is already Active (i.e., Dismounted), PGF's engine DOES NOT allow it to be rendered Passive via on-the-spot Mounting; reason being, the hex is NOT situationally accessible by the Half-Tracked Organic Transport unit.
Important: Roadwork underlying a hex often DOES allow accessibility despite the underlying terrain type.
DMCUs: Mode Movement Capabilities
A DMCU can only move or retreat to hexes that are accessible by both constituent units (i.e., "Main" Unit and "Container" Unit). Moreover, the situationally Passive Mode constituent unit's Movement Allowance value has no bearing whatsoever on the situationally Active Mode constituent unit's movement capabilities.
Staying with the example above, the Infantry Class unit on its own could certainly enter Muddy Ground hexes, no questions asked. However, the Half-Tracked Organic Transport unit simply cannot. Since DMCU constituent components are virtually inseparable, the Infantry Class unit must "stay with" its Half-Tracked Organic Transport, for better or worse (i.e., mode concordance constraint).
Important: Roadwork underlying a hex often DOES allow accessibility despite the underlying terrain type.
DMCUs: An "Advanced" Modding Example
Consider
"Anchored" Garrison Units
viewtopic.php?f=100&t=540#p8971
The main idea here is to "construct" DMCUs consisting of ordinary Ground Super-Class units and "Transporter" units sporting a Naval Movement Type. Barring a handful of special situations, PGF's engine DOES NOT allow the Ground Super-Class units to be Mounted; reason being, the land hexes are NOT situationally accessible by "Transporter" units. Also, barring, once again, a handful of special situations, the Ground Super-Class units cannot enter hexes which are readily enterable by "Transporter" units and vice versa. Mathematically speaking, the intersection is virtually the null set. For all practical purposes, such DMCUs cannot move or be retreated !
===============================================
Absolute Prerequisite
Dual-Mode, Composite Units
viewtopic.php?f=100&t=540#p8965
DMCUs: Mount / Dismount Capabilities & Restrictions
A DMCU's Currently Passive Mode can only be rendered Active ON / OVER a hex that would be situationally accessible by the Currently Passive unit and vice versa.
Taking SSI's "flagship" content and its emulations, consider the rather illustrative situation where an Infantry Class unit having Half-Tracked Organic Transport somehow finds itself on a Swamp hex under Muddy Ground Conditions.
a) If the Infantry Class unit is already Passive (i.e., Mounted), PGF's engine DOES allow it to be rendered Active via on-the-spot Dismounting.
b) If, on the other hand, the Infantry Class unit is already Active (i.e., Dismounted), PGF's engine DOES NOT allow it to be rendered Passive via on-the-spot Mounting; reason being, the hex is NOT situationally accessible by the Half-Tracked Organic Transport unit.
Important: Roadwork underlying a hex often DOES allow accessibility despite the underlying terrain type.
DMCUs: Mode Movement Capabilities
A DMCU can only move or retreat to hexes that are accessible by both constituent units (i.e., "Main" Unit and "Container" Unit). Moreover, the situationally Passive Mode constituent unit's Movement Allowance value has no bearing whatsoever on the situationally Active Mode constituent unit's movement capabilities.
Staying with the example above, the Infantry Class unit on its own could certainly enter Muddy Ground hexes, no questions asked. However, the Half-Tracked Organic Transport unit simply cannot. Since DMCU constituent components are virtually inseparable, the Infantry Class unit must "stay with" its Half-Tracked Organic Transport, for better or worse (i.e., mode concordance constraint).
Important: Roadwork underlying a hex often DOES allow accessibility despite the underlying terrain type.
DMCUs: An "Advanced" Modding Example
Consider
"Anchored" Garrison Units
viewtopic.php?f=100&t=540#p8971
The main idea here is to "construct" DMCUs consisting of ordinary Ground Super-Class units and "Transporter" units sporting a Naval Movement Type. Barring a handful of special situations, PGF's engine DOES NOT allow the Ground Super-Class units to be Mounted; reason being, the land hexes are NOT situationally accessible by "Transporter" units. Also, barring, once again, a handful of special situations, the Ground Super-Class units cannot enter hexes which are readily enterable by "Transporter" units and vice versa. Mathematically speaking, the intersection is virtually the null set. For all practical purposes, such DMCUs cannot move or be retreated !
COMBATANT-OWNED HEXES: PROPERTIES
COMBATANT-OWNED HEXES: PROPERTIES
====================================
Absolute Prerequisite
Listed & Unlisted Combatants
viewtopic.php?f=100&t=543#p11540
Terminology
Owned Hex
A Port City / Port Facility / Embarkation City / Non-Naval City / Airfield hex owned by a Combatant or Neutralized.
Designated Ground Unit Type (DGUT)
A Ground Super-Class unit assigned to one of the following Unit Classes: Infantry / Tank / Recon / Anti-Tank.
DGUT Having Entered An Owned Hex
A DGUT having found itself ON an Owned Hex during its half-turn as a result of it having:
a) Been prepositioned ON the Owned Hex (first half-turns only); or
b) Just Disembarked / Air Landed / Air Dropped ONTO the Owned Hex; or
c) Just Entered the Owned Hex during its movement phase.
DGUT Having Captured An Owned Hex
A DGUT which, upon having Entered an Owned Hex, has effected a change in that Hex's Combatant Ownership Status.
Owned Hexes: Origins
Scenario definition files *.SET (Section 4) contain Combatant hex ownership data which specify the status of such hexes at scenario's commencement. By themselves, these files are completely agnostic as to whether the specified Combatants are Listed or Unlisted. It is data residing within scenario definition files *.PGSCN -- Section entitled "Nations" which complete the picture.
Owned Hex Side Alignment
--- Hexes owned by Listed Combatants (LCs) are Side-Aligned as per the data appearing in file *.PGSCN -- Section entitled "Nations" under the column entitled "Side".
--- Hexes owned by Unlisted Combatants (UCs) do NOT exhibit any Side Alignment (SA) whatsoever.
Owned Hex Spotting Behavior
Port City / Port Facility / Embarkation City / Non-Naval City / Airfield hexes exhibit spotting capabilities fully consistent with the SA of the LCs that own them. Consequently, UC-Owned hexes do NOT provide spotting services to either Side.
Owned Hex Captures
Upon having entered an Owned Hex, a DGUT unit captures it UNLESS:
1) Just prior to the hex-entry, both the unit and the hex are owned by one and the same Combatant; OR
2) The DGUT unit is owned by a LC that shares the same SA (as per file *.PGSCN -- Section entitled "Nations" data) with the hex which is LC-Owned as well and the DGUT unit's SA (as per file *.PGSCN -- Section entitled "Units" data) "agrees" with the hex's SA. [In other words, LC-Owned DGUT units belonging to the same Side and sporting normally corresponding SAs CANNOT capture each other's Owned Hexes]; OR
3) The DGUT unit is owned by a UC while the hex is owned by a LC and the DGUT unit's SA (as per file *.PGSCN -- Section entitled "Units" data) "agrees" with the hex's SA (as per file *.PGSCN -- Section entitled "Nations" data).
"Carpet Bombing" Restrictions
Unscouted and / or Empty UC-Owned hexes can NEVER be subjected to "Carpet Bombing" attacks by Level Bomber Class units. However, the visual presence of units sporting enemy Side SAs on such hexes DOES allow "Carpet Bombing" to proceed normally.
====================================
Absolute Prerequisite
Listed & Unlisted Combatants
viewtopic.php?f=100&t=543#p11540
Terminology
Owned Hex
A Port City / Port Facility / Embarkation City / Non-Naval City / Airfield hex owned by a Combatant or Neutralized.
Designated Ground Unit Type (DGUT)
A Ground Super-Class unit assigned to one of the following Unit Classes: Infantry / Tank / Recon / Anti-Tank.
DGUT Having Entered An Owned Hex
A DGUT having found itself ON an Owned Hex during its half-turn as a result of it having:
a) Been prepositioned ON the Owned Hex (first half-turns only); or
b) Just Disembarked / Air Landed / Air Dropped ONTO the Owned Hex; or
c) Just Entered the Owned Hex during its movement phase.
DGUT Having Captured An Owned Hex
A DGUT which, upon having Entered an Owned Hex, has effected a change in that Hex's Combatant Ownership Status.
Owned Hexes: Origins
Scenario definition files *.SET (Section 4) contain Combatant hex ownership data which specify the status of such hexes at scenario's commencement. By themselves, these files are completely agnostic as to whether the specified Combatants are Listed or Unlisted. It is data residing within scenario definition files *.PGSCN -- Section entitled "Nations" which complete the picture.
Owned Hex Side Alignment
--- Hexes owned by Listed Combatants (LCs) are Side-Aligned as per the data appearing in file *.PGSCN -- Section entitled "Nations" under the column entitled "Side".
--- Hexes owned by Unlisted Combatants (UCs) do NOT exhibit any Side Alignment (SA) whatsoever.
Owned Hex Spotting Behavior
Port City / Port Facility / Embarkation City / Non-Naval City / Airfield hexes exhibit spotting capabilities fully consistent with the SA of the LCs that own them. Consequently, UC-Owned hexes do NOT provide spotting services to either Side.
Owned Hex Captures
Upon having entered an Owned Hex, a DGUT unit captures it UNLESS:
1) Just prior to the hex-entry, both the unit and the hex are owned by one and the same Combatant; OR
2) The DGUT unit is owned by a LC that shares the same SA (as per file *.PGSCN -- Section entitled "Nations" data) with the hex which is LC-Owned as well and the DGUT unit's SA (as per file *.PGSCN -- Section entitled "Units" data) "agrees" with the hex's SA. [In other words, LC-Owned DGUT units belonging to the same Side and sporting normally corresponding SAs CANNOT capture each other's Owned Hexes]; OR
3) The DGUT unit is owned by a UC while the hex is owned by a LC and the DGUT unit's SA (as per file *.PGSCN -- Section entitled "Units" data) "agrees" with the hex's SA (as per file *.PGSCN -- Section entitled "Nations" data).
"Carpet Bombing" Restrictions
Unscouted and / or Empty UC-Owned hexes can NEVER be subjected to "Carpet Bombing" attacks by Level Bomber Class units. However, the visual presence of units sporting enemy Side SAs on such hexes DOES allow "Carpet Bombing" to proceed normally.
Last edited by HexCode on 2021-12-11 12:26, Saturday, edited 1 time in total.
OWNED HEX ENTRY: PRESTIGE POINT AWARDS
OWNED HEX ENTRY: PRESTIGE POINT AWARDS
=========================================
Absolute Prerequisite
Combatant-Owned Hexes: Properties
viewtopic.php?f=100&t=543#p12143
Hex Specificity
Under certain conditions, upon a Designated Ground Unit Type (DGUT) unit having entered an Owned Hex, the Side which "agrees" with the DGUT unit's Side Alignment (SA) (as per file *.PGSCN -- Section entitled "Units" data) is awarded a specific Prestige Point (PP) amount. PGF individualizes PP awards earned upon hex-entry. It does so via the specification of the intended, individualized values appearing under file *.PGSCN -- Section entitled "Supply hexes". Any Owned Hexes which are NOT listed therein are automatically assigned default values of EIGHTY (80) or FORTY (40) PPs by PGF's engine depending on whether they are objective hexes or not, respectively.
Prestige Point Awards: Restrictions
With respect to some particular Owned Hex:
1) Each Side is limited to receiving AT MOST ONE (1) PP Award throughout the scenario's entire duration.
2) The PP Award is granted to a specific Side upon the FIRST EVER hex-entry by a DGUT unit the SA (as per file *.PGSCN -- Section entitled "Units" data) of which "agrees" with that specific Side.
3) A PP Award is NEVER granted if the hex is owned by a Listed Combatant whose SA (as per file *.PGSCN -- Section entitled "Nations" data) "agrees" with the DGUT unit's SA (as per file *.PGSCN -- Section entitled "Units" data).
=========================================
Absolute Prerequisite
Combatant-Owned Hexes: Properties
viewtopic.php?f=100&t=543#p12143
Hex Specificity
Under certain conditions, upon a Designated Ground Unit Type (DGUT) unit having entered an Owned Hex, the Side which "agrees" with the DGUT unit's Side Alignment (SA) (as per file *.PGSCN -- Section entitled "Units" data) is awarded a specific Prestige Point (PP) amount. PGF individualizes PP awards earned upon hex-entry. It does so via the specification of the intended, individualized values appearing under file *.PGSCN -- Section entitled "Supply hexes". Any Owned Hexes which are NOT listed therein are automatically assigned default values of EIGHTY (80) or FORTY (40) PPs by PGF's engine depending on whether they are objective hexes or not, respectively.
Prestige Point Awards: Restrictions
With respect to some particular Owned Hex:
1) Each Side is limited to receiving AT MOST ONE (1) PP Award throughout the scenario's entire duration.
2) The PP Award is granted to a specific Side upon the FIRST EVER hex-entry by a DGUT unit the SA (as per file *.PGSCN -- Section entitled "Units" data) of which "agrees" with that specific Side.
3) A PP Award is NEVER granted if the hex is owned by a Listed Combatant whose SA (as per file *.PGSCN -- Section entitled "Nations" data) "agrees" with the DGUT unit's SA (as per file *.PGSCN -- Section entitled "Units" data).
COMPLETELY UNENTERABLE HEXES: PROPERTIES
COMPLETELY UNENTERABLE HEXES: PROPERTIES
===========================================
Completely unenterable hexes (i.e., "Neutral" hexes) sport LIGHT GREEN hexagonal frames.
Restrictions
--- NO unit can EVER enter such a hex in-game. For greater clarity, units subject to automatic, forced retreats can NEVER be retreated onto such hexes.
--- NO newly purchased units can EVER be placed ON / OVER such hexes.
Unimpacted Properties & Operations
With respect to prepositioned units ON / OVER such hexes:
1) They can leave normally.
2) Their spotting capabilities are unaffected.
3) Their Zones of Control (ZoC) are unaffected.
4) They can be disbanded.
5) They can be resupplied without observing any special particularities.
6) They can receive replacements (including over-strengthening) without observing any special particularities.
7) They can be upgraded if ON / OVER such hexes which are also Combatant-Owned ones.
8) They can engage in combat normally.
In addition, the spotting capabilities of such hexes which are also Combatant-Owned ones are unaffected.
===========================================
Completely unenterable hexes (i.e., "Neutral" hexes) sport LIGHT GREEN hexagonal frames.
Restrictions
--- NO unit can EVER enter such a hex in-game. For greater clarity, units subject to automatic, forced retreats can NEVER be retreated onto such hexes.
--- NO newly purchased units can EVER be placed ON / OVER such hexes.
Unimpacted Properties & Operations
With respect to prepositioned units ON / OVER such hexes:
1) They can leave normally.
2) Their spotting capabilities are unaffected.
3) Their Zones of Control (ZoC) are unaffected.
4) They can be disbanded.
5) They can be resupplied without observing any special particularities.
6) They can receive replacements (including over-strengthening) without observing any special particularities.
7) They can be upgraded if ON / OVER such hexes which are also Combatant-Owned ones.
8) They can engage in combat normally.
In addition, the spotting capabilities of such hexes which are also Combatant-Owned ones are unaffected.
LEVEL BOMBING - KEY ELEMENTS
LEVEL BOMBING - KEY ELEMENTS
===========================
Absolute Prerequisites
Level Bombing
viewtopic.php?f=100&t=531#p14523
Listed & Unlisted Combatants
viewtopic.php?f=100&t=543#p11540
Level Bombing: Two Types
Carpet Bombing - Level Bombing of surface units aligned with the enemy side.
Strategic Bombing - Level Bombing of certain cities, ports and airfields.
It is important to note that the very same Level Bombing (LB) run can entail both Carpet and Strategic Bombing (CB & SB) aspects. This is the case where a surface unit aligned with the enemy side (other than a Submarine Class one) is situated right ON a city / port / airfield hex the ownership status of which is either aligned with the enemy side or non-aligned.
Level Bombing: Listed Accuracy Rating
File EQUIPMENT.PGEQP assigns a LB Listed Accuracy Rating (LAR) to each Level Bomber Class unit type therein. The values appear in column the heading of which PGF's Developer / Programmer introduced as "Bomber Special".
Computationally speaking, LB LARs lie at the heart of PGF's LB-specific programming.
Level Bombing: Provisional Efficiency
The effects of LB attacks are largely based on the following Provisional Efficiency (PE) formula:
PE = (LAR / 10) * S + 10 * EL
(rounded down) where S is the number of an LB Class unit's Strength Factors (SFs) effectively participating in the attack and EL is the number of the said unit's Experience Levels (ELs).
1) Under Overcast Skies, ONLY HALF ( 1 / 2 ) of an LB Class unit's Strength Factors (SFs) get to even attempt to actively participate in the attack (rounded down, 1 SF minimum).
2) Participating LB unit SFs eliminated by enemy Fighter / Air Defense unit interception / indirect support fire immediately preceding the LB run are EXCLUDED from S. However, suppressed SFs are INCLUDED !! This inclusion flies in the face of the logic and attendant calculations underlying all other interception / indirect support fire event types...
===========================
Absolute Prerequisites
Level Bombing
viewtopic.php?f=100&t=531#p14523
Listed & Unlisted Combatants
viewtopic.php?f=100&t=543#p11540
Level Bombing: Two Types
Carpet Bombing - Level Bombing of surface units aligned with the enemy side.
Strategic Bombing - Level Bombing of certain cities, ports and airfields.
It is important to note that the very same Level Bombing (LB) run can entail both Carpet and Strategic Bombing (CB & SB) aspects. This is the case where a surface unit aligned with the enemy side (other than a Submarine Class one) is situated right ON a city / port / airfield hex the ownership status of which is either aligned with the enemy side or non-aligned.
Level Bombing: Listed Accuracy Rating
File EQUIPMENT.PGEQP assigns a LB Listed Accuracy Rating (LAR) to each Level Bomber Class unit type therein. The values appear in column the heading of which PGF's Developer / Programmer introduced as "Bomber Special".
Computationally speaking, LB LARs lie at the heart of PGF's LB-specific programming.
Level Bombing: Provisional Efficiency
The effects of LB attacks are largely based on the following Provisional Efficiency (PE) formula:
PE = (LAR / 10) * S + 10 * EL
(rounded down) where S is the number of an LB Class unit's Strength Factors (SFs) effectively participating in the attack and EL is the number of the said unit's Experience Levels (ELs).
1) Under Overcast Skies, ONLY HALF ( 1 / 2 ) of an LB Class unit's Strength Factors (SFs) get to even attempt to actively participate in the attack (rounded down, 1 SF minimum).
2) Participating LB unit SFs eliminated by enemy Fighter / Air Defense unit interception / indirect support fire immediately preceding the LB run are EXCLUDED from S. However, suppressed SFs are INCLUDED !! This inclusion flies in the face of the logic and attendant calculations underlying all other interception / indirect support fire event types...
CARPET BOMBING - DETAILS
CARPET BOMBING - DETAILS
========================
Absolute Prerequisites
Level Bombing
viewtopic.php?f=100&t=531#p14523
Listed & Unlisted Combatants
viewtopic.php?f=100&t=543#p11540
Level Bombing - Key Elements
viewtopic.php?f=100&t=543#p14525
Target Unit Strength Factor Elimination(s)
Carpet Bombing (CB) is NOT allowed to impact surface units other than enemy-aligned ones.
Strength Factor (SF) Elimination results strictly adhere to the engine's coded specifications as they apply to combat in general. To this effect, Broken Up LB unit attacks result in NO enemy target unit SF Eliminations.
Target Unit Strength Factor Suppression(s)
Suppression inflicted on enemy surface units by Level Bomber (LB) attacks lasts until the very end of the current half-turn (Persistent / Durable Suppression).
Broken Up LB unit attacks result in NO enemy target unit SF Suppression(s).
The number of suppressed SFs equals the sum of:
The Suppression results strictly adhering to the engine's coded specifications as they apply to combat in general (this time around, the LB unit's suppressed SFs due to interception / indirect support fire are NOT allowed to attack).
PLUS
LAR / 10
where LAR stands for LB Listed Accuracy Rating. It is important to note that this summand is independent of the number of LB unit SFs involved, their Experience Levels (ELs) and prevailing atmospheric conditions...
Important: The resulting sum total CANNOT exceed the target unit's surviving SFs (Calibrated Suppression).
HOWEVER:
There is an exception here. An enemy target unit can be subjected to TWO (2) LB attacks during one and the same half-turn. The first attack could be carried out by an LB unit which, at the start of its movement phase, already finds itself located OVER the enemy target unit. The LB unit would attack and immediately fly away so that another LB unit could fly to the vacated airspace and attack as well. In this case, the suppression inflicted by the second attack "simply" gets added to the Calibrated Suppression resulting from the first attack regardless of the target unit's ultimately surviving SFs...
No Fuel / Ammo Loss Situations
There are are two LB unit attack situations which leave the enemy-aligned target unit's Fuel and Ammo Points completely unscathed; namely, instances where:
a) The LB unit's attack is Broken Up due to overwhelmingly effective enemy interception / indirect support fire.
b) The LB unit engages in a "blind" run against a currently unscouted city / port / airfield hex ON which an enemy-aligned surface unit happens to be situated.
Carpet Bombing Efficiency
Carpet Bombing Efficiency (CBE) represents the resulting enemy-aligned surface unit's Fuel and Ammo Point losses expressed as one and the same percentage of that attacked unit's respective Listed Fuel and Ammo Capacities.
File EQUIPMENT.PGEQP assigns Listed Fuel & Ammo Capacities (LFC & LAC, respectively) to each unit type therein. The values appear in columns the headings of which PGF's Developer / Programmer introduced as "Max Fuel" and "Max Ammo", respectively.
CBE = PE
where PE stands for Provisional Efficiency.
PGF's engine interprets values greater than ONE HUNDRED (100) as 100%.
Special Features & Observations
Fuel Points
CB per se can NEVER further reduce an enemy-aligned surface unit's LAST remaining Fuel Points if such Points are EQUAL TO OR LESS than the said unit's Listed Movement Allowance (LMA).
File EQUIPMENT.PGEQP assigns a Listed Movement Allowance (LMA) to each unit type therein. The values appear in column the heading of which PGF's Developer / Programmer introduced as "Movement".
Ammo Points
CB per se can NEVER eliminate an enemy-aligned surface unit's LAST remaining Ammo Point.
Attention: Ammo Point losses due to CB do NOT include that extra Ammo Point which may be expended by an enemy-aligned Air Defense or Anti-Air(craft) Class unit responding to a targeted attack upon it by the LB unit.
========================
Absolute Prerequisites
Level Bombing
viewtopic.php?f=100&t=531#p14523
Listed & Unlisted Combatants
viewtopic.php?f=100&t=543#p11540
Level Bombing - Key Elements
viewtopic.php?f=100&t=543#p14525
Target Unit Strength Factor Elimination(s)
Carpet Bombing (CB) is NOT allowed to impact surface units other than enemy-aligned ones.
Strength Factor (SF) Elimination results strictly adhere to the engine's coded specifications as they apply to combat in general. To this effect, Broken Up LB unit attacks result in NO enemy target unit SF Eliminations.
Target Unit Strength Factor Suppression(s)
Suppression inflicted on enemy surface units by Level Bomber (LB) attacks lasts until the very end of the current half-turn (Persistent / Durable Suppression).
Broken Up LB unit attacks result in NO enemy target unit SF Suppression(s).
The number of suppressed SFs equals the sum of:
The Suppression results strictly adhering to the engine's coded specifications as they apply to combat in general (this time around, the LB unit's suppressed SFs due to interception / indirect support fire are NOT allowed to attack).
PLUS
LAR / 10
where LAR stands for LB Listed Accuracy Rating. It is important to note that this summand is independent of the number of LB unit SFs involved, their Experience Levels (ELs) and prevailing atmospheric conditions...
Important: The resulting sum total CANNOT exceed the target unit's surviving SFs (Calibrated Suppression).
HOWEVER:
There is an exception here. An enemy target unit can be subjected to TWO (2) LB attacks during one and the same half-turn. The first attack could be carried out by an LB unit which, at the start of its movement phase, already finds itself located OVER the enemy target unit. The LB unit would attack and immediately fly away so that another LB unit could fly to the vacated airspace and attack as well. In this case, the suppression inflicted by the second attack "simply" gets added to the Calibrated Suppression resulting from the first attack regardless of the target unit's ultimately surviving SFs...
No Fuel / Ammo Loss Situations
There are are two LB unit attack situations which leave the enemy-aligned target unit's Fuel and Ammo Points completely unscathed; namely, instances where:
a) The LB unit's attack is Broken Up due to overwhelmingly effective enemy interception / indirect support fire.
b) The LB unit engages in a "blind" run against a currently unscouted city / port / airfield hex ON which an enemy-aligned surface unit happens to be situated.
Carpet Bombing Efficiency
Carpet Bombing Efficiency (CBE) represents the resulting enemy-aligned surface unit's Fuel and Ammo Point losses expressed as one and the same percentage of that attacked unit's respective Listed Fuel and Ammo Capacities.
File EQUIPMENT.PGEQP assigns Listed Fuel & Ammo Capacities (LFC & LAC, respectively) to each unit type therein. The values appear in columns the headings of which PGF's Developer / Programmer introduced as "Max Fuel" and "Max Ammo", respectively.
CBE = PE
where PE stands for Provisional Efficiency.
PGF's engine interprets values greater than ONE HUNDRED (100) as 100%.
Special Features & Observations
Fuel Points
CB per se can NEVER further reduce an enemy-aligned surface unit's LAST remaining Fuel Points if such Points are EQUAL TO OR LESS than the said unit's Listed Movement Allowance (LMA).
File EQUIPMENT.PGEQP assigns a Listed Movement Allowance (LMA) to each unit type therein. The values appear in column the heading of which PGF's Developer / Programmer introduced as "Movement".
Ammo Points
CB per se can NEVER eliminate an enemy-aligned surface unit's LAST remaining Ammo Point.
Attention: Ammo Point losses due to CB do NOT include that extra Ammo Point which may be expended by an enemy-aligned Air Defense or Anti-Air(craft) Class unit responding to a targeted attack upon it by the LB unit.
Last edited by HexCode on 2023-11-17 23:18, Friday, edited 1 time in total.
STRATEGIC BOMBING - DETAILS
STRATEGIC BOMBING - DETAILS
===========================
Absolute Prerequisites
Level Bombing
viewtopic.php?f=100&t=531#p14523
Listed & Unlisted Combatants
viewtopic.php?f=100&t=543#p11540
Level Bombing - Key Elements
viewtopic.php?f=100&t=543#p14525
Strategic Bombing: Restrictions
Level Bombing (LB) of certain city, port and airfield hexes constitutes Strategic Bombing (SB). If allowed at all, SB may result in EITHER Target Hex Neutralization OR Enemy Prestige Point (PP) Losses BUT NEVER BOTH SIMULTANEOUSLY.
As far as SB restrictions go:
a) SB gets altogether aborted whenever the LB unit's attack is Broken Up due to overwhelmingly effective enemy interception / indirect support fire.
b) SB of hexes owned by Friendly Listed Combatants (FLCs) is NEVER allowed.
c) SB of Neutralized hexes or hexes owned by Unlisted Combatants (UCs) is ONLY
allowed IF AND ONLY IF enemy-aligned surface units happen to be situated ON such hexes.
d) SB of Objective (i.e., Victory) hexes can NEVER trigger Target Hex Neutralizations.
e) SB of a Non-Objective (i.e., Non-Victory) hexes can NEVER trigger Enemy PP Losses.
Strategic Bombing Efficiency
Strategic Bombing Efficiency (SBE)
SBE = PE
UNLESS an enemy-aligned surface unit (other than a Submarine Class one) happens to be situated ON the hex under attack, in which case
SBE = PE / 2
(rounded down). PE stands for Provisional Efficiency.
Prestige Point Losses
The PP Losses (PPL) inflicted upon the enemy due to SB are equal to
PPL = SBE / 2
(rounded down).
Target Hex Neutralization Percentage Likelihood
The percentage chances of Target Hex Neutralization (THNPL) due to SB are equal to
THNPL = SBE
PGF's engine interprets values greater than ONE HUNDRED (100) as certainty.
===========================
Absolute Prerequisites
Level Bombing
viewtopic.php?f=100&t=531#p14523
Listed & Unlisted Combatants
viewtopic.php?f=100&t=543#p11540
Level Bombing - Key Elements
viewtopic.php?f=100&t=543#p14525
Strategic Bombing: Restrictions
Level Bombing (LB) of certain city, port and airfield hexes constitutes Strategic Bombing (SB). If allowed at all, SB may result in EITHER Target Hex Neutralization OR Enemy Prestige Point (PP) Losses BUT NEVER BOTH SIMULTANEOUSLY.
As far as SB restrictions go:
a) SB gets altogether aborted whenever the LB unit's attack is Broken Up due to overwhelmingly effective enemy interception / indirect support fire.
b) SB of hexes owned by Friendly Listed Combatants (FLCs) is NEVER allowed.
c) SB of Neutralized hexes or hexes owned by Unlisted Combatants (UCs) is ONLY
allowed IF AND ONLY IF enemy-aligned surface units happen to be situated ON such hexes.
d) SB of Objective (i.e., Victory) hexes can NEVER trigger Target Hex Neutralizations.
e) SB of a Non-Objective (i.e., Non-Victory) hexes can NEVER trigger Enemy PP Losses.
Strategic Bombing Efficiency
Strategic Bombing Efficiency (SBE)
SBE = PE
UNLESS an enemy-aligned surface unit (other than a Submarine Class one) happens to be situated ON the hex under attack, in which case
SBE = PE / 2
(rounded down). PE stands for Provisional Efficiency.
Prestige Point Losses
The PP Losses (PPL) inflicted upon the enemy due to SB are equal to
PPL = SBE / 2
(rounded down).
Target Hex Neutralization Percentage Likelihood
The percentage chances of Target Hex Neutralization (THNPL) due to SB are equal to
THNPL = SBE
PGF's engine interprets values greater than ONE HUNDRED (100) as certainty.