SITREP

[Arjuna]

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.

[Txema]

Hi Arjuna,

Thank you very much for your detailed report and for all the work you do on this excellent game. I really appreciate it !! [:)]

Let me ask a question. Have you been able to fix the other bugs that you reported some time ago? I am referring to the bugs reported in this post:

"As I mentioned in the other thread this week, we have a few serious issues (not related to the halting issue) but which are crashing the game. One is an XP compatibility issue which is preventing our autotesters from working. The other is a memory leak which eventually stalls or locks up the game. Another involves a major lockup or thread crash caused by an errant iterator (the pointer used to navigate lists and vectors)."

Any news on them?

Keep up the good work. I am really looking forward to the patch ![:)]


Txema

[oldspec4]

Also looking forward to the patch..

[Fishbreath]

I couldn't be gladder to hear this. No longer will sluggish units be able to mask my incompetence.

[Arjuna]

Txema,

The memory issue has proved a difficult one to pinpoint. It's turned out to be not so much a memory issue but a problem with our POD iterator class and is due to changes in the way iterators are handled by the compiler. It fires occassionally when we run the game in debug mode with iterator debugging on. Once I finish this current coding I will turn off iterator debugging and see if it still fires. If not, I think we can safely leave it. Thios may also be causing problems with XP compatibility. So we'll just have to see how this pans out once we have the game autotesting again.

[wdkruger]

If you need any extra beta-testers, I will be happy to help.

Warren

[Phoenix100]

Thanks, Dave. SITREP much appreciated.

[Arjuna]

FYI we now believe that the iterator issue is caused by how our database engine defines the end of a vector. Paul is going to trial various fixes to see if we can nail this.

[SapperAstro_MatrixForum]

Thanks for the updates. Glad to see things are moving on and appreciate your efforts to keep everyone informed.

I am really looking forward to the next patch, and even more to the CotA pack.

[Txema]

ORIGINAL: Arjuna

FYI we now believe that the iterator issue is caused by how our database engine defines the end of a vector. Paul is going to trial various fixes to see if we can nail this.

Fingers crossed [:)]

[wodin]

Thanks for the update.

[Shadrach]

Huzzah! for keeping us informed [&o]

btw, pointers, ugh I hate those things...

[Txema]

Hi Arjuna !

How is the work progressing?

Any news?

Thanks in advance !


Txema

[Arjuna]

Made good progress this week. Both Paul and I have had success stomping some key frustrating bugs. Paul has fixed one of the iterator bugs that was causing a memory leak and crashing the game. Tests indicate there is still at least another such bug. I fixed a bug in the force allocation code that was erroneously using the values of another force when assessing whether a unit should stay put or not. This too had the potential to crash and bleed memory.

I have also made some mods to the objective prioritisation code used when developing plans. I noticed that the AI was tending to allocate to many forces to friendly controlled objectives that had enemy within 3000m even though those enemy were closer to other objectives. Now the code will devalue the factors of enemy units within threat range if they are closer to other objectives. The amount they are devalued increased by the number of other objectives they are closer to. This has had a very positive impact on the momentum that an offensive force can have and sustain. So I am very pleaed with that.

It's early in the morning and my check of the autotesters reveals just two issues. Regardless, I will endeavour to put out a new beta build later today after I finish converting the COTA estabs.

So progress is being made.

[Phoenix100]

Great. Thanks dave. Are we likely to have COTA and the patch in time for my birthday - on 23rd November. I know that's the date you will have been working towards....

[Txema]

Thank you very much for the information.

I am very glad to see that good progress is being made [:)]


Txema

[Arjuna]

I have just kicked off the upload for a new beta build. This includes the conversions for the entire COTA Ex Pack files. As to whether it will be out for Phoenix's birthday well we aim to please but that will depend on a lot of things. We still have a few bugs to crush (5 that I know of right now). Fingers crossed.

FYI here are the fixes for the latest build.
Fixes:

• Prevent face changing for assaulting units and those moving in road column
• Default the task settings for ArtyDirectFireOnly to true for attacks and probes
• Added the registrationTime to remainingDuration in bombardment events. This ensures that the arty unit fires for at least the specified number of minutes.
• Now cap maxSuppression to 75% for direct fire and to 85% for indirect fire when the target is in covered terrain.
• Reduced max registration times from 15 to 5 minutes and increased the range denominator from 200 to 500. Rego time = min( 5, range / 500 ). The overall effect is to reduce registration times for arty fire. Fatigue and training can increase time by up to 56% to a max of 8 minutes.
• OnCallSpt bombardment duration now reduced if arty ammo level below 50%.
• Ensured suitability iterator updated before allocating resources to nearby objectives.
• Overhauled Halting code to reduce instances of halting.

New Features:

• Added new AssessForStalledAttack() reassessment code. It now checks to see if an attack should be called off if subordinates are halting.
• Modified the code that prioritieses objectives. If a nearby enemy ( ie one within 3000m ) is closer to another objective then its values are reduced. This has the effect of reducing the amount of friendly forces assigned to friendly objectives and helps maintain momentum in an advance.

[Phoenix100]

Fingers crossed, then.

[wodin]

Hehe..5 bugs for Dave means at least another 20 or so as he finds more while squashing those 5 or he has a to alter something else to fix the bug which then cascades..thats the problem I think..very complicated software.

[wdkruger]

Does Dave ever do public betas like WIE?