PG1: Omnibus Posting (ask questions or comment here)

Panzer / Allied General Remake: Strategies, Tactics, Efiles, Custom Campaigns, Customizations, Documentation.

Moderator: Radoye

Ol' Willy
Private
Private
Posts: 16
Joined: 2021-09-08 12:29, Wednesday

Re: PG1: Omnibus Posting (ask questions or comment here)

Post by Ol' Willy » 2021-09-10 05:44, Friday

Hey guys. I'm making my own little mod for PG1-DOS and since dedicated PG1 forum seems to be dead this forum looks like a good place to ask. I have several questions and would be grateful for answers or directions to these answers.

- What is the unit limit in EQP file?
- What is the icon number limit in TACICONS file?
- I have read that PG1 doesn't allow the campaign path to be changed. Is it still so or there are new workarounds?
- How to change mission's victory conditions? For example, vanilla Barbarossa map: to win, Axis need to capture all VHs; to win, Allies need to retain at least one VH. Let's say I make a Soviet campaign: I just reuse that map and place it in mission slot four; I make Soviet Axis and Germans Allies for gameplay reasons. How do I create victory conditions, i.e., Soviets needing to retain at least one VH for Minor and three VHs for a Major?

HexCode
Second Lieutenant
Second Lieutenant
Posts: 750
Joined: 2019-09-30 18:54, Monday

[PG1] Technical Answers

Post by HexCode » 2021-09-10 16:12, Friday

PG1-DOS
Ol' Willy wrote:
2021-09-10 05:44, Friday
What is the unit limit in EQP file?
450 (not counting the first "RESERVED" record)
Ol' Willy wrote:
2021-09-10 05:44, Friday
What is the icon number limit in TACICONS file?
There's no such limit per se. However, the buffer which accommodates the unit icons is quite limited size-wise. One keeps on adding icons until the game crashes... :)
Ol' Willy wrote:
2021-09-10 05:44, Friday
I have read that PG1 doesn't allow the campaign path to be changed. Is it still so or there are new workarounds?
The only way to do such things is to extensively hex-edit PANZER.EXE. To do so, one will have to be very familiar with some of its hexadecimal contents.
Ol' Willy wrote:
2021-09-10 05:44, Friday
How to change mission's victory conditions? . . . How do I create victory conditions
Once again, the only way to do such things is to extensively hex-edit PANZER.EXE. To do so, one has to be very familiar with some of its hexadecimal contents.

Ol' Willy
Private
Private
Posts: 16
Joined: 2021-09-08 12:29, Wednesday

Re: [PG1] Technical Answers

Post by Ol' Willy » 2021-09-12 17:37, Sunday

HexCode wrote:
2021-09-10 16:12, Friday

Once again, the only way to do such things is to extensively hex-edit PANZER.EXE. To do so, one has to be very familiar with some of its hexadecimal contents.
Thanks. Also I wanted to ask how to change hardcoded unit features or class features but I can see the answer now.

Is there some info somewhere on the hex-structure of Panzer.exe?

HexCode
Second Lieutenant
Second Lieutenant
Posts: 750
Joined: 2019-09-30 18:54, Monday

[PG1] PANZER.EXE Technical Information

Post by HexCode » 2021-09-12 21:12, Sunday

:howdy # Ol' Willy #,

You asked:
Ol' Willy wrote:
2021-09-12 17:37, Sunday
Is there some info somewhere on the hex-structure of Panzer.exe?
Ok, some necessary background and a couple of questions of my own. :)

B1) The poster child of what a determined, technically knowledgeable and adept hobbyist can do by extensively hex-editing PANZER.EXE is none other than Pacific Panzer General (PacPG) playable under PG1-DOS. :clap

B2) Many years ago, a hobbyist unrelated to the development of PacPG "publicly" documented the locations and meaning of a few selected subroutines and passive code data residing within PANZER.EXE. With the exception of this forum's Moderator and myself, the "publicly" manifested "Hobby at Large" just... yawned ! ;)

B3) The aforesaid documentation was hosted by a Web venue that's now defunct. Consequently, the information is no longer accessible.

Q1) Do you consider yourself to be technically skilled enough so as not to be mortally afraid :) of hex-editing hexadecimal code ?

Q2) Why is it that you seem to be interested in performing major hexadecimal "surgery" to PG1-DOS and not simply migrate to the considerably more modder-friendly universe of PGF ?

Best regards,

HC
Last edited by HexCode on 2021-11-17 00:32, Wednesday, edited 1 time in total.

Ol' Willy
Private
Private
Posts: 16
Joined: 2021-09-08 12:29, Wednesday

Re: [PG1] PANZER.EXE Technical Information

Post by Ol' Willy » 2021-09-13 11:48, Monday

HexCode wrote:
2021-09-12 21:12, Sunday
Best regards,

HC
B1) Yeah, I play it right now, quality stuff.
B3) You mean JP forum? Not only it's gone, but also excluded from Wayback machine. What a mystery
Q2) I like the DOS PG engine. Tried PGF, not a fan. OpenGen engine is also cool, but maybe I delve in it later

PepaDrobny
Private
Private
Posts: 28
Joined: 2019-10-16 19:56, Wednesday
Location: CZ
Contact:

Re: [PG1] PANZER.EXE Technical Information

Post by PepaDrobny » 2021-09-17 14:43, Friday

Hallo Ol' Willy and Hexcode
Ol' Willy wrote:
2021-09-10 05:44, Friday
- I have read that PG1 doesn't allow the campaign path to be changed.
- How to change mission's victory conditions?
Can be changed, proven by PacPG :)
But very hard and log time consuming to explain it to profi programmer. Unpossible to layman.
Fortunately there is way, just send me your ideas and stuff and I can do it for you when possible.
HexCode wrote:
2021-09-12 21:12, Sunday

Q2) Why ... not simply migrate to the considerably more modder-friendly universe of PGF ?
Unfortunately, there is serious reason - because of unoriginality and big stupidity of AI of PGF.

Ol' Willy
Private
Private
Posts: 16
Joined: 2021-09-08 12:29, Wednesday

Re: [PG1] PANZER.EXE Technical Information

Post by Ol' Willy » 2021-09-17 16:52, Friday

PepaDrobny wrote:
2021-09-17 14:43, Friday

Can be changed, proven by PacPG :)
But very hard and log time consuming to explain it to profi programmer. Unpossible to layman.
Fortunately there is way, just send me your ideas and stuff and I can do it for you when possible.
Thanks man. I still work on original campaign but then I want to make a Soviet one. I will not bother you until everything is finished, so that's that

PepaDrobny
Private
Private
Posts: 28
Joined: 2019-10-16 19:56, Wednesday
Location: CZ
Contact:

Re: [PG1] PANZER.EXE Technical Information

Post by PepaDrobny » 2021-09-18 05:22, Saturday

Ol' Willy wrote:
2021-09-17 16:52, Friday
I still work on original campaign
And what you do?

Ol' Willy
Private
Private
Posts: 16
Joined: 2021-09-08 12:29, Wednesday

Re: [PG1] PANZER.EXE Technical Information

Post by Ol' Willy » 2021-09-18 16:59, Saturday

PepaDrobny wrote:
2021-09-18 05:22, Saturday
Ol' Willy wrote:
2021-09-17 16:52, Friday
I still work on original campaign
And what you do?
Well, some of it is as usual - unit bloat in EQP, some historical inaccuracies (I guess everyone was annoyed by FW190 appearing to early), some changes to the maps, etc.

Some are changes to make different units more useful or more different from each other. Like, I divided artillery into four groups: light, medium, heavy, super-heavy. Light has two movement and two range, medium one movement and three range, heavy zero movement and four range, super-heavy zero movement and five range; different icons to distinguish them as well. Recons and infantry are more sturdy. Nerfed Pioneers and Bridge Engineers so they wouldn't be the only choice of infantry for player. Anti-tanks, IMHO, were quite useless until you get powerful ones later in campaign; I gave them actual range so they will be quite handy sometimes. Flak18 in AT role now has two range but zero movement, so it's a good idea to take it behind your tanks in case you will encounter some tough Soviet armor - like Germans did in a real life. And so on.

Also, I quite wondered how do you guys assign stats to various units and vehicles - is it balance, or some other arbitrary criteria? I decided to add some realism to that matter and made some simple formulas that are used to process real life characteristics (from the internet, of course) and give units specs closer to reality. I matched my formulas so the end result won't weer too far away from the original range but results are interesting.

For example, formula for Hard Attack for tanks, antitanks and AA:
- caliber of the gun/10 + length of the gun in cm/35

Sometimes, it matches the original values 1 to 1! But sometimes, the result is very different.

Or movement for planes:
- Max Speed/40

I test the maps with the new EQP and changes: it doesn't differ that much, but the feel is not the same most definitely

HexCode
Second Lieutenant
Second Lieutenant
Posts: 750
Joined: 2019-09-30 18:54, Monday

[PG1] Can They Embark ? (Part I)

Post by HexCode » 2021-09-30 02:05, Thursday

Terminological Mess

From SSI's PG1-DOS manual:
Embark / Disembark
Allows most units to use naval transport... When embarking, the unit's icon is replaced by a sea transport icon. Units can only embark on naval transport at ports or coastal cities... Naval transports can disembark into an adjacent unoccupied land hex.

Entrenchment
Base entrenchment levels are : 3 for cities... 1 for non-city port facilities.

Naval Transports
All cities adjacent to an ocean hex act as ports for the purpose of embarking units on naval transports.

Sea transport is non-organic transport which allows ground units to embark at friendly port facilities or coastal cities and disembark in any unoccupied coastal land hex.

The number of transport points currently available to you appears at the top right of the screen when you pass the mouse icon over a friendly port or coastal port.

Supply
At the end of each turn, naval units which are in port automatically resupply.
Let's see...

--- Ports
--- Port facilities
--- Non-city port facilities
--- Coastal ports
--- Coastal cities
--- Cities

Why not add the kitchen sink... variation while we're at it ? ;)

Cutting Through It All...

Time to do something drastic about the preceding royal mess.

PORT @ = @ Any hex sporting a map tile suggestive of a "port" which IS adjacent to a Body of Water (e.g., Ocean, Sea) hex.

INLAND CITY @ = @ Any hex sporting a map tile suggestive of an urban center which IS NOT adjacent to a Body of Water (e.g., Ocean, Sea) hex.

COASTAL CITY @ = @ Any hex sporting a map tile suggestive of an urban center which IS adjacent to a Body of Water (e.g., Ocean, Sea) hex.

Yet Another Careless Statement...

From SSI's PG1-DOS manual:
All cities adjacent to an ocean hex act as ports for the purpose of embarking units on naval transports.
A case could be made to the effect that SSI's manual was referring to "our" just defined Coastal Cities, right ? If so, SSI-PG1-NORWAY would be ideal to test things out... :hmm The scenario's map contains the following Coastal Cities:

Andalsnes < 10 , 27 >
Trondheim < 17 , 23 >
Bjerkvik < 35 , 01 >

AND

Mo-i-rana < 30 , 11 >

An Allied Player hovering the mouse cursor over the hexes of the preceding, first 3 Coastal Cities respectively would certainly confirm that his observations are in line with SSI's assertion.

BUT

the test would spectacularly fail in the case of Mo-i-rana < 30 , 11 > ! Yet, adjacent hex < 29 , 11 > is an Ocean one. For greater certainty, if the Allied Player were to attempt to embark a friendly unit, the engine will NOT allow him to do so... :evil ;)
Last edited by HexCode on 2021-10-19 22:43, Tuesday, edited 3 times in total.

HexCode
Second Lieutenant
Second Lieutenant
Posts: 750
Joined: 2019-09-30 18:54, Monday

[PG1] Can They Embark ? (Part II)

Post by HexCode » 2021-09-30 16:27, Thursday

Early Days Experimentation

Attempting to understand the "Mo-i-rana Exception", a certain "researcher" loaded SSI-PG1-NORWAY's (Scenario #3) file definition into C. Tyson's good ol' PZGMAPED support utility.

Lo and behold, PZGMAPED identified Andalsnes < 10 , 27 > , Trondheim < 17 , 23 > and Bjerkvik < 35 , 01 > as "Ports" by virtue of their Underlying Terrain Representation (UTR) hexadecimal "1D" (1Dh). On the other hand, Mo-i-rana < 30 , 11 > was identified as "City" by virtue of its UTR hexadecimal "15" (15h).

Logical Conclusion

Clearly, although adjacency to a map hex properly sporting a Body of Water (in a UTR sense) was necessary for Unit Naval Embarkation (UNE), it was not sufficient !! UTR "1D" did allow for UNE while UTR "15" did not...

Robust Terminology

There are TWO (2) Coastal City types:

1) EMBARKATION CITY @ = @ UTR "1D" ; decimal 29

2) NON-NAVAL CITY @ = @ UTR "15" ; decimal 21

Symbolic Effectiveness Measures

How was a player supposed to visually distinguish "things" here ? Obviously, SSI never intended (or, more appropriately, neglected for) the visible map tiles to provide guidance in this instance...

Wait, though; a player could still "tell" by hovering the mouse cursor over the Coastal City hex in question. If it's UTR "1D", the naval transport point availability was going to show up at the top right of the screen (provided the hex was a friendly one and it was his half-turn as well, of course).

The preceding "test" may have been good enough for "AI Warfighting" where the AI never embarks anything... :) But, when it came to challenging H2H play, it was the "little things" that counted... :2cents To this effect, it would behoove a H2H player to fully understand his human opponent's battlefield capabilities and plan accordingly ! :doh

The "adopted" solution was quite simple and efficacious. In file MAPNAMES.STR, the string "Mo-i-rana" was replaced by its somewhat expanded string version "Mo-i-rana #E". "#E" symbolically and explicitly pointed to the Coastal City enjoying UNE capabilities !
Last edited by HexCode on 2021-10-01 22:26, Friday, edited 1 time in total.

PepaDrobny
Private
Private
Posts: 28
Joined: 2019-10-16 19:56, Wednesday
Location: CZ
Contact:

Re: PG1: Omnibus Posting (ask questions or comment here)

Post by PepaDrobny » 2021-10-01 07:06, Friday

HexCode wrote:
2021-09-30 02:05, Thursday
Terminological Mess
......
From SSI's PG1-DOS manual:
All cities adjacent to an ocean hex act as ports for the purpose of embarking units on naval transports.
I am strict opponent of using coastal cities as embarktion points and I never use it in my scenarios.
There is no reason for not using hex of port (if the city really is/has port). When the city is not port (or was not in WW2) in reality (a lot of coastal cities so), there is wrong to use it as embarktion point in PG. For loading transport ship is port needed in real.
At least, when unit loaded to ship in coastal city, ship on inland city hex looks stupid. And additionally, the ship can be stayed in the city. :)

BTW: Do you know about Anzio scenario bug connected with this topic? :)
Latina (18,26) and Sezze (20,25) are not coastal cities, they are deep in land. And wrongly, units can be embarked to sea transport! :D

(Btw2 incorrect name Latina, in fact it was Littoria in WW2 period, renamed after war)

HexCode
Second Lieutenant
Second Lieutenant
Posts: 750
Joined: 2019-09-30 18:54, Monday

[PG1] Play System: Technical Capabilities

Post by HexCode » 2021-10-01 18:48, Friday

My Forum Angle
PepaDrobny wrote:
2021-10-01 07:06, Friday
Do you know about the Anzio scenario bugs connected with this topic? Latina (18,26) and Sezze (20,25) are not coastal cities, they are deep inland. And wrongly, units can be embarked onto sea transport! ... incorrect name Latina, in fact it was Littoria in WW2 period, renamed after war)
[EPH] My Interests: A Restatement
viewtopic.php?f=95&t=174&start=200#p10971

Enjoy ! :ihope :)

WWII Content Choices
PepaDrobny wrote:
2021-10-01 07:06, Friday
I am a strict opponent of using coastal cities as embarkation points and I never use them in my scenarios. There is no reason for not using a hex port (if the city really is/has port). When the city is not a port (or was not in WW2) in reality (like many coastal cities), it is wrong to use it as an embarkation point in PG. To load a transport ship a real port is needed.
I certainly agree. ;)

WWII Content Aesthetics & Glitches
PepaDrobny wrote:
2021-10-01 07:06, Friday
when a unit is loaded into a ship in a coastal city, that ship on inland city hex looks stupid ... additionally, the ship can stay in the city.
Yes, of course. ;)
Last edited by HexCode on 2021-10-04 19:22, Monday, edited 1 time in total.

Ol' Willy
Private
Private
Posts: 16
Joined: 2021-09-08 12:29, Wednesday

Re: PG1: Omnibus Posting (ask questions or comment here)

Post by Ol' Willy » 2021-10-04 15:29, Monday

PepaDrobny, are you Hartmann.Valka? There are few people in this world who can hex edit PG.exe and even less of them who are from Czechia; seems to be not a coincidence.

PepaDrobny
Private
Private
Posts: 28
Joined: 2019-10-16 19:56, Wednesday
Location: CZ
Contact:

Re: PG1: Omnibus Posting (ask questions or comment here)

Post by PepaDrobny » 2021-10-04 16:10, Monday

Ol' Willy wrote:
2021-10-04 15:29, Monday
PepaDrobny, are you Hartmann.Valka?
Oh, Yeah. Hartmann is my nickname.
Guitly as charged! :D
Ol' Willy wrote:
2021-10-04 15:29, Monday
There are few people in this world who can hex edit PG.exe
not PG.exe .... panzer.exe exactly :)
Ol' Willy wrote:
2021-10-04 15:29, Monday
and even less of them who are from Czechia
not even less ... all of them are from Czechia :)

Ol' Willy
Private
Private
Posts: 16
Joined: 2021-09-08 12:29, Wednesday

Re: PG1: Omnibus Posting (ask questions or comment here)

Post by Ol' Willy » 2021-10-04 22:41, Monday

PepaDrobny wrote:
2021-10-04 16:10, Monday
Oh, Yeah. Hartmann is my nickname.
Guitly as charged! :D
Cool!
Gotta say, your mods for PG are great, really classy work.
Cheers!

PepaDrobny
Private
Private
Posts: 28
Joined: 2019-10-16 19:56, Wednesday
Location: CZ
Contact:

Re: PG1: Omnibus Posting (ask questions or comment here)

Post by PepaDrobny » 2021-10-06 18:50, Wednesday

Ol' Willy wrote:
2021-10-04 22:41, Monday
PepaDrobny wrote:
2021-10-04 16:10, Monday
Oh, Yeah. Hartmann is my nickname.
Guitly as charged! :D
Cool!
Gotta say, your mods for PG are great, really classy work.
Cheers!
Image

HexCode
Second Lieutenant
Second Lieutenant
Posts: 750
Joined: 2019-09-30 18:54, Monday

[PG1] Port What ? (Part I)

Post by HexCode » 2021-10-19 02:24, Tuesday

Terminological Mess... Revisited

From SSI's PG1-DOS manual:
Embark / Disembark
Units can only embark on naval transport at ports...

Entrenchment
Base entrenchment levels are : 3 for cities... 1 for non-city port facilities.

Naval Transports
Sea transport is non-organic transport which allows ground units to embark at friendly port facilities... The number of transport points currently available to you appears at the top right of the screen when you pass the mouse icon over a friendly port or coastal port.
Once again, let's see...

--- Ports
--- Port facilities
--- Non-city port facilities
--- Coastal ports

I'm having trouble restraining myself from adding the kitchen sink... variation ! ;)

Hitherto Established Terminology

PORT @ = @ Any hex sporting a map tile suggestive of a "port" which is adjacent to a Body of Water (e.g., Ocean, Sea) hex.

However, are all "Ports" the same ? :evil :)

Early Days Experimentation

A certain "researcher" loaded SSI-PG1-LOW COUNTRIES' (Scenario #4) file definition into C. Tyson's good ol' PZGMAPED support utility. The scenario's map contains the following "Ports" provisionally identified by their map tiles (TIRs) ==>

Calais < 06 , 04 >

AND

Dunkirk < 11 , 03 >

PZGMAPED identified both "Ports" as, well, "Ports"... Calais < 06 , 04 > was identified as UTR hexadecimal "08" (08h), a terrain designation previously encountered in SSI-NORWAY (Scenario #3). But, Dunkirk < 11 , 03 > was identified as UTR hexadecimal "25 (25h), a newly encountered terrain type ! :|

HexCode
Second Lieutenant
Second Lieutenant
Posts: 750
Joined: 2019-09-30 18:54, Monday

[PG1] Port What ? (Part II)

Post by HexCode » 2021-10-20 00:21, Wednesday

Terrain Typology Note

Binary file TACMAP.TGF is an external support file the contents of which, inexplicably, have generated virtually ZERO interest throughout the years... Yet, "advanced" understanding / modding can greatly benefit from familiarity with the file's important data arrays / tables.

As is somewhat known, there're 39 individually defined terrain types (UTRs). These UTRs are aggregated into 12 collectively constituted terrain types. File TACMAP.TGF contains the relevant Terrain Aggregation Table. The engine utilizes this Aggregate Terrain Typology for the most part... :evil :)

"Ports" ?

The 12th Aggregate Terrain Type comprises UTRs hexadecimal "08" (08h) AND "25" (25h). Quite understandably, this Terrain Type is being referred to as "Port".

However, if, in fact, there ARE differences between these two UTRs, don't they "deserve" to sport distinguishing names ?

Consider SSI-PG1-D-DAY (Scenario #15) map hexes < 39 , 02 > and < 45 , 01 >. Their common UTR assignment is hexadecimal "08" (08h). They're clearly identified by (stock) SSI file MAPNAMES.STR as "Port Facility" hexes. Bingo !

For reasons that will become apparent shortly, hexes assigned UTR hexadecimal "25" (25h) are referred to as "Port City" hexes.

Robust Terminology

There are TWO (2) Port types:

1) PORT FACILITY @ = @ UTR "08" ; decimal 8

2) PORT CITY @ = @ UTR "25" ; decimal 37

Port Type Differences

File TACMAP.TGF also contains the Terrain Base Entrenchment Level and Initiative Cap Tables. These tables do NOT observe the Aggregate Terrain Typology. Instead they accommodate data separately for each one of the 39 UTRs.

Consequently, there IS a basis for differentiation here. In fact, (stock) SSI data ARE different.

Now, (stock) SSI data for Cities are identical to the (stock) data corresponding to Port Cities; hence the adoption of the term "City". :bonk

Symbolic Effectiveness Measures

How was a player supposed to visually distinguish "things" here ? Obviously, SSI never intended (or, more appropriately, neglected for) the visible map tiles or any other element of the player interface to provide guidance in this instance...

The "adopted" solution was quite simple and efficacious. In file MAPNAMES.STR, the string "Calais" was replaced by its somewhat expanded string version "Calais #F". "#F" symbolically and explicitly pointed to a Port Facility's properties / capabilities !

HexCode
Second Lieutenant
Second Lieutenant
Posts: 750
Joined: 2019-09-30 18:54, Monday

[PG1] DOSbox Technical Hint

Post by HexCode » 2021-10-21 05:41, Thursday

Some of us may be playing PG1-DOS under MS 64-bit Windows of more recent vintage than XP. Also, there's a bewildering number of possible Display Adapter / (Monitor) Screen combinations... In any case, DOSbox / D-Fend Reloaded have to be invoked ! :bonk

On occasion, the PG1-DOS frame doesn't fit perfectly on the computer screen while playing in full screen mode. Invariably, this is because the computer hardware (and their requisite drivers) can't deal seamlessly with PG1-DOS' original (i.e., native) 640x480 VGA resolution.

The "garden variety" DOSBOX.CONF settings in Section [sdl] look something like this:

Code: Select all

[sdl]
fullscreen=true
fulldouble=false
fullresolution=original
windowresolution=original
output=surface
autolock=true
sensitivity=100
waitonerror=true
priority=higher,normal
mapperfile=mapper-0.74.map
usescancodes=true
Try the following edited version instead:

Code: Select all

[sdl]
fullscreen=true
fulldouble=false
fullresolution=800x600
windowresolution=original
output=overlay
autolock=true
sensitivity=100
waitonerror=true
priority=higher,normal
mapperfile=mapper-0.74.map
usescancodes=true
What has changed ?

1) The value of "fullresolution" has been changed from "original" to "800x600". There's a good chance that your computer will start... behaving properly ! :) :ihope

2) The value of "output" has been changed from "surface" to "overlay". This often "forces" the computer to use the entire screen thereby avoiding playing within black frames of various sizes...

Good luck. :ihope

HexCode
Second Lieutenant
Second Lieutenant
Posts: 750
Joined: 2019-09-30 18:54, Monday

[PG1] Just An Erroneous Display Issue

Post by HexCode » 2021-10-22 07:42, Friday

PepaDrobny wrote:
2021-04-15 08:57, Thursday
When you have in initial deployment more air transport units than slots for air transports possible (can be so in custom scenario, not in original scenario, where always: number of slots >= number of all transport units on map). There is variable in scenario "transports available", visible when you move mouse cursor over own airfield or port. When you lose transport by enemy fire (means not by disbanding or disembark/dropping of para), this variable is dropping by 1. When "transports available" is 0, in such situation next value is calculated by 0 minus 1. In real world is result -1, but in PG world result is jump to 255 :)
This "backwards looping" anomaly doesn't trigger anything of substance out of the ordinary. PG1-DOS still "knows" perfectly well what to do (or not). The player isn't really being granted additional, let alone a treasure trove of, transport points no matter what the screen display might imply. Practically speaking, all this is a rather harmless programming oddity... :2cents

PepaDrobny
Private
Private
Posts: 28
Joined: 2019-10-16 19:56, Wednesday
Location: CZ
Contact:

Re: PG1: Omnibus Posting (ask questions or comment here)

Post by PepaDrobny » 2021-11-20 18:00, Saturday

Bugs in Scenario stats

I have detected some bugs in original PG scenario descriptions:
As a sample see pictures connected with scenario Kharkov. Description says that battle starts on February 11. Wrongly, because in this time was Kharkov still yet on German hands, on February 16 it was taken by Red Army. German counterattack started on February 19, so the date February 21 on 1st turn of scenario is OK.

Complete list:
ScenarioWrong text->Correct textexplanation
WARSAWSeptember 10, 1939->September 11, 1939according 1st turn date of scenario
SEALION (40)missing->.missing dot on end of sentence (all other not missing)
TORCHNov 8, 1942->November 12, 1942full name of month, corrected date as 1st turn in corrected scenario, unit deplyement is as this date
ANZIOJan 22, 1944->January 22, 1944full name of month
ANVILANVIL
Aug 6, 1944
->DRAGOON
August 15, 1944
full name of month, corrected date as 1st turn in corrected scenario, as this landing really occured
MARKET-GARDENSeptember 17, 1944->September 17, 1944just note, it is OK, 1st turn date of scenario is September 18, unit deployement is after paratroops dropped (correctly one day later)
ARDENNESDec 16, 1944->December 16, 1944full name of month
KHARKOVFebruary 11, 1943->February 21, 1943according as 1st turn of scenario, as German counterattack really occured


Image

Image

Post Reply