[DEV] Content Generation - Ideas, Approaches & Discussions

[Lettos]

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

It's possible that I've overreacted while working on the scenario!
Checking in tests now and I see no difference in the behavior of a unit with Negative Listed Fuel Capacity depending on whether it has transport or not. But it's the tiniest little thing. Getting that Zero MVT transport out of the scenario is a few clicks.

I've already written about SFC - it slows down the work in the scenario creation process, when you have to change the position of units on the map very often.
It's easier to make a clone of the unit in the eqp file. When the scenario is complete, you can replace the clone with a normal unit with negative SFP. But why do this if the clone has already been created, and the eqp file size looks unlimited at this point?
Also, scenarios will never be completely finished. There will constantly be some sort of tweaking going on. And then we'll have to use the clone again at the design stage, and then replace it with a normal unit again... a lot of unnecessary mechanical work, which will only make sense if it suddenly turns out that the behavior of clone units with negative LFC and normal units with negative SFP differs in some way. So far they look the same in behavior.

That's why I use SFC only for slow start of individual units, but not for mass stationarity of garrisons and batteries.

[Lettos]

ENT Level can be set in pgscn to values much greater than the allowed nine.
In tests, even a three-digit ENT number does not cause any problems in the interface and executable program.

Assigning for certain units the ability to ignore entrenchment was already discussed two years ago.
viewtopic.php?f=95&t=467&start=150#p12712

The idea to use 'ignore entrenchment' ability by long-range and heavy guns is questionable for me ! This feature is more suitable for rocket artillery...

Generally speaking, a missile is just a means of delivering a certain mass of explosive packed in a certain type of container at a certain speed to a target.

Gustav/Dora, Karl, Thor, TallBoy bomb, 1000kg bomb, 356/381/406/456 mm shell - their effect on fortifications is very significant.
Engineers haven't guns but have flamethrowers. Flamethrower tanks - can they have ability to ignore entrenchment too?
These issues are decided by the scenario designer himself.

And the general theme is that if you need to destroy some unit with ENT=30, or 99, then the usual means in the form of multiple strikes that reduce the ENT level will be extremely ineffective.
Of course, there remains the notorious PGF engine principle that any weak unit can someday do a little damage to a strong one.
The remedy to this principle is to give the fortress/bunker unit not only a very high ENT, but also as much STR as possible (20). Weak units will not be able to quickly destroy such a fortification.

Until the player brings some heavy guns to the fortress, or brings Engineers or flamethrower tanks, the fortress will remain a fortress. It's a plug fortress on an important road or, for example, a coastal battery like the Todt or fort "Maxim Gorky".

[HexCode]

ENT Level can be set in pgscn to values much greater than the allowed nine. In tests, even a three-digit ENT number does not cause any problems in the interface and executable program.

Assigning for certain units the ability to ignore entrenchment was already discussed two years ago.

A clarification: For a long time, the "hobby" generally assumed that "ignore entrenchment" just protects the attacker from triggering a potentially nasty, enemy rugged defense. In fact, it does much more; namely, it lowers the enemy unit's defense grade by nullifying the ENT factor in the formula. This renders the enemy unit situationally more vulnerable.

[Lettos]

viewtopic.php?f=100&t=544#p8985
Fair Weather & Storm Fronts

A typical scenario's duration is subject to strictly alternating periods of

A) Fair Weather; and
B) a Storm Front.

No "gaps" are allowed here. Please note that a scenario may commence with a Storm Front already being present. The Boolean value assigned to variable "Current Weather" in file *.PGSCN controls this feature (i.e., value 1 implies "Fair Weather" while value 0 implies "Storm Front Presence"). Whether a Fair Weather or a Storm Front period, its Average Duration is expressed in full turns.

One subtle nuance came to light.

There is a scenario with Current Weather = 0.
Probability of precipitation = 50%.

1) Run it as a separate scenario.
On the first turn the weather is Overcast much more often than Precipitation.
2) Run the same scenario in a campaign. On the first turn the weather will always (or almost always - at least 10 times out of 10 runs of the scenario) be Precipitation.

The nuance, I think, is that the deployment stage is kind of a separate pre-turn. 'First-to-first', or 'zero' turn.
We don't see any difference in the interface. Turn 1 Deployment goes to turn 1 when the End turn button is pressed.
But for the weather model there is a difference.

The nuance was revealed when testing the scenario. On the first turn it was planned to use overcast weather and strike by aviation. And while the scenario was tested as a separate one, everything was according to plan and just fine. But during the final testing in the campaign, when the army was deployed on the 'zero' turn, it suddenly turned out that instead of the overcast weather, a little devil came out, made precipitation with almost 100% probability, and told the aviators - no attacks, rest!

[HexCode]

The nuance was revealed when testing the scenario. On the first turn it was planned to use overcast weather and strike by aviation. And while the scenario was tested as a separate one, everything was according to plan and just fine. But during the final testing in the campaign, when the army was deployed on the 'zero' turn, it suddenly turned out that instead of the overcast weather, a little devil came out, made precipitation with almost 100% probability, and told the aviators - no attacks, rest!

As far as I know, the probability of Precipitation during a particular turn is independent of

1) Either the number of turns elapsed since the onset of the current Storm Front.

2) Or the Precipitation's actual status in the immediately preceding turn.

However, should the Storm Front's duration straddle two consecutive months, the probability of Precipitation might change from one month to the next one.

The above "theory" seems to be at odds with the presented empirical evidence. I mean, "Turn-0" and "Turn-1" Precipitation events are presumed to be probabilistically independent. If so, "Turn-1" Precipitation events should be statistically "identical" whether the scenario is played in Standalone or Campaign mode.

[Lettos]

The nuance was revealed when testing the scenario. On the first turn it was planned to use overcast weather and strike by aviation. And while the scenario was tested as a separate one, everything was according to plan and just fine. But during the final testing in the campaign, when the army was deployed on the 'zero' turn, it suddenly turned out that instead of the overcast weather, a little devil came out, made precipitation with almost 100% probability, and told the aviators - no attacks, rest!

As far as I know, the probability of Precipitation during a particular turn is independent of

1) Either the number of turns elapsed since the onset of the current Storm Front.

2) Or the Precipitation's actual status in the immediately preceding turn.

However, should the Storm Front's duration straddle two consecutive months, the probability of Precipitation might change from one month to the next one.

The above "theory" seems to be at odds with the presented empirical evidence. I mean, "Turn-0" and "Turn-1" Precipitation events are presumed to be probabilistically independent. If so, "Turn-1" Precipitation events should be statistically "identical" whether the scenario is played in Standalone or Campaign mode.

I drew erroneous conclusions from some very unfortunate random sequence.

I have now checked in tests: the weather in a single scenario and the weather in the same scenario in the campaign are not different.
I tested a month with a 60% chance of precipitation during a stormy period.
In the standalone scenario 40 runs shared: 23 precipitation, 17 overcast.
In the scenario in the campaign 100 runs eventually shared as 62 precipitation, 38 overcast.

What's interesting about the sequences: in a separate scenario, after 25 tests, there was a score of 10 precipitation vs. 15 overcast! I.e. not 60% precipitation, but like only 40%! But tests 26-36 gave precipitation 11 times in a row! This is the longest sequence in 100+40 tests.
Two other times a sequence of 7 times in a row was observed.

What can I say... the little devil gave me a very tricky sequence of 10 in a row while testing my scenario..... that statistically couldn't have happened on the first try! But it did! The little devil made a joke and went somewhere else.

[Lettos]

The nuance was revealed when testing the scenario. On the first turn it was planned to use overcast weather and strike by aviation. And while the scenario was tested as a separate one, everything was according to plan and just fine. But during the final testing in the campaign, when the army was deployed on the 'zero' turn, it suddenly turned out that instead of the overcast weather, a little devil came out, made precipitation with almost 100% probability, and told the aviators - no attacks, rest!

As far as I know, the probability of Precipitation during a particular turn is independent of

1) Either the number of turns elapsed since the onset of the current Storm Front.

2) Or the Precipitation's actual status in the immediately preceding turn.

However, should the Storm Front's duration straddle two consecutive months, the probability of Precipitation might change from one month to the next one.

The above "theory" seems to be at odds with the presented empirical evidence. I mean, "Turn-0" and "Turn-1" Precipitation events are presumed to be probabilistically independent. If so, "Turn-1" Precipitation events should be statistically "identical" whether the scenario is played in Standalone or Campaign mode.

I drew erroneous conclusions from some very unfortunate random sequence.

I have now checked in tests: the weather in a single scenario and the weather in the same scenario in the campaign are not different.
I tested a month with a 60% chance of precipitation during a stormy period.
In the standalone scenario 40 runs shared: 23 precipitation, 17 overcast.
In the scenario in the campaign 100 runs eventually shared as 62 precipitation, 38 overcast.

What's interesting about the sequences: in a separate scenario, after 25 tests, there was a score of 10 precipitation vs. 15 overcast! I.e. not 60% precipitation, but like only 40%! But tests 26-36 gave precipitation 11 times in a row! This is the longest sequence in 100+40 tests.
Two other times a sequence of 7 times in a row was observed.

What can I say... the little devil gave me a very tricky sequence of 10 in a row while testing my scenario..... that statistically couldn't have happened on the first try! But it did! The little devil made a joke and went somewhere else.

I found the answer to the question of strange pathological bad luck.

The main point is that there is no unluckiness.
Here everything happens according to completely different laws, which can be understood.

Consider two related scenarios in a campaign, the previous one where victory is won and the next one where the weather will be, well, not so good at the start. Let it be overcast/precipitation 50/50.

If the player is playing - how do you say it right? - honestly, gambling, going from scenario to scenario without any saves at the deployment stage, then the chance of a player getting an overcast/precipitation will be 50/50.

But if the player made a save at the Deployment stage, then there is phenomenon.
Phenomenon is proven by numerous test experiments - the weather in the first turn has already been determined and saved in the save. You can reload the Deployment stage save as much as you want, but it will not change the weather. Hence my unlucky series of 10+ precipitation. There could have even been 1000 of them.

Now that I've learned this strange secret, to work on the next scenario with Current Weather set to 0, I do two deployment stage saves after the previous scenario: Precipitation on 1st turn and Overcast.

[HexCode]

But if the player made a save at the Deployment stage . . . the weather in the first turn has already been determined and saved in the save.

Now that I've learned this strange secret, to work on the next scenario with Current Weather set to 0, I do two deployment stage saves after the previous scenario: Precipitation on 1st turn and Overcast.

You've lost me here. Are you going to repeatedly save during the Deployment Phase until you get two separate saves, each sporting a different Weather on Turn-1 ?

[Lettos]

But if the player made a save at the Deployment stage . . . the weather in the first turn has already been determined and saved in the save.

Now that I've learned this strange secret, to work on the next scenario with Current Weather set to 0, I do two deployment stage saves after the previous scenario: Precipitation on 1st turn and Overcast.

You've lost me here. Are you going to repeatedly save during the Deployment Phase until you get two separate saves, each sporting a different Weather on Turn-1 ?

I'll explain.
Our path:
Finished scenario - > Deployment Phase (Weather for 1st turn already determined!) -> 1st turn

If we want to have another weather:
Reload Finished scenario (saved on last turn last movement) -> go to Deployment Phase (not spent time now for units Deployment, but just make a save 'DDD') - > Check weather on 1 st turn
IF weather is same as on previous attempts, repeat actions.
IF weather is another, open save 'DDD' and Deploy units.

[Radoye]

Does it make a difference if you save during the "view battlefield" after the end of previous scenario (but before moving onto the next scenario deployment phase), instead of during the last turn of the previous scenario (before winner is declared)?

[Lettos]

Does it make a difference if you save during the "view battlefield" after the end of previous scenario (but before moving onto the next scenario deployment phase), instead of during the last turn of the previous scenario (before winner is declared)?

Checked. There's no difference. After the "View battlefield" save, the weather in the next scenario will still be different.

[Radoye]

Good to know. Because that's how i usually make a save after a scenario, when i do playtesting. Glad that it does not skew the gameplay