Arjuna
Posts: 16448
Joined: 3/31/2003
From: Canberra, Australia
Status: online
|
SITREP 1700hrs Friday 9 Nov 2012 ( Canberra time ).
Hi all. It's been a very busy week. Monday was spent at a Defence conference but the rest of the week I have been cutting code for the patch. My focus has been to try and get to the bottom of the halting issue. After putting out a new beta build last weekend Richard observed that he was finding it hard to disengage units - ie if they had Move order to head north but had enemy to the south, then his units would Halt rather than retreat or withdraw so they could continue moving away from the enemy. I also noticed that some complex attacks were being continually slipped and the sub atack groups never moving.
So I decided to tackle the latter one as it was having the biggest impact. It's taken me all week but finally I think I have cracked this one. What was happening was that when the complex attack was developed it had the superior HQ and its arty in reserve with four different sub attack tasks. It wasn't a coordinated attack, so the sub attacks were able to select their own start times dependent on their individual orders delay. The reserve and four subAttacks tasks were all linked as concurrent tasks. When the first sub attack task began it requested aditional time to complete its Move to its FUP. This was granted by the superiorHQ and the complex attack plan slipped. Alas, because the other subAttacks had not started yet it was slipping their start by the amount requested by the first subAttack. This meant in some cases delays of four to 8 hours. It was then repeated each time the next subAttack was started. So in this case the whole attack was eventually slipped by a day and everyone sat around twiddling their thumbs.
I fixed this by ensuring that the start of concurrent tasks cannot be slipped if the sourceTask ( ie the task belonging to the original requester ) has already started. This worked a treat till an assert fired to say that the advance to the reserve task end was greater than the reserve task start. These two tasks are linked sequentially. So the start of the reserve should immidiately follow the end of the advance. So I had to ad code to prevent the slipping of any sequentially linked tasks affected by the earlier mod that prevented their start from being adjusted. I have gone through an initial test and it looks pretty good now. This should mean that big scale attacks will work effectively.
While I have also fixed a number of other bugs reported by the autotesters ( see list below ) I have run out of time to address the disengagement issue reported by Richard. I will look into this next. I have a pretty good idea of how to address this. Basically I will test for the direction of the unit and the enemy threats. If it's deemed to be moving away from them, then I will reduce the probability of it halting and either increase the prob of it retreating or ignoring the threat altogether. I need to step through the code first though.
Once I have this fixed that should be it. from me.
Paul has written some conversion code for the maps to fix an anomoly that occured on some older maps that were opriginally made with an earlier version of the MapMaker. This was affecting the base altitude layer and could have the effect of creating bad spot heights in certain places. We will have to run a conversion on all maps though.
Here is the list of fixes for this week::
- Ensure that attack are called off due to lack of time if the shortfall exceeds the assaultDuration. ( PA 10835 )
- Fix Assert in DetermineSlippageResponse() to account for cases where the FUP has been terminated and its times all set to its start. ( MSP 5511 )
- Ensure attackSubHQs determined after independents in End of Scenario attack ( PA 2343 )
- Ensure that all stored peripheral task force groups are factored into the unitCount inside VerifyPlanForceGroups() regardless of their status ( SMP 4097 )
- Modify Assert inside AssessForSubAttacksWhoseReorgsCanBeBroughtForward() to cater for cases where an attack is scheduled to start next minute while it's status is set to current. ( TA 1789 )
- Ensure that OnCallSpt forces subtracted from Independents before developing end of scenario attacks. This avoids the possibility of allocating the same unit to more than one current task - ie reserve and assault. ( SRF 16165 )
- Ensure that the start of concurrent tasks are not slipped if the sourceTask they are linked to is already current. This prevents continual slipping of complex tasks, where their starts are not coordinated. ( SMP 4228 )
- Prevent the allocation of a forceGroup subject to a task if it is not suitable. ( SFTTAR 4309 )
- Added new member to SlippageTask and modified slippage code to ignore End if nextTask is ignoring its start time. This ensures that linked tasks are slipped and cribbed correctly. ( SMP 4311 )
- Ensure that existing peripheral forceGroups are deducted from the CoreFG at the start of DevelopMissionPlan() ( SMP 4098 )
_____________________________
Dave "Arjuna" O'Connor
www.panthergames.com
|
Printable Version
RE: SITREP - 
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread