Welcome to the LnLP Forums and Resource Area

We have updated our forums to the latest version. If you had an account you should be able to log in and use it as before. If not please create an account and we look forward to having you as a member.

SITREP

Joined
Oct 20, 2014
Messages
1,083
Points
63
Age
74
Location
Livonia, MI (Detroit-area suburb)
The bomber campaign was not as effective as the Allies thought. The US Strategic Bombing Survey created after the war assessed that the moral bombing failed more or less completely, but also that the Germans managed to repair most of the targeted facilities until around May 1944, usually they got their refineries and plants back to like 60%-90% output, usually within weeks, sometimes even within days. The German oil production and distribution crippled as late as November 1944. Only the 1944 bomber campaign targeting oil fields in Rumania, refineries and hydrogen plants in Germany showed a lasting effect, because that campaign involved consecutive raids on those targets, where then the Germans did not manage to apply sufficient repairs, eventually. In between, most - if not all - refineries were repaired 1 - 3 times resulting in reduced output, but then stayed at a 0-15% output level, iirc, due to the power (and number) of the bombardments.
The bomber campaign was not as decisive as promised when it was initiated, but the attrition to the industrial capacity over the years took it's toll or the targeted facilities would have continued to be returned to service after May 1944 and the fuel replenishment wouldn't have ended in November 1944.

The loss of the refining capacity that couldn't be repaired after May 1944 most likely lead to the end of fuel distribution once reserves were exhausted in November of 1944.
 
Joined
Oct 20, 2014
Messages
1,083
Points
63
Age
74
Location
Livonia, MI (Detroit-area suburb)
@GoodGuy,

It is nice to see you as well. You have always been there contributing with lots of history and good discussion.

No offense, but I will elect to neither discuss the last World War or the current. (just software engineering which I feel very comfortable with)

Be well.

@jimcarravallah,

I tried HOI4 for and EU4 (about a year ago with full DLCs at that time). Actually, the only current PDS title which I am impressed with is City Skylines ... probably because the team is not theirs.

As a retired software engineer it is blatantly apparent that Johan's driving engineering effort is to write the absolute minimum code possible with the greatest amount of reuse possible such that graphics can be hung on it to make it look like a given topic. Some quick examples of this:

* EU4 features fleet mechanics coded especially for player and released in a DLC; so PDS says. So, they worked hard to give you PATROL and EXPLORE. But any programmer would realize they need such modules for the SP-AI portion of the game. So, what you really paid for in a DLC was UI screen as a combo box UI which allowed you to communicate with the pre-written fleet routines.

* HOI4 every game will need some form of positional addressing scheme. Whether a transparent fine resolution grid of CO2 or a hex grid of WITE-2. HOI4, went with a network of region nodes which probably do maintain some properties with the nodes and arcs. Additionally, both for combat simulation/political simulation a zone/state/province framework was hung on top of that. So far, nothing has gone terribly amuck in the systems modeling process ... Now, here we go ... hang on tight ... Johan is going to derail the software process in the name of improved ROI:

** The air war is also built on the same political zones for movement and operations and combat. Is there any correspondence between aircraft and/or air war that would correspond to these zones? No. Absolutely not.

** The naval war is again built on such zones. Of course, the zones since they were constructed for ground war, must by definition be divided at the coast line. So again, we end up with behaviors that have no analogue in the real world of aircraft or air war. One cannot simply assign a mission of air superiority over near inland, beaches, and coastal landing craft waters, because these are in arbitrarily separate zones. Is there anything about this that corresponds to ships or naval war in zones? No. Absolutely not.

So, why do we have zones across the entire description of battle space?

(1) Regions was probably the first and most obvious piece of a project needed by "seat of the pants" designer ... Johan. Good designers spend months modeling. Poor designers will almost immediately jump to coding, and then, the entire project becomes an effort to retrofit the project to a set of atrocious assumptions already cast in stone in the code.

(2) The realization of the need for zones was not far behind.

(3) At this point, you've done quite a bit of coding about zones and ground warfare. So, what do you do? Do you go back and come up with something new for air and naval combat so they can be recast to be consistent with zones? Systems modeling be damned, no one is going to do any additional coding. You are going to make one code base for land warfare work three times for ground, air, and sea.

This is the PDS design process; minimal coding; maximal reuse; maximal hype; demanding maximum compensation from customers.

Now if we compare this to two actual world class designers/modelers: Dave O'Connor and Gary Grigsby, we will see that logical distinct systems in the real world receive distinct modeling and handling in the game world. The goal for both designers is accurate modeling which by definition will be complex while trying to keep the complexity manageable via the availability of clean and information rich UIs along with varying degrees of automation which the player may choose to scale for their desired level of hardcore involvement. Accuracy and NOT code reuse/hype-profits are the driving motivations of these two designers. This is why these games despite being complex merit the player time investment, because there is real sense of command and operations that you can learn from ... as opposed to a sandbox which requires suspension of disbelief so at best you can treat it as an RPG and story diary game.

(the above are my personal views and conclusions ... not those of anyone else)
Thanks for the insight.

Similar to your comment to Goodguy about being a software engineer not that prone to discussing history, I won't get into discussions of which is the best approach to programming. Haven't done it, so it's difficult to discuss it.

But as a user of software, I can identify the attributes I like to see and hope a good software engineer accepts input from his / her user audience as guidance on what the coding should output.

Back in the day when my job was more or less a liaison between a user community and the software technical community, you sound like you would have been a good guy to work with.
 

Agema

Member
Joined
Jan 4, 2015
Messages
17
Points
3
Age
46
Location
UK
I tried HOI4 for and EU4 (about a year ago with full DLCs at that time).

Separate from your informative discussion of coding, that DLC model where I opt out of a lot of Paradox games. £30 for an suboptimal base game, or £120+ for something much less satisfying than four games, largely comprising a mass of mini-DLCs each costing more than they are worth.
 

GoodGuy

Member
Joined
May 20, 2015
Messages
435
Points
28
Age
52
Location
Cologne
The bomber campaign was not as decisive as promised when it was initiated, but the attrition to the industrial capacity over the years took it's toll or the targeted facilities would have continued to be returned to service after May 1944 and the fuel replenishment wouldn't have ended in November 1944.
Yes, correct, the air campaign against industrial targets proved to be a constant drain on German armament replacement/supply distribution efforts. The bombing campaign forced the Germans to move plants/production to safer areas (eg. East Germany, Bavaria, Austria or Czech). In some cases the movers took several months. So a large share of the Allied bombing effort disrupted production plans and replenishment schedules. Example from 1943: The USAAF strikes on the Messerschmitt plant in Regensburg and the ball-bearing plant in Schweinfurt (110 km east of Frankfurt) inflicted heavy damage and resulted in a somewhat serious loss of output in Schweinfurt, but Speer compensated most of the production loss by buying ball-bearings in Sweden and Switzerland, plus Germany had produced large stocks, as they knew how important they were. The factor here: time "only". The impact on tank/fighter production was marginal, I'd say, the impact on the ball-bearing production itself was mediocre, as the production output decreased by 33% for a short amount of time, at least. The bomber formation (220 B-17) sent to Schweinfurt lost 36 B-17, 27 B-17 were damaged beyond repair and used as spare part donors afterwards.

The constant repairs ate up resources and manpower ofc, where the latter was partially compensated by slave labour.
You should keep in mind that Germany's armament production output peaked in 1944, though. This was a result of streamlining designs and production lines, and - partially - of relocating some of the industrial capacity (see above) and redirecting orders to other contractors.

The loss of the refining capacity that couldn't be repaired after May 1944 most likely lead to the end of fuel distribution once reserves were exhausted in November of 1944.

In turn, the failing fuel production was a direct result of the loss of the rumanian oil fields, the loss/reduction of refinery output (Ploiesti in Romania, Rijka in Yugoslavia and German refineries) and the loss of the majority of coal hydrogenation plant output (the Germans planned to move all their hydrogenation output to protected underground facilities, but the output of the few completed underground versions remained marginal and that output didn't materialize before March/April 1945, iirc) caused by the US bombing efforts and the subsequent Soviet onslaught on the ground.

Aviation fuel: the Germans lived off of the huge aviation fuel stocks captured in France in 1940, the monthly aviation fuel production never met the actual monthly consumption for years, so that the first aerial units had to be kept on the ground as early as late 1943. Aviation fuel was still available - even in late 1944 - it was distributed unevenly and fuel reserves were held back, though, Goering hoarded large stocks in and near Berlin and at other places even in late 1944, while entire sectors and fighter units had almost zero fuel in spring or summer 1944, already.

Motor engine gasoline: The gasoline reserves captured in France gave the Germans a giant cushion during the following years, but since the production never met the demand/actual consumption and since civil consumption was allowed until 1942, the stocks started to seriously dwindle in late 1943, resulting in increasingly uneven/unreliable fuel distribution . The first major problem with fuel distribution (not production) came up in summer 1942, where an entire Corps was immobilized in Russia, iirc, because the German distribution network (and the railroad system in Russia) was congested. Only the gigantic vehicle losses of 1944 in Russia and in France lowered the consumption to a level, where the production output (almost) matched the total consumption for once in August (iirc), before the production crippled in November. Basically, the Germans had to draw from those captured stocks every month to bridge the output gap, since 1940. The stocks hit an all-time low around November '44. The Germans had to search gas stations all over Germany for remaining ("idle") gasoline and move the collected fuel to the supply storage area (set up on the right bank of the river Rhein), they had to take fuel out of vehicles/or hold back fuel from fighting units on the Eastern Front and they had to collect the meager output from operational refineries to stock enough gasoline to support the first few days of combat in the Battle of the Bulge, while still trying to supply at least some combat units in other sectors (eg. during and after Market Garden in the Netherlands). If I am not mistaken, the collection/hoarding for the "Wacht am Rhein" offensive (BFTB) took 3 months.

The majority of the German refinery facilities were "soft" versions:
I live around 1.8 miles from a refinery (Union Fuel AG back then, built in 1937, Shell nowadays) that was one of the major coal hydrogenation plants in Germany. The plant was one of the very few refineries with a small protected underground part that could still operate (or be reactivated quickly) after a bombardment, and which then guaranteed a certain minimum output, at least, afaik.
Plants in other areas were pure surface facilities, means pure soft targets, where it took quite some effort to get their output up again (until the next bombardment). The US did not focus on this industry sector (refineries processing crude oil or intermediate products and coal hydrogenation plants producing additional fuel, where the refineries were spread over 4 countries) before 1944. Two vital reasons: 1) The limited range of the escort fighters, which was was fixed in spring 1944, when fighters with external fuel tanks became the standard. 2) US Bomber Wings stationed in Italy could not be escorted to the oil fields and refineries in Romania (for the most part), Hungary and Yugoslavia, plus the focus was put on targeting armament production facilities.

The biggest hydrogenation plant in Germany, Ruhland-Schwarzheide (East Germany) was hit hard on 21 June, 1944, 100 Allied bombers heavily damaged the plant, the mission was part of Operation Frantic (shuttle bombing missions where US planes landed + rearmed in the Sovietunion). KZ inmates were forced to repair the plant after the raid, following raids knocked out the plant. At the end of the war, 75% of the plant was destroyed. The plant resided at the Eastern tip of the industrial belt that was protected by more than 1,000 AA guns and at or slightly over the range limit of regular bombing runs (where the units returned to England), until airfields that supported large bomber operations in France and Belgium became available. The Russians made the US bomber units avoid German aircraft production facilities in East Germany, as they tried to get a hold of intact facilities, in an attempt to grab samples, tools and technology for their own aviation industry.

The railroad network collapsed around November 1944, this turned the proper long distance distribution of the remaining stocks and the little refinery output that was left into an almost impossible mission.
The reason here: Allied aviation (mostly US) could now use airfields in France and Belgium and be tasked with frequent aerial tactical bombardments or fighter raids (targeting locomotives, trains, important railroad lines and railroad stations/hubs in West and Southwest Germany). The rest of the German fighter force was mostly absent, with a last serious effort put up during the Battle of the Bulge. Starting in November, the daily operation of German railroad assets involved frequent detours, moving at night only, pulling destroyed locomotives off the tracks, repairing tracks, retrieving repairable locomotives and putting derailed trains back on the tracks. Relocation of troops and armor could then easily take 4-7 days, where it used to take let's say 2 days before the campaign, for example.
 
Last edited:

GoodGuy

Member
Joined
May 20, 2015
Messages
435
Points
28
Age
52
Location
Cologne
@GoodGuy,

No offense, but I will elect to neither discuss the last World War or the current.

Be well.
No offense taken. :)
Take care!


I tried HOI4 for and EU4 (about a year ago with full DLCs at that time). Actually, the only current PDS title which I am impressed with is City Skylines ... probably because the team is not theirs.

As a retired software engineer it is blatantly apparent that Johan's driving engineering effort is to write the absolute minimum code possible with the greatest amount of reuse possible such that graphics can be hung on it to make it look like a given topic.

You wrote a perfect description of what I think the HOI series (and its programmer) is about: Milking a franchise, putting a minimum effort into fixing apparent bugs and deficiencies to calm ppl in their forums and then raise expectations (and hopes) with sequel announcements, making gullible (or hopeful) people believe that serious fixes are on the horizon, instead of fixing a large share of the bugs in the current installment. I played HOI 3 quite a bit, but I figured that the AI was so bad, fighting the AI was rather a time killer than a serious challenge. While one or another mod kind of shifted the AI to a bearable level, the unbelievably crappy naval and aerial war elements pissed me off to no end. I remember that my (new) rig struggled with long freezes during the calculations, vanilla had memory leaks (iirc) and produced weird CTDs, which forced me to redo looooong unit moves (like having to issue the same orders to 60+ units several times, due to frequent crashes).
Some of Johan's reactions to customer requests or complaints in the Paradox forums really put me off.
The HOI3 experience and the attitude towards paying customers made me avoid their products.

As you pointed out, besides Dave being a good/thorough programmer, Dave is one of the few developers who actually lend their customers/fan bases an ear (or two) to listen to suggestions, plus he's always eager to make an awesome product even more enjoyable.
I just wish he'd be able to sit back in an armchair and give orders to 5-10 capable programmers. :D
 
Last edited:

MarkShot

Member
Joined
Jun 3, 2015
Messages
266
Points
18
Age
77
Location
NYC+13,000mi
I joined in 2000 after buying RDOA. It was not simply Dave's invitation. At that time, I was convinced that Dave had discovered the future of PC gaming. Meaning not just automating board games with PCs arbitrating the complex rules, but the players would have intelligent agents acting on his/her behalf.

I've never commanded, but have project managed. And no series comes closer to what the sense of directing others all as one unified objective, and the fact that time plays a key role. I could upgrade the team to the next compiler which will make the code 20% faster, but require one month. Is that 20% boost worth the month lost to the competition relative to market share? Dave captures time or the OODA loop like no game ever has.

So, already you have two innovations which even now are revolutionary:

* Intelligent agents

* Time as part of hierarchical team efforts

Some other unique visions Dave has brought to gaming:

* The ability for the player find their own balance between the micro/macro. Now, Gary does this by letting you put entire systems on auto-pilot and editing their plans. But Gary's approach is far more course grained than Dave's. We can see this in the sense that in Gary's design you must often commit to how much automation you will use up front for the next 500 turns. In Dave's designs, you can literally change the balance on the fly.

* I have never seen a series so scalable. Most games have a natural size for which they perform well. This system is able to scale two orders of magnitude without seeing an exponential growth in complexity. This is all due to the correct modeling of command and intelligent agents. In fact, the design could in theory handle 4 orders of magnitude, but not the underlying hardware.

---

Now for me, it might be odd to hear me signing the praise of Gary Grigsby designs. As I always argued against TBS designs, but I was arguing against chess without ever exploring what someone like Gary Grigsby brings to the hobby. His designs actually range across realtime, WEGO, and TBS. Gary moves very fluidly between mechanisms and creates hybrids with can find the strength of all three. He does not capture Dave's sense of command modeling, but no one captures logistics and staff planning better than Gary. Yes, the world of wargaming is big enough for two geniuses.

---

Back to Dave. You are right he listen very avidly to players and betas. Dave finds it very hard to say "no". To be honest, this is part of the reason for extremely long delays between patches. Dave is always working very hard, but he does have trouble with "no". Of course, I only purchased one title: RDOA. But I figure Dave's personal style is his right. Dave has always put quality before $$$. I wouldn't, but it is his business.

And very rarely, Dave has said "no". When did he? We could have had a more sophisticated FOW where each unit had it own database (it would be like the CMx2v4 engine does now). Dave said "no" mainly since such fidelity would have brought mighty PCs to there knees. For supply, the supply situation in terms of the network is regularly evaluated (I think every 6 hours, but I could be wrong or out of date) ... as you see, I think, 1 minute is a game tick. Could supply have been more dynamic and evaluated on the game tick? Yes. But again the performance penalty would have been huge. So, again "no". I have never seen Dave say "no" to get paid 6 months earlier only to allow people with old to mid-range PCs to be able to enjoy the game ... if not every scenario (some scenarios just have too many units for old hardware; back at Matrix I published a set of complexity charts which showed which title was best based on your PC).

---

Finally, I want to give you a last example of how far ahead Dave and Paul were ahead of the industry. Notice no matter how busy the battle, the map scrolls as smooth as silk. No, jerky map because a big fight is on. From 1995, Dave and Paul, put the map and combat simulation in separate threads. Now that it truly visionary. Multi-cores had yet to hit the market place ... I think maybe just hyper-threading the pipeline.

---

So, I am honored having been on the team. Dave/Paul are a Sid Meier, Will Wright, Phil Steinmeyer to me ... If you bought one of these titles, you got more than just a game, but part of humanities digital legacy of art and science!
 

MarkShot

Member
Joined
Jun 3, 2015
Messages
266
Points
18
Age
77
Location
NYC+13,000mi
Thanks for the insight.

Back in the day when my job was more or less a liaison between a user community and the software technical community, you sound like you would have been a good guy to work with.

As you probably know, I have done 1,000 pages of gamer guides, but rarely community software. To celebrate 20 years of www.simtropolis.com and SC4, I just released a utility. 1,100 lines of code. No alphas, no betas, no questions (professional documentation). It is what software is supposed to be; just works out of the box and a clear simple user guide:

 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,318
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
SITREP 27 Jul 22

Hi all,

Caught some wretched flu like virus (not Covid) and was out of action for a fortnight. I've been back at this last week and have now committed my latest changes to our source repository. I am still not finished the attack overhaul. I have yet to finalise complex attacks. The general thrust for these is to do more of the code development for the subAttacks up front when developing the complex attack. This means we have to store that data in the subAttacks so the Bn HQs when they get their orders don't recreate the wheel. I have created a new subClass of ScenTask called ScenTaskAttack, which allows me to store the specific data for attack tasks. I now need to seed this data from the Approach data created inside DevelopComplexAttack2(). Then we need to test that it works.

 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,318
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
Here's the change log for the recent commit:

Build 5.1.0.45 Commit 20 Jul 22
Changes:

- FPPlanningParams - DetermineForceRatios() - excludeDuplicates no longer ignores timeStamp

- FPRouteInput - Added mIsFrontalApproach flag and mMaxTravelTicks. DetermineMapControlAvoidance() reduced avoidance mod for contested map control from 0.05 to 0.025 and for oldEnemy from 0.1 to 0.05.

- FPRouteOutput - Added mMaxTicks and CalcMaxTicks(). This function determines the max modified ticks for this route, using the full firepower and map control effects used in the A* pathing routines. Called on the frontal approach route of an attack to cap the search range of the non-frontal approach routes.

- MapSearchParams - class MapDirectPathSearchParams - added members mRouteParams, m_MoveGridsPerFPGridNumerator, m_MoveGridsPerFPGridDenominator, m_MoveGridsPerControlGridNumerator and m_MoveGridsPerControlGridDenominator. Added functions MoveGridToFPGrid(), MoveGridToControlGrid and GetTravelCost(). MapAStarSearchParams::ExpandState() now calls GetMaxTravelTicks() and if the current travel cost exceeds maxTravelTicks it stops searching that path. MapDirectPathSearchParams::GetTravelCost() added.

- PodConfig - forced specification of POD_MAX_USER_CLASSES and POD_MAX_INTERNAL_CLASSES to longs.

- ScenReceiveOrdersEvent - Added mTask member. CreateReceiveOrdersEvent() for both AI and Player now update the missionPlan's lastOrderExecutionTime to the event's execution time if this is greater than the existing lastOrderExecutionTime. Destroy() now ensures that the event is removed from mTask.

- ScenTaskEvent - ProcessEvent() now asserts that theSubject does not have a processedTaskEvent and then sets theSubject's HasProcessedTaskEvent flag to true.

- ScenForceGroupUtils - Added AssignOrganicSpt(). This is a helper function used in the attack code to assign bases and fire support units.

- ScenRealForce - Added IsSeniorSub() and IsBasedHQ() helper functions. Added mHasProcessedTaskEvent member.

- PlanAttack - Extensive revisions. Added DetermineInitialOffsetsForSubAttackTasks(), DetermineInitialEchelonOffsets(), DetermineRemainingRouteDuration(), RejectApproaches(). DestroyEmptyAttackTasks() fixed bug which left an empty reserve task. DevelopApproaches() now takes additional input paramter isComplexAttack and revises seeding of approach route details accordingly, plus factors in the remaining route duration and preferred assault range. DevelopAttack() no longer determines an assemblyLoc if it is a subAttack. We leave that to the boss.

DevelopComplexAttack2() now takes addition input parameter for nearAssemblyDefendTask. if the force is part of a coordinated attack or it will coordinate this one, then it will call DetermineInitialOffsetsForSubAttackTasks() prior to force allocation. It uses the FUP for the selected approach as the hub. It will then revise the offsetted FUPs for the additional tasks once forces have been assigned. This way the probability of being assigned to the nearest FUP is increased and hopefully stops units from crossing over.

DevelopBasicAttack() major overhaul to resequence basic attacks - ie attacks with no more than one HQ.
// We start with the FUP and work our way backwards through a series of steps.
// The intent is to move the force as one stream dropping off along the way.
// Yet we must integrate the two FGs from the attackTasks - ie assaultFG and resFG.

// We start by assigning the FGs from the assault and reserve tasks to the assaultFG and reserveFG.

// Step 1 - Determine FUP FGs
// - copy assaultFG to FUPReorgFG
// - copy FUPReorgFG to moveToFUPFG
// - determine nearFUPFG
// - subtract nearFUPFG from moveToFUPFG
// Step 2 - Determine Reserve FGs
// - copy reserveFG to moveToReserveFG
// - determine nearReserveFG
// - subtract nearReserveFG from moveToReserveFG
// - add moveToFUPFG to moveToReserveFG
// Step 3 - Determine Assembly FGs
// - copy moveToReserveFG to assemblyFG
// - copy assemblyFG to moveToAssemblyFG
// - determine nearAssemblyFG
// - subtract nearAssemblyFG from moveToAssemblyFG

// Note we need to handle cases where there is no advance route. In which case the reserveLoc
// will be the attackSubjectLoc. There maybe a reserveTask but no moveToReserve, nearReserve, assemble,
// nearAssemble or move to assemble tasks.

// We also need to handle cases where there is an advance route but everyone is near the reserveLoc.
// So again no need for moveToReserve, nearReserve, assemble, nearAssemble or move to assemble tasks.

// Similarly we can have an assemble task but no moveToAssemble task.

// To manage this we'll proceed from the front backwards, checking at each step whether we need
// to proceed or not.

DetermineMaxDesiredSlippages() now slips HHOur and End times separately. RejectApproaches() now handles separate end and HHour slippage amounts. Ditto for ResolveSlippageForApproaches(). CreateAssaultTask() assaultEnd now determined from the assaultStart forward not from the finalReorgStart backwards. This posed an artifiical constraint that caused many attacks to abandon.

SeedSpecifiedFUPApproachDetails() now determines if the HHour is self assigned and sets a new member of ScenApproach, which is subsequently used to fine tune the development of the attack. Also seeds the FUPReorgDuration and other attack timings storting these in the ScenApproach for subsequent processing. It now determines totalDuratyion as startAt + advanceDuration + FUPReorgDuration + AssaultDuration + finalReoeergDuration. Note advanceDuration covers everything from startLoc to AssemblyLoc to reserveLoc to FUP. This function also determines desiredSlippage and calls ResolveSlippageForApproaches().

Ditto for SeedInSituApproachDetails() and SeedApproachDetails().

DetermineApproachRoute() now uses a caution factor of 2.0 for all approaches instead of 3.0 for the frontal approach and 1.0 for the flank aporroaches. It also factors in exclusion areas, maxTravelTicks and isFrontalApproach. DetermineFUP() now tries to place FUP close behind forward units near the objective, rather than going back to a safe distance. SplitApproachRoute() now determines times from the start forward rather than from the planned end backwards. This prevents unnecessary abandoning due to lack of time. AdjustMoveToFUPRoute() now avoids truncating route when not necessary. DetermineMinAssaultRange() now outputs a preferred assault range as well as returning the min assault range. DetermineAndCheckMoveToFUPRoute() now bails out rather than reject a route if it needs more time. The calling function then gets an opportunity to request more time before rejecting. CreateFinalReorgTask() no longer sets the end time to the mission end. It now sets it to the start + duration. If this exceeds the assigned missionEnd the calling function will now request extra time.

ConfirmTimings() now caters for separate HHour and End slippages. AskBossToSlipPlan() now caters for separate HHour and End slippages. Revised initial asserts. Now handles cases where we don't have a required end slippage, where we don't have a required HHourSlippage, and where we have both. SeedAttackTimings() only determines maxDeploymentDuration of reserve task if it is populated. VerifyAttackTimings() fixed bug by using mStart instead of mStartAt. ConfirmAssaultTaskDetails() no longer copies the assaultFG to the task. This is done by the calling function. ConfirmIndependentTaskDetails() now sets all task timings not just the end.

DetermineReserveLoc() now determines a subReserveLoc for the frontal approach of complex attacks and sets the main reserveLoc behind it. PreAllocateSubHQs() now assigns organic support units (eg mortars) along with the Bn HQs to the sub attack tasks.

...more to follow.
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,318
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
- PlanDoctrine - GenerateAttackOption() now handles based HQ by using the location of the mainFGSubject as an alternative and the coreFG instead of the totalFG. Also getting enemy concentrations will no longer ignore the time stamp to reduce processing load. InitiateAttack() was reducing reduce engagement probability if the force was doing a secure and the targetLoc was outside its secure perimeter. However this was firing when it was still moving to the objective and thus making it harder to launch an attack on the way to the objective. It now only does so if the missionTaskType is not a Move. DetermineInitialIndependents() now exempts HQ Basing for attacks. The HQ will now move with the main force to the reserveLoc for an attack. This should stop them leading the charge.

PlanReorg - DetermineDurationToComplete() - constrains the duration to a minimum based on moveType - foot = 5 mins, mot = 2 mins.

ScenApproach - Deleted GetEarliestHHour() and GetEarliestApproachEnd(). Now handles separate HHour and End slippage.

ScenEnemyConcentration - DetermineEnemyConcentrations() now takes optional parameter for alternate subject location when HQ is based.

ScenMissionPlan - Added mLastOrderExecutionTime, IsHHourSelfAssigned() AND SetLastOrderExecutionTime(). DetermineSlippageResponse() will now return None if there is no start, end, HHour or startAt adjustments. It also fixes a bug which was leaving a gap between the end of the assault and the start of the final reorg tasks.

ScenPlanScheduling - IsMissionPlanFeasible(), DetermineMissionTask() now handle based HQ. ProcessSlipPlans() fixed bug which set the end of the objectiveTask instead of the missionTask. ProcessSlipPlan() fixed bug which continued processing when there was nothing to update. ScheduleNextTask() will no longer develop a filler mission plan if the force has just completed a temporary advance.

ScenPlanSlippage - GetMaxSlippage() - removed invalid asserts. Now slips HHour independently of End time. Ditto for DetermineCurrSlippageTask() and DetermineCurrSlippageGroup().

ScenRoute - DetermineRoute() now determines and sets the maxTicks value for frontal approaches.

ScenTask - Destroy() now kills off any related Receive Orders events. IsAttackPlanTaskType() now caters for the additional plan taskl types - kIndMoveToReservePlanTask, kIndDefendAtFUPPlanTask and kPeripheralAttackPlanTask. Added mReceiveOrderEvents, AddReceiveOrdersEvent(), RemoveReceiveOrdersEvent, IsPreHHourTask() and IsPostHHourTask(). GetEnemyConcentrations() now caters for based HQ by taking in an alternate subject location..

ScenCommonAI - DetermineRouteInput() takes additional input parameters - inMaxTravelTicks and inIsFrontalApproach. TruncateMissionRouteAndCalcValues() now caters for based HQ.

ScenTypes - Now at version 205 after adding mLastOrderExecutionTime to ScenMissionPlan, mTask to ReceiveOrdersEvent and mReceiveOrdersEvents to ScenTask, mHasProcessedTaskEvent to ScenRealForce, mMaxTicks to FPRouteOutput and ScenTaskAttack as a subClass of ScenTask. ScenEventCompare::eek:perator() revised comparison when one or both events are NOT Move events.

Scenario.vcxproj - automatically updated with new ScenTaskAttack class.

ScenScenario - ProcessNextMinute() now verifies and initialises task event processing up front. Added VerifyTaskEventProcessing() and InitialiseTaskEventProcessing()

TaskAttack - ReassessAttack() fixed bug by removing +1 minute from setting of newHHour

TaskDoctrine - ReassessTask() now caters for based HQ who are defending while the main force is moving.

TaskMove - ReassessTaskSelf() if subject's boss is based it will exclude much of the reassessment as this will be handled by the based HQ. Added ReassessMove() that is now called by the basedHQ so it can manage the reassessment.
 

MarkShot

Member
Joined
Jun 3, 2015
Messages
266
Points
18
Age
77
Location
NYC+13,000mi
Dave,

It is great to hear from you. Remember, it is not only COVID which can kill you, and when the hospitals are in the middle wave, it is hard to get other care and full work ups. (I got the impression that Australia is in its BA5 wave now.) Finally, we've met. I know how old you really are. :) So, as you always to said about ops planning, take in the big picture.

God bless you, Dave. Regards to Paul.
 
Top