Separate names with a comma.
Discussion in 'Command Ops Series' started by Dave 'Arjuna' O'Connor, Jan 15, 2015.
Minor SITREP update.
Started playtesting the first Khalkhin-Gol scenario.
SITREP 29 Apr 2019
Just put out a new build 5.1.41 to our beta testers. I've been focused on eliminating all formation lockups and overruns. Overruns are when the formation hub or a filler keep moving when the guards have stopped , thus ending up with the HQs in the front - not a good outcome. This ended up in me completely overhauling the formation movement code.
The code now uses current location rather than next location for all tests. It no longer uses the boss Indexes to determine where a subordinate should be. Rather it now calculates that on the fly every minute. I also ditched the phase line code designed to ignore the location checks unless the force was at a phase line. I was worried that these two changes would slow the game down a little, but in fact it is marginally faster now. But the most important thing is that I have not seen any more lockups or overruns. No doubt the beta testers will try and prove me wrong on that.
- FPRouteOutput - Added EndIndex to GetFirstPassableIndexWithinRange() parameters so the search can be terminated before the end of the route
- GameRecorder - Action logs - Isolated logging of Action time to debug versions as time is not recorded in release versions of the game.
- ScenEvent - ScenEvent::GetPartialMinuteExecutionTime() - added default return value of zero to prevent crash from this moribund function.
- ScenForceGroupUtils - SplitForceByReachabilityAndReasonableRangeFunction() added RequiresLineUnit parameter and if it does require a line unit then the process function will call CullNonLineUnitFGs(). This ensures that HQs and support units don't move to enemy controlled objectives without a line unit.
- PlanAttack - DevelopAttack() - If there was no reserve task it was using the subjectLoc to determine the closest point on the boss route. Now if no reserve loc it will use the FUP loc and only if it can't find that will it use the subject loc. This ensures the boss doesn't advance too far along their route when a subordinate guard is launching an attack.
- Plan Attack - ConfirmFinalReorgTaskDetails() - the final reorg task was using the assault formation's formation type but potentially changing its facing. This could see the assault companies try to advance further into enemy territory. Now it sets the formation type to inSitu to ensure the assault companies reorg on their objectives.
- PlanDefend - Added DetermineSpecialRequirements() to ensure that a line unit is allocated to a force if the objective is enemy controlled or enemy nearby. This ensures non-line units don't go moving to and defending at threatened objectives without a line unit.
- PlanMove - DevelopTaskPlanSelf() and DetermineSpecialRequirements()- Added code to ensure line units are allocated to split forceGroups if the objective is enemy controlled or enemy are nearby
- ScenTask - Added GetCurrentRouteIndex() to use the actual locatioin on the route rather than the "next" location. This is part of the formation movement overhaul.
- ScenScenario - GetTodaysFirstLight() and GetTodaysLastLight() - Ensure these handle cases where a scenario ends on a day before first light or starts on a day after last light.
- TaskMove - ReassessOptions() - Prevent AssessChangeInAdvanceFormation() or AssessChgFormationIfGuardsTired() from being called if the force has a subForce attacking
- ScenRoute - CalcRouteFromSubjectToJoinIndex() - Added a proximity margin to mitigate against culling minor loopbacks. Modified the way bossIndexes are calculated.
- ScenRoute - CalcRouteBetweenJoinAndLeaveIndex() - added assert to ensure correct bossIndexes
- ScenRoute - MustWaitForUnitAhead() and MustWaitForUnitBehind() - Use current index not next index. Factor in offsetIndexes into test.
- ScenRoute - MustWaitForOffsetUnit() - Ensure subGroups governed by order of march call MustWaitForReassessingSubordinate() and MustWaitForReactingSubordinate()
- ScenRoute - MustWaitForReassessingSubordinate() - removed redundant indexOffset parameter
- ScenRoute - CalcTempBossMoveIndex() - overhauled. Now calls GetClosestIndexToStart() and passes in the reserveLoc or FUPLoc or if nothing else the subjectLoc.
- ScenMoveEvent:: ProcessEventSelf() - Onl;y calls CalcNewUnitFormation() if not routing, retreating or halted - ie routStatus is normal.
- ScenBaseForce - Added IsRoutingRetreatingOrHalted().
- ScenPlanScheduling::CalcNewUnitFormation() - now defaults to using the task formation type if it's been specified and the unit is not routing, retreating or halted and it hasn't achieved its objective and it's not close to its objective. This prevents a lot of unnecessary changing of unit formations.
- ScenRoute - GetIndexOffset() - now used Cos() instead of Sin() to determine the effective boss offset
- ScenRoute - Added GetSubGroupIndexOffset() to calc its offset from the boss. Now all calcs are relative to the boss's route and use Cos() instead of Sin() to determine the correct distance offset.
- ScenRoute::CalcBossOffsetRoute() - now uses Cos() instead of Sin().
- ScenRoute::CanMove() - Ignore Phase Lines. Now checks offset for all subordinates not governed by order of march.
- ScenRoute::MustWaitForBoss() - Ditch use of bossIndexes. Now calc offset on the fly.
- ScenRoute::MustWaitForOffsetUnit() - Ditch use of bossIndexes and only ignore subordinates waiting on orders if they do not havce a current subject task.
- ScenRoute::IsAtOrBeyondLeaveIndex() - Now uses current subject loc instead of next route loc. All offsets determined on current locations.
- ScenRoute::IsAtOrBeyondJoinIndex() - Now uses current subject loc instead of next route loc. All offsets determined on current locations.
I have received a lot of feedback about senior HQs ending up on the front line. This has been from beta testers and general users, both here and on Steam. Now that I have the formation movement working a lot better, I did some tests and ran one of the new Bradley at Bay scenarios which has five senior HQs. After ten hours four of them ended up on the front line. these were key objectives and they didn't overrun their subordinate guards. But they did close enough to come under fire. This is not realistic. So I am going to initiate a new feature to base these senior HQs, not just for attacks, as they do now, but for all tasks. I'll do this while the beta testers are testing the latest build - a bit of concurrent activity.
Sounds like an excellent development, Dave. Thanks. Would it then be going too far to ask for similar basing code for the other types of 'rear' unit that end up out front? For bases, artillery, mortars, AT guns, for example? (Especially when they're wheeled.)
Let's just do this one step at a time. I'll get HQ's doing it right first. Then we can see about the others. There already is code to handle the basing of arty and bases. It may need to be tweaked. What I think happens is that they only move when their HQ does a move with the whole force. So I am hoping that as soon was we base the HQ, they will base too. But we'll see.
Any news ?
yep any news on the engine upgrade plz.
Dave is a bit under the weather these days, but hopefully the coding team will be able to resume their tasks soon. Meanwhile the testers and development team are tinkering away on bug hunting and scenario development. I recently took the opportunity during this lull to create another 3rd Army-Lorraine scenario (that's 6 total) covering the southern hook of the encirclement of Nancy. This scenario is designed to provide new players with a platform for learning the game concepts as U.S. attacker without worrying too much about an aggressive German defensive opponent. Or, they can step it up a bit and lock horns with one of the "Lorraine Panzer Brigades" at one of several random locations.
Anyway, hang in there, good stuff is in the works.
Dave best wishes, get better soon.
Thanks guys. I'm getting back into it. But my new medications affect my concentration. So I'm a little slower than usual right now.
Hope you are feeling better soon Dave.
JFYI, I'm getting some reasonably good results with first two Khalkhin-Gol scenarios.
Once .45 dev build is out, I think we could start some internal playtesting (because I rely upon some balancing changes/features which will only become available with the new dev build).
Sounds good. When will that be? .45?
I hope to talk with Dave later this week about how far are we with the HQ basing issue fix and whether he thinks that one is a must for .45.
It is the only remaining blocker for .45 IIRC.
I'm looking forward to my introduction to that little known (at least in US history) front, particularly as the system's official introduction to Japanese and Soviet forces in World War II.
SITREP Friday 2 Aug 2019
Sorry for the tardiness in reporting in. I have been busy working on the HQ Basing code. This is the last feature I am going to add before we put out a new public release build. It's a big change. Currently the version you have and all previous versions do not base senior HQs, except for attacks. The attack code, both the plan doctrine and tactical doctrine was changed years back. It basically hives off all HQs, senior and junior and bases them near the forming up place for an attack. That ensures they're not on the firing line and in harms way during the assault. I had wanted to write more comprehensive HQ basing code for all mission types. But it's a lot of work. So I begged off then.
The current new code will address Move and Defend missions. It will only apply to senior HQs - ie Brigade and above. I've just finished writing the plan doctrine for this. When the AI develops a plan for a Defend or Move it will test to see if the subject of the force is a senior HQ. If it is, it will then determine whether it can find a safe location within effective command range of the objective and if so it will subtract the subject from the main force group and assign it an independent HQ basing task at that location.
Sounds simple enough, right? Wrong. I want to avoid cases of HQs moving around the map independently through unsafe territory. So I have chosen to limit the search for suitable locations to the appropriate mission route and adjacent locs. It will try the mission task route first, then the subject to objective route, creating this if not already generated, followed by the main supply route - ie supply source to objective. The trouble is none of these may be safe at the moment when the plan is developed but may become so as the force advances. So there's a plethora of cases to be handled. I've been progressively working my way through these and adding smarts to handle them with the aim of basing the HQ if at all possible. It will stay put, if it's safe and it can cover a goodly portion of the chosen route. Otherwise it will default to the current practice and advance or deploy with the main force.
So that's where we are up to at the moment. That's all well and good, but what I now need to do is write code to reassess and move the HQ forward as the main force clears the route or reaches the objective. I also need to handle all the scheduling and status code that currently relies on the mission subject being the subject of the main force group, which will no longer be the case. I know it's been a while, but it's going to be a bit longer. I thank you for your patience.
In the meantime Pavlo (ioncore) is ploughing ahead with his new Khalkhin-Gol scenarios, not to mention fixing, tweaking and enhancing other aspects of the game code. Testing is also progressing on the Bradley at Bay scenarios.
That's great news all around Dave!
To give you an example of where we are this new HQ Basing feature, check out this screen dump. Note the senior HQ is now based where it started from and the rest of the force (its three battalions) are moving along the road.
So far so good. I now need to write some scheduling code and reassessment code to make this all work properly. But we are getting there.
Bravo, Dave! Really looking forward to testing this. Great job that you've taken it on, as some aspects of HQ behaviour were certainly long a source of issues due to ending up in the firing line a bit too often. Thanks. Peter