Panzer General 1: Omnibus Posting - Questions & Commentary

[Ol' Willy]

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]

PG1-DOS

What is the unit limit in EQP file?

450 (not counting the first "RESERVED" record)

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

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.

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]

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]

# Ol' Willy #,

You asked:

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.

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

[Ol' Willy]

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]

Hallo Ol' Willy and Hexcode

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

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]

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]

I still work on original campaign

And what you do?

[Ol' Willy]

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]

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

[HexCode]

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... To this effect, it would behoove a H2H player to fully understand his human opponent's battlefield capabilities and plan accordingly !

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 !

[PepaDrobny]

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!

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

[HexCode]

My Forum Angle

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 !

WWII Content Choices

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

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.

[Ol' Willy]

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]

PepaDrobny, are you Hartmann.Valka?

Oh, Yeah. Hartmann is my nickname.
Guitly as charged!

There are few people in this world who can hex edit PG.exe

not PG.exe .... panzer.exe exactly

and even less of them who are from Czechia

not even less ... all of them are from Czechia

[Ol' Willy]

Oh, Yeah. Hartmann is my nickname.
Guitly as charged!

Cool!
Gotta say, your mods for PG are great, really classy work.
Cheers!

[PepaDrobny]

Oh, Yeah. Hartmann is my nickname.
Guitly as charged!

Cool!
Gotta say, your mods for PG are great, really classy work.
Cheers!

[HexCode]

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 ?

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]

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

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

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]

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 !

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 !

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.

[HexCode]

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

[PepaDrobny]

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:

Scenario	Wrong text	->	Correct text	explanation
WARSAW	September 10, 1939	->	September 11, 1939	according 1st turn date of scenario
SEALION (40)	missing	->	.	missing dot on end of sentence (all other not missing)
TORCH	Nov 8, 1942	->	November 12, 1942	full name of month, corrected date as 1st turn in corrected scenario, unit deplyement is as this date
ANZIO	Jan 22, 1944	->	January 22, 1944	full name of month
ANVIL	ANVIL 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-GARDEN	September 17, 1944	->	September 17, 1944	just note, it is OK, 1st turn date of scenario is September 18, unit deployement is after paratroops dropped (correctly one day later)
ARDENNES	Dec 16, 1944	->	December 16, 1944	full name of month
KHARKOV	February 11, 1943	->	February 21, 1943	according as 1st turn of scenario, as German counterattack really occured

[JediKnight007]

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?

I just happen to have some of those technical threads from the old forum, in text format, still around. They were very helpful in the development of my mod. Send me a PM if you want them.

[HexCode]

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

I just happen to have some of those technical threads from the old forum, in text format, still around. They were very helpful in the development of my mod. Send me a PM if you want them.

I'm glad to hear that someone found that "stuff" practically useful.

The truth of the matter is this. PG1-DOS "hard" technical information DID appear under a number of topics hosted by a now defunct Web venue. A couple of posters ventured into doing so for awhile amidst a general atmosphere of indifference, even hostility. However, all this is water under the bridge...

[JediKnight007]

For Norway, Fokker D.XXIII should be a Gloster Gladiator (there is an unused icon just for that).

I actually renamed the Norwegian fighter to the Fokker CVD based on this source: http://www.nuav.net/norwair1940.html

Would be interested in using the unique icon for the Gladiator. Is it specificly made for Norway?

For Belgium, no PZL P.24 - not sure what would be a suitable replacement though.

Looking at their used airplanes my first thought is to use that Gloster Gladiator icon for the Belgian airforce. It fits the equipment they used according to this source: https://weaponsandwarfare.com/2019/04/1 ... orce-wwii/

The Gladiator was Norway's most numerous fighter, but they had only about 10 in service. The CV-D was their most numerous plane, around 40 (it's been awhile since I've looked at my notes). But the CV-D was an old light bomber, not a fighter.

Belgium's main fighter was the Fiat CR.42, just like the Italians. Their most numerous plane (around half of their forces) was the Fairey Fox, an obselete light bomber that was forced into a fighter role, with horrible results. In my mod I have it as a fighter/bomber.

Need some help for the renaming of the equipment file. France has the HF II fighter in its unit roster. After doing some research I think it is supposed to be the Hawker Fury Mk II. But that was never used by france So I'm looking for a replacement that matches the unit model.

So far the Loire 45 seems like the only aircraft with a similar look that got used by france during WW2, but not completely convicned it's the right choice. Preferably I would like to have a biplane for that. Any suggestions?

From what I remember France did not use biplanes in combat during WW2, only as trainers and perhaps observation/recon. A suitable replacement would be the Bloch MB-152, which was more common than the H75 or D.520.

Also Soviet self propelled AT /ATY (SU/ISU 122, 152 and such) - these are exactly the same vehicles, where in PG/AG we have a repeat in AT and ATY role.
...

All of these vehicles had secondary roles as assault guns (bunker busting and infantry support), which explains the duplicate units. Actually, the ISU-152 and maybe the SU-152 were designed specifically as assault guns, but they also excelled at ATG duties.

[Radoye]

All of these vehicles had secondary roles as assault guns (bunker busting and infantry support), which explains the duplicate units. Actually, the ISU-152 and maybe the SU-152 were designed specifically as assault guns, but they also excelled at ATG duties.

These were direct fire weapons, so having them in ATY class with R=2 don't make much sense. AT class units would suffice - of course, with suitably high SA values due to their infantry support role...

[JediKnight007]

All of these vehicles had secondary roles as assault guns (bunker busting and infantry support), which explains the duplicate units. Actually, the ISU-152 and maybe the SU-152 were designed specifically as assault guns, but they also excelled at ATG duties.

These were direct fire weapons, so having them in ATY class with R=2 don't make much sense. AT class units would suffice - of course, with suitably high SA values due to their infantry support role...

Actually, now that I consulted my notes, these vehicles had a third, but rarely-used role;. indirect fire. Soviets had no specifically-designed SP arty. Your Waffen-SS mod does have SPATGs with high SA ratings, which I also used in my mod.

German StuG IIIB and StuH 42 were also assault guns, placed in arty role in PG. Not sure if they were actually used in indirect fire, though.

[Radoye]

German StuG IIIB and StuH 42 were also assault guns, placed in arty role in PG. Not sure if they were actually used in indirect fire, though.

Yeah, i moved these too to AT class.

Also all the vehicles armed with sIG33 150mm gun / these too were direct fire support weapons. Having them as ATY with R = 3 is just wrong on so many levels.

[PepaDrobny]

The PG Torch scenario is basically Run for Tunis.

Basically, with the Vichy collapse in North Africa both Allies and Axis ran unopposed to capture as much territory as possible before the other. The remaining Vichy troops didn't offer much resistance to either at first, but later joined the Allies / Free French.

So technically the map should be all French at the start of the scenario with each side capturing cities and turning them to their side. And both sides should indeed be on the offensive - at least at first, until further Axis advance is stopped by overwhelming Allied forces.

Great idea! I have found how to do it in PG1-DOS. Hexes of French cities have to be set as "strategically bombarded" and set to French flag. Axis and Allied cannot see around these cities, but can be occupied (not only by infantry) and change flag. Now tested, working on both key and normal cities.
Yes! These damn German flags on cities in Algeria where German unit never was, got me nervous for 2 decades.
Will do this with my next correction release.

[Radoye]

Great idea!

You're welcome!

[PepaDrobny]

Flags&Arrows animation for Torch (PG1) - "Run for Tunis" needs also some correction.

- missing British flag, althought British units are in scenario
- wrong color of Axis arrow
- added Vichy Frech flag

BTW: There is much more historical bug in this scenario. Italians are totally ignored, missing in this scenario, althought there were deloyed more Italian soldiers than German soldiers.

Original animation:


How it is possible to correct:

[JediKnight007]

I accidently discovered several map bugs while sprucing up Luftwaffe General. In Anzio, you can embark on sea transports from the land-locked cities of Sezze and Frosinone.

[PepaDrobny]

I accidently discovered several map bugs while sprucing up Luftwaffe General. In Anzio, you can embark on sea transports from the land-locked cities of Sezze and Frosinone.

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!

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

I must do some sw utility for systematical search and check all cities in all scenarios for this bug.
I dont know if wino still is making on FPGE, he did a lot of similar search bug procedures for FPGE.

[PepaDrobny]

In Anzio, you can embark on sea transports from the land-locked cities of Sezze and Frosinone.

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!

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

The same case in Balkans scenario.
In-land cities Larissa (48,37) and Levadnia /correctly Livadeia/ (49,41) with possibility to embark units to boat which cannot move then

[JediKnight007]

Budapest scenario has both sides set to offensive. Historically the Soviet plan was to dig in and stall the Germans long enough to mount a counterattack and push them back, which is what actually happened. That's different than having both sides charge in at each other like PG has them doing.

[JediKnight007]

The PG Torch scenario is basically Run for Tunis.

Basically, with the Vichy collapse in North Africa both Allies and Axis ran unopposed to capture as much territory as possible before the other. The remaining Vichy troops didn't offer much resistance to either at first, but later joined the Allies / Free French.

So technically the map should be all French at the start of the scenario with each side capturing cities and turning them to their side. And both sides should indeed be on the offensive - at least at first, until further Axis advance is stopped by overwhelming Allied forces.

Great idea! I have found how to do it in PG1-DOS. Hexes of French cities have to be set as "strategically bombarded" and set to French flag. Axis and Allied cannot see around these cities, but can be occupied (not only by infantry) and change flag. Now tested, working on both key and normal cities.
Yes! These damn German flags on cities in Algeria where German unit never was, got me nervous for 2 decades.
Will do this with my next correction release.

I've done this to Tunisia in my mod. However, should all of the hexes west of the Medjerda River be marked as Free French, or just some of them?

[HexCode]

Hexes of French cities have to be set as "strategically bombarded" and set to French flag. Axis and Allied cannot see around these cities, but can be occupied (not only by infantry) and change flag.

Ok, commencing hex flags can certainly be set inside a scenario's file definition. They don't even have to be explicitly listed within file GAME0??.SCN. However, when it comes to SSI's "flagship" PG1 / AG content, neutralized hexes are encountered only during actual scenario play (by the way, objective hexes cannot be neutralized in-game).

NOW, let's enter "technical secrets" territory, shall we ?

Technically speaking, what sort of data should one alter inside file MAP??.SET to render a hex "behaviorally neutralized" before actual scenario play commences ?

From Father Time's Jurassic Archives...

Relevant excerpt ==>

MAP??.SET -- Section 5 -- Alliance Leaning Parameters

. . .

Ambivalent Hex (02)

a) Attributes NO 1-hex all around spotting properties to it whatsoever.
b) Allows NO level (strategic) bombing of it whatsoever.
c) Confers the usual prestige bonus EITHER to the AXIS OR to the ALLIES depending on whether the FIRST APPROPRIATE GROUND UNIT that enters and occupies it is an AXIS or an ALLIED one (IRRESPECTIVE of whether a possibly ATTENDANT CHANGE in nationality ownership ACTUALLY takes place as well !!!).

It's always possible additional, hitherto undiscovered nuances may be lurking in this rather innovative content design area...

[HexCode]

As a dyed-in-the-wool board rather than video wargamer, I always aim at understanding a play system's details and nuances provided, of course, I deem the wargame capable of effectively supporting my preferred content design and play activities. However, given the PG1 / AG hobby's time-honored orientation, my posts under this topic are essentially... rhetorical in nature ! I harbor absolutely NO illusions...

[HexCode]

My Offbeat Angle

[PG1] A Short Note
viewtopic.php?f=95&t=213&start=50#p15267

Ground Movement Fuel Utilization

When it comes to fuel utilization due to ground movement, PGF does NOT differentiate at all on the basis of ground conditions. However, this topic is most definitely NOT about PGF !

What about PG1-DOS though ? Well, the underlying programming doubles the fuel utilization rate when the ground is FROZEN. Now, what about MUDDY ground conditions ? What's so special about FROZEN ground conditions compared to MUDDY ones ?

[HexCode]

My Offbeat Angle

[PG1] A Short Note
viewtopic.php?f=95&t=213&start=50#p15267

Aircraft Carriers: Some Properties

When it comes to Fighter, Tactical Bomber and Level Bomber Class units situated OVER / ON a friendly Aircraft Carrier Class unit, PGF does NOT differentiate at all with respect to Unit Type Class, Strength Factor (SF) Procurement or Upgrade Feasibility. Specifically:

a) NO Upgrades are allowed whatsoever.

b) There's NOTHING special about SF Procurement.

However, this topic is most definitely NOT about PGF !

What about PG1-DOS though ? Well, the underlying programming:

1) Allows Fighter and Tactical Bomber Class Unit Types to be Upgraded but blocks the Upgrade of Level Bomber Class Unit Types.

2) Allows the SF procurement for Fighter and Tactical Bomber Class Unit Types but blocks it for Level Bomber Class Unit Types.

Why the rather... liberal approach to Fighter and Tactical Bomber Class Unit Type Upgrades ? Also, what's so special about Level Bomber Class Unit Types ?

[HexCode]

My Offbeat Angle

[PG1] A Short Note
viewtopic.php?f=95&t=213&start=50#p15267

Air Units: Spotting Range Reductions

When it comes to effective Spotting Ranges (SpRs) of Air Super-Class units operating under adverse atmospheric conditions (i.e., skies are NOT Clear), PGF:

a) Just HALVES (rounded down) the listed SpR values.

b) In all cases, effective SpRs CAN NEVER be LESS THAN ONE (1).

However, this topic is most definitely NOT about PGF !

What about PG1-DOS though ? Well, the underlying programming:

1) HALVES (rounded down) the listed SpR values when the skies are OVERCAST.

2) All effective SpRs are assigned a value of ONE (1) under PRECIPITATION (i.e., Rain or Snow).

Clearly, PG1-DOS is blessed with a differentiation which makes more sense from the standpoint of reality representation. Sorry PGF; you're too "primitive" here !

[HexCode]

Is the English language localization project still alive ?

[PepaDrobny]

Is the English language localization project still alive ?

Yeah, working on it. Next release of PacPG will be both CZ a EN localization. And maybe more

[Radoye]

Yeah, working on it. Next release of PacPG will be both CZ a EN localization. And maybe more

Cool, looking forward to it!

[PepaDrobny]

LAST 2 IMAGES of PG/AG/PacG are WAITING for PHOTO IDENTIFICATION!

ALL OTHERS can be seen HERE

Any help greatly welcome!

[Radoye]

I can't shake the feeling that i saw the 1st one before... something about it seems to be saying Norway 1940 to me but i can't find any evidence to back that up...

[PepaDrobny]

Most similar I have found.

[PepaDrobny]

New PG1 bug detected

Scenario Sealion 43

There are two Free Poland (FPO) units ATG, wearing wrongly GB flag instead of PL flag.
21st FPO 6 Pdr ATG located in Winchester (24,26)
48th FPO 6 Pdr ATG located in London entrenchment (33,23)

It is unconsistent with other scenarios, where FPO units have PL flags, for example FPO Para in scenario Market-Garden

[Radoye]

Indeed, good catch!

[PepaDrobny]

Metry X-mas to all and happy new year !!!

And small xmas gift - let me inform you about new bug in PG1Dos detected. In El Alamein scenario, if the Allies occupy all the strategic cities on the map, the game will NOT end! In the scenario file, the redundant victory hex must be located on a hex other than a city, airport or port - in which case it is invisible in the game undtakeable. And exactly so that there is - on (30,22) - hex of path. The same behavior and the same bug also noted in Crete, where the victory hex on the hills (19,25) is such a defective.