|
kmitahj -> RE: Reinforcements Question (NO COLCATHCART PLEASE) (12/6/2011 6:22:52 PM)
|
Having some time I took a deeper look into the mechanics. Below I describe how (I believe) it works (does not neccessary equal to "why" [:)]). However I must underscore that even though one may find exact mechanics interesting (i hope), from practical point of view the best advise to avoid troubles is - as rominet said - monitor your reinforcements list and make sure that at least a day before airgroup arrival your pool has enough planes (if neccessary downgrading temporarily one of existing groups).
Now the mechanics (apply to both sides unless stated otherwise): if the pool has not enough planes needed for newly arriving airgroup engine starts the procedure which try to figure out which replacement plane type to use based on the plane upgrade paths defined by scenario designer(s).
First procedure goes two steps up the requested plane upgrade path. If such plane upgrade is already available (as defined by aircraft avail date from scenario editor, possibly modified by R&D) and there is enough such planes in the pool job is done and incoming airgroup is auto-upgraded. If not procedure takes step back and make the same checks for a plane directly (one step) up in the requested plane upgrade path.
If both attempts fail procedure iterates over all plane types looking for one which directly upgrades to requested plane. First found (there maybe none or more then one of course) having enough planes in the pool is used to auto-downgrade airgroup.
If that step fails too procedure ends signaling failure to the engine. Here things differ for two sides. Generally speaking (there are some nuances involving nationalities of airgroup itself and HQ to which airgroup is attached to) allied airgroups for which replacement procedure failed are still mercifully allowed to enter the map using requested number of initially requested plane type. For japanese airgroup engine checks again if in pool are any planes of requested type and if so airgroup is allowed to enter a map with planes limited to the number in the pool. If pool is empty airgroup is hanging up waiting.
Now - applying the above to situation described in initial post - in CHS relevant upgrade paths look like that:
B-17D group: (none?) => B-17D => B-17E => B-24J
B-17E group: (B-18A, B-17D) => B-17E => B-24J => /self/
Assuming that "D" group was handled first (note that outcome maybe be different depending on the processing order which depends on the airgroup ids as defined by their positions in scenario editor list) procedure first goes two steps up to B-24J, finds out that model is not avail yet, backs down one step to B-17E, realise there is not enough of these planes in the pool and finally when it finds no plane type upgrade to B-17D model it signals failure to the engine which then notwithstanding allows the group to enter map with requested number of B-17D.
For "E" group procedure checks twice B-24J type (because it upgrade to itself) which as we saw already is not yet avail, and then iterating over all plane types finds that both B-18A Bolo and B-17D upgrade to B-17E. It chooses Bolo because it is first on the list (and then even if B-17D was first there is zero B-17D in the pool) and thus "E" group is auto-downgraded to Bolo...
|
|
|
|
