[DEV] Content Generation - Ideas, Approaches & Discussions

HexCode · Post by **HexCode** » 2022-11-19 08:43, Saturday

INTENT & UTILITY
===================

Not all [DEV] projects lead to generated content. Some of them never come to any tangible fruition. Nevertheless, content development invariably starts with the formulation of ideas and preliminary approaches which, hopefully, trigger "public" discussions.

To date, all [DEV] topics have accommodated content development projects which have, at least, reached "betaware" status. To this effect, "public" discussions therein could be highly focused.

The present [DEV] topic is intended to address... "vaporware". To the extent that a specific piece of "vaporware" achieves "betaware" status, the relevant "public" discussions (if any) will be accommodated via a brand new [DEV] topic strictly dedicated to its further development.

Lettos · Post by **Lettos** » 2023-11-01 06:03, Wednesday

I made changes to the MVT classes table in the EXE file. I couldn't look at the obvious illogic any longer.

Compare default from EXE to my innovations below.

Value "9C FF FF FF" connotes the expenditure of a unit's full Movement Allowance (MA) in support of terrain enterability.
Value "38 FF FF FF" connotes terrain unenterability.

Lettos · Post by **Lettos** » 2023-11-01 06:13, Wednesday

While I was revising the MVT table, I had a question for myself about the MVT Type "9". Currently 4 units out of 4000 in equipment have MVT Type 9. Only 4!!! Check them:
1500 Fukuryu -- Japan "suicide divers" or "kamikaze frogmen"
1543 Su-Ki - - Japan Amphibious Truck
2680 DUKW - - USA six-wheel-drive amphibious
3713 DUKW

MVT Type "9" designed for All-Terrain Amphibious MT (Bridge Eng ONLY!).
Therefore all these above mentioned 3(4) units should have MVT Type "8".
So, MVT TYPE "9" became unused at all. A surprising waste given the narrow set of tools that PGF provides.

Well, I'll be the first to at least try to use the MVT Type "9" for its intended purpose.
In my understanding this type of movement should be at Bridge Engineers unit using vehicles. Of course, it would be more correct to make three types of movement - for Bridge Engineers on wheeled trucks, half-track, fully tracked. But we only have one free "9".
I'll make a movement type for a generalized mechanical vehicle in my version of the EXE. Let it be a conditional half-track.
It can't go into the mountains.
It can drive into forests, swamps and rough.
And it spends not full MVT (9C FF FF FF FF FF) but (02 00 00 00 00) or (03 00 00 00 00) to cross the river.
And, of course, Can Bridge Rivers = 1 (YES)
This creates a Bridge Engineer unit which, with MVT 5-6-7-8, can run up the river and provide a path for other units. This gives us the ability to conduct a high-speed offensive across rivers.

Something like this:

All-Terrain Amphibious MT (Bridge Eng ONLY!)
00080A90 | 01 00 00 00 01 00 00 00 01 00 00 00 | CITY
00080A9C | 01 00 00 00 03 00 00 00 01 00 00 00 | CLEAR
00080AA8 | 02 00 00 00 03 00 00 00 02 00 00 00 | FOREST
00080AB4 | 02 00 00 00 03 00 00 00 02 00 00 00 | BOCAGE (VILLAGE)
00080AC0 | 02 00 00 00 03 00 00 00 02 00 00 00 | ROUGH
00080ACC | 38 FF FF FF 38 FF FF FF 38 FF FF FF | MNT
00080AD8 | 01 00 00 00 02 00 00 00 01 00 00 00 | DES
00080AE4 | 02 00 00 00 04 00 00 00 02 00 00 00 | SWAMP
00080AF0 | 38 FF FF FF 38 FF FF FF 38 FF FF FF | SEA
00080AFC | 02 00 00 00 03 00 00 00 02 00 00 00 | RIVER
00080B08 | 02 00 00 00 03 00 00 00 02 00 00 00 | FORT
00080B14 | 01 00 00 00 01 00 00 00 01 00 00 00 | PORT

Lettos · Post by **Lettos** » 2023-11-03 18:54, Friday

As a follow-up to previous posts about MVT TYPE.

Prerequisity: "UNIT INITIATIVE IN COMBAT", section "Terrain Impact"
viewtopic.php?f=100&t=544#p8988

"If a unit's (possibly already) Modified Listed Initiative Rating is greater than the relevant TIC value, the said unit's initiative rating is now set to equal the relevant TIC value itself."

Terrain Type ------ Initiative Cap Value
City, Mountain ------- 1

That is, if I understand what I read correctly, a 5-stars INF in the city will have initiative = 1, and in the mountains too.
Doesn't this INI CAP surprise you?

1) You shouldn't have told about this INI CAP to the guys in Bastogne in January 1945... Very probably the Gebirgsjäger would have been surprised by the logic of the PG/PGF creators too.
2) The strange logic is understandable, by the way. Since in PG tanks and even heavy guns are allowed to climb mountains like some mountain goats, these tanks should be weakened in the mountains. And the creators of PG reduced in the mountains INI for all units. Simple and primitive...
3) If I change the MVT TYPES so that wheeled, semi-tracked and tracked vehicles can barely get into the mountains, who is left in the mountains? Only units with MVT TYPE = LEG and MNT.
Infantry, light ATY and "towed" ATG. INF and ATY have INI=1 or 2, AT is the bigger one (4-6-10), but nobody seems to be going to raise their INI.
So why not cancel the Terrain INI CAP for them by changing it to "7"?
4) I think it's a good idea to abolish INI CAP in cities too. Yes, this will cause tanks in a city to have a significant advantage over infantry at the start of the campaign. This is a bad thing. But easily remedied by placing garrisons with zero MVT in the city.
And even if the tank has INI=7, it's pretty realistic and shouldn't hurt the game.
- Tanks were used in the defense of cities.
- Player will use LB more actively when attacking cities.

Lettos · Post by **Lettos** » 2023-11-12 15:10, Sunday

I've tried next idea about Air war in seas(oceans).

I've created Torpedo Bomber (Class TacBomber) with SA=0 and HA=0 and high Naval Attack, about "14-16". For my purposes these torpedo bomber(s) as AUX units will be very usable in North Africa scenario. Actually only one AXIS unit till 1942 - SM.79/Torp (carried one torpedo 860kg). Since 01/42 will come another one, Ju 88A-4/Torp (carried two torpedoes 1100 kg each) with Naval Attack about "20"(?).
Ground Defense of such torpedo tactical bombers should be less than for usual TacBombers.

And I've created Light AA(Anti Aircraft) cruiser. Historically same as "Calcutta"(has sunk in 1941) or later Dido-class cruisers. Class - "5", Anti-aircraft. MVT Type = Naval. Fire range = 1. SA=0, HA=0. AA and AD about "8 or 9". Work pretty good in tests!

And simultaneously I want to increase AD for Battleships (only for this class, and not all Battleships! - and not for other capital ships too!) to make them much better defended from usual Tactical Bombers attacks. Deck armor 150mm made Battleships unsinkable if attacked with 500kg bombs. These battleships can be destroyed from air only by torpedoes and not by bombs till 1943.

HexCode · Post by **HexCode** » 2023-11-26 19:07, Sunday

Intended Audience: # Lettos # & # Radoye #

Absolute Prerequisite

[AI] Offensive "Slugfests": Addendum
viewtopic.php?f=95&t=597#p15576

Any Ideas / Suggestions ?

Ok, when it comes to aero-naval matters, PGF's programming is kind of primitive compared to, say, Pacific General's. Nevertheless, creative modders should put whatever features and capabilities available to them to good use.

I'd like to design a pilot aero-naval battle (scenario) practically devoid of land hexes. My design approach will be both ahistorical as well as "for effect". In particular, I'd like the AI to behave meaningfully as an "attacker".

Let me give you an example of what I mean "for effect". Very often, AI-controlled air units run out of fuel and plunge to their doom. Relatedly, they don't "recognize" friendly Aircraft Carrier Class units. To compensate for all that, I'd greatly increase their fuel capacities to ensure such air units keep on flying around for many, many turns without needing to refuel.

There're many design elements requiring careful thought here. After all, this is a pilot project.

Being very realistic, I'd imagine I'm likely to "hear" on this from two posters, tops.

Lettos · Post by **Lettos** » 2023-12-07 14:55, Thursday

Suppose I want to create a scenario in which... some units will be available for purchase for a few turns. Maybe even just one turn.
It could be a scenario where the player has a lot of starting prestige, and there is only one starting unit. The rest must be bought during the scenario. But at the same time "units, or goods" appear in the store very occasionally.

It's very easy to do it. The PGF universe allows "Days per turn" values of 180, 365, 720... I think a value of "365" is sufficient for the stated purpose. All that remains is to adjust the "Month" and "Year" and "Last Year" parameters in the equipment file. Alone scenario will not suffer from the fact that the duration of one turn will be... one year?

But if I want to build such a Scenario into a campaign that historically begins in the 1930s?
It turns out that the PGF universe allows you to start a Scenario in any "minus" year. Even the year -399. But the equipment file does not understand the three-digit "Year" value, although it is completely indifferent to "minus".
Therefore, the modder has a time frame from "minus" 99 to, let's say, 36 (i.e. from 1801 till 1936). Whether this is a lot or a little, at least the space (going back in time) for weird scenarios is 99+36 = 135 years. If there are 25-30 turns (counting 365 days per turn) in the scenarios, you can make at least 4-5 scenarios with very strange appearance of some very specialized units for purchase. Another 40-50 years can be taken from the future, from 1950-1999. Naturally, in case Days per turn is reduced to "180", the timeframe for scenarios is doubled.

Of course, there's the problem that a strange year will appear on the screen in every turn, in 19-NN format. Just who even looks at that date during the game? A description in the briefing that the start of the scenario is on such-and-such date would suffice, and - don't miss the opportunity to buy a Bentley-unit for the price of a Tata during the 19-66 New Year sale

HexCode · Post by **HexCode** » 2023-12-08 05:01, Friday

Lettos,

Utility Scenarios (USs) have been discussed in the past within the context of Custom Campaign design. Such "interim" scenarios may render possible all kinds of special-purpose actions which cannot be technically accomplished during "ordinary" play. Technically speaking, a US need not entail a complicated map or last too long. However, care must be taken to accommodate the "inherited" Campaign Path bifurcations (if any) moving forward upon the US's termination.

Typical Example:

The rather well known Boolean setting regarding Inter-Scenario Core Unit Strength Factor (SF) Replacements may be, well, too... Boolean.

Namely, one either gets practically everything for free or nothing at all. Per contra, a suitably designed US might allow the human player to individually select Core Units for SF replacements. To boot, even Regular SF Replacements might be available as an option. From an interpretation standpoint, such a US will be supporting specific Core Units' "resting & refitting" modes.

HexCode · Post by **HexCode** » 2023-12-10 05:41, Sunday

Lettos,

Lettos wrote: ↑2023-12-07 14:55, ThursdaySuppose I want to create a scenario in which... some units will be available for purchase for a few turns. Maybe even just one turn. It could be a scenario where the player has a lot of starting prestige, and there is only one starting unit. The rest must be bought during the scenario. But at the same time "units, or goods" appear in the store very occasionally. It's very easy to do it.

I 'd go the Utility Scenario route here. The design is bound to be more robust.

Lettos wrote: ↑2023-12-07 14:55, Thursday... there's the problem that a strange year will appear on the screen in every turn, in 19-NN format.

One can limit the aesthetic... monstrosity to just one date which never changes during multi-turn scenario play. Just assign some negative value to the variable "Days per Turn".

HexCode · Post by **HexCode** » 2023-12-14 00:31, Thursday

Intended Audience: # Lettos # & # Radoye #

1) The Battle will pit Great Blue's (GB's) aero-naval forces against Big Red's (BR's).

2) The Battle will be a scenario the duration of which could be longish.

3) The Battle will be ahistorical. GB and BR unit specifications will be identical.

4) PGF's AI Module will be set to "attack".

5) PGF's AI Module will be granted units which can be reasonably effective in the expected absence of sophisticated playing capabilities on the part of the Module.

6) Human players will be granted units which can readily accommodate the expected, superior playing capabilities befitting such players.

Lettos · Post by **Lettos** » 2023-12-15 10:37, Friday

HexCode wrote: ↑2023-12-14 00:31, Thursday 3) <...> GB and BR unit specifications will be identical.
<...>
5) PGF's AI Module will be granted units which can be reasonably effective in the expected absence of sophisticated playing capabilities on the part of the Module.

There is some contradiction between 3) and 5). I think we are talking only about EXP and STR here?

But as part of the Human vs AI game concept, I now want to talk about one... freak hiding in the corner of the PGF marine universe. It's an AI aircraft carrier.
It's the only unit that AI can't use at all. But there should be no useless units in the game.
The only thing I see ready to be fixed in this situation is Spotting an aircraft carrier. It's realistic and historical. Even if a few planes from the air group remain on the aircraft carrier, they can take off on reconnaissance flights.
During the game a ship of this PGF class is sometimes even too lazy to sink... unless it's usable for PP gaining.

What happens if we give it Spotting = 8-10?

That's when this useless junk will go from being a freak to a prime target!

Even moving it in a straight line to the nearest AI Victory Hex will cause the player some problems.
And maybe AI will finally be able to use aviation over the ocean. At least in flights from one "hidden underwater" airfield to another?

The topic of reconnaissance aircraft comes up in passing. The player doesn't need them right now. In fact, even if a combat bomber of the same model was used as a reconnaissance aircraft, it loaded the maximum amount of fuel and minimum bomb load when reconnaissance. It should be different in the equipment file. And this spotting at sea by 2-3 hexes is an immutable axiom since Panzer General?

In short, I'm sticking with the concept of highly specialized units. The player's task is to assemble a full-fledged complex out of them. AI can't do that, so it should be given an advantage in parameters in the same units.

HexCode · Post by **HexCode** » 2023-12-18 00:26, Monday

Lettos,

Lettos wrote: ↑2023-12-15 10:37, FridayHexCode wrote: ↑2023-12-14 02:31, Thursday
3) <...> GB and BR unit specifications will be identical. <...>
5) PGF's AI Module will be granted units which can be reasonably effective in the expected absence of sophisticated playing capabilities on the part of the Module.

There is some contradiction between 3) and 5). I think we are talking only about EXP and STR here?

Lettos wrote: ↑2023-12-15 10:37, FridayIn short, I'm sticking with the concept of highly specialized units. The player's task is to assemble a full-fledged complex out of them. AI can't do that, so it should be given an advantage in parameters in the same units.

The above commentary anticipates the actual experimentation results. Chances are some unit stats differentiation might prove to be unavoidable after all. However, in my case, I'll start off with "pure" symmetry. If it turns out that unit stats differentiation is inescapable, well, I'll adopt the minimum such differentiation necessary to achieve desirable, practical behaviors on the part of PGF's AI Module.

By the way, I'm leaning towards assigning Spotting value ZERO (0) to all units. I'm curious to see what happens when vast watery expanses become... threatening just by being quite dark and unexplored...

In any case, "my" AI Module will be set to "attack"; even blindly.

Lettos · Post by **Lettos** » 2023-12-18 05:46, Monday

HexCode wrote: ↑2023-12-18 00:26, Monday The above commentary anticipates the actual experimentation results. Chances are some unit stats differentiation might prove to be unavoidable after all. However, in my case, I'll start off with "pure" symmetry. If it turns out that unit stats differentiation is inescapable, well, I'll adopt the minimum such differentiation necessary to achieve desirable, practical behaviors on the part of PGF's AI Module.

By the way, I'm leaning towards assigning Spotting value ZERO (0) to all units. I'm curious to see what happens when vast watery expanses become... threatening just by being quite dark and unexplored... In any case, "my" AI Module will be set to "attack"; even blindly.

This will be the Clash of the Dreadnoughts of World War I.... would you consider giving one side (AI) a radar that has already been actually used? Or give not all, but at least some of the larger Capital ships?

Lettos · Post by **Lettos** » 2023-12-22 12:00, Friday

1) Yes, negative unit price is possible and does not cause bugs in the engine.
By making an upgrade, you add PP to yourself equal to 5/6*100%=83.33% of the cost of the new unit.
This is... it's not just hacking or stupidity.

Where can this trick be used?

For example, Rommel's army has captured El Alamein and is preparing to "jump to Cairo". If anyone has seen a 1941 map of Cairo, Alexandria and the Nile Delta, they will be surprised at the number of different canals and small rivers. This is not at all suitable terrain for armored infantry and tanks. It's almost like Venice, only in total mud and Bocage. To move around it requires regular infantry with expensive very specialized transport called "rubber boat and pontoon kit", with bridging option to cross rivers seamlessly.
But... in the player's INF are already motorized and waiting for bridge engineers. Which are simply not and will not be available in such quantity.
It is possible to upgrade (in fact it is downgrade) armored inf unit to a regular one. But who will compensate the costs? Besides, it is clear that during the upgrade the unit did not scrap all its armored inf vehicles, but only left them in El Alamein or Tobruk for a while.

Solution: an interim scenario is made for attacking Cairo and Alexandria.
Trick requires Time and Date adjustments for scenario and dates for similar units as explained in [DEV] PGF timeframe viewtopic.php?f=95&t=956#p17679
The player upgrades INF units at minimum price, and buys them "boat+pontoon" transport without cost. After the victory in Cairo-Alexandria, the player has to return the funds. But if given just the PP amount, the player can buy airplanes and tanks instead of INF. But this loan was targeted, only for infantry! So in the after-Cairo interim scenario the player is given the opportunity to buy his armored infantry at a negative price, i.e. return the value of his army to the account status that was before Cairo + gained PP for victory and during scenario.

=====

2) Sorry to be creative, but after experimenting with negative unit price another paradoxical idea came up - what happens if an AI unit in the scenario file is assigned a negative Fuel value?

Seems that Air units did not understand this trick.
But Land units reacted in the following way: in one turn the unit is resupplied with a value of half the unit's FUEL +1.

That is, if a unit has FUEL=60, it will receive resupply 30+1=31 Fuel each turn.
For example, if a unit has FUEL=60 in equipment and the fuel parameter at the beginning of the scenario is -140, the unit will receive fuel resupply =30+1 every turn, and will move on the 6th turn having fuel = +15.
A Christmas gift from Rudankort, I guess

You don't need to make any already discussed two years ago "corridors" on the map. It's much simpler than that, as it turns out.

I also need to do similar experiment with naval units.

It seems to me that finally the problem of delayed start is solved.

HexCode · Post by **HexCode** » 2023-12-24 04:08, Sunday

Intended Audience: # Lettos # & # Radoye #

This issue has been bedeviling... generations of PG1 "universe" modders aiming at modifying AI Module battle behavior. Remarkably, it can apply to human players as well.

Lettos wrote: ↑2023-12-22 12:00, Friday... what happens if an AI unit in the scenario file is assigned a negative Fuel value?

Land Units

Lettos wrote: ↑2023-12-22 12:00, FridayLand units reacted in the following way: in one turn the unit is resupplied with a value of...

Such units remain immobilized until their Fuel Point (FP) status turns positive. All resupply rules regarding enemy unit lateral / vertical adjacency (if any) are fully applicable.

Auto-Upgrade immediately restores a unit's FP status to its full, Listed Capacity (LC).

Naval Units

Lettos wrote: ↑2023-12-22 12:00, FridayI also need to do similar experiment with naval units.

Such units remain immobilized until their Fuel Point (FP) status turns positive. All resupply rules regarding enemy unit lateral / vertical adjacency (if any) are fully applicable.

Per turn, units on friendly Port / Port Facility hexes receive new FPs up to a maximum of their LCs.

Air Units

Lettos wrote: ↑2023-12-22 12:00, FridaySeems that Air units did not understand this trick.

Actually, air units behave as expected...

Any air unit running out of fuel plummets to its doom

UNLESS

it's laterally / vertically adjacent to a friendly airfield hex or "over" a friendly Aircraft Carrier Class unit.

Absent any laterally / vertically adjacent enemy units, the air unit gets immediately resupplied with whatever FPs are needed to render it fully supplied to its LC.

CONCLUSION

This is a very promising area to do further research. Remember: the usually resides in the details (and offbeat situations).

P.S. Realistically speaking, three research "caballeros" max...

Post by **Radoye** » 2023-12-24 17:49, Sunday

HexCode wrote: ↑2023-12-24 04:08, Sunday CONCLUSION

This is a very promising area to do further research. Remember: the usually resides in the details (and offbeat situations).

Indeed it is. It might finally be possible to precisely time reinforcements arrival in scenarios!

HexCode · Post by **HexCode** » 2023-12-26 00:22, Tuesday

Intended Audience: # Lettos # & # Radoye #

Seasoned PGF players are reasonably acquainted with unit resupply restrictions due to enemy unit adjacency. Clearly, such phenomena are manifestly situational.

The odd content designer might wish to introduce effective Resupply Restrictors (RRs) on a semi-permanent basis. The usual aim here is to block an enemy (static) unit from replenishing its Ammo Points (APs).

1) The RRs themselves should not be able to attack the enemy (static) unit in any meaningful way. The design aim here is very narrowly focused...

2) The vulnerability of RRs to enemy attacks should be carefully designed to address the scenario's particularities.

3) Human player attacks (if any) upon the enemy (static) unit should be carefully considered. Remember: a unit receiving replacements automatically receives some supplies as well.

Lettos · Post by **Lettos** » 2023-12-26 18:07, Tuesday

HexCode wrote: ↑2023-12-26 00:22, Tuesday 1) The RRs themselves should not be able to attack the enemy (static) unit in any meaningful way. The design aim here is very narrowly focused...

2) The vulnerability of RRs to enemy attacks should be carefully designed to address the scenario's particularities.

3) Human player attacks (if any) upon the enemy (static) unit should be carefully considered. Remember: a unit receiving replacements automatically receives some supplies as well.

The solution has already been found. Look at the clouds near the forts.
https://www.mediafire.com/file/kxedv7n5 ... 7.zip/file

Lettos · Post by **Lettos** » 2023-12-26 18:50, Tuesday

Yes, MVT TYPE can have a negative value. Many experiments have been conducted.

MVT TYPE = "-4", "-5", "-6", "-16", "-17" proved to be most useful
In PGF UI they are called: Soft, Sea Transport, Air Transport, AD, AA. Strange names for MVT TYPE!
This does not change their essence, as all five values lead to the same result. A unit with MVT TYPE -4, -5, -6, -16, -17 can only move on the following Terrain types: road, city, port (8 and 37), airfield and fortification.
I researched "-4" and unit Target type 0 or 1, Soft or Hard.
Unit spends 1 unit of Fuel per hex to move when the surface condition are Dry, Frozen or Muddy.

It's a train!

If it couldn't drive into terrain fortification yet, it would be absolutely perfect. But as it is, it's better to have a train like this than no train at all.

Experimental results showed that a unit with a normal MVT TYPE can get an upgrade in the form of Organic transport with a strange negative value. After the upgrade, a normal unit starts moving according to the MVT TYPE of the acquired transport. But alas, the transport switch does not work.
If you upgrade a normal unit with a negative MVT TYPE and buy a normal Organic transport, the transport switch works.

During the experiments I've found MVT TYPES looks as cheating: -2, -19, -20, -22, -23. They tend to make some type of terrain non-enterable, and some (the ocean) becomes a boundless field.

There are MVT TYPES that might be more useful someday, like -1, -3, -18. But I don't see any use for them yet. I don't think it is necessary to describe these types in detail now.

Types -8, -9, -10, -11, -12, -13, -14, -15 in my experiments led to program crash.

HexCode · Post by **HexCode** » 2023-12-26 22:44, Tuesday

Lettos,

Lettos wrote: ↑2023-12-26 18:50, TuesdayYes, MVT TYPE can have a negative value. Many experiments have been conducted. MVT TYPE = "-4", "-5", "-6", "-16", "-17" proved to be most useful. In PGF UI they are called: Soft, Sea Transport, Air Transport, AD, AA. Strange names for MVT TYPE!

Excellent CDP research intro !

Don't worry about what PGF's UI "says". It's total garbage ! It's due to the highly unfortunate, "seat-of-the-pants" programming ways employed by PGF's Developer / Programmer to embed alphanumeric content into PGF executable's code...

HexCode · Post by **HexCode** » 2023-12-27 00:21, Wednesday

Lettos,

Lettos wrote: ↑2023-12-26 18:07, TuesdayThe solution has already been found. Look at the clouds near the forts.
https://www.mediafire.com/file/kxedv7n5 ... 7.zip/file

Yes ! Very good !

It's quite generalizable...

Let's consider the three "tests":

HexCode wrote: ↑2023-12-26 00:22, Tuesday1) The RRs themselves should not be able to attack the enemy (static) unit in any meaningful way. The design aim here is very narrowly focused...

Check ! Absolutely !

HexCode wrote: ↑2023-12-26 00:22, Tuesday2) The vulnerability of RRs to enemy attacks should be carefully designed to address the scenario's particularities.

In this case, enemy air unit attacks are bound to prove very costly to them, if not outright suicidal... On the other hand, they could be quite vulnerable to enemy AD or AA unit attacks provided the scenario does allow for such potential threats...

HexCode wrote: ↑2023-12-26 00:22, Tuesday3) Human player attacks (if any) upon the enemy (static) unit should be carefully considered. Remember: a unit receiving replacements automatically receives some supplies as well.

Well, it's up to human players to weigh the situational pros and cons.

HexCode · Post by **HexCode** » 2023-12-27 00:41, Wednesday

Intended Audience: # Lettos # & # Radoye #

HexCode wrote: ↑2023-12-24 04:08, SundayAny air unit running out of Fuel Points plummets to its doom UNLESS it's laterally / vertically adjacent to a friendly airfield hex or "over" a friendly Aircraft Carrier Class unit.

The above "rule" entails an additional caveat: air units use a minimum of HALF their Movement Allowance (MA) in Fuel Points, per turn.

Now, what happens if one (e.g., Lettos

) constructs a static air unit restricted to keeping on hovering "over" some specific hex ? Well, assigning to it an MA of ZERO (0) amounts to a very elegant technical solution. Namely, the per turn fuel utilization is ZERO (0) divided by TWO (2); hence, ZERO (0). Consequently, the unit can never experience actual fuel drain.

Lettos · Post by **Lettos** » 2023-12-27 15:33, Wednesday

HexCode wrote: ↑2023-12-26 00:22, Tuesday2) The vulnerability of RRs to enemy attacks should be carefully designed to address the scenario's particularities.
...
In this case, enemy air unit attacks are bound to prove very costly to them, if not outright suicidal... On the other hand, they could be quite vulnerable to enemy AD or AA unit attacks provided the scenario does allow for such potential threats...

I was unable to "kill" the test unit with anything other than the Supply unit assigned to destroy it. Too much difference in AA, INI, AD prevents other units from not only "killing" it, but even damaging it.

Lettos · Post by **Lettos** » 2024-01-10 07:52, Wednesday

I thought it was wrong to be able to land my transport planes on an empty AI airfield.
The airfield service, even if they have no weapons at all, should know that the runway is easily blocked by a few trucks, or barrels with gasoline, placed on trolleys. And if a message from friendly Air forces is received that their are coming, the trucks&barrels can be removed before landing. That's reality.

How do I map this in PGF and force the player to use paratroopers rather than regular infantry to capture the empty AI airfield? Very simple. Place some specialized Class FORT unit on the empty airfields, which in the scenario will capture from the sky. The icon is some trucks and barrels imitating the technical service of the airfield. AI will not be able to send replacements to this unit. Paratroopers will land nearby, destroy the AI unit and take over the airfield.

And you need to make it so that the player can't destroy this unit from the air. Bombing an airfield before sending transport planes there is not a good idea, is it?

I've been experimenting with the parameters. You have to take all factors into account.

I created an Allied unit "Trucks & Barrels" (TrB) SA=0, HA=0, GD=0, AD=99, INI=0, and, very importantly, gave it an EXP value of minus 500. Yes, exactly - minus! I assigned the TrB STR=10.

Note: When EXP is negative, a square with triangular black and white stripes appears next to the unit's stars. It is visually ugly, but it does not interfere with the game at all.

I placed 10 of these TrBs on the map on the airfield hex.
(EXP= -500 is to make the GD parameter as weak as possible. This weakens the AD parameter from 99 to 94, which makes no difference in this case. And that EXP trick works!)

They are attacked by standard paratroopers STR=10 SA=7 EXP=100.
Repeated experiments have shown that on average 9 out of 10 TrBs are destroyed on the first turn. (Sometimes all 10, sometimes only 8).
On the second turn there is 100% destruction of TrBs.
That is, the paratroopers land in an empty city next to the airfield on the first turn of the attack, and on the next turn occupy the airfield with a 90% probability.

The player now attacks TrB with ten tactical bombers. Ju 87D, SA=11, EXP=400, STR=14. Each bomber attacks only one assigned TrB.
The first Trb is not destroyed until turn 9.
The second is destroyed on turn 11.
The third is destroyed on turn 13.
The next two Trb's are destroyed on turn 14.
After 14 turns there are 5 Trb still alive.

In pre-1943 scenarios, the Player(AXIS) will not have so powerful Tac Bomber such as Ju 87D, EXP=400 or STR=14. Allied haven't Marauder till end of 1941.
Therefore, a bomb strike of weaker Tac Bombers on TrB will be completely pointless. Even in Sealion 43 waiting for at least 9 turns, with no guarantee, to land a usual INF unit on an AI airfield is also illogical.

I don't think we need to worry about the Trucks&Barrels unit telling the player which airfield to capture with paratroopers.
And this unit shouldn't be a problem for AI in defense actions.

Firstly, the player himself will realize that something is going wrong if he does not capture the airfield(s) when he loses or fails to MAJ victory once again in this scenario.
Secondly, you could create other airfields in the rear of the AI with the same TrBs to make the player think - which airfield he should capture. And all of these airfields do not have to be on hexes adjacent to the VH.
Third, the same TrB units can be placed on some airfields that the player will capture shortly after the scenario begins.

At least if the TrB unit tool exists, then maybe the scenario designer will apply it someday.

Post by **Radoye** » 2024-01-11 15:11, Thursday

I have been thinking about "obstacle" units similar in concept to this for a while now, roadblocks placed along strategic pathways, or in some cities / airfields, since even in otherwise undefended cities it would likely be impossible for the advancing side to just simply drive through unhindered. Some level of resistance / sabotage attempts are to be expected from the civilian populace and/or Police etc even if no military units are present. Traffic signs will be taken down or misplaced, roads dug up or barricaded off, railway switches damaged...

Lettos · Post by **Lettos** » 2024-01-11 17:28, Thursday

Radoye wrote: ↑2024-01-11 15:11, Thursday I have been thinking about "obstacle" units similar in concept to this for a while now, roadblocks placed along strategic pathways, or in some cities / airfields, since even in otherwise undefended cities it would likely be impossible for the advancing side to just simply drive through unhindered. Some level of resistance / sabotage attempts are to be expected from the civilian populace and/or Police etc even if no military units are present. Traffic signs will be taken down or misplaced, roads dug up or barricaded off, railway switches damaged...

There are two options here on how these road signs and other obstacles can be removed.
- the first option is that any ground units can remove them. In this case, an obstacle on the road is hardly an obstacle.
- second option - only the player's special ground units can remove the signs/obstacles.

Once upon a time, a long time ago, I wrote a post:
"Naval attack and ... minefields in PGF" viewtopic.php?f=95&t=174&start=50#p8742

And now after almost 3 years the topic is back.

Yes, this obstacle should be a Naval target. And the specialized ground unit must have a very high Naval attack parameter. Only this unit can remove the obstacle in one turn. Neither Tiger nor Marauder 5-stars STR=15, should remove this obstacle unit.
Only specialized engineers should do it.

How do I prevent specialized ground units from attacking ships? I had this thought recently - why are ships allowed to approach the shore? There are shoals, reefs. Why not create a strip of "Ocean" terrain type Escarpment tiles along the shore? Create such hexes everywhere but the harbour? How likely would it be for Engineers to wait for an enemy battleship in friendly port and attack ships? By the way, do you often use a port as a port to re-suplly AMMO your fleet? I used it once - just out of interest, to see the AMMO and FUEL increased. That is, in some scenarios where fleets are used, it is also possible to separate the port from the ocean. The scenario (North Africa, Middle East) will not lose anything.
But! Destroying or damaging Allied ships from shore is possible in scenarios: D-Day, Anvil, Crete, Norway, Sealion. Yes, this is a problem. At the moment there is no universal solution on how to incorporate such a specialized unit seamlessly into CORE.

The best solution I see is that the specialized unit needed is given as an AUX in the scenarios provided by the designer and is not available for purchase/upgrade.

Then, for example, the AI unit "damaged bridge" can also be used as an obstacle. Place it, for example, on a road across a river. Let this unit mean that the allies(AI) blew up the bridge while retreating. Or a "rockfall" on a mountain road. Or, as scary as it is to say, a blown up city. Or a damaged airfield.
With explosives, there are many ways to hurt the advancing side while retreating.

In short, there are variations on the theme here!

Lettos · Post by **Lettos** » 2024-01-15 06:38, Monday

Lettos wrote: ↑2023-12-22 12:00, Friday 1) Yes, negative unit price is possible and does not cause bugs in the engine.
By making an upgrade, you add PP to yourself equal to 5/6*100%=83.33% of the cost of the new unit.
This is... it's not just hacking or stupidity.

Where can this trick be used?

It's not all that simple with tricks! The devil is in the details!

Negative cost of a unit (or its transport) has undesirable consequences:

- AI receives a reduction in prestige from attacks and destruction of such a unit
- When sending Replacements to a unit with a negative transport cost, the transport cost is not taken into account (apparently, the PGF engine takes it as 0).

As much as I'd like to, I can't manage to leave my Land transports in a supermarket car park in Tobruk...

HexCode · Post by **HexCode** » 2024-02-07 17:43, Wednesday

Intended Audience: # Lettos # & # Radoye #

Elsewhere in THIS Forum, I wrote:

In a nutshell, the unit keeps on shooting without being afraid of running out of ammo. It can still Resupply with or without Replacements Procurement without losing the benefit of negative {Ammo Point } (AP) values. Moreover, it doesn't have to worry about any adverse effects on its APs due to Carpet Bombing. Sounds like a dream weapon to me...

Well, "design-for-effect" need not bow to SSI play system's "intended" behaviors. For sure, AP Resupply is subject to rather well known, time-honored rules / constraints. However, situations might arise calling for "exceptional" approaches.

For instance, visualize a heavily entrenched, static unit destined to fight to the death. Carpet bombing cannot deplete its deeply stored, plentiful APs. To boot, the unit will be shooting at the enemy down to its very last remaining Strength Factor (SF). Ergo...

Lettos · Post by **Lettos** » 2024-02-07 18:30, Wednesday

HexCode wrote: ↑2024-02-07 17:43, Wednesday Elsewhere in THIS Forum, I wrote:

In a nutshell, the unit keeps on shooting without being afraid of running out of ammo. It can still Resupply with or without Replacements Procurement without losing the benefit of negative {Ammo Point } (AP) values. Moreover, it doesn't have to worry about any adverse effects on its APs due to Carpet Bombing. Sounds like a dream weapon to me...
Well, "design-for-effect" need not bow to the play system's "intended" behaviors. For sure, AP Resupply is subject to rather well known, time-honored rules / constraints. However, situations might arise calling for "exceptional" approaches.

For instance, visualize a heavily entrenched, static unit destined to fight to the death. Carpet bombing cannot deplete its deeply stored, plentiful APs. To boot, the unit will be shooting at the enemy down to its very last remaining Strength Factor (SF). Ergo...

I imagined it... There's some truth to it.
Shevardino redoubt on Borodino, Hougoumont on Vaterloo, Brest Fortress, Metaxas Line, an island in the Pacific in 1943-45. PGF Thermopylae. 300 Terminators entrenched.
Usually the attackers just bypassed them after the first blows to the face (unless they were complete idiots in some cases).
If we gave Terminators the opportunity to entrench and stand to the death, it is necessary to provide for the possibility of bypassing them. Issue the army saws to make a road in the woods or a path in the swamp, or possibility to dig up a mountain.
But there is no such possibility. You can't cram an entire army into one closed passageway like Thermopylae. There's a way around it.
I think in the scenario terminators can be present only for several moves.
The old philosophical rule is, "If you create a new poison, come up with an antidote for it."

Lettos · Post by **Lettos** » 2024-02-08 20:44, Thursday

HexCode wrote: viewtopic.php?f=100&t=543#p8978

In my opinion, this has always been... semantically unfortunate territory. Ok, when it comes to "pure" play, one may wish to "cheat"; big deal ! It is only a game...

As far as I am concerned, the so called "Cheat" Codes (CCs) can be very useful tools in the hands of custom content modders wishing to conveniently and effectively test out many, many "things". Moreover, specific CCs may need to be invoked during play in support of prescribed "house rule" implementations (if any).

I agree with what has been said!

Announcing a new scenario (soon to be released) example:

Ahistorical honesty and honest immorality

Lettos · Post by **Lettos** » 2024-02-10 11:05, Saturday

HexCode wrote: ↑2024-02-09 15:24, Friday Even my contemplated aero-naval scenario is sort of very iffy "vaporware" at present.

Radoye wrote: ↑2022-08-14 21:21, Sunday
HexCode wrote: ↑2022-08-14 19:06, Sunday In any case, I doubt it very much whether some definitive, "universally accepted", "cleaned up" SSI PG1 / AG content version will ever emerge...
Yes, i agree there likely never will be "the one" - universally accepted flavor of PGF. But i think it's a good thing, as long as people tinker with it the game is alive. Once people stop modding, you can replay the same content only so many times before it becomes boring (i'm talking about one human player vs AI play, not human vs human - but even H2H has it's limits and can become repetitive if played against the same one opponent).

Now let's try to combine the aero-naval scenario with the lack of boredom of repeated replaying.
I haven't seen any scenarios where the ocean (sea) has been used in even the slightest scale and most importantly, consciously.
Husky and Norway uses ships as coastal artillery pieces from the beginning of the scenario. Some fragment of what I want to talk about is still created in Norway on the first turn, but that's what the whole intrigue is limited to.

I want to share my observations and experience from working on a scenario on a large map (44 x 126 hexes).
Dry land takes up about a third of the entire map. North Africa'41.
Placing ships at a great distance from the land (about 20 hexes or more), when fine-tuning the scenario, I noticed that sometimes it is enough to move the starting position of the ship 1-2-3 hexes, and .... it suddenly sails in a different direction, to a different point of land.
The logic of moving in a straight line is preserved, but the straight line changes its vector.
These observations suggest that there is some AI mechanism in the PGF to estimate land by looking at it from the ocean. On the principle that it is more "profitable" to sail there and not there.
In a customized scenario pursuing certain goals in the Campaign, the necessary movement vectors of AI ships can be achieved. And then don't change anything, because the Campaign is a delicate creature.

But the thought comes to mind that if you consciously make a scenario on a large map (in shape close to a square), which will be about 1/3 of the land and 2/3 of the ocean, then changing then the starting position of naval units can achieve significant changes in the course of events in the scenario. That is, when creating a scenario, one should immediately assume that this scenario should not be static once and for all, but changeable.
A large map is 100x100 hexes, for example. The point of the size is to make the Unit MVT comparable to the distance it has to travel to coastal line. It can now be seen that the distance should be at least 4-5 MVT, i.e. 20-30 hexes.
Events on the way to land sometimes cause a unit to deviate slightly or even significantly from its chosen initial vector (observed in one scenario).

This should work if it's already working in the one created scenario.
A way to combat boredom?

I guess so.

HexCode · Post by **HexCode** » 2024-02-11 06:17, Sunday

Lettos,

Lettos wrote: ↑2024-02-10 11:05, SaturdayBut the thought comes to mind that if you consciously make a scenario on a large map (in shape close to a square), which will be about 1/3 of the land and 2/3 of the ocean, then changing then the starting position of naval units can achieve significant changes in the course of events in the scenario. That is, when creating a scenario, one should immediately assume that this scenario should not be static once and for all, but changeable.

The idea to render unit initial deployments somewhat probabilistic comes up from time to time. Actually, it can be done without resorting to "deep" programming. Nevertheless, it requires "power user" computer knowledge as per the 1990s computer user culture.

Not that many hobbyists in SSI's "world" have bothered to acquire the requisite technical knowledge or had the patience to go down that road...

Lettos · Post by **Lettos** » 2024-02-11 08:44, Sunday

HexCode wrote: ↑2024-02-11 06:17, Sunday The idea to render unit initial deployments somewhat probabilistic comes up from time to time. Actually, it can be done without resorting to "deep" programming. Nevertheless, it requires "power user" computer knowledge as per the 1990s computer user culture. Not that many hobbyists in SSI's "world" have bothered to acquire the requisite technical knowledge or had the patience to go down that road...

Can you share an idea?

I understand that I need to shuffle the hexes (XX:YY) in the scenario file. Do it randomly. And shuffle within a given range of ocean territory.
Take the value of (XX:YY) from the given boundaries. Change it to a different value. Write it to the scenario file. Take the next value. Change to another, excluding the new values already created.
All this should be done by some program. Command line level interface to set the four corner hexes of the shuffled area.

HexCode · Post by **HexCode** » 2024-02-11 17:18, Sunday

Lettos,

Lettos wrote: ↑2024-02-11 08:44, SundayCan you share an idea?
I understand that I need to shuffle the hexes (XX:YY) in the scenario file. Do it randomly. And shuffle within a given range of ocean territory. Take the value of (XX:YY) from the given boundaries. Change it to a different value. Write it to the scenario file. Take the next value. Change to another, excluding the new values already created. All this should be done by some program. Command line level interface to set the four corner hexes of the shuffled area.

No, nothing of the sort. One simply designs a number of *.PGSCN files, each representing a specific unit initial deployment. At scenario start, one of those *.PGSCN files is selected at random. Technically, the scheme can be implemented via "batch" files (DOS territory).

Lettos · Post by **Lettos** » 2024-02-11 17:32, Sunday

HexCode wrote: ↑2024-02-11 17:18, Sunday
Lettos wrote: ↑2024-02-11 08:44, SundayCan you share an idea?
I understand that I need to shuffle the hexes (XX:YY) in the scenario file. Do it randomly. And shuffle within a given range of ocean territory. Take the value of (XX:YY) from the given boundaries. Change it to a different value. Write it to the scenario file. Take the next value. Change to another, excluding the new values already created. All this should be done by some program. Command line level interface to set the four corner hexes of the shuffled area.
No, nothing of the sort. One simply designs a number of *.PGSCN files, each representing a specific unit initial deployment. At scenario start, one of those *.PGSCN files is selected at random. Technically, the scheme can be implemented via "batch" files (DOS territory).

Back in the 90s, system administrators used to call me an "advanced user". I once wrote programs on a device that few people haven't any idea about nowadays. I understand what a program algorithm is. I used to read Wirth's books. But, uh, I'm completely uncultured when it comes to coding, even at the DOS file level. This batch doesn't look complex in terms of algorithms. It will remain a dream for me unless someone more cultured than me takes up coding.

HexCode · Post by **HexCode** » 2024-02-19 18:28, Monday

Intended Audience: # Lettos # & # Radoye #

Designing Unit Types which aren't "meant" to move isn't a new subject around here. Historically, the focus has been on AI Module behaviors. To this effect, the practice of "anchoring" units has been resorted to on a number of content design occasions.

Recent "practical discoveries" revolving around NEGATIVE Fuel Points (FPs) have provided content designers with new, flexible and quite effective options. These new options are essentially player-agnostic. In other words, a designer may meaningfully render some of a human player's units immobile for awhile or throughout the scenario's entire duration; ditto for the AI Module's units, of course.

Note: It so happens that PGF-CDP often shines in suggesting practical solutions implementable via "design-for-effect". It's unavoidable, then, that "design-for-representation" will somewhat... suffer.

Lettos · Post by **Lettos** » 2024-02-19 19:21, Monday

HexCode wrote: ↑2024-02-19 18:28, Monday Designing Unit Types which aren't "meant" to move isn't a new subject around here. Historically, the focus has been on AI Module behaviors. To this effect, the practice of "anchoring" units has been resorted to on a number of content design occasions.

Recent "practical discoveries" revolving around NEGATIVE Fuel Points (FPs) have provided content designers with new, flexible and quite effective options. These new options are essentially player-agnostic. In other words, a designer may meaningfully render some of a human player's units immobile for awhile or throughout the scenario's entire duration; ditto for the AI Module's units, of course.

Note: It so happens that PGF-CDP often shines in suggesting practical solutions implementable via "design-for-effect". It's unavoidable, then, that "design-for-representation" will somewhat... suffer.

If we assume that CDP is an invariant platform, a powerful theoretical basis for turn-based 5-stars games, then open tricks allow to create more interesting content even in primitive PGF. Design for the sake of true game effect is invariant!

HexCode · Post by **HexCode** » 2024-02-22 03:22, Thursday

Intended Audience: # Lettos # & # Radoye #

Don't Move for Awhile

Historically, content designers had to rely on House Rules... Recently, NEGATIVE Starting Fuel Point (SFP) specifications in Scenario Definition File *.PGSCN proved their worth and, then, some. Mind you, in order to take advantage of this newly discovered feature (bravo Lettos), a content designer might have to render some "fuel-less" PGF-SSI Unit Types subject to faux fuel utilization.

Don't Move Voluntarily, Ever

The obvious solution to set a unit's Movement Allowance (MA) value to ZERO (0) was tried first.

Custom Unit Sporting Movement Allowance Zero Oddities
viewtopic.php?f=100&t=555#p9109

details the experienced drawbacks.

Once again, NEGATIVE SFPs twinned with NEGATIVE Listed Fuel Capacity (LFC) values certainly do the trick.

Don't Move Voluntarily or Even Involuntarily Retreat, Ever

"Anchored" Garrison Units
viewtopic.php?f=100&t=540#p8971

features detailed analysis and description of options. Key here is a property attaching to the Structure Class which prohibits units of that class to ever involuntarily retreat as a result of combat.

HexCode · Post by **HexCode** » 2024-02-22 18:40, Thursday

Intended Audience: # Lettos # & # Radoye #

In view of the Herculean efforts Lettos is putting into reshaping aero-naval matters, I'm going to wait until the emerging configuration matures. If I'm going to design "something" involving PGF's AI Module, I may as well go the "SSI-heterodox" way; all the way !

Lettos · Post by **Lettos** » 2024-02-22 20:01, Thursday

HexCode wrote: ↑2024-02-22 18:40, Thursday Intended Audience: # Lettos # & # Radoye #

In view of the Herculean efforts Lettos is putting into reshaping aero-naval matters, I'm going to wait until the emerging configuration matures. If I'm going to design "something" involving PGF's AI Module, I may as well go the "SSI-heterodox" way; all the way !

Thanks for the assessment!

Yes, we need a normal working tool for creating naval scenarios. The one we have now is really impossible to describe without ancient Greek philosophy - then there is Gordian Knot (SA/HA), then there are Augeas stables (has not been cleaned in over thirty years) - amazing coincidence in timing, isn't it?

Lettos · Post by **Lettos** » 2024-02-24 19:12, Saturday

Absolute Prerequisite:
WEATHER DETERMINATION TABLE
viewtopic.php?f=100&t=551#p9043

Let's say I want to find out how random the choice of weather is in the model. I change three Data Descriptors in the exe file:
1) Clear Time, 2) Storm time and 4) Storm Chance.
I set the third Data Descriptor, 3) Storm Type, to 100% (only Snowing in case of precipitation) to first deal with one type of precipitation and its effect on the state of the earth's surface. I wonder how much random can diversify the scenario. If it can, of course!
Let's check it out now.
The table above shows the results of the experiments.
Explanation of abbreviations:
SF - Snowing Frozen
SD - Snowing Dry
OF - Overcast Frozen
CF - Clear Frozen

OD - Overcast Dry
CD - Clear Dry
A/B/C/D/E/F/G on green color background corresponds to Weather front OFF on start (=1 in pgscn)
C and D on orange color background corresponds to Weather front ON on start (=0 in pgscn)

Some comments and thoughts.

The black squares on the right edge of the table are what I didn't look for in the tests, because I've seen many times in vanilla settings in real scenarios - it's lack of unpredictability or very little random.

Large periods (seems starting from =5 and =5) of Clear and Precipitation are too predictable.
According to the tests you can see that the expansion/decrease of the period is very likely to happen not by times, but by +/- 1 turn.
Smaller ones - 2 turns each - have no effect in terms of impact on the ground surface.

Random is certainly present in the weather model.
Now it can be used!
You can clearly see that the optimal field for finding equilibrium in the weather model is short periods of 2-4 turns for each of the two weather states - Clear or Precipitation. You see percentage probabilities of precipitation, not Overcast - 50% or 75%. The lower probability of precipitation is something I don't want to explore yet, and does it make sense to do so?

It is very interesting how the probabilities are distributed. In the overall statistics, both cases "C" and cases "D" with Weather Front on or off are statistically equal. But how differently they are distributed over 24 turns! You can make a scenario in which all weather troubles statistically come at the end of the scenario (there are many such scenarios already!), or you can shift all weather troubles to the beginning of the scenario!
Shifting bad weather to the beginning of the scenario is very interesting in terms of war at sea. (If you make a new type of weather condition, of course!). As long as the AI fleet isn't destroyed yet, it would be more interesting to fight them.... there is no guarantee that you can use aviation, spotting in one turn is large, then decreases... intrigue!

We need to investigate how to combine the two types of precipitation, and thus the two types of impact on the earth's surface, with respect to specific months of the year and geographical zones. I wouldn't be surprised if again things don't turn out the way we are used to seeing them in Panzer General/PGF. I assume that the three geographical zones will most likely result in the notional Stable-Ground, Normal, Naval-Extremal zones. We'll see!

Lettos · Post by **Lettos** » 2024-02-25 08:30, Sunday

Absolute Prerequisite:
WEATHER DETERMINATION TABLE
viewtopic.php?f=100&t=551#p9043

Working with these descriptors, there are some facts to note first.
1) Some Weather Zones in some months are completely the same. Some months differ so slightly that they can be interchanged without affecting the scenarios. This is very good for advanced modding!
2) Some of the scenarios in the vanilla PG/PGF campaign feature very strange WZ setups.

Examples:
1) Equality

In Sevastopol scenario (June'42, duration 1 month) used Weather Zone 1. Descriptors for June in WZ1 are the same as in WZ3 (12-4-0-20). We can replace WZ1 with WZ3. Perfect!
Generally speaking, WZ1 and WZ3 are the same in June, July and August. Therefore same changes WZ1->WZ3 can be done for Anvil scenario (Aug'44).

In Market Garden scenario (Sep'44, duration 1 month) used WZ2 (10-5-0-20). It is exactly same as WZ3 used in Poland and Warsaw scenarios. We can set WZ3 in Market Garden. Same for Sealion'40 and Sealion Plus.

Scenarios LOW COUNTRIES, FRANCE, SEALION'43, D-DAY, COBRA, WASHINGTON have WZ2 now. Period of these scenarios is: May, June, July, August.
Let's compare WZ2 with WZ3:
May (10-5-0-50) --- (10-5-0-20)
June (12-3-0-20) -- (12-4-0-20)
July (12-3-0-20) -- (12-4-0-20)
Aug (12-3-0-20) -- (12-4-0-20)

That is, in June-August, both Weather zones first have a Clear-Dry period for 12 turns, followed by a short period of rain and overcast. The probability of rain is the same, 20%. The only difference is the duration of this short period, 3 or 4 turns.
In May, the Clear/Dry periods are the same, but the probability of rain in WZ2 is 50% and in WZ3 = 20%.
Could such a minor difference make a significant difference in the way the scenario plays out? In my opinion, the impact is so insignificant that it can be neglected.
By the way, the probability of rain in Eastern Europe in May is incorrectly exhibited in the PG/PGF model. The month of May can be very rainy.

2) Oddities

Scenarios BERLIN(WEST); BERLIN have WZ2, but BERLIN(EAST) have WZ3. All three scenarios begins in April.
In April there are huge difference between WZ2 and WZ3. Chance for Snowing is 5% vs 60%.
Snow means possible frost, freezing of rivers ... in Germany in April???

In 1945, the average temperature in April was about +8 +10 degrees Celsius!

For Berlin(East) WZ3 must be changed to WZ2!

And at the same time in April, Norway has the same weather as Berlin, WZ2!

I understand the speculative nature of the Norway scenario. Maybe such a fantastic scenario should also have fantastic weather... or maybe something could be done a little differently?

Husky scenario have WZ1 now. It mean for September 5% probability of Snowing. Husky begins July 10th, 4 days per turn, scenario duration 21 turn. The 15th turn will be on September 4th! Snow is likely in Sicily in September ...

Torch (duration 5 month), November'42-May'43 have WZ0.

Interim Conclusion

Here it looks like you can pretty much free up space (or at least most of the month slots) in one Weather Zone for use with a new weather type...

Lettos · Post by **Lettos** » 2024-02-25 19:19, Sunday

Yes, I didn't misspoke - we're talking about the weather during a very strange battle (according to the pgscn setting). Days per turn - now the absolute champion in this indicator is the FINLAND scenario, duration 12 turns, begins November 30, and 7 Days per turn!

There are scenarios where Days per turn = 4 or 5. Torch, Anzio, Stalingrad, Caucasus.

The goals of historicism were pursued - to show that the battle had been going on for a long time. (Although in the specific case of Torch the active phase of the battle was not from November 1942 to May 1943, but in February-March 1943).
The goals of upgrading units were pursued. A new assortment of the latest industry developments could be offered to the player in six months.
This is all understandable. To me, let them besiege this Mannerheim line for at least three years, and live near Troy for at least 30 years...

And then, uh. Whoa! What's going on with the weather?

In scenarios with these Days per turn settings, there are multiple transitions from one month to the next. And there are 4-5-6-7 turns for each month.

What happens to the weather if we have Data Descriptors Clear Time/Storm Time settings in cases:
a. Clear Time/Storm Time is longer than the number of turns in a month? (common situation for Days per turn = 1 or 2)
b. Clear Time/Storm Time is roughly comparable to the number of turns in a month (this is the case when Days per turn = 4-7).
c. The scenario is modeled after Mannerheim's Siege of Troy. Oh no, Hector was there! No matter. What is important is to understand what happens in the sky over Troy in the strange range when Clear Time/Storm Time is greater than the number of turns in a month (this is the case when Days per turn = 10-20-30)

Lettos · Post by **Lettos** » 2024-02-25 21:25, Sunday

The beginning of this research is here:
viewtopic.php?f=95&t=956#p18550

Lettos wrote: ↑2024-02-25 08:30, Sunday Interim Conclusion

Here it looks like you can pretty much free up space (or at least most of the month slots) in one Weather Zone for use with a new weather type...

In accordance with the principles outlined in the link above, I did a little experimental work. The results of the work are unlikely to be useful to anyone right now. But in the future - who knows?

I examined the scenarios kindly provided by Radoye for their possible optimization in Weather Zone settings. The total number of original, non-duplicate scenarios analyzed for the opposing side is on the order of 100.

One example of optimization, in addition to the already mentioned almost equal, excessive snow in September and so on, I will give here:
Scenario Madrid with Weather Zone 1. Madrid begins on March'25. Scenario duration 10 turns. 1 turn per day. Madrid ends on April 3rd.
Data descriptors WZ1 for March are: 10-5-35-40. This means that the first 10 turns will be Clear weather and Dry conditions. But there are only 10 turns in the scenario. If we do not consider the as yet unexplored case of moving to the next month, then for Madrid in this case WZ1 is equivalent to WZ0 zero zone.
After this conversion, the 'March WZ1' slot has one less scenario using it.

I'll report the results: I managed to free nine or ten of the twelve slots in WZ1 (all months except April and May, although May could theoretically be freed after changes in one scenario) and three slots (June, July, August) in WZ2.

The free slots can be used someday, let's say, to create a different weather - not Eastern European (WZ3), not Western European and Mediterranean(WZ2). For example, you could create scenarios with tropical weather.

If anyone is interested in how exactly the optimization is done - write to me in PM. There is a large file, there is no sense to publish it here in pieces.

Lettos · Post by **Lettos** » 2024-02-26 08:13, Monday

Lettos wrote: ↑2024-02-25 19:19, Sunday What happens to the weather if we have Data Descriptors Clear Time/Storm Time settings in cases:
a. Clear Time/Storm Time is longer than the number of turns in a month? (common situation for Days per turn = 1 or 2)
b. Clear Time/Storm Time is roughly comparable to the number of turns in a month (this is the case when Days per turn = 4-7).
c. The scenario is modeled after Mannerheim's Siege of Troy. Oh no, Hector was there! No matter. What is important is to understand what happens in the sky over Troy in the strange range when Clear Time/Storm Time is greater than the number of turns in a month (this is the case when Days per turn = 10-20-30)

A simple rule for Clear Time/Storm Time works: what has been started must be finished.
Changing months does not reset a period that was started once (in the previous month, or even three months ago).

For example: scenario has settings 5 Days per turn, WZ3, and Clear Time duration for WZ3 in August is 12 turns (scenarios STALINGRAD, CAUCASUS). Begins June 25th.
Second Clear Time period in this scenario started at the end of August, duration of period is 12 x 5 = 60 days (average, depending from random). Until the end of October, or early November, there will only be Clear weather.
When this period, which began in August, ends, weather changes to Storm time period according to the rules of the current month (October or November).

Duration of Storm time is determined by the rules of the month in which the period began (same as for Clear Time period) but possibilities Overcast Skies/Precipitation are determined by the current month's rules.
For example, if in the month when the long-standing and still ongoing Storm Time period began, the probability of Precipitation was 100%, but in the current month, the probability of Precipitation is only 50%, we will see both Precipitations and Overcast weather during current month.
Ground conditions - logically! - will remains same as set in starting month of Storm period until it ends.

Lettos · Post by **Lettos** » 2024-03-02 19:27, Saturday

HexCode wrote: ↑2023-11-26 19:07, Sunday Intended Audience: # Lettos # & # Radoye #

Absolute Prerequisite

[AI] Offensive "Slugfests": Addendum
viewtopic.php?f=95&t=597#p15576

Any Ideas / Suggestions ?

Ok, when it comes to aero-naval matters, PGF's programming is kind of primitive compared to, say, Pacific General's. Nevertheless, creative modders should put whatever features and capabilities available to them to good use.

I'd like to design a pilot aero-naval battle (scenario) practically devoid of land hexes. My design approach will be both ahistorical as well as "for effect". In particular, I'd like the AI to behave meaningfully as an "attacker".

Let me give you an example of what I mean "for effect". Very often, AI-controlled air units run out of fuel and plunge to their doom. Relatedly, they don't "recognize" friendly Aircraft Carrier Class units. To compensate for all that, I'd greatly increase their fuel capacities to ensure such air units keep on flying around for many, many turns without needing to refuel.

There're many design elements requiring careful thought here. After all, this is a pilot project. Being very realistic, I'd imagine I'm likely to "hear" on this from two posters, tops.

I'll speak out, after testing some scenarios from the extensive mod library.

You're absolutely right about
A) fuel for AI aircraft
B) AI Offensive scenario settings.

My comments about:
A) FUEL. In battles, the AI sends its aircraft to the player's VH in the fog of war. The AI will only start returning its aircraft to the friendly airfield when the aircraft has enough fuel left to fly to the adjacent airfield hex.
The player put a small barrier in the way of AI aircraft... voila, the player saw them fall into the waves!
The amount of fuel available to aircraft in aero-naval scenarios must be very large, almost limitless.
I independently came up with the same concept about sea planes. Lots of fuel, reduced MVT.
I just saw really excellent standalone Midway scenario, from PGF Complete pack. In this scenario it is very clear that the author thought about the same problems as we did and solved them in a similar way!
Download link named People General (incorrect name!): http://www.peoplesgeneral.de/Downloads/PGFcomplete.zip , Midway 1.2.

About

practically devoid of land hexes

I almost agree. But! If the AI at the start of the scenario has, for example, 24 aircraft and their fuel is not unlimited, then at least 3-4 AI-controlled airfields will be needed on the map. AI doesn't understand what it means to free up adjacent hexes for refueling other aircraft.

When we have mastered though these rules, we can start expanding the islands to create ground fighting. Now I would like to deal with naval combat to make this combat a real combat, and not a cluster of rams at the slaughterhouse...

B) OFFENSIVE.
My opinion in case of naval combat settings should be OFFENSIVE.
With Offensive setups, the AI moves according to different rules compared to Defensive.
Well, there's even a very innovative way to manipulate his movements! You can actually give groups of AI ships different orders to move! I know more than well what I'm talking about. No one has ever done this before - but it turned out to be POSSIBLE to implement with just the game interface, without decompiling the EXE at all.

And a quick observation about AI actions in real scenarios. If the AI has an Air Carrier, or 2-3 Air Carriers, the AI hides these Air Carriers somewhere in the back of the ocean, on the edge of the map, and brings them to the battlefield at the very last turn.

It's not a miracle - we've all seen it back in vanilla Panzer General (Norway).
The problem here is that if the AI has a lot of ships at the start, some of them will not be sent to attack, but will be grouped next to the Air Carrier. But in the case I observed, there was another entity there - AD Cruiser (not dual-purpose). And AI grouped 2 Air Carriers and 4 warships around the AD Cruiser.
When organizing an AI offensive, you can't give a child toys that they don't understand...

Lettos · Post by **Lettos** » 2024-03-06 18:20, Wednesday

HexCode wrote: ↑2024-02-22 03:22, Thursday Intended Audience: # Lettos # & # Radoye #

Don't Move for Awhile

Historically, content designers had to rely on House Rules... Recently, NEGATIVE Starting Fuel Point (SFP) specifications in Scenario Definition File *.PGSCN proved their worth and, then, some. Mind you, in order to take advantage of this newly discovered feature (bravo Lettos), a content designer might have to render some "fuel-less" PGF-SSI Unit Types subject to faux fuel utilization.

Don't Move Voluntarily, Ever

The obvious solution to set a unit's Movement Allowance (MA) value to ZERO (0) was tried first.

Custom Unit Sporting Movement Allowance Zero Oddities
viewtopic.php?f=100&t=555#p9109

details the experienced drawbacks.

Once again, NEGATIVE SFPs twinned with NEGATIVE Listed Fuel Capacity (LFC) values certainly do the trick.

Don't Move Voluntarily or Even Involuntarily Retreat, Ever

"Anchored" Garrison Units
viewtopic.php?f=100&t=540#p8971

features detailed analysis and description of options. Key here is a property attaching to the Structure Class which prohibits units of that class to ever involuntarily retreat as a result of combat.

I am now creating Garrisons out of any necessary unit (INF, ATY, ATG, AD) by creating a clone of it in the eqp file, but with Listed Fuel Capacity (LFC) = Negative (let's say I chose a value of "-4"). And I give this clone Organic transport class 15, all parameters are zero.
Everything works fine! They fight to the last man, they don't run away, they have a correct ENT that increases by the end of the scenario; the units obey the INI Cap settings for their class.

HexCode · Post by **HexCode** » 2024-03-06 20:01, Wednesday

Lettos wrote: ↑2024-03-06 18:20, WednesdayI am now creating Garrisons out of any necessary unit (INF, ATY, ATG, AD) by creating a clone of it in the eqp file, but with Listed Fuel Capacity (LFC) = Negative (let's say I chose a value of "-4"). And I give this clone Organic transport class 15, all parameters are zero. Everything works fine! They fight to the last man, they don't run away, they have a correct ENT that increases by the end of the scenario; the units obey the INI Cap settings for their class.

But they STILL involuntarily retreat as a result of enemy ground attacks, right ? Unless one puts them in the Structure (i.e., SSI's Fort) Class.

By the way, why are you invoking Organic XPort at all?

Lettos · Post by **Lettos** » 2024-03-06 21:41, Wednesday

HexCode wrote: ↑2024-03-06 20:01, Wednesday
Lettos wrote: ↑2024-03-06 18:20, WednesdayI am now creating Garrisons out of any necessary unit (INF, ATY, ATG, AD) by creating a clone of it in the eqp file, but with Listed Fuel Capacity (LFC) = Negative (let's say I chose a value of "-4"). And I give this clone Organic transport class 15, all parameters are zero. Everything works fine! They fight to the last man, they don't run away, they have a correct ENT that increases by the end of the scenario; the units obey the INI Cap settings for their class.
But they STILL involuntarily retreat as a result of enemy ground attacks, right ? Unless one puts them in the Structure (i.e., SSI's Fort) Class.

By the way, why are you invoking Organic XPort at all?

Yes, they still retreat. Its behavior is like that of a normal unit as a result of an attack. But for me it is very important that this unit stands still and does not run away from its hex at its (AI) will. And for that unit to be of any class, just like regular units, not Fort.

Without Organic transport this unit can retreat to ocean.
And another very important reason is ergonomics. FPGE replaces negative SFP values with a standard blank value when saving a scenario. It is easier to issue a transport once than to edit pgscn manually hundreds of times (this is not an exaggeration!)

HexCode · Post by **HexCode** » 2024-03-06 22:45, Wednesday

Lettos wrote: ↑2024-03-06 21:41, WednesdayWithout Organic transport this unit can retreat to ocean.

As far as I know, this unfortunate behavior has been observed in instances where the unit's Movement Allowance (MA) is ZERO (0). Why resort to such specification? Just give adequate NEGATIVE SFPs to the unit which will definitely last until the very end of the scenario.