[VP] Play System: Advanced Features

Librarian: HexCode
Post Reply
HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

[VP] Play System: Advanced Features

Post by HexCode » 2021-04-04 00:29, Sunday

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

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

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

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
Last edited by HexCode on 2021-12-02 16:08, Thursday, edited 34 times in total.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

VICTORY CONDITIONS: TERMINOLOGY

Post by HexCode » 2021-04-04 00:36, Sunday

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.

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-11-28 06:28, Sunday, edited 2 times in total.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

UNIT PRESTIGE & EXPERIENCE MODIFIERS

Post by HexCode » 2021-04-04 00:45, Sunday

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).
Last edited by HexCode on 2021-06-06 19:11, Sunday, edited 4 times in total.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

"CHEAT" CODES

Post by HexCode » 2021-04-04 00:50, Sunday

"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.
Last edited by HexCode on 2021-10-27 05:15, Wednesday, edited 5 times in total.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

INDIRECT SUPPORT FIRE

Post by HexCode » 2021-04-04 00:57, Sunday

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...
Last edited by HexCode on 2021-05-18 06:22, Tuesday, edited 1 time in total.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

SURPRISE UNIT COLLISIONS: OVERVIEW

Post by HexCode » 2021-04-04 01:04, Sunday

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.
Last edited by HexCode on 2021-10-30 03:34, Saturday, edited 3 times in total.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

SURPRISE UNIT COLLISIONS: COMBAT AVOIDANCE

Post by HexCode » 2021-04-04 01:09, Sunday

SURPRISE UNIT COLLISIONS: COMBAT AVOIDANCE
===========================================

In the immediately preceding post, I wrote:
If the hitherto hidden stationary unit sports either a bracketed or a ZERO (0) combat-relevant Attack value, no combat ensues.
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.

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.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

SURPRISE UNIT COLLISIONS: PORT EVENTS

Post by HexCode » 2021-04-04 01:13, Sunday

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.
Last edited by HexCode on 2021-10-30 03:22, Saturday, edited 3 times in total.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

UNIT REINFORCEMENTS: TYPOLOGY

Post by HexCode » 2021-05-12 04:04, Wednesday

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.
Last edited by HexCode on 2021-06-01 01:33, Tuesday, edited 8 times in total.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

UNIT REINFORCEMENTS: PRESTIGE COSTS

Post by HexCode » 2021-05-15 05:35, Saturday

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.
Last edited by HexCode on 2021-11-23 11:58, Tuesday, edited 1 time in total.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

STRENGTH FACTOR PROCUREMENT: DETAILS

Post by HexCode » 2021-05-29 02:12, Saturday

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:

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+                        0
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 City / Port hex, NO SF Replacements whatsoever 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
By exception, Naval Transport Class units are subject to the Full Chart (encountered earlier under this post) applicable to Ground / Air Super-Class units.
Last edited by HexCode on 2021-10-30 03:39, Saturday, edited 3 times in total.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

GETTING RID OF ORGANIC TRANSPORT

Post by HexCode » 2021-06-09 19:17, Wednesday

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... :)
Last edited by HexCode on 2021-10-12 03:15, Tuesday, edited 1 time in total.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

SUBMARINE CLASS UNIT DETECTION

Post by HexCode » 2021-09-10 01:10, Friday

SUBMARINE CLASS UNIT DETECTION
===============================

SSI Says...

From SSI's PG1-DOS manual:
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.
Well, that is "something". When it comes to verification guidance, "something" is usually better than "nothing"...

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

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

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

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.00
The "cumulative story" certainly tempts one to conclude that P=0.50 is, indeed, the "true" probability.

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

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

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

NAVAL TRANSPORT: DETAILS

Post by HexCode » 2021-10-05 07:12, Tuesday

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:

Code: Select all

Terrain               UTR
Types                 Designations

Bodies of Water       04h, 05h, 06h, 07h
Rough Desert          22h
Escarpment            23h, 24h
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.
Last edited by HexCode on 2021-10-20 05:58, Wednesday, edited 4 times in total.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

UNIT AUTO-UPGRADES

Post by HexCode » 2021-10-11 22:58, Monday

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...
Last edited by HexCode on 2021-11-13 06:35, Saturday, edited 1 time in total.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

UNIT DEPLOYMENT: BOARDED OR NOT ?

Post by HexCode » 2021-10-12 23:56, Tuesday

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 !

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

SUBMARINE CLASS UNIT EVASION (Part I)

Post by HexCode » 2021-10-15 17:57, Friday

SUBMARINE CLASS UNIT EVASION (Part I)
====================================

Prima's PG Official Strategy Guide Says...
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...
Well, that is "something". When it comes to verification guidance, "something" is usually better than "nothing"...

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.00
The "cumulative story" certainly tempts one to conclude that P=0.50 might, indeed, be the "true" probability.

Friendly 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.00
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.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

SUBMARINE CLASS UNIT EVASION (Part II)

Post by HexCode » 2021-10-15 18:03, Friday

SUBMARINE CLASS UNIT EVASION (Part II)
====================================

Prima's PG Official Strategy Guide Says...
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...
Well, that is "something". When it comes to verification guidance, "something" is usually better than "nothing"...

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

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

UNIT PARA-DROP AIR DRIFT

Post by HexCode » 2021-10-15 18:13, Friday

UNIT PARA-DROP AIR DRIFT
========================

SSI's PG1-DOS Manual Says...
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.
Pretty... laconic !

Prima's PG Official Strategy Guide Says...
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 !
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...

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, 24h
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

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.00
Not picture perfect but it is certainly plausible that the "true" probability might actually be P=0.50.

Designated "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.00
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.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

RUGGED DEFENSE EVENT CHANCE

Post by HexCode » 2021-10-18 19:47, Monday

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

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

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

AIR TRANSPORT: DETAILS

Post by HexCode » 2021-10-19 04:51, Tuesday

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

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

TRANSPORT POINT... OVERUSE

Post by HexCode » 2021-10-22 04:49, Friday

TRANSPORT POINT... OVERUSE
===========================

Preliminaries

Elsewhere in the Library:
Going 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 !
Prepositioned... Violators

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:
TPs lost due to combat cannot be replaced in-game; they are gone for good !
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 ! :P Any such losses will be reducing "MM"; tough ! In fact, "MM" could even end up in NEGATIVE territory and be displayed as such ! :bonk

Non-Positive Values

Non-positive "ff" and / or "MM" values prohibit any in-game friendly unit Embarkations whatsoever.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

CITY & PORT TYPOLOGY

Post by HexCode » 2021-10-25 22:35, Monday

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.
Last edited by HexCode on 2021-10-29 22:26, Friday, edited 1 time in total.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

TRANSPORT MODE CLASSES: ATTACK PROPERTIES

Post by HexCode » 2021-10-25 23:05, Monday

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.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

PURCHASED UNIT PLACEMENT: ENEMY PRESENCE ADJACENCY

Post by HexCode » 2021-10-25 23:29, Monday

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:
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}.
There is a subtle semantic difference here. Mere enemy presence is NOT good enough. One or more enemy units have to occupy "their" hexes.

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

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

CORE UNIT DEPLOYMENT: DETAILS

Post by HexCode » 2021-10-25 23:47, Monday

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.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

UNIT EMBARKATION & DISEMBARKATION: PROCEDURAL DETAILS

Post by HexCode » 2021-10-27 01:10, Wednesday

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 unit by clicking on one of the PALE YELLOW colored hexes. However, suitable Disembarkation / Landing hexes the TU could potentially move to ARE NOT indicated. To render such hexes available for unit Disembarkation / Landing purposes one has to press the 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 them 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".

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

LISTED & UNLISTED COMBATANTS

Post by HexCode » 2021-10-27 04:44, Wednesday

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

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).
Last edited by HexCode on 2021-12-06 15:56, Monday, edited 6 times in total.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

UNIT UPGRADES & PURCHASES IN-GAME: COMBATANT PSEUDO-TAB DISPLAY DETAILS

Post by HexCode » 2021-10-27 05:09, Wednesday

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.
Last edited by HexCode on 2021-11-27 06:31, Saturday, edited 9 times in total.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

PORTS: ENEMY NAVAL TARGET EVICTION

Post by HexCode » 2021-11-12 06:00, Friday

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... !!!
Last edited by HexCode on 2021-11-18 01:46, Thursday, edited 1 time in total.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

UNIT RECONSTITUTION: EXPERIENCE POINT DILUTION

Post by HexCode » 2021-11-12 19:42, Friday

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.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

HEX COMBATANT OWNERSHIP AGNOSTICISM

Post by HexCode » 2021-12-02 12:26, Thursday

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 !

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

UNIT COLLOCATION DETERMINANTS

Post by HexCode » 2021-12-02 12:43, Thursday

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.

HexCode
First Lieutenant
First Lieutenant
Posts: 755
Joined: 2019-09-30 18:54, Monday

DMCU MOUNT / DISMOUNT & MOVEMENT CAPABILITIES

Post by HexCode » 2021-12-02 13:06, Thursday

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 !

Post Reply