Search This Blog

Monday, December 9, 2013

HUGE campaign update on the way for BOBII

For BOBII officionados, there is plenty on the way in patch 2.13.

A WIP update posted on the beta testing forum recently by campaign modder Two27 (Randy) shows just how much work has been done so far. Enjoy!

+++++

Rowan was confronted with the need to provide special handling for virtual units destroyed in 3D, but was constrained by the limitations of the variables available in that bit of code. The parent unit diary variables can be made available (I tested this.). However, without knowing the casualty detail of the sister Staffeln, the diary variables can't be used (data without context). There would be no way to know which Staffel owned which of the accumulated parent unit diary casualties. Only the package/virtual unit variables were usable. This was the immediate cause of the 3/4-1/4 coding. Basically, they faced a choice of cheating one side or the other, because of the limited variables they could lay hands on. To understand this requires looking at the variables available and reliable in this function.

Useable:
* numacoriginal = count of original AC in this virtual unit
* numacleft = operational aircraft remaining, some of which may be lightly damaged
* numacditched = number of aircraft no longer operational, includes shot down, writeoffs, and heavily damaged aircraft
* numacrecoveredlow = lightly damaged AC
* numacrecoverdmed = badly damaged AC
* numacrecoveredbad = writeoffs

Useless in this function (no context):
* numlosses = shot down outright
* numacdamaged = all damaged aircraft, light, heavy, and writeoffs

There are exclusions and overlaps among these variables.
Useable:
* numacditched = shot down outright + writeoffs + heavily damaged (these are aircraft out of the fight and can't be spawned into a new 3D session)
* numacrecoveredlow = lightly damaged, still in combat, can be spawned in a new 3D session
* numacrecoverdmed = heavily damaged aircraft, out of the fight, can not be spawned into a new 3D session
* numacrecoveredbad = writeoffs, basically heavily damaged, can not be repaired, potentially can be rebuilt, out of combat, not shot down outright, can not be spawned into a new 3D session

Useless in this function (no context):
* numlosses is ONLY the AC shot down outright. It does not include writeoffs.
* numacdamaged is ALL damaged aircraft regardless of degree.


Conversions
* numlosses will always be counted in ditched
* numacdamaged is an aggregate coming out of 3D and must be broken up into types (light, heavy, writeoff) in report handling
* numacditched = numlosses + numacdamaged – numacrecoveredlow
* numacditched = numlosses + numacrecoveredbad + numacrecoverdmed

Bottom line
* an AC can be ditched and not shotdown
* an AC can be damaged and either flyable (light) or not flyable (heavy, writeoff)
* an AC can be damaged AND destroyed (writeoff)
* and AC can be ditched and repairable (heavy)

Since an aircraft can be destroyed for 3D purposes and remain flyable and repairable, Rowan faced a dilema. 
Without accessing the parent unit's diary and the detail data for all sister units of the same parent unavailable, how to allocate casualties? 
Their solution 3/4-1/4, assuming 75% were shot down outright and the remainder were damaged enough to require repair. 
After all the reseach I've done surrounding this code and the code prior to and following, I agree with their decision. 
Cheat the losing force by denying them repairs of critical aircraft or cheat the shooter by allowing nominally "destroyed" aircraft to be repaired.

The current version changes the allocation so all are counted as destroyed, but 25% are write off candidates. 
This still permits some chance of getting the AC back, while crediting them as kills. 
I am leaning toward the possibility of increasing the write off percentage to 40% so the losing side has a better chance of recovering AC destroyed in this manner.

/ / /

Ready for testing:
Rewritten pertinent AUTOSAG_DESTROYED code and all of ApplyDiaryLosses(int). I have faith in the reliability of the 3D-to-2D code now. 
Other than the discrepancy revealed by the now reliable reports, it is sound. So the remaining problems are both upstream and downstream of the 3D casualty code (ApplyDiaryLosses(int)).

Another change is removal of assigned target dogleg points resulting in direct raid path plotting for LW missions. 
A temporary fix for the periodic absurd raid paths until I can get to learning the coordinate system and plot all the extant points coded by Rowan.

I've tested these changes extensively and believe I've caught all the bugs. Other eyes welcome.

If you are testing 3D combat using this file, please do the following.
After each 3D combat, rename the 3d_diary.txt file to something unique, then delete the original. It will regenerate each time needed. Feel free to look through the output files, 
but please please don't modify them. Post links to the output files so I can see how things are going. Remember there is a newly discovered error once a virtual unit is destroyed in 3D.

If you'd like to discuss combat results, I've developed my own shorthand so I can write everything down quickly for comparison. Try using nX nD. X is number destroyed, D is damaged.

Multiple fragins of same combat: The new 3D casualty code includes handling of multiple fragins, or so I believe. I've not tested that element yet. 
While the manual will discourage multiple fragins, I decided I'd best be prepared, because instructions and manual just get in the way for some people.

Newly revealed 3D bug: As a refresher, consider that RAF units always scramble with a 1-to-1 ratio; there is one and only one virtual unit created from a parent unit in any package. 
LW can have 1-to-many relationships and therein lies the new problem. Suppose three Staffeln of level bombers are sent on a raid. 
Three virtual units are created in the package and all share the same parent Gruppe. When a virtual unit, say 3 Staffeln is destroyed, its flag is set to destroyed. Once destroyed, 
it can not have any more casualties allocated at the package virtual unit level; similarly it is not processed upon landing for report outputs. All good to this point. 
The problem arises from the how the complete flag is setting. For some reason the code is setting the complete flag for all sister units of the same parent. 
These sister Staffeln can be allocated casualties at the parent unit level and the new code will process these new casualties into the virtual unit detail variables. 
However, since the unit is flagged destroyed, those new casualties will never get processed upon landing into the Review reports or see the writeoff code for determining which writeoff aircraft get sent to rebuild.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

c02_212

This test exe adds the fix for units being excluded from 3d reports because one or more virtual units in the package was destroyed.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

c03_212

Escort Rendezvous fixed!

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

c04_212

A funny thing happened on the way to Lympne . . .

With takeoff times working, I thought it'd be a good idea to back out my earlier changes involving detached escorts. These are 65a, b, and c. 
Only one change remains and that forces detached to fly in a block rather than Schwarme so they are easier to count.
I ran three raids, two using detached and one as attached. It looks like we need to rethink what is wrong with escorts in 3d. 
Getting the takeoff and rendezvous right changes just about everything we think we know about 3d escorts.

Also as per stickman's request, Escorts no longer have the Strafe Target option ON by default.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

c05_212

I "think" I solved both the LW Task Summary spinner issues.
*Bombers will now allocate and de-allocate properly. As part of this I standardized bomber Staffeln to 10 AC. 
Some parts of the code used 10 and others 12. One used both for bombers. Since the different functions were not aware of the others' behavior, really odd things could happen.
*Fighters spinner now working. Previously in some cases both 109 and 110 Gruppen could only send up a max of 8 AC.

There may be more problems in Task data handling. Fix one, find one has been a general rule. With these two fixed, we may well find other issues now revealed

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Test version c06_212

Changes:

All of the above plus:

Randomized fighter rendezvous. I couldn't find the date of the order for rendezvous over fighter fields, so chose 5% as best fit over the course of the battle. 
For bad rendezvous times am using original takeoff time code so they will take off same time as bombers.

RAF delayed activation for 302, 303, 310, 312. Added 312 in place of 245 which was in Ireland.

LW 109 consolidation mostly done. Still need to modify for later campaign start dates.

[color=#FFFF00]============================================================================================================================[/color]

Randy's brief summary of the changes above:

1. Changed 263 Sq markings to correct HE letter codes for MultiSkin.

2. Removed hard coded LuftWaffe Dogleg Way Points from aircraft factory and fighter field Targets.
These Targets should now have the Dogleg Way Point in a straight path from the Fighter Rendezvous Way Point to the Initial Way Point to Target.

3. Rewrote 3d-to-2d report data. New code for when a virtual unit (squadron or Staffel) is destroyed in 3d. 
Removed code that was setting all VU's in a package to complete when one VU was destroyed in 3d. 
To the extent I was able to test, the 3d reports are now accurate. Note that it is possible for the 2d combat code to run prior to and after exiting 3d. 
This accounts for any “drift” from results the player observes in 3d.

4. The RAF and LW skill variables in Options-Sim-Mission are now live in the campaign. Default setting for both is Medium resulting in no change.

5.  LW fighter rendezvous with bombers works now!
Changed the Fighter escort time of take off relative to bomber takeoff time to do this. So far as tested, this can work 100% successfully of the time.
100% rendezvous succes unrealistic, so implemented a fixed 5% failure rate resulting in missed rendezvous.
When a fighter unit does fail to rendezvous properly, it uses old Rowan code whereas the fighter unit goes to Target many minutes ahead of Raid bombers,
leaving the bombers far behind.

6. Changed LW detached escorts to use a block formation and not the Schwarme so the AC are easier to count in 3d.

7. In LW Directives, no major changes, but commented out most of the code dealing with the old Reconn flights. 
Basic preparation of clearing clutter prior to examining LW Directives in detail. Reconn elements in the Directives dialog are now dead. 
The check boxes can be marked and unmarked, but all four controls have no inputs to the code now.

8. In LuftWaffe Directives and the Task dialogs, the Raid Escorts are given a choice to Strafe Target or not.
This has previously been set ON to Strafe Target by default, which often results in very unrealistic escort behavior, especially from normally default given high altitudes for a Raid.
Now Strafe Target is set OFF by default. Can still be switched to On by the LW player.

9. LW Task Summary dialog fighter and bomber spinner issues now resolved. 26 individual changes and rewrites. 
Mystery LW unit lockouts removed. Both fighter and bomber spinners now work properly. Standardized bomber Staffeln to 10AC in all cases, even 110Jabo. 
Code adding and removing Staffeln will now add and subtract the correct number of Staffeln and number of aircraft. 
The only LW unit lockouts are those we know about, unit use, low morale, and minAC. 
If a unit is available for use, Task Summary will allow its allocation to missions without restriction.

10.  Substituted 312 Sq (Czech) for 245 Sq which was in Ireland during the battle. 312 located at Duxford and squadron markings of DX.
Like the LW OOB changes, 312 Squadron will still carry the original 245 label. Used 310 Squadron unit skill and morale, Veteran skill and Excellent morale.

11. RAF delayed activation now live. 302 – 7/13, 303 – 7/22, 310 – 8/18, 312 – 8/29. These units will have 0 AC until activation. 
Prior to activation they can not be moved by the AI or receive new aircraft whether newly built or rebuilt.

12. LW AC consolidation code for 109s is working. All LF3 109 Gruppen are candidates. 
When a LF2 109 Gruppe drops below minAC, a check is made to see if a LF3 Gruppe is available (has activated and still has aircraft). 
If so, then the losing LF3 Gruppe's aircraft and pilots are divided among the three neediest LF2 109 Gruppen. Skill and morale are recalculated. 
At any campaign start date beyond 10 July, some LF3 Gruppen will be assumed to have been used up already. 
Radar campaign -3 LF3 Gruppen. Airfield campaign -5 LF3 Gruppen, and Blitz -8 Gruppen.

Example from 7 September Blitz start. Eight of the LF3's 109 units have 0 aircraft.
http://s1140.photobucket.com/user/charge62/media/c07/LW_res_consolidate_zps9fc52948.jpg.html
The game behavior looks good. Am considering expanding this to all AC types, and extending the 109 code to consolidate among LF2 Gruppen once all LF3 Gruppen used up.

13. Geschwader list dialog Category spinner will now increment from A to C, rather than C to A.

14. Geschwader list and Squadron list Ready column now live. RAF will see readiness time, “Mission” if assigned to mission or actually in flight, “Released”, or if 13 Gr “Resting.” 
For LW only had two character width to work with so chose a simplified set of indicators that should work across all languages. "+" indicates unit ready for action. "-" indicates unit is unavailable for some reason (unit use lockout, low morale, min AC, or on mission). 
A blank indicates the unit is either not activated yet or its aircraft have been used as part of consolidation.
http://s1140.photobucket.com/user/charge62/media/c07/RAF_Sqdlist_rdy2_zps2df28996.jpg.html?sort=3&o=2
http://s1140.photobucket.com/user/charge62/media/c07/LW_Gesch_rdy_zpsa1d209e1.jpg.html?sort=3&o=4

15. Activity (readiness) line also updating correctly on Squadron detail and Gruppe detail dialogs.
http://s1140.photobucket.com/user/charge62/media/c07/RAF_Sqdetail_13_zps7168475c.jpg.html
http://s1140.photobucket.com/user/charge62/media/c07/RAF_Sqdetail_mission_zps32518639.jpg.html

16. Extended the abbreviations used on Geschwader List dialog and added some localized text to help understand the meaning.
http://s1140.photobucket.com/user/charge62/media/c07/LW_Gruppe_ready_zpsf53b6c01.jpg.html?sort=3&o=7
http://s1140.photobucket.com/user/charge62/media/c07/LW_Gruppe_inactive_zps6155ee1d.jpg.html?sort=3&o=6
http://s1140.photobucket.com/user/charge62/media/c07/LW_Gruppe_unavail_zps4b4e8484.jpg.html?sort=3&o=0

17. Was unable to get LW airfields to display tabs for each assigned Gruppe like RAF player sees. Instead chose to use the existing Fighter and Bomber buttons. Changed their captions, help text, and functionality so they'll pull the Gruppe detail dialog for Gruppe 1 and Gruppe 2. Gruppe 1 button will be alone if only single Gruppe on the field.
http://s1140.photobucket.com/user/charge62/media/c07/LW_field_1_zps10eab4ab.jpg.html?sort=3&o=8
http://s1140.photobucket.com/user/charge62/media/c07/LW_field_2_zpsd70e7108.jpg.html?sort=3&o=5

Have begun changing the BoB2_ver.txt file so you can tell which .exe you are running. Won't appear on the splash screen.

Update, 27 June ------------------------------------------------------------------------------------------------------------------------------------------------

Last code version c07b_212:

1. Changed Duxford capacity to 3 squadrons. Don't know how AC takeoff spots look.

2. Corrected for potential hang if all Staffeln of a Gruppe destroyed in 3d and if diary is too messed up to be used.

3. Finally, if you recall back in 2011 Sean was complaining about RAF continuing to fight when it should have reached 0 AC. During testing for the problem above, I noticed something strange and it took a while to work it out and then find a solution. I know why the RAF continued to fly when it had no AC. Rowan clearly considered how to update report data when a virtual unit was destroyed. What they didn't write any code for was to tell the losing unit that it had lost those AC and their pilots. Hard to figure out code when it's just plain missing. It is fixed.

No comments:

Post a Comment