[VM] Advanced Technical Know-How
[VM] Advanced Technical Know-How
CONTENT LINKS
==============
Introduction
viewtopic.php?f=100&t=540#p8962
Plain Text Files: Accommodating Unicode Characters
viewtopic.php?f=100&t=540#p11092
Map Frames
viewtopic.php?f=100&t=540#p9906
Standalone Scenario Play: Core & Auxiliary Unit Designation Uses
viewtopic.php?f=100&t=540#p11375
Unit Type Descriptor Display: How Long ?
viewtopic.php?f=100&t=540#p11152
City & Port Type Visual Differentiation
viewtopic.php?f=100&t=540#p11525
Scenario Panel Button... Surgery
viewtopic.php?f=100&t=540#p11492
Scenario Duration: Technical Specification
viewtopic.php?f=100&t=540#p11782
Campaign Inter-Scenario Replacements
viewtopic.php?f=100&t=540#p8963
Unit Class Purchase Accessibility
viewtopic.php?f=100&t=540#p8964
Restricting Unit Purchases
viewtopic.php?f=100&t=540#p9909
Restricting Unit Replacements
viewtopic.php?f=100&t=540#p9910
Restricting Unit Over-Strengthening
viewtopic.php?f=100&t=540#p11445
Enabling Naval Unit Purchases
viewtopic.php?f=100&t=540#p9911
Restricting Unit Experience Gains
viewtopic.php?f=100&t=540#p8966
Prepositioned Units: "Unorthodox" Entrenchments
viewtopic.php?f=100&t=540#p12142
Core Complement: "Unorthodox" Restrictions
viewtopic.php?f=100&t=540#p11529
Objective Hex Complete Unenterability: Victory Determination Implications
viewtopic.php?f=100&t=540#p12141
Negative Prestige Points
viewtopic.php?f=100&t=540#p9993
Dual-Mode, Composite Units
viewtopic.php?f=100&t=540#p8965
"Anchored" Garrison Units
viewtopic.php?f=100&t=540#p8971
Glider-Borne Units
viewtopic.php?f=100&t=540#p8968
Land Minefield Units
viewtopic.php?f=100&t=540#p11401
Roadwork Problem "Sniffers"
viewtopic.php?f=100&t=540#p9907
===================================================================
The topic's contents may be modified or progressively added upon as time goes by.
===================================================================
INTRODUCTION
==============
This topic should be of interest to Veteran Modders (VMs). It is assumed that the reader is already intimately familiar with the information featured here:
[NP] Introductory Documentation
viewtopic.php?f=100&t=531
"Ambitious" Novice Modders (NMs) are most definitely welcome !
==============
Introduction
viewtopic.php?f=100&t=540#p8962
Plain Text Files: Accommodating Unicode Characters
viewtopic.php?f=100&t=540#p11092
Map Frames
viewtopic.php?f=100&t=540#p9906
Standalone Scenario Play: Core & Auxiliary Unit Designation Uses
viewtopic.php?f=100&t=540#p11375
Unit Type Descriptor Display: How Long ?
viewtopic.php?f=100&t=540#p11152
City & Port Type Visual Differentiation
viewtopic.php?f=100&t=540#p11525
Scenario Panel Button... Surgery
viewtopic.php?f=100&t=540#p11492
Scenario Duration: Technical Specification
viewtopic.php?f=100&t=540#p11782
Campaign Inter-Scenario Replacements
viewtopic.php?f=100&t=540#p8963
Unit Class Purchase Accessibility
viewtopic.php?f=100&t=540#p8964
Restricting Unit Purchases
viewtopic.php?f=100&t=540#p9909
Restricting Unit Replacements
viewtopic.php?f=100&t=540#p9910
Restricting Unit Over-Strengthening
viewtopic.php?f=100&t=540#p11445
Enabling Naval Unit Purchases
viewtopic.php?f=100&t=540#p9911
Restricting Unit Experience Gains
viewtopic.php?f=100&t=540#p8966
Prepositioned Units: "Unorthodox" Entrenchments
viewtopic.php?f=100&t=540#p12142
Core Complement: "Unorthodox" Restrictions
viewtopic.php?f=100&t=540#p11529
Objective Hex Complete Unenterability: Victory Determination Implications
viewtopic.php?f=100&t=540#p12141
Negative Prestige Points
viewtopic.php?f=100&t=540#p9993
Dual-Mode, Composite Units
viewtopic.php?f=100&t=540#p8965
"Anchored" Garrison Units
viewtopic.php?f=100&t=540#p8971
Glider-Borne Units
viewtopic.php?f=100&t=540#p8968
Land Minefield Units
viewtopic.php?f=100&t=540#p11401
Roadwork Problem "Sniffers"
viewtopic.php?f=100&t=540#p9907
===================================================================
The topic's contents may be modified or progressively added upon as time goes by.
===================================================================
INTRODUCTION
==============
This topic should be of interest to Veteran Modders (VMs). It is assumed that the reader is already intimately familiar with the information featured here:
[NP] Introductory Documentation
viewtopic.php?f=100&t=531
"Ambitious" Novice Modders (NMs) are most definitely welcome !
Last edited by HexCode on 2021-12-11 09:00, Saturday, edited 17 times in total.
CAMPAIGN INTER-SCENARIO REPLACEMENTS
CAMPAIGN INTER-SCENARIO REPLACEMENTS
======================================
Preliminaries
File PG.PGCAM contains settings collectively defining one or more than one (serially related) Campaigns. There is a section in that file entitled "Entry points" (PGF programmer's choice of text). Each line in that section corresponds to one and only one Campaign definition. The section's last column is entitled "Free elite replacements" (once again, PGF programmer's choice of text). All column values are Boolean (i.e., 0 or 1).
In my opinion, the text "Free elite replacements" is rather unfortunate and potentially misleading. I mean, what is the Boolean negation ? Paid for Elite Replacements ? And, if so, how and when ? More to the point, what are modders supposed to understand, let alone, do with these Boolean settings ?
Mechanism
Ok, let us take a good look at how PGF's engine precisely "interprets" the aforesaid Boolean setting's values and subsequently acts upon such "interpretations".
The first thing that PGF's engine "wants to know" is whether all under-strength Core units (if any) should be built up back to full strength immediately prior to the usual Campaign Inter-Scenario Core Unit Automatic Transfers.
If the Boolean setting's value is ZERO (0), PGF's engine does nothing. Consequently, all under-strength Core units (if any) enter the upcoming scenario in their prior under-strength states exactly.
If the Boolean setting's value is ONE (1), PGF's engine "knows" that it has to build up all under-strength Core units (if any) back to full strength. But how exactly ? Well, PGF's engine "dictates" the following as well:
a) All building up of under-strength Core units back to full strength should be done via Elite Replacements only.
AND
b) No prestige costs whatsoever should be incurred by the player in the context of the granting of Elite Replacements mandated under preceding point (a).
Key Observations
1) Campaign Inter-Scenario Replacements can never be Normal. Consequently,
2) The Accumulated Prestige Experience (APE) values of Core Units can never be decreased (i.e., APE dilution) due to Campaign Inter-Scenario Core Unit Automatic Transfers.
3) Obviously, other things being equal, a Boolean setting the value of which is ZERO (0) renders the Campaign more challenging for the "Campaigning" Side compared to the Campaign's alternate realities under a value of ONE (1). Specifically, a Boolean setting the value of which is ZERO (0) presents the campaigning Side with choices and decisions as to what to do, if anything, with under-strength Core Units (if any) at the start of each scenario and in-game as well.
======================================
Preliminaries
File PG.PGCAM contains settings collectively defining one or more than one (serially related) Campaigns. There is a section in that file entitled "Entry points" (PGF programmer's choice of text). Each line in that section corresponds to one and only one Campaign definition. The section's last column is entitled "Free elite replacements" (once again, PGF programmer's choice of text). All column values are Boolean (i.e., 0 or 1).
In my opinion, the text "Free elite replacements" is rather unfortunate and potentially misleading. I mean, what is the Boolean negation ? Paid for Elite Replacements ? And, if so, how and when ? More to the point, what are modders supposed to understand, let alone, do with these Boolean settings ?
Mechanism
Ok, let us take a good look at how PGF's engine precisely "interprets" the aforesaid Boolean setting's values and subsequently acts upon such "interpretations".
The first thing that PGF's engine "wants to know" is whether all under-strength Core units (if any) should be built up back to full strength immediately prior to the usual Campaign Inter-Scenario Core Unit Automatic Transfers.
If the Boolean setting's value is ZERO (0), PGF's engine does nothing. Consequently, all under-strength Core units (if any) enter the upcoming scenario in their prior under-strength states exactly.
If the Boolean setting's value is ONE (1), PGF's engine "knows" that it has to build up all under-strength Core units (if any) back to full strength. But how exactly ? Well, PGF's engine "dictates" the following as well:
a) All building up of under-strength Core units back to full strength should be done via Elite Replacements only.
AND
b) No prestige costs whatsoever should be incurred by the player in the context of the granting of Elite Replacements mandated under preceding point (a).
Key Observations
1) Campaign Inter-Scenario Replacements can never be Normal. Consequently,
2) The Accumulated Prestige Experience (APE) values of Core Units can never be decreased (i.e., APE dilution) due to Campaign Inter-Scenario Core Unit Automatic Transfers.
3) Obviously, other things being equal, a Boolean setting the value of which is ZERO (0) renders the Campaign more challenging for the "Campaigning" Side compared to the Campaign's alternate realities under a value of ONE (1). Specifically, a Boolean setting the value of which is ZERO (0) presents the campaigning Side with choices and decisions as to what to do, if anything, with under-strength Core Units (if any) at the start of each scenario and in-game as well.
Last edited by HexCode on 2021-06-01 02:20, Tuesday, edited 1 time in total.
UNIT CLASS PURCHASE ACCESSIBILITY
UNIT CLASS PURCHASE ACCESSIBILITY
=================================
"Classic" Content
Those hobbyists who never venture into scenario territory other than SSI's PG1 / AG stock one (i.e., SSI's 38 plus 39 original scenarios adapted for play under PGF) are always greeted by a truncated list of Unit Classes (UCs) that can be purchased via PGF's New Unit Purchase (NUP) Screen (invoked by clicking the button depicting a dollar sign).
Given a particular SSI-vintage scenario, the following typical section embedded in the relevant scenario definition file xxx.PGSCN (residing in the \SCENARIO\ sub-folder), among other things, "instructs" PGF's User Interface (UI) to visually activate (literally, give the green light) on the NUP Screen those UCs (decimal format identifiers) which sport "1" (Boolean) designations right next to them and only those:
UCs 7, 11, 12, 13, 14, 16 and 17 are nowhere to be found in the preceding xxx.PGSCN section. The engine "interprets" this... glaring absence as a "0" (Boolean) designation and keeps such UCs in a dormant (i.e., inaccessible) state when it comes to effecting NUPs throughout the scenario's duration.
Wanting More...
Some modders may wish to visually activate even more UCs on the NUP Screen. The logical, straightforward thing to do is, of course, to vertically expand the foregoing xxx.PGSCN section by adding entries identifying the UCs that a modder may wish to visually activate as well, among other things. Not surprisingly, a typical such entry would comprise the relevant decimal format identifier of the UC featuring an "1" (Boolean) designation right next to it. For example:
among other things, "instructs" PGF's UI to visually activate the Submarine UC on the NUP Screen.
The List Is Too Long
Unfortunately, PGF's (stock) UI cannot fully handle the visuals triggered by an "instruction" to activate the full UC set. The culprit here is none other than the file PURCHASE.HTM residing in the \UI\ sub-folder.
Ok, Then, Just Replace
The following is the suggested HTML code replacement of the contents of PURCHASE.HTM that should do the trick by introducing a scroll list:
By the way, the unambiguous terminological designation "Structure" has replaced "Forts", let alone, "Fortifications"... Moreover, not every "Capital Ship" is a... "Battleship"; therefore...
=================================
"Classic" Content
Those hobbyists who never venture into scenario territory other than SSI's PG1 / AG stock one (i.e., SSI's 38 plus 39 original scenarios adapted for play under PGF) are always greeted by a truncated list of Unit Classes (UCs) that can be purchased via PGF's New Unit Purchase (NUP) Screen (invoked by clicking the button depicting a dollar sign).
Given a particular SSI-vintage scenario, the following typical section embedded in the relevant scenario definition file xxx.PGSCN (residing in the \SCENARIO\ sub-folder), among other things, "instructs" PGF's User Interface (UI) to visually activate (literally, give the green light) on the NUP Screen those UCs (decimal format identifiers) which sport "1" (Boolean) designations right next to them and only those:
Code: Select all
# Purchasable Unit Classes
# Class Can Purchase
0 1
1 1
2 1
3 1
4 1
5 1
6 1
8 1
9 1
10 1
15 1
Wanting More...
Some modders may wish to visually activate even more UCs on the NUP Screen. The logical, straightforward thing to do is, of course, to vertically expand the foregoing xxx.PGSCN section by adding entries identifying the UCs that a modder may wish to visually activate as well, among other things. Not surprisingly, a typical such entry would comprise the relevant decimal format identifier of the UC featuring an "1" (Boolean) designation right next to it. For example:
Code: Select all
11 1
The List Is Too Long
Unfortunately, PGF's (stock) UI cannot fully handle the visuals triggered by an "instruction" to activate the full UC set. The culprit here is none other than the file PURCHASE.HTM residing in the \UI\ sub-folder.
Ok, Then, Just Replace
The following is the suggested HTML code replacement of the contents of PURCHASE.HTM that should do the trick by introducing a scroll list:
Code: Select all
<html.dialog style="overflow:hidden">
<link rel="stylesheet" type="text/css" href="axis.css">
<body.dialog style="font-family: tahoma; color: @BUTTON_TEXT_COLOR; overflow:hidden">
<div style="left:1#; top:1#; bottom:2#; width: 130px; overflow:hidden">
<div id="Header">
<img src="purchase_header.png" />
</div>
<div>
<table style="position:relative; top: 3px;">
<tr><td.pgbtn2 id="cmd_ok" disabled>
<div style="color: @BUTTON_ETCHED_TEXT_COLOR" id="PurchaseText">PURCHASE</div><div style="position: relative; bottom: 13px" id="PurchaseText">PURCHASE</div>
</td></tr>
<tr><td.pgbtn2 id="cmd_cancel">
<div style="color: @BUTTON_ETCHED_TEXT_COLOR">EXIT</div><div style="position: relative; bottom: 13px">EXIT</div>
</td></tr>
</table>
</div>
<div style="margin-top: 10px; position: relative; height: 14px; overflow: hidden" id="FlagList">
<table>
<tr id="Tr1">
<td.flagbtn type="radio" name="flag"><img.flagbtn_int src="flag01.png" /></td>
<td.flagbtn type="radio" name="flag"><img.flagbtn_int src="flag02.png" /></td>
<td.flagbtn type="radio" name="flag"><img.flagbtn_int src="flag03.png" /></td>
<td.flagbtn type="radio" name="flag"><img.flagbtn_int src="flag04.png" /></td>
<td.flagbtn type="radio" name="flag"><img.flagbtn_int src="flag05.png" /></td>
</tr>
</table>
</div>
<div style="height: 388px; overflow: auto">
<table style="margin-top: 10px" id="ClassList">
<tr><td.pgbtn2 type="radio" style="behavior: radio;" name="unitclass" id="unitclass0">
<div style="color: @BUTTON_ETCHED_TEXT_COLOR">Infantry</div><div style="position: relative; bottom: 13px">Infantry</div>
</td></tr>
<tr><td.pgbtn2 type="radio" style="behavior: radio;" name="unitclass" id="unitclass1">
<div style="color: @BUTTON_ETCHED_TEXT_COLOR">Tank</div><div style="position: relative; bottom: 13px">Tank</div>
</td></tr>
<tr><td.pgbtn2 type="radio" style="behavior: radio;" name="unitclass" id="unitclass2">
<div style="color: @BUTTON_ETCHED_TEXT_COLOR">Recon</div><div style="position: relative; bottom: 13px">Recon</div>
</td></tr>
<tr><td.pgbtn2 type="radio" style="behavior: radio;" name="unitclass" id="unitclass3">
<div style="color: @BUTTON_ETCHED_TEXT_COLOR">Anti-Tank</div><div style="position: relative; bottom: 13px">Anti-Tank</div>
</td></tr>
<tr><td.pgbtn2 type="radio" style="behavior: radio;" name="unitclass" id="unitclass4">
<div style="color: @BUTTON_ETCHED_TEXT_COLOR">Artillery</div><div style="position: relative; bottom: 13px">Artillery</div>
</td></tr>
<tr><td.pgbtn2 type="radio" style="behavior: radio;" name="unitclass" id="unitclass5">
<div style="color: @BUTTON_ETCHED_TEXT_COLOR">Anti-Aircraft</div><div style="position: relative; bottom: 13px">Anti-Aircraft</div>
</td></tr>
<tr><td.pgbtn2 type="radio" style="behavior: radio;" name="unitclass" id="unitclass6">
<div style="color: @BUTTON_ETCHED_TEXT_COLOR">Air Defense</div><div style="position: relative; bottom: 13px">Air Defense</div>
</td></tr>
<tr><td.pgbtn2 type="radio" style="behavior: radio;" name="unitclass" id="unitclass7">
<div style="color: @BUTTON_ETCHED_TEXT_COLOR">Structure</div><div style="position: relative; bottom: 13px">Structure</div>
</td></tr>
<tr><td.pgbtn2 type="radio" style="behavior: radio;" name="unitclass" id="unitclass8">
<div style="color: @BUTTON_ETCHED_TEXT_COLOR">Fighter</div><div style="position: relative; bottom: 13px">Fighter</div>
</td></tr>
<tr><td.pgbtn2 type="radio" style="behavior: radio;" name="unitclass" id="unitclass9">
<div style="color: @BUTTON_ETCHED_TEXT_COLOR">Tac Bomber</div><div style="position: relative; bottom: 13px">Tac Bomber</div>
</td></tr>
<tr><td.pgbtn2 type="radio" style="behavior: radio;" name="unitclass" id="unitclass10">
<div style="color: @BUTTON_ETCHED_TEXT_COLOR">Level Bomber</div><div style="position: relative; bottom: 13px">Level Bomber</div>
</td></tr>
<tr><td.pgbtn2 type="radio" style="behavior: radio;" name="unitclass" id="unitclass11">
<div style="color: @BUTTON_ETCHED_TEXT_COLOR">Submarine</div><div style="position: relative; bottom: 13px">Submarine</div>
</td></tr>
<tr><td.pgbtn2 type="radio" style="behavior: radio;" name="unitclass" id="unitclass12">
<div style="color: @BUTTON_ETCHED_TEXT_COLOR">Destroyer</div><div style="position: relative; bottom: 13px">Destroyer</div>
</td></tr>
<tr><td.pgbtn2 type="radio" style="behavior: radio;" name="unitclass" id="unitclass13">
<div style="color: @BUTTON_ETCHED_TEXT_COLOR">Capital Ship</div><div style="position: relative; bottom: 13px">Capital Ship</div>
</td></tr>
<tr><td.pgbtn2 type="radio" style="behavior: radio;" name="unitclass" id="unitclass14">
<div style="color: @BUTTON_ETCHED_TEXT_COLOR">Air Carrier</div><div style="position: relative; bottom: 13px">Air Carrier</div>
</td></tr>
<tr><td.pgbtn2 type="radio" style="behavior: radio;" name="unitclass" id="unitclass15">
<div style="color: @BUTTON_ETCHED_TEXT_COLOR">Ground Xport</div><div style="position: relative; bottom: 13px">Ground Xport</div>
</td></tr>
<tr><td.pgbtn2 type="radio" style="behavior: radio;" name="unitclass" id="unitclass16">
<div style="color: @BUTTON_ETCHED_TEXT_COLOR">Air Xport</div><div style="position: relative; bottom: 13px">Air Xport</div>
</td></tr>
<tr><td.pgbtn2 type="radio" style="behavior: radio;" name="unitclass" id="unitclass17">
<div style="color: @BUTTON_ETCHED_TEXT_COLOR">Naval Xport</div><div style="position: relative; bottom: 13px">Naval Xport</div>
</td></tr>
</table>
</div>
<div style="height: 100%%"/>
</div>
<div.sunken class="background" style="left:2#; top:1#; height:100%%; width: 100%%">
<widget.typelist type="select" id="UnitList">
</widget>
</div>
<div.sunken class="background" style="left:2#; top:2#; height:127; width: 100%%">
<widget.typelist type="select" id="TransportList">
</widget>
</div>
<div style="left:3#; top:1#; bottom:2#; height:100%%; width: 170; overflow: hidden">
<div style="text-align: center">
<img src="purchase_panel.png" />
<div style="margin-left: 20px; position: relative; top: -76px">Prestige: <span id="Prestige">99999</span></div>
<div style="position: relative; top: -63px">
<p style="margin:-2; padding:0">UNITS AVAILABLE</p>
<table><tr>
<td align=left>Core: <span id="CoreUnits">999</span></td>
<td style="width: 5px;"></td>
<td align=right>Auxiliary: <span id="AuxUnits">999</span></td>
</tr></table>
</div>
<div style="position: relative; top: -53px">Total cost: <span id="TotalCost">0</span></div>
</div>
<div style="color: @TEXT_COLOR; text-align:center; font-family: Arial; position: relative; top: -30px" id="UnitStats">
<div class="background" id="UnitBlock">
<p id="UnitType">Wehr Inf</p>
<table cellspacing=-1 cellpadding=0>
<tr>
<td>
<table cellspacing=-1 cellpadding=0>
<tr><td align=right style="width: 63px">Cost</td></tr>
<tr style="height: 5px"><td/></tr>
<tr><td align=right>Max Ammo</td></tr>
<tr><td align=right>Max Fuel</td></tr>
<tr style="height: 5px"><td/></tr>
<tr><td align=right>Movement</td></tr>
<tr><td align=right>Spotting</td></tr>
<tr><td align=right>Range</td></tr>
<tr><td align=right>Initiative</td></tr>
<tr style="height: 5px"><td/></tr>
<tr><td align=right>Soft Attack</td></tr>
<tr><td align=right>Hard Attack</td></tr>
<tr><td align=right>Air Attack</td></tr>
<tr><td align=right>Naval Attack</td></tr>
<tr style="height: 5px"><td/></tr>
<tr><td align=right>Ground Def</td></tr>
<tr><td align=right>Air Def</td></tr>
<tr><td align=right><span id="UnitCloseDefName">Close</span> Def</td></tr>
<tr style="height: 5px"><td/></tr>
<tr><td align=right>Target Type</td></tr>
</table>
</td>
<td>
<table style="height: 100%%" cellspacing=-1 cellpadding=0>
<tr><td id="UnitCost" align=center style="width: 70px"></td></tr>
<tr style="height: 5px"><td/></tr>
<tr><td id="UnitMaxAmmo" align=center></td></tr>
<tr><td id="UnitMaxFuel" align=center></td></tr>
<tr style="height: 5px"><td/></tr>
<tr><td id="UnitMovement" align=center></td></tr>
<tr><td id="UnitSpotting" align=center></td></tr>
<tr><td id="UnitRange" align=center></td></tr>
<tr><td id="UnitInitiative" align=center></td></tr>
<tr style="height: 5px"><td/></tr>
<tr><td id="UnitSoftAttack" align=center></td></tr>
<tr><td id="UnitHardAttack" align=center></td></tr>
<tr><td id="UnitAirAttack" align=center></td></tr>
<tr><td id="UnitNavalAttack" align=center></td></tr>
<tr style="height: 5px"><td/></tr>
<tr><td id="UnitGroundDefense" align=center></td></tr>
<tr><td id="UnitAirDefense" align=center></td></tr>
<tr><td id="UnitCloseDefense" align=center></td></tr>
<tr style="height: 5px"><td/></tr>
<tr><td id="UnitTargetType" align=center></td></tr>
</table>
</td>
</tr>
</table>
</div>
<p> </p>
<div class="background" id="TransportBlock">
<p id="TransportType">Opel 6700</p>
<table>
<tr>
<td>
<table cellspacing=-1 cellpadding=0>
<tr><td align=right style="width: 63px">Cost</td></tr>
<tr style="height: 5px"><td/></tr>
<tr><td align=right>Max Fuel</td></tr>
<tr style="height: 5px"><td/></tr>
<tr><td align=right>Movement</td></tr>
<tr><td align=right>Spotting</td></tr>
<tr><td align=right>Initiative</td></tr>
<tr style="height: 5px"><td/></tr>
<tr><td align=right>Soft Attack</td></tr>
<tr><td align=right>Hard Attack</td></tr>
<tr><td align=right>Air Attack</td></tr>
<tr style="height: 5px"><td/></tr>
<tr><td align=right>Ground Def</td></tr>
<tr><td align=right>Air Def</td></tr>
<tr><td align=right><span id="TransportCloseDefName">Close</span> Def</td></tr>
<tr style="height: 5px"><td/></tr>
<tr><td align=right>Target Type</td></tr>
</table>
</td>
<td>
<table id="TransportBlock" style="height: 100%%" cellspacing=-1 cellpadding=0>
<tr><td id="TransportCost" align=center style="width: 70px"></td></tr>
<tr style="height: 5px"><td/></tr>
<tr><td id="TransportMaxFuel" align=center></td></tr>
<tr style="height: 5px"><td/></tr>
<tr><td id="TransportMovement" align=center></td></tr>
<tr><td id="TransportSpotting" align=center></td></tr>
<tr><td id="TransportInitiative" align=center></td></tr>
<tr style="height: 5px"><td/></tr>
<tr><td id="TransportSoftAttack" align=center></td></tr>
<tr><td id="TransportHardAttack" align=center></td></tr>
<tr><td id="TransportAirAttack" align=center></td></tr>
<tr style="height: 5px"><td/></tr>
<tr><td id="TransportGroundDefense" align=center></td></tr>
<tr><td id="TransportAirDefense" align=center></td></tr>
<tr><td id="TransportCloseDefense" align=center></td></tr>
<tr style="height: 5px"><td/></tr>
<tr><td id="TransportTargetType" align=center></td></tr>
</table>
</td>
</tr>
</table>
</div>
</div>
</div>
</body>
</html>
Last edited by HexCode on 2021-06-12 20:10, Saturday, edited 3 times in total.
DUAL-MODE, COMPOSITE UNITS
DUAL-MODE, COMPOSITE UNITS
===========================
We are all familiar with organic, naval and air transports, right ? Well, what are they really ? They are units transporting their companion units in a "contained" (i.e., boarded) state. The requisite technical specifications reside within files *.PGSCN. Specifically:
"Normally" an organic transport unit may "contain" some "allowable" land unit and a naval transport unit may simultaneously "contain" the whole companion duo. BUT, no unit can enjoy naval and air transport status simultaneously...
"Normally" ? "Allowable" ? These qualifiers refer to SSI's flagship content. They don't circumscribe what's technically possible.
Technically speaking, any unit can be assigned to some other unit as its "organic transport" companion. This feature allows modders to "construct" dual-mode, composite units (DMCUs). In-game, at any particular instant, one of the constituent units is in active mode while its companion is in passive mode. The mount / dismount button serves as an active / passive mode toggle.
As a rule, a creative DMCU design necessitates tinkering with and / or adding new unit stats to be hosted within file EQUIPMENT.PGEQP and, possibly, generating some new icon(s) to be incorporated into file TACICONS.BMP.
Example
Submarines that can surface and dive.
===========================
We are all familiar with organic, naval and air transports, right ? Well, what are they really ? They are units transporting their companion units in a "contained" (i.e., boarded) state. The requisite technical specifications reside within files *.PGSCN. Specifically:
Code: Select all
# Units
# Hex....{Unit} Type....Organic Transport Type....Sea/Air Transport Type
"Normally" ? "Allowable" ? These qualifiers refer to SSI's flagship content. They don't circumscribe what's technically possible.
Technically speaking, any unit can be assigned to some other unit as its "organic transport" companion. This feature allows modders to "construct" dual-mode, composite units (DMCUs). In-game, at any particular instant, one of the constituent units is in active mode while its companion is in passive mode. The mount / dismount button serves as an active / passive mode toggle.
As a rule, a creative DMCU design necessitates tinkering with and / or adding new unit stats to be hosted within file EQUIPMENT.PGEQP and, possibly, generating some new icon(s) to be incorporated into file TACICONS.BMP.
Example
Submarines that can surface and dive.
I have modeled the existing submarines as submerged ones - submarine unit class, spotting = 1, no use of deck guns, slow(er) speed - and I created a surfaced duplicate for each submarine in the Destroyer unit class, spotting = 2, use of deck guns where appropriate (HA / SA attack values for shore bombardment, AA values for defending from air attack), fast(er) speed (where appropriate), and assigned these as organic transports to the submerged sub. Clicking on the truck mount / dismount icon switches between surfaced / submerged modes. The surfaced sub loses the bonuses of the Submarine unit class (cannot evade, can be attacked by all unit classes not just Destroyers). I find it works rather nicely, very similar to how Pacific General used to handle submarine combat !
Last edited by HexCode on 2021-06-28 19:49, Monday, edited 3 times in total.
RESTRICTING UNIT EXPERIENCE GAINS
RESTRICTING UNIT EXPERIENCE GAINS
==================================
Intent
Some modders may consider slowing down the pace at which Core Units earn additional Experience Levels (i.e.,"Stars") so as to render campaigns a bit more challenging; ditto for longish scenarios playable in Standalone Mode.
Basic Terminology
Units accumulate Experience Points via in-game combat. Such Points should not be confused with Experience Levels (usually referred to as "Stars"). Gaining one additional "Star" requires the additional accumulation of 100 Experience Points.
It is important to appreciate that the 100 Experience Point increments are not applied arbitrarily. Rather, they strictly and prescriptively conform to the following table:
Preserving a Unit's Experience Points
Units engaging in combat often lose Strength Factors (SFs). To replace such losses without losing AEPs, a player must procure Elite Replacements. Such replacements leave a unit's hitherto AEPs unmolested.
By the way, should the player opt for procuring Normal (i.e., "Green") Replacements instead, his unit will suffer an AEP loss (sometimes, this loss is referred to as unit Experience Dilution).
Technical Means
PGF provides modders with the technical means to slow down the pace at which units gain additional "Stars". This is accomplished by assigning appropriate values to variable "Max Unit Experience", encountered in scenario files *.PGSCN within the section entitled "General scenario data" (PGF programmer's choice of text).
The above setting is scenario-specific. To boot, it applies to all units present. To repeat, the setting's assigned value impacts in-game behavior across the board within any particular scenario.
Accumulated Experience Points (AEPs) Are THE Technical Thing
It is extremely important for modders to internalize that, technically speaking, one never tinkers directly with Experience Levels (i.e., "Stars"). All the requisite modding is being done by specifying appropriate values for AEPs (scenario-wide or per participating unit).
Scenario files *.PGSCN contain a section entitled "Units" (PGF programmer's choice of text). One of that section's column is entitled "Experience" (once again, PGF programmer's choice of text). Each unit listed under the aforesaid section is assigned a starting, "assumed to have hitherto been accumulated", Experience Point value. It is important to note that these AEP values do NOT apply to Core Units once Campaign Play gets going.
"Max Unit Experience" Setting -- It Only Impacts Certain In-Game Events
One should not get the impression that the "Max Unit Experience" setting lops off any previously AEPs.
Instead, right on the heels of any particular combat:
1) If a participating unit enters combat sporting a hitherto AEP value LOWER THAN the cap (i.e., the scenario-wide setting), PGF's engine ensures that adding whatever AEPs are earned due to the particular combat to the unit's prior AEP total does NOT breech the cap.
2) If a participating unit enters combat sporting a hitherto AEP value GREATER THAN OR EQUAL to the cap (i.e., the scenario-wide setting), PGF's engine ensures that the unit's AEP total does NOT increase at all.
The above mechanism holds true unless one enters "highly experimental" territory (i.e., AEPs greater than 599). More on this below.
By the way, additional Experience Points earned due to combat cannot be negative unless, once again, one enters "highly experimental" territory (i.e., AEPs greater than 999). More on this below.
Modding Implications
Heading Assumption: No unit is preassigned an Accumulated Experience Point (AEP) value greater than 599.
Consider AEP values x00, x99 and all values in between them (x may be 0, 1, 2, 3, 4, or 5). How does a modder decide which value within range [ x00 , x99 ] to assign to variable "Max Unit Experience" ?
a) In the case of Standalone Scenario Play Mode, the particular value is of no importance. Any range values greater than x00 definitely allow for additional Experience Points to be earned (if any). However, at scenario's end these additional Points and their potential utility will vanish into thin air...
b) In the case of Campaign Play Mode, everything depends on what a modder has in store for the Core Units during the scenarios which follow the one subjected to an AEP restriction. A value of x00 represents the most restrictive option while a value of x99 represents the least restrictive one. Any other value within range [ x00 , x99 ] finely calibrates "things". The key idea here is to delay the conversion of additional Experience Points earned (if any) into additional "Stars" !
"Highly Experimental" Territory
Heading Assumption: One or more units are preassigned an Accumulated Experience Point (AEP) value greater than 599.
Range [ 600 , 999 ] : Variable "Max Unit Experience"'s setting is ignored. PGF's engine just does not allow these units to increase their AEP totals. A couple of unimportant, minor nuances are beyond the scope of this post.
Range [ 1000 , ???? ] : Additional Experience Points earned due to combat are negative !!
It is important to note that PGF's UI just provides a maximum of five (5) visually depicted "Stars"; even in instances discussed under the present heading.
==================================
Intent
Some modders may consider slowing down the pace at which Core Units earn additional Experience Levels (i.e.,"Stars") so as to render campaigns a bit more challenging; ditto for longish scenarios playable in Standalone Mode.
Basic Terminology
Units accumulate Experience Points via in-game combat. Such Points should not be confused with Experience Levels (usually referred to as "Stars"). Gaining one additional "Star" requires the additional accumulation of 100 Experience Points.
It is important to appreciate that the 100 Experience Point increments are not applied arbitrarily. Rather, they strictly and prescriptively conform to the following table:
Code: Select all
Accumulated Earned
Experience "Stars"
Points
000-099 0
100-199 1
200-299 2
300-399 3
400-499 4
500-599 5
Units engaging in combat often lose Strength Factors (SFs). To replace such losses without losing AEPs, a player must procure Elite Replacements. Such replacements leave a unit's hitherto AEPs unmolested.
By the way, should the player opt for procuring Normal (i.e., "Green") Replacements instead, his unit will suffer an AEP loss (sometimes, this loss is referred to as unit Experience Dilution).
Technical Means
PGF provides modders with the technical means to slow down the pace at which units gain additional "Stars". This is accomplished by assigning appropriate values to variable "Max Unit Experience", encountered in scenario files *.PGSCN within the section entitled "General scenario data" (PGF programmer's choice of text).
The above setting is scenario-specific. To boot, it applies to all units present. To repeat, the setting's assigned value impacts in-game behavior across the board within any particular scenario.
Accumulated Experience Points (AEPs) Are THE Technical Thing
It is extremely important for modders to internalize that, technically speaking, one never tinkers directly with Experience Levels (i.e., "Stars"). All the requisite modding is being done by specifying appropriate values for AEPs (scenario-wide or per participating unit).
Scenario files *.PGSCN contain a section entitled "Units" (PGF programmer's choice of text). One of that section's column is entitled "Experience" (once again, PGF programmer's choice of text). Each unit listed under the aforesaid section is assigned a starting, "assumed to have hitherto been accumulated", Experience Point value. It is important to note that these AEP values do NOT apply to Core Units once Campaign Play gets going.
"Max Unit Experience" Setting -- It Only Impacts Certain In-Game Events
One should not get the impression that the "Max Unit Experience" setting lops off any previously AEPs.
Instead, right on the heels of any particular combat:
1) If a participating unit enters combat sporting a hitherto AEP value LOWER THAN the cap (i.e., the scenario-wide setting), PGF's engine ensures that adding whatever AEPs are earned due to the particular combat to the unit's prior AEP total does NOT breech the cap.
2) If a participating unit enters combat sporting a hitherto AEP value GREATER THAN OR EQUAL to the cap (i.e., the scenario-wide setting), PGF's engine ensures that the unit's AEP total does NOT increase at all.
The above mechanism holds true unless one enters "highly experimental" territory (i.e., AEPs greater than 599). More on this below.
By the way, additional Experience Points earned due to combat cannot be negative unless, once again, one enters "highly experimental" territory (i.e., AEPs greater than 999). More on this below.
Modding Implications
Heading Assumption: No unit is preassigned an Accumulated Experience Point (AEP) value greater than 599.
Consider AEP values x00, x99 and all values in between them (x may be 0, 1, 2, 3, 4, or 5). How does a modder decide which value within range [ x00 , x99 ] to assign to variable "Max Unit Experience" ?
a) In the case of Standalone Scenario Play Mode, the particular value is of no importance. Any range values greater than x00 definitely allow for additional Experience Points to be earned (if any). However, at scenario's end these additional Points and their potential utility will vanish into thin air...
b) In the case of Campaign Play Mode, everything depends on what a modder has in store for the Core Units during the scenarios which follow the one subjected to an AEP restriction. A value of x00 represents the most restrictive option while a value of x99 represents the least restrictive one. Any other value within range [ x00 , x99 ] finely calibrates "things". The key idea here is to delay the conversion of additional Experience Points earned (if any) into additional "Stars" !
"Highly Experimental" Territory
Heading Assumption: One or more units are preassigned an Accumulated Experience Point (AEP) value greater than 599.
Range [ 600 , 999 ] : Variable "Max Unit Experience"'s setting is ignored. PGF's engine just does not allow these units to increase their AEP totals. A couple of unimportant, minor nuances are beyond the scope of this post.
Range [ 1000 , ???? ] : Additional Experience Points earned due to combat are negative !!
It is important to note that PGF's UI just provides a maximum of five (5) visually depicted "Stars"; even in instances discussed under the present heading.
Last edited by HexCode on 2021-10-11 05:44, Monday, edited 3 times in total.
GLIDER-BORNE UNITS
GLIDER-BORNE UNITS
===================
Preliminaries
Bears repeating:
viewtopic.php?f=100&t=540#p8965
is an absolute prerequisite here !
Modding Requirements
In reality, gliders need be towed by aircraft such as air transports. However, for PGF's purposes, Glider units can be usefully viewed and treated as Air Transport units in their own right. It is up to the modder to come up with "reasonable" Glider unit specs, including images.
The general idea here is this. Glider-borne units will be "contained" in Glider units which will fly them to some hex chosen for disembarkation. Disembarkation will be subject to the usual paradrop rules / mechanics.
Modder Options
Option #1
PGF only allows the specification of just one particular, default Air Transport type per Side on a scenario-specific basis. This means that, unless, a Side has no use whatsoever for "regular" Air Transports, Glider transport cannot be used for in-game embarkation.
A modder may be inclined to specify brand new, dedicated unit types (e.g., "Glider Infantry") with both their "Can Have Air Transport" and "Can Paradrop" Boolean settings assigned values of ONE (1) (in file EQUIPMENT.PGEQP).
Option #2
A modder may choose to start off a scenario by specifying units which are already "contained" in Glider transports. Such transports do not affect the scenario's Air Transport Point (ATP) utilization. To this effect, all such "contained" unit types have their "Can Have Air Transport" Boolean setting assigned a value of ZERO (0) and their "Can Paradrop" Boolean setting assigned a value of ONE (1), respectively (in file EQUIPMENT.PGEQP).
It is important to note that such "contained" units are "allowed" to bring along their organic transports (if any) !!
===================
Preliminaries
Bears repeating:
Dual-Mode, Composite Units"Advanced" modding is all about coming up with novelties based on extracting advantages from as well as avoiding pitfalls lurking in technical details. To this effect, PGF allows for tremendous customization of battlefield initial conditions incomparable to anything feasible in-game.
viewtopic.php?f=100&t=540#p8965
is an absolute prerequisite here !
Modding Requirements
In reality, gliders need be towed by aircraft such as air transports. However, for PGF's purposes, Glider units can be usefully viewed and treated as Air Transport units in their own right. It is up to the modder to come up with "reasonable" Glider unit specs, including images.
The general idea here is this. Glider-borne units will be "contained" in Glider units which will fly them to some hex chosen for disembarkation. Disembarkation will be subject to the usual paradrop rules / mechanics.
Modder Options
Option #1
PGF only allows the specification of just one particular, default Air Transport type per Side on a scenario-specific basis. This means that, unless, a Side has no use whatsoever for "regular" Air Transports, Glider transport cannot be used for in-game embarkation.
A modder may be inclined to specify brand new, dedicated unit types (e.g., "Glider Infantry") with both their "Can Have Air Transport" and "Can Paradrop" Boolean settings assigned values of ONE (1) (in file EQUIPMENT.PGEQP).
Option #2
A modder may choose to start off a scenario by specifying units which are already "contained" in Glider transports. Such transports do not affect the scenario's Air Transport Point (ATP) utilization. To this effect, all such "contained" unit types have their "Can Have Air Transport" Boolean setting assigned a value of ZERO (0) and their "Can Paradrop" Boolean setting assigned a value of ONE (1), respectively (in file EQUIPMENT.PGEQP).
It is important to note that such "contained" units are "allowed" to bring along their organic transports (if any) !!
Last edited by HexCode on 2021-06-28 19:57, Monday, edited 3 times in total.
"ANCHORED" GARRISON UNITS
"ANCHORED" GARRISON UNITS
===========================
Preliminaries
Bears repeating:
viewtopic.php?f=100&t=540#p8965
is an absolute prerequisite here !
AI's Specific "Shortcoming"
Stationary Garrison Units (SGUs) are exclusively relevant to PGF's AI behavior. PGF's AI Module is completely clueless when it comes to "understanding" the defensive advantages entrenchment level preservation confers upon its units. Whether a unit's entrenchment level is 0 or 255, well, it makes no difference to the AI Module... Worse, PGF's AI Module exhibits the most unfortunate tendency to aimlessly move its units about and away from natural defensive terrain such as urban centers. Consequently, PGF's AI Module cannot be relied upon to conduct a credibly strong defense of Victory Hexes (VHs), let alone of important non-VHs.
Emerging Modding Requirement
Clearly, PGF's AI Module is in dire need of some "help" when it comes to putting up stiffer resistance in defense of certain important VHs and, possibly, non-VHs as well. To this effect, the emerging technical requirement here is rather straightforward. Namely, technical means need be employed to prohibit PGF's AI from moving about SGUs.
Immediate Implications & Directions
==> PGF's AI Module should not be allowed to purchase SGUs.
==> It is the scenario designer who should preposition all requisite SGUs on the map.
Modders' Key Preferences
1) For rather obvious reasons, allowing PGF's AI Module to "voluntarily" vacate some important hex is a non-starter !
2) A modder may wish to prohibit or, alternatively, allow the forced retreat of SGUs, immediately following combat. Mind you, depending on some modder's precise aims, SGUs of various types may be prepositioned on some scenario map as well !
An SGU which cannot retreat as a result of combat gets outright eliminated on the spot. On the other hand, a successfully retreated such unit would still constitute an "obstacle" of sorts. Generally, this is not a clear cut case of certain advantages outweighing any attendant disadvantages. I would imagine, though, that modders will be making their judgment calls primarily keeping urban VHs in mind.
Explicitly Defined & Dedicated SGUs
A modder may actually choose to explicitly define one or more SGU types in file EQUIPMENT.PGEQP. Custom SGUs assigned to the Structure (i.e., Fort) Unit Class and sporting Movement Allowance (MA) value ZERO (0) have already been put to good use by at least one Veteran Modder (VM). It is worth noting that placing such units in Non-Naval City hexes allows them (by exception) to receive Replacements. However, they cannot ever involuntarily retreat; they get eliminated instead.
KEY ASSUMPTION: For the remainder of this post, it is assumed that the suggested technical solution does not rest upon explicitly defining one or more dedicated SGU types in file EQUIPMENT.PGEQP.
Ни шагу назад / Kein Schritt zurück / Not a step back
The proposed technical solution herein would employ a specially designed pseudo-unit belonging to the Structure Class; the "Anchor". File *.PGSCN will feature all such "Anchors" as Organic Transports attached to the units intended to serve as predetermined hex garrisons. In the sequel, such dual-mode, composite units (DMCUs) will be referred to as "Anchored" Garrison Units (AGUs). Clearly, AGUs are a subset of all possible SGUs.
File EQUIPMENT.PGEQP will contain the "Anchor" pseudo-unit specification (including pointing to some distinct image in file TACICONS.BMP). Specifically:
Starting with the "Anchor's" class designation and ending with its unit cost, all 17 consecutive values will be set to ZERO (0) excepting:
Unit Class : 7 (i.e., Structure)
Movement Type : 6 (i.e., Naval)
PGF's engine allows in situ "mounts" rendering the pseudo-unit active only on Port / Embarkation City hexes. To this effect:
a) PGF's AI never proactively embarks its units onto Transports; therefore, one need not worry about such "things" ever happening... Incidentally, as a precondition to effective Naval Embarkation, the player must abandon the pseudo-unit !
b) PGF's AI never proactively (auto)upgrades its units in-game; therefore one need not worry about "Anchors" being gotten rid of in this fashion !
c) PGF's AI proactively renders "Transporters" active for movement and / or attack. Given the pseudo-unit's particular specification, rendering it active will serve no purpose since neither movement nor attack are possible.
Two Permissive Exceptions
There are a couple of exceptions to AGUs possibly... disobeying orders to stand their ground ! In all such instances, an AGU may proactively move to some "appropriate", not necessarily adjacent, vacant hex. To boot, such a unit may also enter one of those (by necessity adjacent) hexes upon forced retreat.
To this effect:
A) An AGU adjacent to a Port / Embarkation City Hex may proactively move or retreat to it, as the case may be.
B) An AGU on a hex technically traversed by a road may proactively move to any normally accessible, vacant hex strictly along the said road. Such a unit may also retreat to some adjacent, vacant hex strictly along the said road as well.
Therefore, depending on a scenario map's specifics, it may be necessary to bring in other SGU types as well.
On-Road Only or Rail Movement
The empirical findings stated under preceding point (B) potentially invite "advanced" modding opportunities. Namely, a practical, technical "trick" has been identified which restricts designated units to On-Road Only (or Rail) Movement.
===========================
Preliminaries
Bears repeating:
Dual-Mode, Composite Units"Advanced" modding is all about coming up with novelties based on extracting advantages from as well as avoiding pitfalls lurking in technical details. To this effect, PGF allows for tremendous customization of battlefield initial conditions incomparable to anything feasible in-game.
viewtopic.php?f=100&t=540#p8965
is an absolute prerequisite here !
AI's Specific "Shortcoming"
Stationary Garrison Units (SGUs) are exclusively relevant to PGF's AI behavior. PGF's AI Module is completely clueless when it comes to "understanding" the defensive advantages entrenchment level preservation confers upon its units. Whether a unit's entrenchment level is 0 or 255, well, it makes no difference to the AI Module... Worse, PGF's AI Module exhibits the most unfortunate tendency to aimlessly move its units about and away from natural defensive terrain such as urban centers. Consequently, PGF's AI Module cannot be relied upon to conduct a credibly strong defense of Victory Hexes (VHs), let alone of important non-VHs.
Emerging Modding Requirement
Clearly, PGF's AI Module is in dire need of some "help" when it comes to putting up stiffer resistance in defense of certain important VHs and, possibly, non-VHs as well. To this effect, the emerging technical requirement here is rather straightforward. Namely, technical means need be employed to prohibit PGF's AI from moving about SGUs.
Immediate Implications & Directions
==> PGF's AI Module should not be allowed to purchase SGUs.
==> It is the scenario designer who should preposition all requisite SGUs on the map.
Modders' Key Preferences
1) For rather obvious reasons, allowing PGF's AI Module to "voluntarily" vacate some important hex is a non-starter !
2) A modder may wish to prohibit or, alternatively, allow the forced retreat of SGUs, immediately following combat. Mind you, depending on some modder's precise aims, SGUs of various types may be prepositioned on some scenario map as well !
An SGU which cannot retreat as a result of combat gets outright eliminated on the spot. On the other hand, a successfully retreated such unit would still constitute an "obstacle" of sorts. Generally, this is not a clear cut case of certain advantages outweighing any attendant disadvantages. I would imagine, though, that modders will be making their judgment calls primarily keeping urban VHs in mind.
Explicitly Defined & Dedicated SGUs
A modder may actually choose to explicitly define one or more SGU types in file EQUIPMENT.PGEQP. Custom SGUs assigned to the Structure (i.e., Fort) Unit Class and sporting Movement Allowance (MA) value ZERO (0) have already been put to good use by at least one Veteran Modder (VM). It is worth noting that placing such units in Non-Naval City hexes allows them (by exception) to receive Replacements. However, they cannot ever involuntarily retreat; they get eliminated instead.
KEY ASSUMPTION: For the remainder of this post, it is assumed that the suggested technical solution does not rest upon explicitly defining one or more dedicated SGU types in file EQUIPMENT.PGEQP.
Ни шагу назад / Kein Schritt zurück / Not a step back
The proposed technical solution herein would employ a specially designed pseudo-unit belonging to the Structure Class; the "Anchor". File *.PGSCN will feature all such "Anchors" as Organic Transports attached to the units intended to serve as predetermined hex garrisons. In the sequel, such dual-mode, composite units (DMCUs) will be referred to as "Anchored" Garrison Units (AGUs). Clearly, AGUs are a subset of all possible SGUs.
File EQUIPMENT.PGEQP will contain the "Anchor" pseudo-unit specification (including pointing to some distinct image in file TACICONS.BMP). Specifically:
Starting with the "Anchor's" class designation and ending with its unit cost, all 17 consecutive values will be set to ZERO (0) excepting:
Unit Class : 7 (i.e., Structure)
Movement Type : 6 (i.e., Naval)
PGF's engine allows in situ "mounts" rendering the pseudo-unit active only on Port / Embarkation City hexes. To this effect:
a) PGF's AI never proactively embarks its units onto Transports; therefore, one need not worry about such "things" ever happening... Incidentally, as a precondition to effective Naval Embarkation, the player must abandon the pseudo-unit !
b) PGF's AI never proactively (auto)upgrades its units in-game; therefore one need not worry about "Anchors" being gotten rid of in this fashion !
c) PGF's AI proactively renders "Transporters" active for movement and / or attack. Given the pseudo-unit's particular specification, rendering it active will serve no purpose since neither movement nor attack are possible.
Two Permissive Exceptions
There are a couple of exceptions to AGUs possibly... disobeying orders to stand their ground ! In all such instances, an AGU may proactively move to some "appropriate", not necessarily adjacent, vacant hex. To boot, such a unit may also enter one of those (by necessity adjacent) hexes upon forced retreat.
To this effect:
A) An AGU adjacent to a Port / Embarkation City Hex may proactively move or retreat to it, as the case may be.
B) An AGU on a hex technically traversed by a road may proactively move to any normally accessible, vacant hex strictly along the said road. Such a unit may also retreat to some adjacent, vacant hex strictly along the said road as well.
Therefore, depending on a scenario map's specifics, it may be necessary to bring in other SGU types as well.
On-Road Only or Rail Movement
The empirical findings stated under preceding point (B) potentially invite "advanced" modding opportunities. Namely, a practical, technical "trick" has been identified which restricts designated units to On-Road Only (or Rail) Movement.
Last edited by HexCode on 2024-02-21 17:50, Wednesday, edited 12 times in total.
MAP FRAMES
MAP FRAMES
===========
Preliminaries
In PGF:
1) All fully visible hexes along a map's edges are accessible to units.
2) All partially visible hexes along a map's edges are inaccessible to units.
Modder Option
Long time ago, a modder came up with the practical notion of a "Map Frame". The idea here was to employ map editing resources to generate such frames which would visually signal hex "unenterability" in a most pronounced way. A typical map frame hex was technically specified as follows:
@ Underlying (hexadecimal) terrain: "07"
@ Geographical name (in MAPNAMES.STR): "OFF LIMITS"
@ Visible terrain tile: Custom (Pitch Black)
@ Completely unenterable (i.e., "Neutral") territory
One has to make absolutely sure that the visible terrain tile's blackness is totally impervious to illumination changes due to scouting.
===========
Preliminaries
In PGF:
1) All fully visible hexes along a map's edges are accessible to units.
2) All partially visible hexes along a map's edges are inaccessible to units.
Modder Option
Long time ago, a modder came up with the practical notion of a "Map Frame". The idea here was to employ map editing resources to generate such frames which would visually signal hex "unenterability" in a most pronounced way. A typical map frame hex was technically specified as follows:
@ Underlying (hexadecimal) terrain: "07"
@ Geographical name (in MAPNAMES.STR): "OFF LIMITS"
@ Visible terrain tile: Custom (Pitch Black)
@ Completely unenterable (i.e., "Neutral") territory
One has to make absolutely sure that the visible terrain tile's blackness is totally impervious to illumination changes due to scouting.
Last edited by HexCode on 2021-12-28 01:19, Tuesday, edited 2 times in total.
ROADWORKS PROBLEM "SNIFFERS"
ROADWORKS PROBLEM "SNIFFERS"
==============================
Observations
While playing / modding under PGF, one occasionally comes across situations where some unit is not able to reach / enter some hex despite the "fact" that it is "supposed to". Conversely, one also comes across situations where some unit is able to reach / enter some hex despite the "fact" that it is "not supposed to". These are map technical definition "discrepancies".
By far, the most frequent type of map technical definition "discrepancy" is due to a mismatch between the roadworks a terrain tile depicts and those underlying ones which PGF's engine "understands".
Practical Means
In practical terms, the best way to empirically go after the identification of map technical roadworks "discrepancies" is to unleash a swarm of motorized (i.e., mounted on trucks, not half-tracks) units all along a map's visible roadworks and look out for movement oddities.
==============================
Observations
While playing / modding under PGF, one occasionally comes across situations where some unit is not able to reach / enter some hex despite the "fact" that it is "supposed to". Conversely, one also comes across situations where some unit is able to reach / enter some hex despite the "fact" that it is "not supposed to". These are map technical definition "discrepancies".
By far, the most frequent type of map technical definition "discrepancy" is due to a mismatch between the roadworks a terrain tile depicts and those underlying ones which PGF's engine "understands".
Practical Means
In practical terms, the best way to empirically go after the identification of map technical roadworks "discrepancies" is to unleash a swarm of motorized (i.e., mounted on trucks, not half-tracks) units all along a map's visible roadworks and look out for movement oddities.
Last edited by HexCode on 2021-06-01 22:09, Tuesday, edited 2 times in total.
RESTRICTING UNIT PURCHASES
RESTRICTING UNIT PURCHASES
===========================
Content designers may want to restrict one's ability to purchase new units in some specific fashion or another.
Unit Class-Specific Restrictions
One may wish to restrict new unit purchases across an entire Unit Class. This is accomplished by opening the relevant scenario-specific *.PGSCN file and locating the section entitled "Purchasable classes". Under this section, each Unit Class sports a Boolean setting. Assigning to it a value of ZERO (0) (or deleting it outright) accomplishes the objective. It is important to note that, once invoked, this restrictive mode will apply to both sides during the scenario's entire duration.
Unit Type-Specific Restrictions
One may wish to restrict the purchase of one or more specific Unit Types. This is accomplished by opening the relevant EQUIPMENT.PGEQP file and locating the rightmost column entitled "Flag". One edits the values corresponding to the "targeted" Unit Types by assigning them a common value of MINUS ONE (-1), thereby denoting an inability to purchase any of them. Once again, it is important to note that, once invoked, this restrictive mode will apply to any and all scenarios playable in concert with the edited EQUIPMENT.PGEQP file.
Core / Auxiliary Complement-Specific Size Restrictions
One may wish to impede the number of new unit purchases without necessarily zeroing in on specific Unit Classes or Types. Such restrictions (i.e., "obstacles") may apply to the Core Complement, the Auxiliaries Complement or both. They are side-specific. To accomplish this, one opens the relevant scenario-specific *.PGSCN file and locates the section entitled "Sides". Under this section, there are two adjacent columns entitled "Core Limit" and "Aux Limit" respectively. It is up to the scenario designer / modder to choose specific values which are consistent with his aims.
Important Clarification
None of the above outlined restrictions in any way constrains what units a designer / modder may preposition at the very start of a scenario.
===========================
Content designers may want to restrict one's ability to purchase new units in some specific fashion or another.
Unit Class-Specific Restrictions
One may wish to restrict new unit purchases across an entire Unit Class. This is accomplished by opening the relevant scenario-specific *.PGSCN file and locating the section entitled "Purchasable classes". Under this section, each Unit Class sports a Boolean setting. Assigning to it a value of ZERO (0) (or deleting it outright) accomplishes the objective. It is important to note that, once invoked, this restrictive mode will apply to both sides during the scenario's entire duration.
Unit Type-Specific Restrictions
One may wish to restrict the purchase of one or more specific Unit Types. This is accomplished by opening the relevant EQUIPMENT.PGEQP file and locating the rightmost column entitled "Flag". One edits the values corresponding to the "targeted" Unit Types by assigning them a common value of MINUS ONE (-1), thereby denoting an inability to purchase any of them. Once again, it is important to note that, once invoked, this restrictive mode will apply to any and all scenarios playable in concert with the edited EQUIPMENT.PGEQP file.
Core / Auxiliary Complement-Specific Size Restrictions
One may wish to impede the number of new unit purchases without necessarily zeroing in on specific Unit Classes or Types. Such restrictions (i.e., "obstacles") may apply to the Core Complement, the Auxiliaries Complement or both. They are side-specific. To accomplish this, one opens the relevant scenario-specific *.PGSCN file and locates the section entitled "Sides". Under this section, there are two adjacent columns entitled "Core Limit" and "Aux Limit" respectively. It is up to the scenario designer / modder to choose specific values which are consistent with his aims.
Important Clarification
None of the above outlined restrictions in any way constrains what units a designer / modder may preposition at the very start of a scenario.
Last edited by HexCode on 2021-06-18 23:46, Friday, edited 4 times in total.
RESTRICTING UNIT REPLACEMENTS
RESTRICTING UNIT REPLACEMENTS
==============================
Preliminaries
Air Units can only receive Replacement or Over-Strengthening Strength Factors (SFs) while being situated on friendly Airfield hexes or Aircraft Carrier Class Units.
Naval Units can only receive Replacement or Over-Strengthening SFs while being situated in friendly Port / Port Facility / Embarkation City hexes.
Almost all Land units can receive Replacement or Over-Strengthening SFs anywhere on Land hexes. There is a sole exception here. Structure (a.k.a. Fort) Class Units can only receive Replacement or Over-Strengthening SFs while being situated in friendly City / Port hexes.
Modding Direction
A content designer wishing to impose restrictions on Land Units similar in character to the ones Air and Naval Units are subject to, might put his imagination to good use by "constructing" various Unit Types and assigning them to the Structure Class.
==============================
Preliminaries
Air Units can only receive Replacement or Over-Strengthening Strength Factors (SFs) while being situated on friendly Airfield hexes or Aircraft Carrier Class Units.
Naval Units can only receive Replacement or Over-Strengthening SFs while being situated in friendly Port / Port Facility / Embarkation City hexes.
Almost all Land units can receive Replacement or Over-Strengthening SFs anywhere on Land hexes. There is a sole exception here. Structure (a.k.a. Fort) Class Units can only receive Replacement or Over-Strengthening SFs while being situated in friendly City / Port hexes.
Modding Direction
A content designer wishing to impose restrictions on Land Units similar in character to the ones Air and Naval Units are subject to, might put his imagination to good use by "constructing" various Unit Types and assigning them to the Structure Class.
Last edited by HexCode on 2021-06-11 05:34, Friday, edited 3 times in total.
ENABLING NAVAL UNIT PURCHASES
ENABLING NAVAL UNIT PURCHASES
===============================
How To Do It
Designers / modders wishing to render naval units purchasable are well advised to carefully consult:
Unit Class Purchase Accessibility
viewtopic.php?f=100&t=540#p8964
and implement its contents down to the minutest detail.
If they are only familiar with file EQUIPMENT.PGEQP encountered in the PG / AG "games", they will need to modify it by assigning specific nationalities to purchasable naval unit types. Otherwise they may get the impression that "things don't work at all".
Technically speaking, the requisite values appearing in the file's rightmost column entitled "Flags" must be changed from MINUS ONE (-1) to whatever Combatant ID code one wishes to assign to them. From that point on, the intended naval unit types will be rendered purchasable under the specific Combatant tab in the Unit Purchase Pop-up Screen.
===============================
How To Do It
Designers / modders wishing to render naval units purchasable are well advised to carefully consult:
Unit Class Purchase Accessibility
viewtopic.php?f=100&t=540#p8964
and implement its contents down to the minutest detail.
If they are only familiar with file EQUIPMENT.PGEQP encountered in the PG / AG "games", they will need to modify it by assigning specific nationalities to purchasable naval unit types. Otherwise they may get the impression that "things don't work at all".
Technically speaking, the requisite values appearing in the file's rightmost column entitled "Flags" must be changed from MINUS ONE (-1) to whatever Combatant ID code one wishes to assign to them. From that point on, the intended naval unit types will be rendered purchasable under the specific Combatant tab in the Unit Purchase Pop-up Screen.
Last edited by HexCode on 2021-11-27 06:19, Saturday, edited 1 time in total.
NEGATIVE PRESTIGE POINTS
NEGATIVE PRESTIGE POINTS
=========================
Key Finding
PGF's play system is quite happy to work with negative Prestige Points (PPs). The coding of its underlying algebraic equations behaves as theoretically expected.
Prestige Point Tallies (PPTs)
a1) Files *.PGSCN readily accommodate starting PPTs sporting negative values without making any fuss.
a2) BUT, any enemy level bomber unit attack on a friendly objective (a.k.a. Victory) hex instantaneously resets a friendly PPT's negative value to ZERO (0) !!
a3) The Scenario Panel has no problem accurately depicting PPTs sporting negative values. However, the Unit Upgrade & Purchase Pop-up Screens depict ridiculously large (decimal) values... Fortunately, such obviously erroneous depictions do not affect actual play in any way. Kindly refer to the Technical Note at the very bottom of this post.
a4) Negative PPTs could be put to good, practical use under battlefield conditions where it may be intended for a side to fight (at least for awhile) without the possibility of procuring any "generalized reinforcements" (i.e., no Unit Purchases, Upgrades, Over-Strengthenings or Replacements of any sort).
Listed Procurement Costs (LPCs)
b1) File EQUIPMENT.PGEQP readily accommodates LPCs without making any fuss.
b2) Procuring such units actually increases a side's running PPT !!
b3) Successful attacks against such units actually decreases the attacking side's running PPT !!
b4) Under certain battlefield circumstances, the effects of procuring such units may trump the desirability of procuring "normal" units. CAVEAT: It might be necessary to prohibit the disbandment of such units lest one sets up a perpetual PP augmentation machine...
Per Turn Prestige Point Awards (PTPPAs)
c1) Files *.PGSCN readily accommodate PTPPAs sporting negative values without making any fuss.
c2) Negative PTPPAs could be put to good, practical use under battlefield conditions where it may be intended for a side to fight their way through some scenario under conditions of ever pressing prestige scarcity.
Prestige Point Awards Incident to Urban Center Capture (PPAsItUCC)
The term "Capture" is shorthand for the less ambiguous "Rendering the Hex's Ownership Friendly".
d1) Files *.PGSCN readily accommodate PPAsItUCC sporting negative values without making any fuss.
d2) Negative PPAsItUCC could be put to good, practical use under battlefield conditions where it may be intended for a side to fight their way through some scenario by discouraging the actual capture of too too many city / port / airfield hexes.
Prestige Point Awards Incident to Campaign Scenario Play Termination (PPAsItCSPT)
e1) File PG.PGCAM readily accommodates PPAsItCSPT sporting negative values without making any fuss.
e2) Negative PPAsItCSPT could be put to good, practical use under Campaign Play conditions where it may be intended for the Campaigning side to fight their way through the Campaign under conditions of carefully targeted prestige scarcity.
Technical Note
Looping Backwards...
Say a PPT sports the value MINUS 200. In hexadecimal terms, that value is expressed as MINUS C8h. The Unit Upgrade & Purchase Pop-up Screens will depict... 4294967096. How come ? In hexadecimal terms and due to 32-bit code arithmetic:
100000000h MINUS C8h = FFFFFF38h
In decimal terms, FFFFFF38h is none other than 4294967096 !
=========================
Key Finding
PGF's play system is quite happy to work with negative Prestige Points (PPs). The coding of its underlying algebraic equations behaves as theoretically expected.
Prestige Point Tallies (PPTs)
a1) Files *.PGSCN readily accommodate starting PPTs sporting negative values without making any fuss.
a2) BUT, any enemy level bomber unit attack on a friendly objective (a.k.a. Victory) hex instantaneously resets a friendly PPT's negative value to ZERO (0) !!
a3) The Scenario Panel has no problem accurately depicting PPTs sporting negative values. However, the Unit Upgrade & Purchase Pop-up Screens depict ridiculously large (decimal) values... Fortunately, such obviously erroneous depictions do not affect actual play in any way. Kindly refer to the Technical Note at the very bottom of this post.
a4) Negative PPTs could be put to good, practical use under battlefield conditions where it may be intended for a side to fight (at least for awhile) without the possibility of procuring any "generalized reinforcements" (i.e., no Unit Purchases, Upgrades, Over-Strengthenings or Replacements of any sort).
Listed Procurement Costs (LPCs)
b1) File EQUIPMENT.PGEQP readily accommodates LPCs without making any fuss.
b2) Procuring such units actually increases a side's running PPT !!
b3) Successful attacks against such units actually decreases the attacking side's running PPT !!
b4) Under certain battlefield circumstances, the effects of procuring such units may trump the desirability of procuring "normal" units. CAVEAT: It might be necessary to prohibit the disbandment of such units lest one sets up a perpetual PP augmentation machine...
Per Turn Prestige Point Awards (PTPPAs)
c1) Files *.PGSCN readily accommodate PTPPAs sporting negative values without making any fuss.
c2) Negative PTPPAs could be put to good, practical use under battlefield conditions where it may be intended for a side to fight their way through some scenario under conditions of ever pressing prestige scarcity.
Prestige Point Awards Incident to Urban Center Capture (PPAsItUCC)
The term "Capture" is shorthand for the less ambiguous "Rendering the Hex's Ownership Friendly".
d1) Files *.PGSCN readily accommodate PPAsItUCC sporting negative values without making any fuss.
d2) Negative PPAsItUCC could be put to good, practical use under battlefield conditions where it may be intended for a side to fight their way through some scenario by discouraging the actual capture of too too many city / port / airfield hexes.
Prestige Point Awards Incident to Campaign Scenario Play Termination (PPAsItCSPT)
e1) File PG.PGCAM readily accommodates PPAsItCSPT sporting negative values without making any fuss.
e2) Negative PPAsItCSPT could be put to good, practical use under Campaign Play conditions where it may be intended for the Campaigning side to fight their way through the Campaign under conditions of carefully targeted prestige scarcity.
Technical Note
Looping Backwards...
Say a PPT sports the value MINUS 200. In hexadecimal terms, that value is expressed as MINUS C8h. The Unit Upgrade & Purchase Pop-up Screens will depict... 4294967096. How come ? In hexadecimal terms and due to 32-bit code arithmetic:
100000000h MINUS C8h = FFFFFF38h
In decimal terms, FFFFFF38h is none other than 4294967096 !
PLAIN TEXT FILES: ACCOMMODATING UNICODE CHARACTERS
PLAIN TEXT FILES: ACCOMMODATING UNICODE CHARACTERS
=====================================================
Preliminaries
First, kindly consult
Character Set Evolution
viewtopic.php?f=100&t=535#p11090
AND
Tab-Separated Unicode Text Files
viewtopic.php?f=100&t=535#p8925
The contents of this post focus on meaningfully embedding into PGF's plain text files Unicode characters other than ASCII Standard ones.
Two Mutually Exclusive Ways
In order to successfully embed into PGF's plain text files Unicode characters other than ASCII Standard ones one must employ the appropriate one of TWO (2) practically noninterchangeable methodologies.
Cumbersome Notation
Step 1: The Unicode definition of each character of interest must be identified first. The Windows Character Map applet comes in handy. One just pinpoints a particular character he is interested in and selects it. The applet will promptly display the corresponding Unicode definition, say, U+039B.
Step 2: One activates the Windows Calculator applet and converts the hexadecimal value to its corresponding decimal one. In this particular case, the decimal value is 923.
Step 3: Staying with the particular example, one types in the character sequence Λ In technical English, the decimal value is flanked on its immediate right by the semicolon character and on its immediate left by the octothorpe (i.e., hash) character. The resulting character sequence itself is then augmented on its immediate left by the ampersand character.
Step 4: One inserts the rather cumbersome looking character sequence into the desired spot in the text file and saves it. Perusing the displayed text upon its invocation during play and staying with the example, the upper case Greek letter Lambda should be readily visible !
Direct Pasting
Step 1: The Unicode character of interest must be pinpointed first within the Windows Character Map applet. Once this is accomplished, one just selects it.
Step 2: One copies the selected character displayed within the Character Map applet and directly pastes it into the desired spot in the text file.
Specifics
Files *.PGBRF
Files *.PGBRF contain the briefing texts a player comes across while in Campaign Play Mode. Such files can be readily and easily edited with a text editor such as Microsoft's Notepad. The text is formatted as per the rather well known HyperText Markup Language (HTML) coding conventions.
To successfully embed into such files Unicode characters other than ASCII Standard ones one must employ Cumbersome Notation.
Files *.PGSCN & PG.PGCAM
These are Tab-Separated Unicode text files containing a bit of alphanumeric text.
To successfully embed into such files Unicode characters other than ASCII Standard ones one must employ:
a) Cumbersome Notation in the text contained in variables "Name" and "Description".
b) Direct Pasting in the scenario outcome messages.
Note: Upon attempting to save a Game-State snapshot, the proposed save name on the Game-State Saves Pop-up Screen displays the cumbersome notation itself. Do NOT be alarmed; this is just the file name recognized by the Operating System. Once the save is effected, all Unicode characters will be properly displayed within PGF proper.
File EQUIPMENT.PGEQP
This is a Tab-Separated Unicode text file.
Each Unit Type Attributes (UTA) record therein spans THIRTY THREE (33) data fields. Traversing the record from left to right, the SECOND (2nd) field is dedicated to the Unit Type's (UT's) alphanumeric descriptor.
A) The text captions appearing immediately below the Unit Icons displayed within gilded rectangular frames in the
--- Battlefield & Undeployed Unit Listing Ribbon Panels
--- Unit Upgrade & Purchase Pop-up Screens
--- New Equipment Availability Notification Pop-up Screen
can only accommodate embedded Unicode characters not belonging to the ASCII Standard set via Cumbersome Notation.
B) In all other instances, embedded Unicode characters not belonging to the ASCII Standard set can only be accommodated via Direct Pasting.
Unfortunately, barring any future relevant "discoveries", this shall remain a classic "short blanket" situation; partially damned if a content designer does X, partially damned if he does Y...
=====================================================
Preliminaries
First, kindly consult
Character Set Evolution
viewtopic.php?f=100&t=535#p11090
AND
Tab-Separated Unicode Text Files
viewtopic.php?f=100&t=535#p8925
The contents of this post focus on meaningfully embedding into PGF's plain text files Unicode characters other than ASCII Standard ones.
Two Mutually Exclusive Ways
In order to successfully embed into PGF's plain text files Unicode characters other than ASCII Standard ones one must employ the appropriate one of TWO (2) practically noninterchangeable methodologies.
Cumbersome Notation
Step 1: The Unicode definition of each character of interest must be identified first. The Windows Character Map applet comes in handy. One just pinpoints a particular character he is interested in and selects it. The applet will promptly display the corresponding Unicode definition, say, U+039B.
Step 2: One activates the Windows Calculator applet and converts the hexadecimal value to its corresponding decimal one. In this particular case, the decimal value is 923.
Step 3: Staying with the particular example, one types in the character sequence Λ In technical English, the decimal value is flanked on its immediate right by the semicolon character and on its immediate left by the octothorpe (i.e., hash) character. The resulting character sequence itself is then augmented on its immediate left by the ampersand character.
Step 4: One inserts the rather cumbersome looking character sequence into the desired spot in the text file and saves it. Perusing the displayed text upon its invocation during play and staying with the example, the upper case Greek letter Lambda should be readily visible !
Direct Pasting
Step 1: The Unicode character of interest must be pinpointed first within the Windows Character Map applet. Once this is accomplished, one just selects it.
Step 2: One copies the selected character displayed within the Character Map applet and directly pastes it into the desired spot in the text file.
Specifics
Files *.PGBRF
Files *.PGBRF contain the briefing texts a player comes across while in Campaign Play Mode. Such files can be readily and easily edited with a text editor such as Microsoft's Notepad. The text is formatted as per the rather well known HyperText Markup Language (HTML) coding conventions.
To successfully embed into such files Unicode characters other than ASCII Standard ones one must employ Cumbersome Notation.
Files *.PGSCN & PG.PGCAM
These are Tab-Separated Unicode text files containing a bit of alphanumeric text.
To successfully embed into such files Unicode characters other than ASCII Standard ones one must employ:
a) Cumbersome Notation in the text contained in variables "Name" and "Description".
b) Direct Pasting in the scenario outcome messages.
Note: Upon attempting to save a Game-State snapshot, the proposed save name on the Game-State Saves Pop-up Screen displays the cumbersome notation itself. Do NOT be alarmed; this is just the file name recognized by the Operating System. Once the save is effected, all Unicode characters will be properly displayed within PGF proper.
File EQUIPMENT.PGEQP
This is a Tab-Separated Unicode text file.
Each Unit Type Attributes (UTA) record therein spans THIRTY THREE (33) data fields. Traversing the record from left to right, the SECOND (2nd) field is dedicated to the Unit Type's (UT's) alphanumeric descriptor.
A) The text captions appearing immediately below the Unit Icons displayed within gilded rectangular frames in the
--- Battlefield & Undeployed Unit Listing Ribbon Panels
--- Unit Upgrade & Purchase Pop-up Screens
--- New Equipment Availability Notification Pop-up Screen
can only accommodate embedded Unicode characters not belonging to the ASCII Standard set via Cumbersome Notation.
B) In all other instances, embedded Unicode characters not belonging to the ASCII Standard set can only be accommodated via Direct Pasting.
Unfortunately, barring any future relevant "discoveries", this shall remain a classic "short blanket" situation; partially damned if a content designer does X, partially damned if he does Y...
UNIT TYPE DESCRIPTOR DISPLAY: HOW LONG ?
UNIT TYPE DESCRIPTOR DISPLAY: HOW LONG ?
=========================================
Unit Type Descriptor Specification
Unit Type (UT) descriptors are specified in file EQUIPMENT.PGEQP. Traversing the columns from left to right, The SECOND (2nd) column encountered therein is dedicated to such specifications.
Display Screen Locations
A UT descriptor is simultaneously displayed on the following screen locations:
--- Scenario Panel Areas A.4, A.5 & A.6
--- Unit Info Pop-up Screen
--- Battlefield & Undeployed Unit Listing Ribbon Panels
--- Unit Upgrade & Purchase Pop-up Screens
--- New Equipment Availability Notification Pop-up Screen
The Technical Challenge
What is the maximum visual length a UT descriptor can sport which does NOT interfere with the full, unobstructed display of everything which is intended to be displayed on each and every screen location ?
As it turns out, certain screen locations are more "demanding / restrictive" than others.
Potential "Bottlenecks"
The key to ensuring that a UT descriptor can be visually accommodated in all depictive respects is to serially focus on potential "bottlenecks".
The most obvious such potential "bottleneck" screen location is
Scenario Panel ==> A.5 Hovered (Mouse Cursor) Unit Info ==> FIRST (1st) row
The following depictive elements are serially encountered as one traverses the row going from left to right:
--- Military ID Designation
--- {Space Character}
--- UT Descriptor
--- {Space Character}
--- Unit Strength Factors enclosed in parentheses
--- Enemy Unit Strength Factors suffering lasting suppression preceded by a MINUS sign to their immediate LEFT (all in blue color)
Progressive Accommodation Easiness
If one were to ensure that no UT descriptor can ever interfere with the full, unobstructed display of everything which is intended to be displayed on the FIRST (1st) row of A.5 (Hovered (Mouse Cursor) Unit Info), he might NOT need to worry about anything else.
The following is a listing of screen locations where UT descriptors are displayed in generally increasing accommodation easiness:
1) SECOND (2nd) row in A.4 (Selected Friendly Unit Info) and A.5 (Hovered Unit Info). The following depictive elements are serially encountered as one traverses the row going from left to right:
--- UT Descriptor
--- {Space Character}
--- {Organic Transport Tiny Icon}
--- {Space Character}
--- {5 Stars}
2) Immediately below the Unit Icons displayed within gilded rectangular frames in the Battlefield & Undeployed Unit Listing Ribbon Panels. The following depictive elements are serially encountered as one traverses the row going from left to right:
--- Military ID Designation
--- {Space Character}
--- UT Descriptor
3) Everywhere else; just the UT descriptor is displayed.
Just Counting Descriptor Characters Is NOT Enough
For the time being, PGF's "native" UI specification remains unmolested...
Consider the following "maximalist" example specifically applicable to the FIRST (1st) row of A.5 (Hovered (Mouse Cursor) Unit Info) potential "bottleneck":
992nd WWWWWWWW (20)-20
where the UT descriptor consists of EIGHT (8) upper case Ws.
Now compare it with the following "minimalist" example:
1st IIIIIIII (1)
where the UT descriptor consists of EIGHT (8) upper case Is.
Clearly, all potential UT visual length display eventualities will essentially fall in between those two extremes. To this effect, empty space to the immediate right of the row's content will vary in length.
More Elongation, Please ?
What if, say, one wants to fully accommodate the "maximalist" example of
992nd WWWWWWWWWW (20)-20
where the UT descriptor now consists of TEN (10) upper case Ws ?
Fortunately, this is currently, technically feasible. It requires that the PGF's "native" UI be modified so that the Scenario Panel's width is allowed to grow a bit at the attendant expense of the Tactical Map's rectangular surface, of course. To be precise, the Tactical Map's "native" aspect ratio is 39:29. The following requisite modifications to the contents of file MAIN.HTM residing in the UI subfolder will render the aspect ratio 37:29:
Modification 1
FROM ==>
TO ==>
Modification 2
FROM ==>
TO ==>
Modification 3
FROM ==>
TO ==>
Modification 4
FROM ==>
TO ==>
In all FOUR (4) instances, the number 213 replaces the number 180.
The first TWO (2) modifications widen the Scenario Panel's rectangular area by approximately TWO (2) centimeters.
The last TWO (2) modifications ensure that all visual elements displayed within the Scenario Panel's rectangular area A6 are visually centered.
It's somewhat useful to visually peruse, say, in MS Notepad, the following vertical comparisons:
WWWWWWWWWW
ABCDEFGHIJKLM
abcdefghijklmnop
Give or take ONE (1) character, there're THIRTEEN (13) upper case characters OR, alternatively, SIXTEEN (16) lower case characters which can visually be accommodated now.
Fundamental Given
The decision one makes and implements regarding the Scenario Panel's width forms the basis of reference for all other UT descriptor screen display manifestations. To this effect, I've already made my strictly personal selection: 213px. The rest follows...
Safe Harbor Technical Suggestion
If one has not yet implemented the technical suggestion covered in
Where Did The "Close" Button Go ?
viewtopic.php?f=100&t=554#p9101
I strongly recommend he does so now !
Excellent News Across the Board
Scenario Panel Areas A.4 & A.5: Third Row
All displayed elements remain unmolested.
Descriptor ABCDEFGHIJKLM is handsomely accommodated in:
--- Scenario Panel Areas A.4 & A.5: Second Row
--- Scenario Panel Area A.6
--- Unit Info Pop-up Screen
--- Battlefield & Undeployed Unit Listing Ribbon Panels
--- Unit Upgrade & Purchase Pop-up Screens
--- New Equipment Availability Notification Pop-up Screen
without any additional modifications.
More... Ambitious Elongations ?
The preceding notwithstanding, designers may decide to do some uncaring... violence to the UT-related information displayed within the Scenario Panel's FIRST (1st) row of A.5 (Hovered (Mouse Cursor) Unit Info) or, alternatively, substantially expand the Scenario Panel's width so as to accommodate much longer UT descriptors on different screen locations.
As one becomes increasingly... ambitious, he is bound to be faced with all kinds of display problems such as a centered descriptor text and unit icon:
--- Running smack into left side "barriers" and, consequently, not visually fitting into / below the intended, gilded, rectangular frame.
--- Pushing the "next" gilded, rectangular frame out of its intended screen location.
=========================================
Unit Type Descriptor Specification
Unit Type (UT) descriptors are specified in file EQUIPMENT.PGEQP. Traversing the columns from left to right, The SECOND (2nd) column encountered therein is dedicated to such specifications.
Display Screen Locations
A UT descriptor is simultaneously displayed on the following screen locations:
--- Scenario Panel Areas A.4, A.5 & A.6
--- Unit Info Pop-up Screen
--- Battlefield & Undeployed Unit Listing Ribbon Panels
--- Unit Upgrade & Purchase Pop-up Screens
--- New Equipment Availability Notification Pop-up Screen
The Technical Challenge
What is the maximum visual length a UT descriptor can sport which does NOT interfere with the full, unobstructed display of everything which is intended to be displayed on each and every screen location ?
As it turns out, certain screen locations are more "demanding / restrictive" than others.
Potential "Bottlenecks"
The key to ensuring that a UT descriptor can be visually accommodated in all depictive respects is to serially focus on potential "bottlenecks".
The most obvious such potential "bottleneck" screen location is
Scenario Panel ==> A.5 Hovered (Mouse Cursor) Unit Info ==> FIRST (1st) row
The following depictive elements are serially encountered as one traverses the row going from left to right:
--- Military ID Designation
--- {Space Character}
--- UT Descriptor
--- {Space Character}
--- Unit Strength Factors enclosed in parentheses
--- Enemy Unit Strength Factors suffering lasting suppression preceded by a MINUS sign to their immediate LEFT (all in blue color)
Progressive Accommodation Easiness
If one were to ensure that no UT descriptor can ever interfere with the full, unobstructed display of everything which is intended to be displayed on the FIRST (1st) row of A.5 (Hovered (Mouse Cursor) Unit Info), he might NOT need to worry about anything else.
The following is a listing of screen locations where UT descriptors are displayed in generally increasing accommodation easiness:
1) SECOND (2nd) row in A.4 (Selected Friendly Unit Info) and A.5 (Hovered Unit Info). The following depictive elements are serially encountered as one traverses the row going from left to right:
--- UT Descriptor
--- {Space Character}
--- {Organic Transport Tiny Icon}
--- {Space Character}
--- {5 Stars}
2) Immediately below the Unit Icons displayed within gilded rectangular frames in the Battlefield & Undeployed Unit Listing Ribbon Panels. The following depictive elements are serially encountered as one traverses the row going from left to right:
--- Military ID Designation
--- {Space Character}
--- UT Descriptor
3) Everywhere else; just the UT descriptor is displayed.
Just Counting Descriptor Characters Is NOT Enough
For the time being, PGF's "native" UI specification remains unmolested...
Consider the following "maximalist" example specifically applicable to the FIRST (1st) row of A.5 (Hovered (Mouse Cursor) Unit Info) potential "bottleneck":
992nd WWWWWWWW (20)-20
where the UT descriptor consists of EIGHT (8) upper case Ws.
Now compare it with the following "minimalist" example:
1st IIIIIIII (1)
where the UT descriptor consists of EIGHT (8) upper case Is.
Clearly, all potential UT visual length display eventualities will essentially fall in between those two extremes. To this effect, empty space to the immediate right of the row's content will vary in length.
More Elongation, Please ?
What if, say, one wants to fully accommodate the "maximalist" example of
992nd WWWWWWWWWW (20)-20
where the UT descriptor now consists of TEN (10) upper case Ws ?
Fortunately, this is currently, technically feasible. It requires that the PGF's "native" UI be modified so that the Scenario Panel's width is allowed to grow a bit at the attendant expense of the Tactical Map's rectangular surface, of course. To be precise, the Tactical Map's "native" aspect ratio is 39:29. The following requisite modifications to the contents of file MAIN.HTM residing in the UI subfolder will render the aspect ratio 37:29:
Modification 1
FROM ==>
Code: Select all
<div id="StatusInfo" style="left:2#; top:1#; width:180px; height:79px; overflow: hidden; background-image: url(SIDE-0_HEADER.PNG); background-position:50% 50%; background-repeat:no-repeat;">
Code: Select all
<div id="StatusInfo" style="left:2#; top:1#; width:213px; height:79px; overflow: hidden; background-image: url(SIDE-0_HEADER.PNG); background-position:50% 50%; background-repeat:no-repeat;">
FROM ==>
Code: Select all
<div id="StatusInfo" style="left:2#; top:2#; width:180px; height: 36px; text-align: center; overflow: hidden">
Code: Select all
<div id="StatusInfo" style="left:2#; top:2#; width:213px; height: 36px; text-align: center; overflow: hidden">
FROM ==>
Code: Select all
<div style="left:2#; top: 7#; height:100%%; width:180px; border-spacing: 7px; overflow: hidden">
Code: Select all
<div style="left:2#; top: 7#; height:100%%; width:213px; border-spacing: 7px; overflow: hidden">
FROM ==>
Code: Select all
<div style="left:2#; top:9#; width:180px; height:32px; overflow: hidden"><center><img src="SIDE-0_FOOTER.PNG" /></center></div>
Code: Select all
<div style="left:2#; top:9#; width:213px; height:32px; overflow: hidden"><center><img src="SIDE-0_FOOTER.PNG" /></center></div>
The first TWO (2) modifications widen the Scenario Panel's rectangular area by approximately TWO (2) centimeters.
The last TWO (2) modifications ensure that all visual elements displayed within the Scenario Panel's rectangular area A6 are visually centered.
It's somewhat useful to visually peruse, say, in MS Notepad, the following vertical comparisons:
WWWWWWWWWW
ABCDEFGHIJKLM
abcdefghijklmnop
Give or take ONE (1) character, there're THIRTEEN (13) upper case characters OR, alternatively, SIXTEEN (16) lower case characters which can visually be accommodated now.
Fundamental Given
The decision one makes and implements regarding the Scenario Panel's width forms the basis of reference for all other UT descriptor screen display manifestations. To this effect, I've already made my strictly personal selection: 213px. The rest follows...
Safe Harbor Technical Suggestion
If one has not yet implemented the technical suggestion covered in
Where Did The "Close" Button Go ?
viewtopic.php?f=100&t=554#p9101
I strongly recommend he does so now !
Excellent News Across the Board
Scenario Panel Areas A.4 & A.5: Third Row
All displayed elements remain unmolested.
Descriptor ABCDEFGHIJKLM is handsomely accommodated in:
--- Scenario Panel Areas A.4 & A.5: Second Row
--- Scenario Panel Area A.6
--- Unit Info Pop-up Screen
--- Battlefield & Undeployed Unit Listing Ribbon Panels
--- Unit Upgrade & Purchase Pop-up Screens
--- New Equipment Availability Notification Pop-up Screen
without any additional modifications.
More... Ambitious Elongations ?
The preceding notwithstanding, designers may decide to do some uncaring... violence to the UT-related information displayed within the Scenario Panel's FIRST (1st) row of A.5 (Hovered (Mouse Cursor) Unit Info) or, alternatively, substantially expand the Scenario Panel's width so as to accommodate much longer UT descriptors on different screen locations.
As one becomes increasingly... ambitious, he is bound to be faced with all kinds of display problems such as a centered descriptor text and unit icon:
--- Running smack into left side "barriers" and, consequently, not visually fitting into / below the intended, gilded, rectangular frame.
--- Pushing the "next" gilded, rectangular frame out of its intended screen location.
STANDALONE SCENARIO PLAY: CORE & AUXILIARY UNIT DESIGNATION USES
STANDALONE SCENARIO PLAY: CORE & AUXILIARY UNIT DESIGNATION USES
==================================================================
Observation
While playing PGF scenarios in Standalone Mode, one notices that the program often "insists" on depicting a certain side's individual units as either Core or Auxiliary. Strictly from a play system standpoint per se, it makes no real difference, of course.
Potential Utility
1) The unit strength labels corresponding to Core Designation are visually sharper than the ones corresponding to Auxiliary Designation. Other things being equal, Core Designation is ergonomically preferable.
2) A content designer may wish to introduce specific unit organizational distinctions by employing both Designations in files *.PGSCN. The pertinent unit setting is Boolean (i.e., ZERO (0) for Core and ONE (1) for Auxiliary).
3) Files *.PGSCN can be utilized to introduce various kinds of restrictive differentiation potentially applicable to replacing (or not) specifically Designated, prepositioned units upon their elimination via new unit procurements.
Elsewhere in the Library:
==================================================================
Observation
While playing PGF scenarios in Standalone Mode, one notices that the program often "insists" on depicting a certain side's individual units as either Core or Auxiliary. Strictly from a play system standpoint per se, it makes no real difference, of course.
Potential Utility
1) The unit strength labels corresponding to Core Designation are visually sharper than the ones corresponding to Auxiliary Designation. Other things being equal, Core Designation is ergonomically preferable.
2) A content designer may wish to introduce specific unit organizational distinctions by employing both Designations in files *.PGSCN. The pertinent unit setting is Boolean (i.e., ZERO (0) for Core and ONE (1) for Auxiliary).
3) Files *.PGSCN can be utilized to introduce various kinds of restrictive differentiation potentially applicable to replacing (or not) specifically Designated, prepositioned units upon their elimination via new unit procurements.
Elsewhere in the Library:
One may wish to impede the number of new unit purchases without necessarily zeroing in on specific Unit Classes or Types. Such restrictions (i.e., "obstacles") may apply to the Core Complement, the Auxiliaries Complement or both. They are side-specific. To accomplish this, one opens the relevant scenario-specific *.PGSCN file and locates the section entitled "Sides". Under this section, there are two adjacent columns entitled "Core Limit" and "Aux Limit" respectively. It is up to the scenario designer / modder to choose specific values which are consistent with his restrictive aims.
LAND MINEFIELD UNITS
LAND MINEFIELD UNITS
====================
Minefields on land hexes can be represented by suitably "constructed" Land Minefield Unit Types (LMUTs).
Desirable Properties & Suggested Solutions
LMUTs:
A) Should NOT be allowed to voluntarily move. This is accomplished by setting their Movement Allowance (MA) value to ZERO (0).
B) Should NOT be allowed to retreat upon enemy-initiated attacks against them. This can be accomplished by designating them as Structure Class units and / or assigning them Naval Movement Type.
C) Should be rendered vulnerable (in varying degrees) to enemy-initiated attacks by a well defined subset of Unit Classes and Types. This would necessitate a precise analysis of enemy Unit Classes / Types which would be capable of initiating attacks against LMUTs sporting specific Unit Class and Target Type designations.
D) Should (or not) be allowed to initiate attacks against enemy units occupying adjacent hexes. Hex-Based, Half-Turn-Based play systems always struggle with representations of event simultaneity...
d1) A proactive minefield can be represented by an LMUT assigned to the Structure Unit Class.
d2) A reactive minefield can be represented by an LMUT assigned to the Air Defense Unit Class (with Air Attack value set to ZERO (0)) and assigned Naval Movement Type.
E) Should (or not) be allowed to receive Replacements and / or Supplies.
e1) Assigning LMUTs to the Structure Unit Class disallows the granting of Replacements altogether provided they are NOT placed on Port / Embarkation City hexes.
e2) Assigning Desert terrain to the hex on which an LMUT is situated severely limits the unit's ability to receive Resupply.
F) Should (or not) be probabilistically spottable (i.e., Submarine Unit Class property). In my opinion, rendering LMUTs probabilistically spottable may not be that important. These units are stationary. Therefore, once spotted, always... remembered.
G) Should (or not) be differentiated as per intended enemy Target Types (e.g., Anti-Personnel, Anti-Tank). Any such differentiation will be reflected in the specific choices of the unit's Soft and Hard Attack values.
H) Should (or not) sport sufficiently high Entrenchment Level / Strength Factor / Various Defense / Ammo Capacity values to render (or not) such units more resilient to enemy efforts to eliminate them. Clearly the sky's the limit here. Content designers have quite a few degrees of freedom to fine tune their "brainchildren".
No Perfect Solution...
It would be a true miracle if PGF's play system were to be able to accommodate the "perfect" all around LMUT solution. However, depending on the particular content designer, the presence of certain LMUT properties / restrictions may be more important than that of others. Representation realism and scenario specificity will always inform such preferences, of course. Equally important, perhaps, what will PGF's AI be doing (or not) with such brand new... toys ?
====================
Minefields on land hexes can be represented by suitably "constructed" Land Minefield Unit Types (LMUTs).
Desirable Properties & Suggested Solutions
LMUTs:
A) Should NOT be allowed to voluntarily move. This is accomplished by setting their Movement Allowance (MA) value to ZERO (0).
B) Should NOT be allowed to retreat upon enemy-initiated attacks against them. This can be accomplished by designating them as Structure Class units and / or assigning them Naval Movement Type.
C) Should be rendered vulnerable (in varying degrees) to enemy-initiated attacks by a well defined subset of Unit Classes and Types. This would necessitate a precise analysis of enemy Unit Classes / Types which would be capable of initiating attacks against LMUTs sporting specific Unit Class and Target Type designations.
D) Should (or not) be allowed to initiate attacks against enemy units occupying adjacent hexes. Hex-Based, Half-Turn-Based play systems always struggle with representations of event simultaneity...
d1) A proactive minefield can be represented by an LMUT assigned to the Structure Unit Class.
d2) A reactive minefield can be represented by an LMUT assigned to the Air Defense Unit Class (with Air Attack value set to ZERO (0)) and assigned Naval Movement Type.
E) Should (or not) be allowed to receive Replacements and / or Supplies.
e1) Assigning LMUTs to the Structure Unit Class disallows the granting of Replacements altogether provided they are NOT placed on Port / Embarkation City hexes.
e2) Assigning Desert terrain to the hex on which an LMUT is situated severely limits the unit's ability to receive Resupply.
F) Should (or not) be probabilistically spottable (i.e., Submarine Unit Class property). In my opinion, rendering LMUTs probabilistically spottable may not be that important. These units are stationary. Therefore, once spotted, always... remembered.
G) Should (or not) be differentiated as per intended enemy Target Types (e.g., Anti-Personnel, Anti-Tank). Any such differentiation will be reflected in the specific choices of the unit's Soft and Hard Attack values.
H) Should (or not) sport sufficiently high Entrenchment Level / Strength Factor / Various Defense / Ammo Capacity values to render (or not) such units more resilient to enemy efforts to eliminate them. Clearly the sky's the limit here. Content designers have quite a few degrees of freedom to fine tune their "brainchildren".
No Perfect Solution...
It would be a true miracle if PGF's play system were to be able to accommodate the "perfect" all around LMUT solution. However, depending on the particular content designer, the presence of certain LMUT properties / restrictions may be more important than that of others. Representation realism and scenario specificity will always inform such preferences, of course. Equally important, perhaps, what will PGF's AI be doing (or not) with such brand new... toys ?
Last edited by HexCode on 2021-11-18 19:23, Thursday, edited 1 time in total.
RESTRICTING UNIT OVER-STRENGTHENING
RESTRICTING UNIT OVER-STRENGTHENING
=====================================
Helpful Reference
Restricting Unit Experience Gains
viewtopic.php?f=100&t=540#p8966
Intent
Some modders may consider restricting the ability of experienced Core Units to procure Over-Strengthening Factors (OSFs) so as to render campaigns somewhat more challenging; ditto for longish scenarios playable in Standalone Mode.
Technical Means
PGF provides modders with technical means to put restrictions on unit OSF procurement. This is accomplished by assigning appropriate values to variable "Max Unit Strength", encountered in scenario files *.PGSCN under the section entitled "General scenario data" (PGF programmer's choice of text).
The above setting is scenario-specific. To boot, it applies to all units present. To repeat, the setting's assigned value impacts in-game behavior across the board within any particular scenario.
"Max Unit Strength" Setting -- It Only Impacts Certain In-Game Events
One should NOT get the impression that the "Max Unit Strength" setting lops off any preexisting, "excess" Strength Factors (SFs).
Unit Over-Strengthening Restriction
Whether a unit has been prepositioned or not, the "Max Unit Strength" setting in no way interferes with the unit's preexisting SFs and Experience Levels (ELs). Instead:
MUS = Scenario-Wide "Max Unit Strength" setting value
RTELs = Restriction Target ELs = "MUS" MINUS TEN = MUS - 10
For OSF procurement purposes and only those, a unit sporting ELs HIGHER THAN "RTELs" is treated as if its ELs just exactly match the "RTELs" value as computed above.
Modding Implications
"MUS" values:
a) LOWER THAN OR EQUAL TO TEN (10) disallow any kind of unit Over-Strengthening across the board. Nevertheless, Under-Strength (i.e., SFs < 10) units are still allowed to procure Elite Replacements as per the usual play system provisions, possibly even bringing them up to full, "normal" strength (i.e., SFs = 10) in one fell swoop.
b) HIGHER THAN TEN (10) DO allow unit Over-Strengthening provided a unit's:
--- SFs are fewer than the scenario "MUS" setting's value.
--- ELs (possibly capped as "RTELs") leave room for OSF procurement.
Beware, Though ! A Fly In the... Ointment
Desert... Super-Easy Unit Over-Strengthening
viewtopic.php?f=100&t=555#p9110
=====================================
Helpful Reference
Restricting Unit Experience Gains
viewtopic.php?f=100&t=540#p8966
Intent
Some modders may consider restricting the ability of experienced Core Units to procure Over-Strengthening Factors (OSFs) so as to render campaigns somewhat more challenging; ditto for longish scenarios playable in Standalone Mode.
Technical Means
PGF provides modders with technical means to put restrictions on unit OSF procurement. This is accomplished by assigning appropriate values to variable "Max Unit Strength", encountered in scenario files *.PGSCN under the section entitled "General scenario data" (PGF programmer's choice of text).
The above setting is scenario-specific. To boot, it applies to all units present. To repeat, the setting's assigned value impacts in-game behavior across the board within any particular scenario.
"Max Unit Strength" Setting -- It Only Impacts Certain In-Game Events
One should NOT get the impression that the "Max Unit Strength" setting lops off any preexisting, "excess" Strength Factors (SFs).
Unit Over-Strengthening Restriction
Whether a unit has been prepositioned or not, the "Max Unit Strength" setting in no way interferes with the unit's preexisting SFs and Experience Levels (ELs). Instead:
MUS = Scenario-Wide "Max Unit Strength" setting value
RTELs = Restriction Target ELs = "MUS" MINUS TEN = MUS - 10
For OSF procurement purposes and only those, a unit sporting ELs HIGHER THAN "RTELs" is treated as if its ELs just exactly match the "RTELs" value as computed above.
Modding Implications
"MUS" values:
a) LOWER THAN OR EQUAL TO TEN (10) disallow any kind of unit Over-Strengthening across the board. Nevertheless, Under-Strength (i.e., SFs < 10) units are still allowed to procure Elite Replacements as per the usual play system provisions, possibly even bringing them up to full, "normal" strength (i.e., SFs = 10) in one fell swoop.
b) HIGHER THAN TEN (10) DO allow unit Over-Strengthening provided a unit's:
--- SFs are fewer than the scenario "MUS" setting's value.
--- ELs (possibly capped as "RTELs") leave room for OSF procurement.
Beware, Though ! A Fly In the... Ointment
Desert... Super-Easy Unit Over-Strengthening
viewtopic.php?f=100&t=555#p9110
Last edited by HexCode on 2021-10-27 05:18, Wednesday, edited 1 time in total.
SCENARIO PANEL BUTTON... SURGERY
SCENARIO PANEL BUTTON... SURGERY
==================================
Preliminaries
PGF's Scenario Panel sports SIXTEEN (16) buttons neatly arranged along FOUR (4) successively displayed rows. There are THREE (3) aspects specific to each such button. Its:
--- Function
--- Tooltip Descriptor
--- Iconic Representation
Technical Definition
A button's technical definition is encountered in file MAIN.HTM which resides in the UI subfolder. It looks like this:
For example, the "Disband" button is defined as follows:
Changing the Button's Icon
One replaces image file "btn_Icon.png" residing in the UI subfolder with his own custom made icon (PNG format).
Changing the Button Tooltip's Text
One replaces "Descriptor" with whatever text he wishes provided he encloses it within double quotation marks.
Changing the Button's Function
Disabling It Altogether
One replaces "btn_Function" with "" (i.e., nothing). For semantic and visual completeness, one also replaces "Descriptor" and "btn_Icon.png" with "" respectively as well. All this... "nothingness" renders the button bland looking and definitely a dud !
Attention: One can still override the restriction imposed by a disabled button by invoking the relevant, dedicated "hot key", if any.
Changing Its Function
PGF's executable contains a listing of "recognizable" variables pointing to various specific functions. All such variables sport names starting with "btn_". Precisely referencing any one of these functions will accomplish the task.
Cautionary Remark
As long as "advanced" modders utilize the same User Interface and PGF executable to both play and mod, they should be careful about disabling any buttons. What might be desirable for actual play may actually come back to haunt scenario designers who always benefit from as many degrees of modding freedom as possible while tinkering with their custom content.
==================================
Preliminaries
PGF's Scenario Panel sports SIXTEEN (16) buttons neatly arranged along FOUR (4) successively displayed rows. There are THREE (3) aspects specific to each such button. Its:
--- Function
--- Tooltip Descriptor
--- Iconic Representation
Technical Definition
A button's technical definition is encountered in file MAIN.HTM which resides in the UI subfolder. It looks like this:
Code: Select all
<td.pgbtn id="btn_Function" tooltip="Descriptor" ><img src="btn_Icon.png" /></td>
Code: Select all
<td.pgbtn id="btn_disband" tooltip="Disband Unit" ><img src="btn_disband.png" /></td>
One replaces image file "btn_Icon.png" residing in the UI subfolder with his own custom made icon (PNG format).
Changing the Button Tooltip's Text
One replaces "Descriptor" with whatever text he wishes provided he encloses it within double quotation marks.
Changing the Button's Function
Disabling It Altogether
One replaces "btn_Function" with "" (i.e., nothing). For semantic and visual completeness, one also replaces "Descriptor" and "btn_Icon.png" with "" respectively as well. All this... "nothingness" renders the button bland looking and definitely a dud !
Attention: One can still override the restriction imposed by a disabled button by invoking the relevant, dedicated "hot key", if any.
Changing Its Function
PGF's executable contains a listing of "recognizable" variables pointing to various specific functions. All such variables sport names starting with "btn_". Precisely referencing any one of these functions will accomplish the task.
Cautionary Remark
As long as "advanced" modders utilize the same User Interface and PGF executable to both play and mod, they should be careful about disabling any buttons. What might be desirable for actual play may actually come back to haunt scenario designers who always benefit from as many degrees of modding freedom as possible while tinkering with their custom content.
Last edited by HexCode on 2022-09-28 19:13, Wednesday, edited 2 times in total.
CITY & PORT TYPE VISUAL DIFFERENTIATION
CITY & PORT TYPE VISUAL DIFFERENTIATION
=======================================
Absolute Prerequisite
City & Port Typology
viewtopic.php?f=100&t=543#p11524
Symbolic Effectiveness Measures
A) How is a player supposed to visually distinguish between Non-Naval and Embarkation City hexes ? Obviously, SSI never intended (or, more appropriately, neglected for) their visible map tiles to provide guidance in this instance...
My suggested solution is quite simple and efficacious. In file MAPNAMES.STR, the string "XXXXXXXXX" referring and corresponding to some particular Embarkation City hex is expanded to "XXXXXXXXX #E". "#E" symbolically and explicitly points to a City hex enjoying embarkation capabilities.
B) How is a player supposed to visually distinguish between Port City and Facilities hexes ? Once again, SSI never intended (or, more appropriately, neglected for) their visible map tiles to provide guidance in this instance...
Unsurprisingly, my suggested solution is also quite simple and efficacious. In file MAPNAMES.STR, the string "YYYYYYYYY" referring and corresponding to some particular Port Facilities hex is expanded to "YYYYYYYYY #F". "#F" symbolically and explicitly points to a Port Facilities hex.
=======================================
Absolute Prerequisite
City & Port Typology
viewtopic.php?f=100&t=543#p11524
Symbolic Effectiveness Measures
A) How is a player supposed to visually distinguish between Non-Naval and Embarkation City hexes ? Obviously, SSI never intended (or, more appropriately, neglected for) their visible map tiles to provide guidance in this instance...
My suggested solution is quite simple and efficacious. In file MAPNAMES.STR, the string "XXXXXXXXX" referring and corresponding to some particular Embarkation City hex is expanded to "XXXXXXXXX #E". "#E" symbolically and explicitly points to a City hex enjoying embarkation capabilities.
B) How is a player supposed to visually distinguish between Port City and Facilities hexes ? Once again, SSI never intended (or, more appropriately, neglected for) their visible map tiles to provide guidance in this instance...
Unsurprisingly, my suggested solution is also quite simple and efficacious. In file MAPNAMES.STR, the string "YYYYYYYYY" referring and corresponding to some particular Port Facilities hex is expanded to "YYYYYYYYY #F". "#F" symbolically and explicitly points to a Port Facilities hex.
CORE COMPLEMENT: "UNORTHODOX" RESTRICTIONS
CORE COMPLEMENT: "UNORTHODOX" RESTRICTIONS
=============================================
Absolute Prerequisite
Turns, Weather & Core Unit Deployment
viewtopic.php?f=100&t=531#p9299
"Unorthodox" Design Ways
One can certainly visualize situations massively deviating from SSI's "flagship" content paradigm whereby the effective Core Complement's size and / or composition are being restricted, possibly as a result of poor battlefield performance...
Core Unit Disbandment
The only way a Core unit can be disbanded is for the player to voluntarily do so in-game, after the Core unit gets actually deployed on the map.
Core Unit "On the Map Isolation"
In board wargaming, maps sporting a section (most likely along one of the map's edges) which is completely insulated from the rest of the map are quite common. So, such a "construct" can readily be implemented in PGF content territory by employing a "zone" of completely unenterable (i.e., "neutral") hexes.
By voluntarily deploying a Core unit onto such a section, one ensures that the unit will be practically unavailable during the Campaign scenario's entire duration; well, 3-hex or farther ranged fire CAN cross such a "zone"...
Very Few Deployment Hexes
By severely restricting the number of Deployment Zone hexes, one can drastically slow down the pace of their potential appearance in-game. During each and, possibly, every turn, the player will have to decide which hitherto undeployed Core units are needed the most and act accordingly.
=============================================
Absolute Prerequisite
Turns, Weather & Core Unit Deployment
viewtopic.php?f=100&t=531#p9299
"Unorthodox" Design Ways
One can certainly visualize situations massively deviating from SSI's "flagship" content paradigm whereby the effective Core Complement's size and / or composition are being restricted, possibly as a result of poor battlefield performance...
Core Unit Disbandment
The only way a Core unit can be disbanded is for the player to voluntarily do so in-game, after the Core unit gets actually deployed on the map.
Core Unit "On the Map Isolation"
In board wargaming, maps sporting a section (most likely along one of the map's edges) which is completely insulated from the rest of the map are quite common. So, such a "construct" can readily be implemented in PGF content territory by employing a "zone" of completely unenterable (i.e., "neutral") hexes.
By voluntarily deploying a Core unit onto such a section, one ensures that the unit will be practically unavailable during the Campaign scenario's entire duration; well, 3-hex or farther ranged fire CAN cross such a "zone"...
Very Few Deployment Hexes
By severely restricting the number of Deployment Zone hexes, one can drastically slow down the pace of their potential appearance in-game. During each and, possibly, every turn, the player will have to decide which hitherto undeployed Core units are needed the most and act accordingly.
SCENARIO DURATION: TECHNICAL SPECIFICATION
SCENARIO DURATION: TECHNICAL SPECIFICATION
===========================================
The Elements
File *.PGSCN contains the data effectively controlling a scenario's maximum duration (expressed in turns). Specifically:
a) File section entitled "General scenario data" hosts variable "Turns" together with its value.
b) File section entitled "Per-turn prestige allotments" hosts a table of data, vertically arranged, one row per successive turn.
An Asymmetrical Relationship
It is the value of variable "Turns" which establishes a scenario's maximum duration (expressed in turns).
BUT
The file section mentioned under preceding point (b) should contain a table with at least as many rows as the value of variable "Turns".
1) If PGF's engine comes across a situation in-game where there are NO table data corresponding to the "NEXT TO CURRENT" turn, it crashes upon termination of the "CURRENT" turn (i.e., before it actually gets to that "NEXT" turn).
2) The presence of "extra" table data corresponding to turns higher than the value of variable "Turns" is completely benign. PGF's engine just ignores them.
Elsewhere In the Library
===========================================
The Elements
File *.PGSCN contains the data effectively controlling a scenario's maximum duration (expressed in turns). Specifically:
a) File section entitled "General scenario data" hosts variable "Turns" together with its value.
b) File section entitled "Per-turn prestige allotments" hosts a table of data, vertically arranged, one row per successive turn.
An Asymmetrical Relationship
It is the value of variable "Turns" which establishes a scenario's maximum duration (expressed in turns).
BUT
The file section mentioned under preceding point (b) should contain a table with at least as many rows as the value of variable "Turns".
1) If PGF's engine comes across a situation in-game where there are NO table data corresponding to the "NEXT TO CURRENT" turn, it crashes upon termination of the "CURRENT" turn (i.e., before it actually gets to that "NEXT" turn).
2) The presence of "extra" table data corresponding to turns higher than the value of variable "Turns" is completely benign. PGF's engine just ignores them.
Elsewhere In the Library
A Template Exampleturns #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.
Code: Select all
# TURN-SPECIFIC
# PRESTIGE
# ALLOTMENTs
# TURN SIDE_0 SIDE_1
1 0 0
2 0 0
3 0 0
4 0 0
5 0 0
6 0 0
7 0 0
8 0 0
9 0 0
10 0 0
11 0 0
12 0 0
13 0 0
14 0 0
15 0 0
16 0 0
17 0 0
18 0 0
19 0 0
20 0 0
21 0 0
22 0 0
23 0 0
24 0 0
25 0 0
26 0 0
27 0 0
28 0 0
29 0 0
30 0 0
31 0 0
32 0 0
33 0 0
34 0 0
35 0 0
36 0 0
37 0 0
38 0 0
39 0 0
40 0 0
41 0 0
42 0 0
43 0 0
44 0 0
45 0 0
46 0 0
47 0 0
48 0 0
49 0 0
50 0 0
51 0 0
52 0 0
53 0 0
54 0 0
55 0 0
56 0 0
57 0 0
58 0 0
59 0 0
60 0 0
61 0 0
62 0 0
63 0 0
64 0 0
65 0 0
66 0 0
67 0 0
68 0 0
69 0 0
70 0 0
71 0 0
72 0 0
73 0 0
74 0 0
75 0 0
76 0 0
77 0 0
78 0 0
79 0 0
80 0 0
81 0 0
82 0 0
83 0 0
84 0 0
85 0 0
86 0 0
87 0 0
88 0 0
89 0 0
90 0 0
91 0 0
92 0 0
93 0 0
94 0 0
95 0 0
96 0 0
97 0 0
98 0 0
99 0 0
OBJECTIVE HEX COMPLETE UNENTERABILITY: VICTORY DETERMINATION IMPLICATIONS
OBJECTIVE HEX COMPLETE UNENTERABILITY: VICTORY DETERMINATION IMPLICATIONS
===============================================================
Absolute Requirements
Victory Conditions: Terminology
viewtopic.php?f=100&t=543#p8976
Listed & Unlisted Combatants
viewtopic.php?f=100&t=543#p11540
Early Victory
With respect to declaring an Early Victory, PGF's engine does NOT check individual objective hex Ownership without any preconditions; rather, it limits the scope of such checks across the map to Listed Combatant-Owned (LC-Owned) objective hexes only.
Since the ownership of a completely unenterable (i.e., "Neutral") objective hex can NEVER change in-game:
a) If such a hex is LC-Owned, no new element is introduced into PGF engine's Early Victory checks. Relatedly, the Side which does NOT own the objective hex can NEVER score an Early Victory in-game.
b) If, on the other hand, the objective hex is owned by an Unlisted Combatant (UC), PGF engine's Early Victory checks will be in vain. Specifically, NEITHER Side can ever score an Early Victory in-game.
Automatic Victory
With respect to declaring an Automatic Victory, PGF's engine does NOT check individual Combatant unit Ownership; rather, it checks individual Combatant unit Side Alignments across the map.
The presence of a unit ON / OVER a completely unenterable objective hex makes no difference whatsoever to PGF engine's Automatic Victory checks.
Modding Implications
By rendering some objective hex completely unenterable, a modder may exclude Early Victory as a possible scenario Victory Condition for one or both Sides. When so, Victory Conditions will be limited to Automatic Victory and / or End-Point Victory.
===============================================================
Absolute Requirements
Victory Conditions: Terminology
viewtopic.php?f=100&t=543#p8976
Listed & Unlisted Combatants
viewtopic.php?f=100&t=543#p11540
Early Victory
With respect to declaring an Early Victory, PGF's engine does NOT check individual objective hex Ownership without any preconditions; rather, it limits the scope of such checks across the map to Listed Combatant-Owned (LC-Owned) objective hexes only.
Since the ownership of a completely unenterable (i.e., "Neutral") objective hex can NEVER change in-game:
a) If such a hex is LC-Owned, no new element is introduced into PGF engine's Early Victory checks. Relatedly, the Side which does NOT own the objective hex can NEVER score an Early Victory in-game.
b) If, on the other hand, the objective hex is owned by an Unlisted Combatant (UC), PGF engine's Early Victory checks will be in vain. Specifically, NEITHER Side can ever score an Early Victory in-game.
Automatic Victory
With respect to declaring an Automatic Victory, PGF's engine does NOT check individual Combatant unit Ownership; rather, it checks individual Combatant unit Side Alignments across the map.
The presence of a unit ON / OVER a completely unenterable objective hex makes no difference whatsoever to PGF engine's Automatic Victory checks.
Modding Implications
By rendering some objective hex completely unenterable, a modder may exclude Early Victory as a possible scenario Victory Condition for one or both Sides. When so, Victory Conditions will be limited to Automatic Victory and / or End-Point Victory.
PREPOSITIONED UNITS: "UNORTHODOX" ENTRENCHMENTS
PREPOSITIONED UNITS: "UNORTHODOX" ENTRENCHMENTS
===================================================
Preliminaries
In-game, PGF's play system caps a Ground Super-Class unit's achievable Entrenchment Levels (ELs) at FIVE (5) OVER AND ABOVE any initially granted ELs due to a hex's underlying terrain. Moreover, Tank Class units are limited to achieving up to TWO (2) ELs irrespective of a hex's underlying terrain.
File *.PGSCN -- Section entitled "Units" sports a column entitled "Entrenchment". Prepositioned units can be assigned specific, commencing ELs by entering the desired values under the aforesaid column.
Prepositioned Ground Super-Class Units
Specific, commencing ELs trump any restrictions enforced by PGF's engine in-game.
Prepositioned Air Super-Class Units
Yes, one can certainly entrench prepositioned Air Super-Class units. SSI's "flagship" content features a handful of such instances...
Prepositioned Naval Super-Class Units
Once again, one can certainly entrench prepositioned Naval Super-Class units. And, yes, SSI's "flagship" content features a handful of such instances...
"Unorthodox" Entrenchments: Combat
PGF's engine does NOT ignore "unorthodox" unit entrenchments. On the contrary, such entrenchments render the units demonstratively more potent in combat. This is the case with Air / Naval Super-Class units as well !
Modding Implications
Rather obvious...
===================================================
Preliminaries
In-game, PGF's play system caps a Ground Super-Class unit's achievable Entrenchment Levels (ELs) at FIVE (5) OVER AND ABOVE any initially granted ELs due to a hex's underlying terrain. Moreover, Tank Class units are limited to achieving up to TWO (2) ELs irrespective of a hex's underlying terrain.
File *.PGSCN -- Section entitled "Units" sports a column entitled "Entrenchment". Prepositioned units can be assigned specific, commencing ELs by entering the desired values under the aforesaid column.
Prepositioned Ground Super-Class Units
Specific, commencing ELs trump any restrictions enforced by PGF's engine in-game.
Prepositioned Air Super-Class Units
Yes, one can certainly entrench prepositioned Air Super-Class units. SSI's "flagship" content features a handful of such instances...
Prepositioned Naval Super-Class Units
Once again, one can certainly entrench prepositioned Naval Super-Class units. And, yes, SSI's "flagship" content features a handful of such instances...
"Unorthodox" Entrenchments: Combat
PGF's engine does NOT ignore "unorthodox" unit entrenchments. On the contrary, such entrenchments render the units demonstratively more potent in combat. This is the case with Air / Naval Super-Class units as well !
Modding Implications
Rather obvious...