Dynamic CS

[umbro]

Hi there Gentlemen (and I use the term loosely :-))

Having purchased the Matrix versions I resurrected my dynamic CS project - which was a mechanism to allow scenario designers to have various parameters change through the playing of a scenario. I did this specifically for visibility and whether night was on/off to allow for dawn and dusk scenarios.

I have two questions:

1: What other parameters would designers like to be able to vary (ammo levels - ammo dump is captured, terrain - snow is falling through the day, star shells, etc.) or should I simply make everything changeable?)

2: Is anybody interested in playtesting this feature? I will supply a scenario (Operation Felix: The invasion of Gibraltar that can be played against the AI. It starts pre-dawn and continues through sunrise) which will include the standard files felix.scn, felix.org, felix.map and felix.dcs; an installer (that patches west front.exe so as to invoke the dynamic code); and the code that performs the dynamic update.

The mechanism requires that the scenario be reloaded at the start of each of your turns. This is not a problem for PBEM as the turn has to be sent and loaded, however, for those playing against the AI you will have to remember to save and reload the scenario at the start of your turn.

umbro

[Von Luck]

Iwoulld give it a try but up to my neck in others plus Earls scenarios.Sounds like a nice idea though.This is a prob they want new things but are unwilling to try them.As you will see from my next MB message.

[Jason Petho]

As a scenario designer, this would really be a dream come true to be able to incorporate this into the scenario design phase. Preferably with the ability to hardcode such a feature into the game.

Ultimately, the ability to have all of the normal scenario editor options be adjusted (ammo level, ground conditions, weather, day-night-day, number of airstrikes (and when), I could go on and on.)

Count me in on helping to test.

Jason Petho

[junk2drive]

I was home for lunch and saw your post. I was tempted to jump in but I fear a monster size scen with fleets of boats to move and offload.

If it's not too big I'd like to try your ideas.

I have 1.04

[umbro]

j2d:

Felix is a relatively small scenario with no real amphibious component. Though I will rework Leros43 for the boat lovers among you!

umbro

[junk2drive]

Aloha

Send the files and some manapua to my email.

[Huib Versloot]

I'd like to see a separate ammo level for artillery. No idea if such a thing would ever be possible.

I also have a scenario where it started snowing during the scenario. I would be nice to be able to set that.

I'm also interested in testing anything you come up with.

send it to huib[dot]versloot[at]gmail[dot]com

Ofcourse I too have a pile of Dutch books in case you continue with the Rotterdam/Moerdijk scenario and need any info.

[umbro]

Huib:

Making all the scenario variables on a turn by turn basis is definitely possible, and the first version that I make public will have that capability. Splitting out a separate ammo level for arty is more interesting, but having thought about it seems possible as long as I can decipher the entire btl file contents and arty carry their supply status with them.

umbro

[Huib Versloot]

Jonathan,

I had been playing with the idea to make a text editor in Visual Basic that would read the bte files and does write actions based on the turn number. Thus you could make a script for each scenario that needs variable parameters. Problem is I have limited time and even more limited knowledge of Visual Basic. I just know that it has to be possible.

Huib

[umbro]

The process that I am working with is:
1) Scenario designer designs the scenario files, when done (s)he drops the complete .SCN file onto a little app that creates a .DSC file for that scenario using the default values that the designer created.
2) The designer opens the .DSC in Excel (or notepad for that matter) and edits the contents as needed. (S)he then packages the scenario files .SCN .ORG .MAP and .DSC into a .ZIP file for distribution.
[Note: the .DSC file has a format that looks like -
Trees Ground ... Visibility Allied Arty Ammo ... Night ...
0 0 0 ... 20 80 ... 1 ...
1 0 0 ... 20 80 ... 1 ...
2 0 0 ... 20 80 ... 0 ...
3 0 0 ... 10 70 ... 0 ...
4 3 0 ... 6 60 ... 0 ...
5 3 3 ... 4 50 ... 0 ...
...
N ... ]
Thus the scenario starts at night, dawn breaks, snow starts to fall so the trees get snow on them and the visibility falls and finally the ground is snow covered. All the while the allied arty ammo level is falling as the rear areas are given the order to retreat.

The players get a package which comprises an installer that patches the west front.exe, east front.exe and rising sun.exe, the dcs.exe .DSC file processor that does the work, an uninstaller and a sample scenario.

The patch simply calls the DSC processor before calling wf.exe, etc. The DSC processor looks for a .DSC file with the same name as the .ORG file of the scenario being played. If there is one then the DSC processor simply calls the appropriate CS application as usual and the user experience remains as it was. If the processor finds an appropriate .DSC file then it interprets the data for this turn, updates the .BTL or .BTE file (those are the saved battle files, the former for play against the AI, the latter for an email opponent) and then invokes the CS application. In this case the player may notice a slight delay as the CS application launches. If this delay becomes noticeable I will throw up a dialog informing the player of what is going on.

This may be more noticeable in the case of arty ammo level. This is because I will have to check to see if I have processed the file already for this turn, and if not I will have to scan though the file to identify arty that have fired in the beginning of the turn and arty that are low on ammo in order to recalculate their ammo status.

Jonathan