Last Updated: Thursday 25th of April 2002

Having any remarks, questions, problems or insults you can contact me here: massena@wp.pl

Here is long delayed story. First I want to say that it is not the lecture for everybody (except maybe Bonus Gallery ?) - and not only because horrible language (but that too :). You will not find there "Canned Solution" - it is not a list of instructions to follow to the letter - it is rather description of "an experiment". Having enough time and will you should be able to repeat most of that experiment (feel free to email me with any questions or remarks: massena@wp.pl). In exchange you will get the ability to play through ANGV engine a number of existing Waterloo scenarios. However ANGV release seems to be about (more or less) a month apart, WNLB Patch should be out quickly after so I personally think that ability in itself (despite all the fun and time I spent testing/playing scenarios) is not worth the effort. The true benefit of that story is for me its educative value. At the beginning my intention was just checking how well (if at all - it turned out to be the valid question) the MultiCampaign feature of ANGV is really working. I've choose the Waterloo as good, ready to use test case. In the process I've learnt (and tried to describe) quite a few facts about ANGV engine (as it is in its current Demo incarnation) internals. Some of them may be useful on their own.

Is it possible to prepare such "canned", "ready for sale" solution? I think it is possible to come quite close to it. There are few things which would need to be done (and can be done) better then I've did for my testing purposes. Still there are also some inherent limitations (uniforms) and at least one severe (though not critical) problem (see Battle Aftermath for more info about it).

Because the size of the story got out of my control I decided to divide it into sections to make reading a bit easier. Here is a list of sections - please, don't treat their headings too serious :-)

1. 0. Preliminaries - you are reading it.
2. 1. First Blood - MultiCampaign is not easy - trying to investigate how to use that feature.
3. 2. Fighting through broken terrain - missing terrain elements are capable to quickly crash the scenario
4. 3. Seeking cover in Buildings - they are integral part of Waterloo battlefield.
5. 4. Uniform Mess: "Sir! They've stolen our uniforms!" - there were more troubles with them then I've expected.
6. 5. Frontal Assault: Straight road to AUSTERLOO^TM - kind of brute-force appoarch - alternative for MultiCampaign
7. 6. Battle Aftermath - what is achieved, what is still missing.
8. 7. Bonus Gallery - twenty pictures from AUSTERLOO^TM AI-vs-AI battle (FeldMarshall Vorwaerts scenario)

That part was originally posted (05.04.02) on the Scenarios section.

I have taken time to check if / how using Campaign different then default ( Campaign=2, value of 1 is apparently reserved for Waterloo) work. I choose value above reserved range (i.e. above 20), create corresponding CONFIG44.CFG and decided to take optimistic appoarch - using whole Waterloo map/oob/scenario pack. Didn't load correctly (of course ;), so I started to replace Waterloo elements by Austerlitz ones. Still didn't work... Switching to pesimistic path - tried to load Austerlitz orginal map data, original oob and everything else through the Campaign key different then default - did not work either !!! Was enough for me so I had started debugger to see what inside. It looks like during loading fog file for Austerlitz (and only for it) is called small piece of code which initiate some variables to non-zero state. For other Campaign settings that code is not called (note that for Waterloo no fog data is loaded at all yet for settings above reserved engine IS trying to load fog file - default name is NAPFOG44.RAW in my case. You can change it using FogFile property in config file. There are also FogStart and FogEnd properties - to define time limit for the fog?). Looks like a bug to me (but it is hard to judge without source code - so it may turn out to be a feature at the end :-). Result is "DIVIDE BY ZERO" exception in the load process. Hope it will be cleaned before the release. For the moment I had patched quickly the code so I managed to load orginal Austerlitz data as a custom campaign (big deal isn't it? :). Still something was looking strange... No lighting, no sunny heights, no valleys in the shadow - it was like during the cloudy day just before the thunderstorm - otherwise everything seemed to be OK and playable. My theory is that lighting conditions are defined in the set of AUSTERMAP_00HH.RAW files in the GRAPHICS folder. It is backed up by the fact that removing that files results in the very same cloudy sky when loading Austerlitz standard way. Do the HH numbers mean the hour of the day (and night)?
From there I returned back to Waterloo. I was able to load a scenario but after a minute or two it hanged up. Switched back to Austerlitz oob/scenarios yet with Waterloo map files (but with cleaned - that is "dotted out" buildings and terrian files). It loaded and I was able to play "St. Hilarie" on the hills and valleys of Waterloo. For the moment it is the end of that long story. Having some time I plan to gradually add Waterloo files to find out which one's incompatibility makes troubles. If someone is interested in making such invetsigation on his own I'm ready to provide patched version without which loading custom campaigns seems now to be not possible at all (?).

So here is the situation: We are using Austerlitz original OOB/SCN files. Still loading (through Multi-Campaign feature) full set of Waterloo MAPDATA files results in the quick bumping-out. When Terrain and Buildings files are "dotted-out" everything loads and plays OK. One more check and it is clear now: terrain is broken! That is parts of the Terrain file contain broken elements - it is enough to scroll (or zoom-out) map a bit - when they are supposed to appear in the camera's view failure is inevitable. Probably easiest way to handle that problem would be to check if WaterMap.BAG taken from WNLB would help. I've taken more complicated way (don't ask why, please :). I started (using block Copy&Paste feature of my editor) to copy step-by-step parts of the original WaterlooTerrain.txt to the initially clean Terrain file. Here is what I've found missing:

• MUSTARD ('f' code) - it is one of the harmful map assets. Copying mustard sprites (four bitmaps) from WNLB into ANGV GRAPHICS/WaterMap.BAG is enough.
• CLOVER ('g' code) - same situation. As above copy four clover sprites into WaterMap.BAG cures the problem.
• QUARRY ('q' code) - not critical (no crashing if missing). To have cool sandpit feature near La Haye Sainte it is needed to copy from WNLB single SANDPIT.BMP sprite. It is a bit odd to have sandpit representing quarry, isn't it? (:-)
• BROKEN ('N' code) - also not critical but very needed as a common element on the WNLB map. To get it visible on the map you need to copy SPROVER bitmaps (sprover02 or 03 - I copied all three in fact. By copying sprover01 one can get fields with crops in December. Should make food supply easier :).
• Hedge is part of a few elements in the Roads file. To make it visible HHEDGE.BMP needs to be transferred from WNLB to ANGV WaterMap.BAG. Copying of HEDGETEXTURE.BMP (located in WaterMisc.BAG bag) may help even more (didn't notice a difference but then didn't really look for it).

These changes should be enough to achieve reasonable good Look&Feel for Waterloo@ANGV terrain. Some discrepancies will be still noticable. Most of them however are the result of the season difference. In other words in ANGV we can see how Waterloo battlefield would look like in cold (but snow-free) early December. The difference is especially sound in case of orchard. Of course it should be possible to improve on that topic by copying more sprites from WNLB WaterMap.BAG or even replacing whole ANGV map bag by that from WNLB - it is up to you. I can not guarantee that I did not miss some assets. Also it is worth to note that ANGV apparently has some new terrain features added. 'V' - like vineyard seems to be best looking and most promising (:-). Marsh ('m' code) will also be very useful in future custom maps (note also 'l', 'k' codes on the borders of marsh terrain). 'E' code looks more or less like normal forest ('W') but seems to be of higher density (?). 'P' repesents frozen pond - from there it is close to the impassable lakes and rivers. Maybe in the next game...
Certainly much more can be said (and done) regarding terrain and terrain features. We may see soon updated version of the MAPCREATION.txt file so it seems reasonable to wait until ANGV release.

Would be nice to have some day in the future the ability to define in the CONFIGnn.CFG the exact location and/or name of the bitmap BAG file(s) to be used in the given campagin. Could be useful not only for WaterMap.BAG and WaterMisc.BAG (?) but also in case of WaterArmy.BAG. It is nothing really important but could make life a bit easier.

Having Terrain file worked out to some degree it is the time for Buildings. Using original WaterlooBuild.txt does not cause crash. That is good but still there is a lot to be done. I want to leave the Hougoumount for later as it is issue in its own right. Most of other fortified buildings are missing too (except the white flags, that is), oddly enough the La Haye Sainte is in its place but... in the form of Sokolnitz Castle. Also the barricade on the road ahead of La Haye Sainte is missing. Going in reverse order:

1. Missing barricade represented by 'c' code has its bitmap in the SPECIALS1.BM2 . Location of that file differs between WNLB and ANGV and it looks like WNLB location is right one. So to get back barricade (and other two 'special' structures) one needs to copy aforesaid file from main GRAPHICS folder into the WaterMisc.BAG file. Doing the same for your original ANGV Demo installation is also profitable because there are quite a few (otherwise invisible) 'a' type buildings on the Austerlitz map.
2. Most of missing fortified buildings are "Walled Farms" ('S' code in the Building file) - these do not occur on the ANGV map. It is enough to copy from WNLB WaterMisc.BAG FORT02.BMP and FORT03.BMP bitmaps into corresponding location in ANGV. Didn't check which one (or both) is really needed. Also note that FORT01.BMP is already on place. It is to be used as "Fortified Church" (code 'C').
3. Lets pit our wits against La Haye Sainte mystery. It is apparently coded as '5' on the Building file - "Fortified House No.5" according to MAPCREATION.txt document. Digging into program code reveals that there is hardcoded linkage between object "No.5" and the name of the bitmap file to be displayed on the map. In case of WNLB it is "LAHAYESAINTE.BMP", in ANGV "SOKOLNITZ.BMP" is tried to be loaded. Of course bitmap format and location ( WaterMisc.BAG) is to be the same in both cases. So the reason why it looks like SOKOLNITZ CASTLE in ANGV is clear. When making custom maps removing La Haye Sainte (aka Sokolnitz Castle) may be desirable. Removing the bitmap file (or using fully transparent one) is not perfect because the white flag stays around. Removing '5' code from Buildings file doesn't help either - the object is still there! Looks like 'No.5' object is internally represented by a structure with hardcoded default location on map. That location however can be easily changed by using '5' code on Buildings file. Thus "No.5" can be easily used as crucial defensive structure wherever needed or moved to the edge of the custom map if not needed. Note that it seems to be possible to have only one "No.5" object on the map. When using more '5' codes the "No.5" seems to be situated in the last - that is farthest from (1,1) square - location used. [The remarks above are true only for ANGV. See the supplement few paragraphs below]
   One way or another in case of Waterloo@ANGV solution is easy: it is enough to replace the original SOKOLNITZ.BMP by renamed LAHAYESAINTE.BMP from WNLB.
4. It turns out that Frichermont is "from the same gang". It is simply object "No.6". In WNLB it is hard-wired to the FRISCHERMONT.BMP (WaterMisc.BAG also). Unfortunately it is not the case in ANGV. In ANGV there is no object "No.6" at all! Thus code '6' on the Buildings file is ignored. Pity, pity, pity. Note that the same is true for all other "Fortified Houses" in '1'-'9' range: despite what is suggested in the MAPCREATION.txt document they seem "to be reserved for the future" and are ignored both in WNLB and ANGV. Sad.
   Quick and dirty solution for Frichermont is using either "Fortified Church" ('C' code) or "Fortified Farm" (code 'S'). It is ugly visually and even worse it gives defender only two (instead of three) morale blocks as defensive bonus. Also it is not impossible (though improbable to be truthful) that "Fortified Houses" have some additional, per-object properties.
5. Speaking about fortified objects it is worth to mention MAPDATA/FortOff.CSV file. At first I've copied version of that file taken from WNLB. It was not good idea as it resulted in nasty mismatches between building bitmaps and their flag markers. Restoring ANGV version brings the order back. Exact format of FortOff.CSV file is to be investigated - in some way it adjusts the positioning of bitmap relative to the defined on-map coords. Why as many as eight points is needed for it - I don't know? My "poor guessing" is that only one anchor point is needed, each for different angle of the camera's view.
   Anyway file does not contain any info about logical properties of the object as I imagined at first. (You know - would be cool to be able to define how much fire protection provides the given side of the structure, how many soldiers can effectively fire through it, how many attackers/defenders and with what bonus/handicap can take part in the melee - that kind of things. Yes I know I have a bit wild imagination :)).
   Note that when the file is read by the engine first (and every ninth) line is treated as comment and ignored. I've thought that it is used to match up name of the building defined elsewhere but it is not true. So effectively matching up is done by position: first eight pairs of numbers are related to the object "No.5" etc.
6. Beside "Fortified Houses" at least two other structures seem to have their bitmaps missing in both WNLB and ANGV: Abatis ('A' code) and Chapel ('P' code). For the moment it is rather minor issue.
7. Time for Hougoumont... it is really wild beast with no real chance for domestication :).
   Its structure and properties seem to be hardcoded in the WNLB executable file which makes recreating of that complex more then challenging task. As usual there is also bright side: making custom map for ANGV engine one does not need to waste time trying to remove, hide or cover Hougoumont and its flag markers from the map. That would be an advantage for every other venture but for Waterloo@ANGV it poses serious problem. In theory it could be possible to find the data hidden inside WNLB and move it in some way to the ANGV (together with parts of code responsible for its handling!). If it sounds insane it is probably because it is insane :-). So what's left? Well, I think that pretty good approximation could be achieved by using SpecArea object(s) feature available in ANGV (see THE PHEASANTRY Tip). Defining one or more such object(s) (which can provide as many squares with wall defensive bonuses as one needs) together with appropriate number of fortified buildings ('S' and/or 'C') would give very strong defensive position. Surely it would look rather oddly... well, nobody is perfect :-). Hougoumont is necessity for full-scale WNLB scenarios but for the time being I decided to leave that task as an excersise for the future.
   BTW note that to disable original PHEASANTRY object on the edge of Waterloo map it is enough to set active property in the MAPDATA/SPECAREA.MOD to zero.

I hope in the future binding between the given "Fortified House" object and its bitmap will be deffered to the run-time. It could be done using (once again) CONFIGnn.CFG file. For example lines like that would define objects "No.5" and "No.6" for Waterloo: Fortified05=LaHayeSainte.BMP,70,39,300,140 Fortified06=Frischermont.BMP,124,39,300,140 The numbers following the bitmap name are currently hardcoded together with the bitmap string. First pair defines (voilla!) default object's coords (in squares), second seems to define the size of the single sprite in pixels (each bitmap has eight sprites for eight view angles). Of course the "Fortified Houses" without corresponding line in CONFIG file would be treated as disabled. Such feature would give great flexibility for map designers allowing them to use from 0 up to all 9 strong defensive buildings each with its own nice look&feel. Reading CONFIG file in run-time wouldn't be a problem at all. A bit more challenging is switching from static structures to memory allocated dynamically only for the objects actually needed in the given campaign. In exchange one would get elegant and extendable (when more then nine objects needed :) solution. Just small step in direction of universal battlefield engine... (Besides everybody knows that maximal separation of presentation and logic layer is always GOOD THING :-)

25.04.02SUPPLEMENT: 
Mentioned above feature of positioning the "Fortified House(s)" over the map is unfortunately available only in ANGV. In WNLB both "No.5" and "No.6" seem to be fixed like a stone in their positions. Maybe in Patch 3? For now it is one another advantage of ANGV other WNLB :-). However for these who really need some solution right now there is (as usual :) workaround available. To move that objects in WNLB one needs to change their hardcoded locations by pokeing into WNLB executable (HEX editor needed). Also as usual such method is highly version specific. For now I can only provide offsets valid in WNLB Demo:
La Haye Sainte X-position offset: 0469866(hex) original 046(hex)
La Haye Sainte Y-position offset: 0469864(hex) original 027(hex)
Frichermont   X-position offset: 0469881(hex) original 07C(hex)
Frichermont   Y-position offset: 046987F(hex) original 027(hex)
For other versions of WNLB I would suggest to search for "context hex strings":
La Haye Sainte: 56 68 8C 00 00 00 68 2C 01 00 00 6A 27 6A 46 6A 05 (hex)
Frichermont: 56 68 8C 00 00 00 68 2C 01 00 00 6A 27 6A 7C 6A 06 (hex)
Both hex strings should be very close each other - about 10 bytes apart. Having them located and taking into account example above should be easy to determine which bytes to change - just to be sure: (46h, 27h) bytes define location of object "No.5" and (7Ch, 27h) bytes determine coords of object "No.6".
09.05.02 Emergency update: Well, the offsets provided here are OK but only when one would like to work with in-memory loaded instance (process) of the game. To do the changes in the EXE file they should be adjusted by removing the leading '4' digit. That is proper on-file offset for La Haye Sainte X-coord is 069866h and similarly for next offsets. Sorry for inconvenience :(. It is the kind of mistake I used to make much to often... Good thing is that the second way (by hex string search) should work in any case (I hope that is :).
And by the way if one don't want to reposition but really get rid of the given "Fortified House" then I would suggest using out-of-map coords. I used (7Fh, 7Fh) (7Fh = 127) which is out of southern edge of Waterloo map. I did test it only playing through one medium scenario (in WNLB demo) so can not guarantee lack of any side effects - still I do believe it is going to work OK :). Another coords to try may be (FFh, FFh) that is (-1, -1).

So now we have (almost) all Waterloo map assets ready to use and it is time for switching from Austerlitz OOB and SCN files to the Waterloo ones. I was quite optimistic in that moment thinking there should be no real problem with it. That is I expceted (of course) to see riderless horses and firing Standards and total mess in the uniforms (and hats) whenever dispalyed at all - but nothing more. As usual I've used L'Arme Blanche as testing scenario. At the beginning things were going as expected: sabres were sharp, artillery strong, many horses lost their riders before fight started. In the middle of the fight however scenario bumps-out to the main screen. I repeated the test a few times with the same results. Apparently this time it was not because of the terrain. It takes me some time to realize that it was connected to the moment when French reinforcements arrive. Tweaking with SCN file I was able to isolate the unit(s) which wreaked havoc. It turned out that only light cavalrymen (hussars) are guilty. Why other (French and British) units did not make troubles? Hussars had assigned uniform ids (54 and 51) higher then Dragoons and Cuirassiers. Could it be the reason? BTW why some units have cavalry stands (wrong of course) displayed at all.? Since all Waterloo uniform ids are below the range of ANGV ids (that is below 100) all units should be phantom-like...

Apparently there was the time to dive into the process of uniform loading. At the beginning I thought that process is somewhat similar to the scenario loading: program scans some folder (bag file in case of uniforms) looking for all the files in form of xxxCAVSTAND.BMP, yyyMARCH.BMP etc., where xxx, yyy can be any number from the wide range (say something between 100 and 200 :). That would allow easy addition of new uniforms; would be enough to put newly created bitmap in right format into BAG file and then assign its number to the unit(s) in the OOB file. Man!- I'couldn't be more wrong. The ranges available for cavalry, infantry, artillery and leaders uniforms are very narrow and all existing slots are already used up. Sounds strange at first but the number of uniform slots for infantry in ANGV is smaller then in case of WNLB. Waterloo is winning 15:8 in that category. For cavalry there is almost perfect deuce. Is ANGV step back comparing to WNLB? Why it is not possible to have more slots free for use for custom campaigns and for enhancing Austerlitz campaign? It takes me some time to find resonable (I think) explanation. My only excuse is that I'm not DirectX specialist nor had I anything in common with game development (until now that is - just joking of course :-). The likely answer is PERFORMANCE. Reasonably good speed of rendering frames for screen refresh is crucial for game engine. That depends on the speed with which all the necessary sprites are scaled down and blitted into display surface. For most video cards the speed of blitting within the limits of internal video memory is orders of magnitude higher then speed of blitting between main and video memory. So the serious limitation is the size of video memory available for sprites. Some caching techniques may help, still best way is to limit total size of the sprite bitmaps trying to fit as much as possible into video memory. Part of uniform bitmaps in ANGV (especially infantry ones) are more detailed then in WNLB: there is more steps of animations; also there is no melee action bitmap in WNLB at all. So it looks like trying to fit into preset memory limit ANGV trades part of infantry uniform slots for better animation quality (there were some complaints about "cartoon-like" quality of animations in WNLB). Raising of memory limit for sprites would probably be possible but would mean also raising hardware requirements. Of course all that is pure quessing. Is there seed of truth in that reasoning we may see when WNLB Patch 3 is available. It is now high time to finish with this digression and come back to reality.

Looking into uniform sprites handling inside ANGV I found out that uniform ids lower then 100 are adjusted to the range suitable for ANGV (id > 100). That explains why some units have any (virtually random) uniform displayed. Most original Waterloo uniform id+100 fit the range of uniforms defined in ANGV. For some of them there are no uniform bitmaps in the ANGVDemo WaterArmy.BAG - these will be well-known ghost units, others are lucky enough to get some (usually odd) dressing. What with ids outside of the ANGV range? That is the case of the French Hussars. Their id (54+100) is outside the range of ANGV cavalry stands. Looks like it is enough to cause access violation and crash scenario. Oddly enough it is not the case for commander uniforms. Many ids are in that case outside of the leader bitmaps' range too. I guess the code is more fail-safe here (but didn't check it really). In fact the cavalry stands between 51-56 may be the only ones causing troubles. French infantry (ids > 8) get uniform 108 (white!) - looks odd but works.

For my own purpose I decided to do remapping of the uniform/hat ids in the batch mode. I've written PERL script (PERL is my favorite choise for the text-processing tasks like this) which do the job based on input criteria defined in the text file. I have limited myself to rather simple mapping: separate uniforms/hats for light and line infantry, heavy and light cavalry, infantry and cavalry commanders. I wanted to be certain that all units on both sides got assigned correct (and resonable looking) uniforms and hats just to be sure that any following crashes would be not connected with uniform issue. Also for the time being I removed all references to the leader portraits (all replaced by -1). Good news is that it was enough to play not only the small scenario like L'Arme Blanche but also "playtesting" a bit (not up to the gory end of course) version of the full battle scenario (I've used Duke of Richmond custom version known as Waterloo: Glory Enough For All. More about my impressions later)

The mapping mentioned above leaves a lot to be desired (lack of red coats is particulary severe :). Unfortunately renaming and direct copying of Waterloo uniform bitmaps is not feasible. The layouts of bitmaps differs, also in many cases ANGV bitmaps contain more sprites. It is certainly possible to reuse Waterloo sprites by copying them piece by piece (that process can be even somewhat automated). Holes can be filled by using the same Waterloo sprite more then once (at a price of reducing animation quality). Still there is a problem of infantry melee action bitmaps (with difficulty melee bitmaps can be recreated using Waterloo sprites from run bitmaps). But even if somebody would use all means available and adapt all Waterloo uniforms to ANGV still such ultimate solution would have to be suboptimal. As said above there is not enough slots in ANGV for all Waterloo (infantry) uniforms - some units would have to lose their beautiful dressing. In any case there is space for improvements in that area.

All the testing described until now was based on the MultiCampaign functionality as described in the MAPCREATION.txt. As far as I can tell there is the bug in the Demo which prevents direct using of that feature. I've got it working by applying quick&dirty patch. As a side effect (?) of that patch scenarios loaded in Campaign different then default are loosing right daylight conditions. They are playable but look a bit depressing :(). There is possibility to correct the bug by recoding Campaign configuration routine (another, more sophisticated patch) but it is wise to wait for the release version first - the bug may be already corrected there.
There is also another, more brute-force approach to the issue of loading custom maps (campaigns) into ANGV (or WNLB for that matter). It is almost as simple as overwriting the original ANGV OOB, SCN and MAPDATA files (and GRAPHICS bags if needed) by the versions prepared for custom campaign. To accommodate to the different map dimensions small intervention into ANGV executable is still desirable. In that case changing two bytes is all what seems to be needed - simple HEX editor should be enough. Here are the "magic" numbers for ANGVDemo:
offset=04AEAFB(hex) original=07D(hex) - to be replaced by your map X-dimension
offset=04AEB0F(hex) original=096(hex) - to be replaced by your map Y-dimension
Note that for Campaign <> 2 map dimensions provided in CONFIG file are adjusted to the range 32 < GameMap{X,Y} < 320 so it is wise to keep yours map within that range. In fact MAPCREATION.txt mentions 256 (255?) as maximal map dimention. Until now I did not test ANGV against any of the limits - anyway Waterloo map dimensions poked in the offsets provided works OK.
Another important remark is that these numbers (offsets) are highly version specific. Method should work for release version of ANGV too, but offsets will certainly differ. Moreover the same should be possible for WNLB. In that case the offsets will be different for each WNLB patch version (In WNLB Demo 049F827hex for X-dim and 049F83Dhex for Y-dim should work - but be careful as I didn't have time to really check it!). Worth to note is that in WNLB size limit against which map dimensions are tested is indeed equal 256. It may mean that abilities of ANGV were extended and it is really able to handle maps nearly as big as 16x16km (is it 10x10 miles? - always have troubles with these strange measures :-) [Actually looks as if currently the largest map which can be loaded properly into ANGV Demo is 256x320 squares. For more details see the UPPER LIMIT FOR MAP DIMENSIONS IN ANGV tip]
25.04.02 There is one another thing which may (theoretically at least) generate some unexpected effects when using the brute-force appoarch. As we know for Campaign=2 engine loads AusterlitzFog.RAW as fog file. That file seems to have the format similar to other MAPDATA files. Obvious difference is that it is binary file whereas other are text files. Yet like other files it is byte matrix with dimensions corresponding to the size of the map. In AUSTERLITZ case it is 125x150 which equals 18750 bytes - exact size of AusterlitzFog.RAW. For custom maps fog file should in theory be adjusted to the new map size. However I did not notice any problems with AUSTERLOO^TM and Waterloo map (or two other maps with yet another dimensions). In fact I do believe that (because of the way it is handled internally) the file left intact would work peacefully with any map. Still it is very possible that in that case you will see in one of your morning scenarios full-scale fog effect. I did achieve such result (see the picture below) when loaded one of Waterloo scenarios with hours put back to early morning. To avoid that side effect it seems to be enough either to remove the fog file altogether or (more elegant) create custom fog file (preferably of right size for given map) with all bytes set to zero. Note however that what in one case is side effect in another may be very welcome feature: if you need to recreate morning fog effect on part of your map now you can prepare your own fog file (well, fully-fledged map editor would be of great help here. Maybe in the future...). For full utilisation of the feature would be good to know how to define time limits for fog. Looks like FogStart, FogEnd properties are read from CONFIG file but then ignored (hmm? I need to check it again...). That would mean that fog time boundaries are now hardcoded.

FOG COVERS WATERLOO BATTLEFIELD

The picture from the opening phase of Colline de Paris scenario loaded into AUSTERLOOTM (it is cool custom WNLB scenario available at THE ANGLE site). To achieve the fog effect I changed the scenario's (and unit's entry) hours to the early morning (in fact I cut out most of units to save time). Ribbon-like appearance of the fog is (I guess) the artefact - fog file had been prepared for the 125x150 map and now is applied to the 145x100 Waterloo map.

Comparing two different roads to AUSTERLOO^TM I'd like to say that MultiCampaign way is potentially much more flexible and promising. Currently it demands to apply tricky code patch and does not support daylight conditions - instead regardless of the time of day fight goes on in the semidarkeness. These faults however may be corrected in the release version making that way the preferred method.
Main advantage of the brute-force way is that it is available right now. It is also relatively easy to use (even though it also demands pokeing into executable file). On the other hand it is rather disc space hungry and hardly can be called elegant.

Is the proposed solution for Waterloo@ANGV issue perfect? Definitely not. Is it good enough? Was it worth the efforts? It is another question. My personal answer is that - taking into account incoming ANGV release and following after it WNLB Patch - the ability to simply play a few Waterloo scenarios through ANGV right now would rather not be worth all that time invested. Not that it was no fun - it was! In fact I wasted much too much time "playtesting" myself or observing the course of battle between "friendly" and "foe" AI generals. And I'm still going to waste a bit more :-).
The real, long-lasting gains are twofold: first in the process I gathered a number of interesting insights regarding ANGV and its internals. Some of them already resulted in (hopefully) useful hints (PHEASANTRY tip, Artillery tip) others may find its application in the next ventures. Second and for me most important and promising is that the experiment described may be treated as the evaluation of ANGV' suitability as an engine for future custom-made campaigns (aka battlepacks). There is so many battles/campaigns deserving attention that BAG company itself will definitely not be able to cover all on its own. I personally will probably not be able to create such campaigns alone but hope to see (and help when possible) others in that process. From that point of view Waterloo@ANGV is just case study. Afterall using Waterloo as a test case with its maps, scenarios, OOBs and graphics - all ready to use - was rather obvious choise.

There are still few minor to severe problems and couple of things "yet-to-be-done" later. Some of them were already mentioned above but here is a full list as I see it at that moment:

1. First and foremost: There is a "Morale accounting" issue on the Allied side. It does not influence the course of battle because Allied side does lose morale as expected (and are susceptible to demoralization) - the problem is that their morale drops are not accounted as French gains on the Status Screen (other way around it works OK). This will obviously twist the final outcome of battle displayed in Afer Action Report.
2. The issue above may have something in common with another (minor) morale problem. For both British and Prussian units (major Allied nationalities) the game uses French (Eagles) morale blocks. Minor Allied nationalities have their proper morale blocks intact. Note that there are appropriate morale blocks for England and Prussia in ANGV ( MoraleBlocks.BM2. In WNLB that file is packed into WATERCMD.BAG but there is no such bag file in ANGV Demo).
3. Hougoumont complex has to be yet recreated. The reasonable approximation is definitly possible. There is also no perfect solution for Frichermont (one defensive morale bonus less).
4. Observing course of events in the full-battle scenario (Waterloo: Glory Enough For All) I'm guessing that there are some differencies between AI commanding style (the way it select its priorities and/or the way it evaluates overall situation). Particulary in ANGV AI may be stronger attracted by the (near-by?) Victory Locations (including the ones already hold by AI). That may influence playability for the largest scenarios but - after trying a few small-to-medium battles - it looks to me that issue does not matter much in smaller scenarios. In fact it was not easy for me to stop "playtest" (:-) this or that scenario and switch back to research mode.
5. Uniforms deserves much more efforts then I have spent on them. A lot can be enhanced in that area - anyway having limited (and smaller then in WNLB) number of infantry uniform slots even best Army Quartermaster will be forced to dress up some units in the suboptimal way.

Some day in the future I may return back to some of the issues listed above. Especially "morale accounting" deserves attention. Resolving it would probably help better understand the way ANGV is handling both army morale and nationality specific properties. Unfortunately this problem can easily consume lot of time and the success is not obvious. Another thing I'd like to play with is the AI behaviour in the Waterloo: Glory Enough For All scenario. I'd like to find the way to convince French AI to command in the way similar to that observed in WNLB without the need to remove all the Victory Locations hold by French forces.

Right now however I gonna take a break: enough is enough :).

25.04.02YET ANOTHER MAP TO EXAMINE THE ENGINE
Some time ago Mr. Davros published on his web page [I had left that link empty to be filled later and then forgot :(. I apologize for it to the author and anybody mislead!] current effects of his Busaco project (WNLB mod). Beside of great artwork (beautiful uniforms!) one can find also there MAPDATA files for the battlefield map. I've taken the advantage of it and checked how both MultiCampaign and brute-force appoarch work with that custom map. In both cases all looked good. The map size is 120x120 thus I had obviously to poke that values into ANGV executable in case of brute-force way. Hope the author will not have anything against posting here two pictures of his map (in fact would love to post more as that map's cool terrain features deserve it - lack of space on my web account prevents it :(). Needless to say I can't wait (as many others I suppose) to see the Busaco mod ready to be played :-). Big thanks and best wishes to the author (and all other guys working on custom campaigns)!.

Below is series of pictures from Feldmarschall Vorwaerts scenario. Battle was played in AI-vs-AI mode. My whole participation (on the Prussian side) was sending a few orders at the opening stage of battle. Note that a result of my laziness is that none of the forty Prussian cannons had taken part in the battle. In my opinion the style in which AI generals are (non)commanding their artillery is currently below medicore level. [OK. Lets face it! Gneisenau is saying it is my fault because I did not send detailed orders to individual batteries. True, but didn't I send the "Vorwaerts!" order to everybody? - I did! I think I should punish few artillery commanders to set a good example... Or maybe should I execute Gneisenau? - he is growing more and more insolent. For the meantime: "Vorwaerts!". :-)]