Remaking campaigns to play other side (volunteers desired :)

[rbodleyscott]

Other considerations for swapping I'm guessing are these in bold at the top of BAM file (this is Stratton.BAM from the ECW):

POINTS0 300
POINTS1 200
POINTSCOOP 0
VERSION 2
DEPLOY TRUE
FLAGS 3
SIDEID0 12
SIDEID1 13

I suspect that POINTS0 and POINTS1 are the available points set in the Editor. If that is the case they don't do anything if the scenario script has Force_Points_Callback(), which overrides it. All the existing scenarios have Force_Points_Callback().

You do need to swap the SIDEIDs.

[rbodleyscott]

Is it documented anywhere what the various unit properties are? Some are immediately obvious, some aren't:

UNITTS_0_0 CORNISH_ROYALIST_PIKE
UNITX_0_0 30
UNITY_0_0 17
UNITROT_0_0 0
UNITTEAM_0_0 0
UNITFIX_0_0 TRUE
UNITST_0_0 0
UNITCAR_0_0 FALSE
UNITREINF_0_0 0

It doesn't make any immediate difference to my app to swap the sides round but it would be nice to give the Unit class attributes meaningful names...

These have nothing to do with class attributes (which are specified in the Squads.csv file), they just tell the program which type of unit to place on the map when the scenario is loaded, where and how.

UNITTS_0_0 CORNISH_ROYALIST_PIKE - the name of the unit as specified in the Squads.csv file. (This is how the program finds the unit type to load it into the scenario map, along with all its attributes derived from the squads.csv file).
UNITX_0_0 30 - the unit's X-location
UNITY_0_0 17 - the unit's Y location
UNITROT_0_0 0 - the unit's rotation
UNITTEAM_0_0 0 - the team it belongs to
UNITFIX_0_0 TRUE - whether it is Fixed or Unfixed. (Unfixed units being the ones you can spend points to "buy" in the Force selection screen).
UNITST_0_0 0 - (?)- not sure what this one is for. It may be Status, which is used in Battle Academy to keep track of unit promotions - but in P&S it is used for something else entirely - and should always be 0 at the start of the scenario.
UNITCAR_0_0 FALSE - probably whether the unit carries forward.
UNITREINF_0_0 0 - whether the unit is reinforcements.

[parmenio]

Thanks very much for the replies - most appreciated

These have nothing to do with class attributes...

Ah.... when I was talking about "class" I was using it in terms of OOP - my app has Scenario, Side and Unit classes (Classes can have methods and attributes)

[rbodleyscott]

Thanks very much for the replies - most appreciated

These have nothing to do with class attributes...

Ah.... when I was talking about "class" I was using it in terms of OOP - my app has Scenario, Side and Unit classes (Classes can have methods and attributes)

I see. You are writing an app to automatically swap the sides?

[parmenio]

I see. You are writing an app to automatically swap the sides?

Correct. It's a bit rough and ready at the moment but it swaps the [UNITS] section perfectly fine.
I just needed to know whether there was anything else that needed catering for... hence my questions yesterday.

As well as SIDEID0 and SIDEID1, I will add support for changing the POINTS0 and POINTS1 values round - the app should be generic even if all existing scenarios use the callback function.

Stratton.BAM (the only one I've played around with) now starts up with the player as Parliament - next thing is to get my head round the scripting API.

I'm guessing that I can't use AI_MasterPlan as that apparently expects the Player to be on the left-hand side of the map - I've not yet waded through the function itself to understand why.

[rbodleyscott]

I'm guessing that I can't use AI_MasterPlan as that apparently expects the Player to be on the left-hand side of the map - I've not yet waded through the function itself to understand why.

It would need extensive reprogramming to make it work the other way round, but in any case it is really only suitable for very straightforward scenarios. The vast majority of the constructed scenarios have bespoke scripting - making use of the functions provided by the engine, and the extended functions in MoreScenarioTools.BSF.

In the case of Stratton, the scripting is more artificial stupidity (making them stick to the historical "script") than artificial intelligence. I suspect that if the Parliamentarian forces used the default AI they would have a much better chance of winning!

Of course, it would presumably be possible to write an app to reverse the map completely in the .BAM file, though I wouldn't like to have to figure it out myself!

[parmenio]

It would need extensive reprogramming to make it work the other way round, but in any case it is really only suitable for very straightforward scenarios. The vast majority of the constructed scenarios have bespoke scripting - making use of the functions provided by the engine, and the extended functions in MoreScenarioTools.BSF.

Probably not worth the effort

Of course, it would presumably be possible to write an app to reverse the map completely in the .BAM file, though I wouldn't like to have to figure it out myself!

Well.... having just opened up MoreScenarioTools.BSF I immediately came across two functions with the following comments:

Code: Select all

// Function to report if enemy advance has reached y - excluding routed units - and with optional other exclusions.
// NOTE: Assumes that armies are in "standard" positions - player lined up parallel to X axis at low Y values, AI lined up parallel to X axis on high Y values. Won't be much use otherwise.
FUNCTION PlayerUnitReachedY(y, excludeFoot, excludeMounted, excludeLights)
.....

// Function to report if team member has reached y - excluding routed units - and with optional other exclusions.
// NOTE: Assumes that armies are in "standard" positions - player lined up parallel to X axis at low Y values, AI lined up parallel to X axis on high Y values. Won't be much use otherwise.
FUNCTION TeamUnitReachedY(side, team, y, excludeFoot, excludeMounted, excludeLights)
......

I'm now wondering if there are more like those then swapping the map round is potentially not a bad idea after all.... I think I can figure out the [TILES] section, but [OBJECTS] not so much at the moment. Another advantage to doing it is that I' m already finding it annoying that on scenario start the "camera" is in the "wrong" place. Is that something that can be controlled programmatically or is it determined by MAPVIEW.TXT?


EDIT: Actually those two functions are relatively simple, so providing new versions of them would be easier than working out the map definition. What I'd need to do though is find out if they're called from within any other functions....

[rbodleyscott]

Hmm, well I wrote AI_Masterplan() on the assumption that the armies would be the "usual" way round. Making it more general would have been much more complex, and unnecessary since it was primarily designed for skirmishes, which always are the same way round. I am pretty sure that those functions are not the only part of AI_Masterplan() that make this assumption. If you really want to use AI_Masterplan() (though it isn't really suitable for all scenarios - I only used it in Adwalton Moor and Naseby I think) I think reversing the map would be easier.

The camera angle always starts up looking from the bottom left corner of the map.