SITREP
Posted: Tue Oct 16, 2012 9:31 am
Hi all,
I have been slogging away for what seems like ages but am now seeing the light at the end of the tunnel. I have been working to fix the so called "halting" issue. This has involved a lot of painstaking maticulous work stepping through code. What in the end I discovered was that changes I had made to the attack code had caused a few sequencing and scheduling issues.
By way of example, the attack timings were being confirmed prior to some of the plan tasks having their location confirmed. Thus their route would change and so would the duration it would take. This could cause excessive slipping and issuing of orders, during which the forces remained where they were. Timings are now confirmed after all tasks have been confirmed.
In the process I discovered that the function to determine the reserve location, which is dependent on the location of the FUP was now being processed before the FUP was determined. Hence it was invariable falling back to a default routine. This routine has an error in the offset it applied to the direction the reserveLoc should be relative to the objectiveLoc. This was in some case puttiung it on the far side of the objective. So the poor hapless HQ and mortars would head off into enemy territory all by themselves. Not good!. I have fixed this, both by ensuring the FUP is determined first and by fixing the offset error.
In fixing this issue I have also taken the opportunity to position the reserveLoc a certain distance from the FUP back along the route used by the assault team to get to the FUP. That way its in safer location. To get this to work for the subAttacks of complex attacks ( eg when a Bde HQ orders its subordinate Bns to mount their own attacks ) I now copy the approach routes to the subAttacks rather than have the subordinates redetermine them when they recceive orders. I did it this way previously because the subordinate would often move in the meantime. Now I have added smarts to adjust the route based on the subordinates current loc when he receives the orders. The good thing about all this is that fewer route calcs are now bein done and that helps performance.
By this afternoon I was able to run the turorial through to the end of Day 3 before I hit another problem to do with the confirmation of the attack timings. Tomorrow I'll step through and fix this. It's probably something I haven't taken care of properly in my recent changes. Buit overall, the attacks were well planned and executed with the American forces maintaining pretty good momentum. I didn't see any halting at all. So I am very happy with that. [:)]
Hopefully tomorrow I will be able to have it play right through the Tutorial. Then I'll set to with the autotesters prior to releasing a new debug build for the beta testers to work through. So we are making progress. Sorry for the delay.
I have been slogging away for what seems like ages but am now seeing the light at the end of the tunnel. I have been working to fix the so called "halting" issue. This has involved a lot of painstaking maticulous work stepping through code. What in the end I discovered was that changes I had made to the attack code had caused a few sequencing and scheduling issues.
By way of example, the attack timings were being confirmed prior to some of the plan tasks having their location confirmed. Thus their route would change and so would the duration it would take. This could cause excessive slipping and issuing of orders, during which the forces remained where they were. Timings are now confirmed after all tasks have been confirmed.
In the process I discovered that the function to determine the reserve location, which is dependent on the location of the FUP was now being processed before the FUP was determined. Hence it was invariable falling back to a default routine. This routine has an error in the offset it applied to the direction the reserveLoc should be relative to the objectiveLoc. This was in some case puttiung it on the far side of the objective. So the poor hapless HQ and mortars would head off into enemy territory all by themselves. Not good!. I have fixed this, both by ensuring the FUP is determined first and by fixing the offset error.
In fixing this issue I have also taken the opportunity to position the reserveLoc a certain distance from the FUP back along the route used by the assault team to get to the FUP. That way its in safer location. To get this to work for the subAttacks of complex attacks ( eg when a Bde HQ orders its subordinate Bns to mount their own attacks ) I now copy the approach routes to the subAttacks rather than have the subordinates redetermine them when they recceive orders. I did it this way previously because the subordinate would often move in the meantime. Now I have added smarts to adjust the route based on the subordinates current loc when he receives the orders. The good thing about all this is that fewer route calcs are now bein done and that helps performance.
By this afternoon I was able to run the turorial through to the end of Day 3 before I hit another problem to do with the confirmation of the attack timings. Tomorrow I'll step through and fix this. It's probably something I haven't taken care of properly in my recent changes. Buit overall, the attacks were well planned and executed with the American forces maintaining pretty good momentum. I didn't see any halting at all. So I am very happy with that. [:)]
Hopefully tomorrow I will be able to have it play right through the Tutorial. Then I'll set to with the autotesters prior to releasing a new debug build for the beta testers to work through. So we are making progress. Sorry for the delay.
