EiA vs EiH Orders of Battle

[pzgndr]

Is anyone still here? Based on several EiA and EiH references I have, attached is a comprehensive OOB for both EiA v3.1 and EiH v4.0 with the EiH differences highlighted in red.

IF/WHEN I can manage to edit minor country morale values, then I should be able to create clean setup files for the classic EiA 1805 campaign and the alternative EiH 1805 campaign. Can't do anything about the map, but the OOBs could be updated.

A modest request. I would appreciate anyone interested to review the attached OOBs and verify the various forces/morales are accurate and as they should be for either campaign. For instance, I've seen the EiA French X-XII Corps listed as either 12 I/M and 1 C or 12 I/M and 2 C, but I think the 2 C is correct. So, I'm looking for feedback and if anyone has corrections then please let me know and provide a reference.

FYI, I also have the EiH v5.1 rules and OOBs as references but I think those introduce too much additional complexity based on the newer rules and do not appear to be a good fit for EIANW. If I can create new clean setup files, then others can further edit those if they want to.

Thanks!

[Pans]

the alternate EiH Setup includes the possibilties to place heavy and light ships in one Counter. If you select the heavy fleet during game Play you only see the heavy ships in the Display - even if lights are part of the fleet?!

[pzgndr]

ORIGINAL: Pans
If you select the heavy fleet during game Play you only see the heavy ships in the Display - even if lights are part of the fleet?!

Good catch, thank you! I spent a bit of time today digging into the update_unit_box function to figure out how to make the naval units display look like the land units. I need to verify everything else still looks OK but it appears this is resolved now.

This little exercise forced me into understanding the forms layout better, so I can experiment some more with improving the visual layouts.

[Daniel Amieiro]

Hi!

I seek these OOB and i think these are correct.
But i think that making a specific scenary is the wrong way. I think a text/config file that overrides the actual data system could make the job for any scenario and the first test would be the 1805 Scenario.

I suppose that the game data are loaded by the two main files (.ged and .tpj).
If it is too complex to work around these files (because you have a lot of code doing that work), perhaps this aproach could be useful.

Function load_scenario ()

{
load_ged_file (gedfilename) -> put ged data file into memory
load_tpj_file (tpjfilename) -> put tpj data file into memory

load_mod_file (modfilename) -> Use a new .mod or .txt file and take these new data into memory and allow overwrite previous one

}

So you don't need to tweak old data, you only need to make an extra file to add the new data (that could rerwrite even the previous one).
The main concept here it is if the struct of the data (for example country morale) are into each country defined or not. Or if a Unit has morale or take the country defaults and never is stored unit morale into the unit data.

I think the modding potential is huge. And making and scenario should go from a modding view not hardcoding it.

Allow th mod data to write on everything and better with a text aproach (to easily mod). PPs for countries, morale per unit, multidistrict countries definitions, etc. So you can take the view that older functions are legacy and you work over these. I do not recomend you to do .ged ot .tpj editing. It only hardwired the game and lacks flexibility and postpone a global solution

On the other hand, great job

[pzgndr]

ORIGINAL: damieiro
I think a text/config file that overrides the actual data system could make the job for any scenario and the first test would be the 1805 Scenario.
I suppose that the game data are loaded by the two main files (.ged and .tpj).
If it is too complex to work around these files (because you have a lot of code doing that work), perhaps this aproach could be useful.

Thanks! The code complexity is not so much the problem as the code compiler is still Borland/CodeGear C++Builder 2007 which is only WinXP compatible. I want to migrate the code to the latest Embarcadero C++Builder Berlin version which is Win10 compatible. Hopefully that will resolve various database issues we're seeing. Also, I might then be able to update the editor code itself to be more functional. I tried to make some edits to fix things that were not saving correctly in the editor but that didn't work, so I ended up making many of those scenario changes with a separate hex editor like you had previously discussed.

Let's see what happens later with the new compiler? I do have a copy of it, and I have made some progress but I'm stuck at a point where I need to make a lot of variable name changes throughout the code and I don't want to do that until I freeze the current update with an official release. If I cannot update the editor to work better, then perhaps a separate scenario editor tool might be the way to go and I could work with you on that. I'd really like to get the 1812 scenario to work and perhaps something to remove Bernadotte from France in 1810 and add him as a Swedish leader available in 1812 or 1813. At least that, perhaps more. We shall see!

[Daniel Amieiro]

Well, i think it's the main program data that should be revisited.

A text file or a editor is the interface to these data. I say a text editor because i think it could be easiest to code, but a editor is fine. But as i said, the main problem is data. The game aren't storing the needed data or not managing that

For example, morale is stored in a per country basis.
Really is stored that majors have their morale value, the minor another ones, and a list (not a full one) special ones,
If morale is unit-basis (stored in each unit), you can get a Old Guard (with 5 morale) and a young guard (with 4.5 morale) for example. And making a EIH scenario easily.

Editing morale per unit basis is really simpler and code that manages that easy too.

But morale should be in the unit structure. Country morale perhaps could be useful, but it's an example

Another example is that Upgrade field data isn't present so a unit X cannot upgrade on unit Y. So scenarios like 1792 can't be possible. (not even specials with code like vive la revolution with special and need coded).

Same for "dead" field. The units have a "born field" in generals, but not a dead one, so a long scenario with dead of generals are impossible. Same for dead of units.

The main data, surpringsly are able to take characteristics in admirals (so nelson is really a 553), so other admirals like gravina could be possible, but there isn't their counters and a graphical error would be. The generic counters are incomplete, and the units should have their generic.

So to get a good scenario, i think it's needed the data that manages it.

Same for multidistrict countries and absorbing/ceding of multidistrict. It's absurd that you make a Confedetation of the Rhine and after you cannot absorb a new province to him. Specially Poland. And in editor (or in text) there isn't a way to make multidistrict (the New Country X is made of S1, S2.. SN with capital SM and minimun M states of these N). Data actually supports that in a limited number, but editing not. An EIH scenario that uses heavily that, needs handling these.

So the text is for making easy the interface. But the needed changes are in the data and the code managing that data. I think this is more (and rewarding) than hex-editing the files...

[Daniel Amieiro]

On the other hand, you should attack first the new compiler needs and hows to. So it's obvious you need to follow the path you explain.
First, make a stable version.
Then upgrade compiler, renaming/making all the changes the upgrade compiling would need, then attack next problem.