Editor HQ Type field

[Chris21wen]

I know hat the numbers mean for HQ but this field has numbers in it that I don't know. They are all associated with TOEs, 220 appear to be Japanese, 221 when Allied, 220 when it's Japanese but I also found 201, these are assigned to Aus units. Any confirm or clarify?

[Kull]

Please post a screenshot - can't figure out which editor fields you are talking about. Thanks.

[Chris21wen]

Please post a screenshot - can't figure out which editor fields you are talking about. Thanks.

Might help

Capture.JPG (19.93 KiB) Viewed 760 times

[Chris21wen]

The Aus units using 201 are ID 2702 and 2703, again TOEs.

[Kull]

That field is specifically intended to identify HQs, and I doubt that it offers any utility when used by other unit types. I agree that you can see it associated with many (but not all) of the TOE IDs, but you can also find it used by a few of the land units.

A good example of the latter are the RNZAF BF units in the 6235-6238 unit ID sequence. 5 and 6 RNZAF have 221 in the HQ field while 1 RNZAF has zero. I can't see any real difference between them, so more likely than not it's just an error. I'm not aware of the specific mechanism by which unit data was uploaded into the game, but it probably involved spreadsheets and very likely a large amount of copy-pasting-editing, during which some fields that should have been changed - weren't.

In this case, direct your attention to ID 2777. That's the TOE for the "RNZAF 43 Base Force" group. It seems VERY likely that was used as the source data for the copy-paste which resulted in the individual units. And in some cases the person doing the editing remembered to delete the unnecessary HQ number, while in others he just missed it.

In sum, it seems likely that this field was used as a harmless way to perform some sort of higher level sort in order to distinguish the TOE groups from the actual units.

[Chris21wen]

OK, got it.

Could you answer two more questions please.

Some scripts do not have an end date, mostly defence ones were you garrison bases. I'm asuming this means they never go dead? If so what state will the be in, active or are alway active of defend?

Rear gaurd the description in the editor manual makes little sense. I think it works like this. The first base listed in an Assault Bases's list acts like a trigger to restart the script if that base or any other base in that list is attacked by land?

Appreciate you help.

[Kull]

OK, got it.

Could you answer two more questions please.

First of all, this caveat: I've actively avoided looking at the in-game scripts, largely because I prefer to remain ignorant on what the AI is going to do, and even on how it operates. AndyMac is clearly the go-to expert, but that said, I took a look at the game-start Luzon scripts to try and get a feel for how they operate. WARNING: Anyone reading this who prefers to be completely ignorant on this topic should stop reading now, although the "spoilers" which follow aren't particularly egregious.

Some scripts do not have an end date, mostly defence ones were you garrison bases. I'm asuming this means they never go dead? If so what state will the be in, active or are alway active of defend?

Yes, no end date means that any units assigned to these scripts will not be harvested by some other script. As an example, script #12 (Defend PI-A) kicks in when Script #1 completes on 12/28/41. This follow-on script has no end date, and the "Defense Units" tab lists 94 specific land units and assigns each one to a single base somewhere in the Philippine archipelago. As you know, the "Tactical AI" (for lack of a better phrase) is able to respond to adjacent enemy land units (i.e. move out to attack them), but I'm pretty sure that is overridden by this script. The units located at the base will stay at that base until they are destroyed or the game ends.

I'm less certain about the associated air units. It is interesting that unlike the LCUs, assigning a fixed base for Air Units is "optional" (for LCUs it is "mandatory"). That might mean that if a specific base is not assigned in the "Air Group Units" tab that they can move among the bases listed in the "Air Group Bases" tab, but that's just a guess.

Rear gaurd the description in the editor manual makes little sense. I think it works like this. The first base listed in an Assault Bases's list acts like a trigger to restart the script if that base or any other base in that list is attacked by land?

Let's look at Script #4 (Attack Luzon 19th Division) and see what that suggests. This script has no precursor script, and does have the "Rear Guard" box checked. It is activated on 3/1/42 and expires on 12/1/42. Three of the tabs are empty (nothing listed under Air Units, Air bases, or Defense units) but there are 5 units assigned to this script ("Assault Units" tab) and a string of 16 bases on the "Assault Bases" tab, several of which are repeats. According to the manual, Assault scripts send units to every base in sequence, and in this case they start at Iba and finish at Bataan. Kind of funny because that's only 2 hexes away, so they take a roundabout path to get there! Bataan is the "Trigger Base" and usually that means the script will end once that base is captured AND the end date of the script occurs.

Anyway, knowing all this, let's see what the manual says about "Rear Guard" scripts:

"Rear Guard targets first base in assault base list that is enemy owned or occupied and will re enter Active Mode if a base in its list is captured by the enemy during its period of activity."

That seems pretty clear. Rear Guard means that - just like a normal Assault script (f/e Script #1 - Attack Luzon 14th Army) - the AI is given a list of bases to process in sequence. But unlike Script #1, the AI will proceed to the first enemy held base on the list, NOT the first base in the sequence. For example, the first four bases on the Script#4 list are Iba, Bayombong, Lingayen, and Clark Field. Let's assume that on 3/1/42 the Japanese already control the first three - in that case the Rear Guard units will proceed DIRECTLY to Clark Field. After that is taken - and assuming in this example that the Japanese hold the next 4 bases on the list, the Rear Guard won't bother with them but will march straight for the next occupied base on the list.

I'm not sure what would happen to the sequence if somehow the Allies were able to retake Base #2 (Bayombong) while also holding (for example) Base #10 (Batangas). Which would the AI go for first? Don't know, but it would definitely not rest until BOTH were taken. Well, at least until the ending date of the script!

Anyway, that is COMPLETELY different from a non-Rear Guard script. In Script #1, the Japanese units will pass through every base on the list, in sequence, all the way to the end. Once they finally arrive at and take (presumably) the Trigger Base, they will not leave that base until the script comes to an end.

Edit: Revised the "Rear Guard" paragraphs since my first explanation was inaccurate.

[Chris21wen]

Thanks for all that. Not quite sure trigger bases use end date though.

Here's my take. An active script will sequentially attack the list of assault base. Once the last base is captured the script enters it's defend state and any units assigned to the script can now be used elsewhere, but, the script is still running and can re-active using the same units dependant upon rear guard setting. The script only dies if the end date is reached or the trigger base is captured by enemy or you, however for you to kill it the 'assult trigger' box needs to be ticked. Not ticking the box means the script remains active until end date is reached.

Garrison unit are set uo every time you use the Assign to base box. Any unit set to garrison will not be considered for any other script while the script is still running (even in defend state). Not using an end date means the script is alway active hence the units will never move from they assigned bases. Tactical AI excluded.

[Kull]

Yes, I missed the significance of the "Assault Trigger" check box. If checked, it ends the script once the Trigger base is taken, regardless of whether there's an End Date or the Rear Guard is Checked. If it is NOT checked however, End Date is the driving factor.

That said, I still believe the "Rear Guard check box" sends units only toward enemy occupied bases, not those which have already been captured. In that sense it does not slavishly follow the base sequence list as does a "normal" Assault script. And it continues to look at every base on that list and will go back to capture those which have been retaken by the enemy, so long as the Script is active.

I think it would be a mistake to check the "Assault Trigger" box on Rear Guard scripts, especially those which are working in large areas. The ability to have a set of AI units permanently "on guard" in large regions like China & Burma is a level of responsiveness that I never realized the AI was capable of.

[Chris21wen]

...
That said, I still believe the "Rear Guard check box" sends units only toward enemy occupied bases, not those which have already been captured. In that sense it does not slavishly follow the base sequence list as does a "normal" Assault script. And it continues to look at every base on that list and will go back to capture those which have been retaken by the enemy, so long as the Script is active.

Not how I read it. Its talking about '...going back to capture those that have been retaken ...'. What you saying is it will pick any of the targets to attack from the list. I'll drop Anymac an email I think.

I think it would be a mistake to check the "Assault Trigger" box on Rear Guard scripts, especially those which are working in large areas. The ability to have a set of AI units permanently "on guard" in large regions like China & Burma is a level of responsiveness that I never realized the AI was capable of.

The manual description of a Trigger Base does hit at this. '... When a script dies no garrison units will deploy for atoll invasions it is often better to have a separate garrison only script without a trigger base and a sequence of small atoll invasion scripts. ....'

I beleive there should be a full stop between 'deploy. For'. All it's doing after 'for' is emphasising the difficulties for Atol.

Just what to add. All ths is about my putting together a up=to-date editor manual which I've now done, apart from a few queries, most of which can be corrected later. I'll post it today.

[Kull]

Not how I read it. Its talking about '...going back to capture those that have been retaken ...'. What you saying is it will pick any of the targets to attack from the list.

Please don't put words in my mouth. This is EXACTLY what I said:

Rear Guard means that - just like a normal Assault script (f/e Script #1 - Attack Luzon 14th Army) - the AI is given a list of bases to process in sequence. But unlike Script #1, the AI will proceed to the first enemy held base on the list, NOT the first base in the sequence. For example, the first four bases on the Script#4 list are Iba, Bayombong, Lingayen, and Clark Field. Let's assume that on 3/1/42 the Japanese already control the first three - in that case the Rear Guard units will proceed DIRECTLY to Clark Field. After that is taken - and assuming in this example that the Japanese hold the next 5 bases on the list, the Rear Guard won't bother with them but will march straight for the next occupied base on the list.

In other words, it DOES follow the list, but ONLY moving to enemy occupied bases. The only thing I'm not clear on is this:

I'm not sure what would happen to the sequence if somehow the Allies were able to retake Base #2 (Bayombong) while also holding (for example) Base #10 (Batangas). Which would the AI go for first? Don't know, but it would definitely not rest until BOTH were taken. Well, at least until the ending date of the script!

Maybe that was unclear, but it was referencing the earlier example in which the AI has moved on to Base #4, taken that, and then sees that the next occupied base on the list is not #5 through #9, but rather #10. But in the meantime the enemy has retaken Base #2. Which would it choose to go after NEXT in that case? Don't know.