SITREP

[HenricE]

I'm still trying to resolve the out of sync bug that manifests in multiplayer and when replaying recordings. It's really low level stuff involving our base level pointer classes and their destruction during the game. Most of this code was written by others and so it's been a steep learning exercise for me. It's very complex. It's also all consuming. I wake up with it and go to bed very late thinking about it. I have been at the point where I thought it was solved several times now over the last few weeks. But I have still to confirm all is good. I hope to have good news later this week.

Oh man, as a developer I know that feeling all to well... Worth it in the end though! Most of the time...

 

[Dave 'Arjuna' O'Connor]

SITREP Friday 27 Jul 2018.

I have spent the last few weeks restructuring three of our foundation classes - ScenTask, ScenTaskEvent and ScenRealForce- to remove a circularity that was playing havoc with the scheduling. I believe I have resolved that. I was able to run twelve hours without an assert. So that's good enough for now. I then did a quick test to see if this has resolved the out of sync issue. Alas, it has not. I focused in on the data size being used to store the checksums and expanded these from INT to DOUBLE. But I suspect I may not have written these out to file correctly. I've asked Pavlo to review this aspect. The game goes out of sync right away now and I suspect the issue is to do with the checksum algorithm rather than any flaw in the game logic. I'm tempted to just rewrite the whole thing from scratch. But I'll await Pavlo's review before I do so. So a lot of brain draining work, but not too much to show for it. Such is the lot of complex software development. Hopefully, next week, everything will resolve in a rush.

 

[jimcarravallah]

SITREP Friday 27 Jul 2018.

I have spent the last few weeks restructuring three of our foundation classes - ScenTask, ScenTaskEvent and ScenRealForce- to remove a circularity that was playing havoc with the scheduling. I believe I have resolved that. I was able to run twelve hours without an assert. So that's good enough for now. I then did a quick test to see if this has resolved the out of sync issue. Alas, it has not. I focused in on the data size being used to store the checksums and expanded these from INT to DOUBLE. But I suspect I may not have written these out to file correctly. I've asked Pavlo to review this aspect. The game goes out of sync right away now and I suspect the issue is to do with the checksum algorithm rather than any flaw in the game logic. I'm tempted to just rewrite the whole thing from scratch. But I'll await Pavlo's review before I do so. So a lot of brain draining work, but not too much to show for it. Such is the lot of complex software development. Hopefully, next week, everything will resolve in a rush.

Thanks for the update, Dave.

The synopsis of your efforts reminds me of the instructor's first statement in my program manager's training "Software Management" module -- "You can understand the process, but the inter dependencies involved in it assure you can't manage the outcome."

 

[col.sanders]

Hope everything is working out,looking forward to the new update and Bradley at bay.

 

[Dave 'Arjuna' O'Connor]

SITREP Friday 3 Aug 2018

Pavlo advised me that the change I made previously to address the overflow in the checksum code wasn't kosher. So, I replaced the data type from 'double' to 'uint64_t'. I also finished off the changes to address the circularity issue and between the two of these managed to get the game back up and running. Previously it was going out of sync straight away. So I felt a great rush of joy when it ticked past the first minute. But then Imy hopes were dashed when at 13 minutes in it went out of sync. It's variable though. I've conducted a series of tests and the best in terms of time was two hours in. Right now, it goes out of sync after a variable amount of time. We've made some progress.

I'm up to Out of Sync Test 13. I've been trying to hone in on the exact piece of code by placing checking code inside the calls where the game goes out of sync. This approach should eventually lead me to the exact line of code causing the problem. But it hasn't worked out that way. After all these tests I've got a plethora of candidate functions and they don't repeat consistently. So, I'm now of the opinion that we have a memory leak or overwrite occurring. These can trash random bits of data. That would be consistent with all these different outcomes I'm getting at the moment.

In the past we used Virtual Leak Detector for tracking these bugs down. But the developer of that tool has abandoned it and it doesn't work with Visual Studio 2017. So I have to find another tool.

In among all this, our family dog, Rory, died. He had a good innings and his passing was easeful. We scattered his ashes on Cooleman Ridge where we used to walk each day. I miss him.

 

[Art Hall]

God Bless you Dave on the passing of Rory............its amazing the companionship those furry friends provide while never speaking a word.....he will be waiting on you down the road.

 

[col.sanders]

Very sorry for your loss of Rory,A dog truly is man's best friend.

 

[Kurt]

I feel your pain , still missing my old cat Kurt .

 

[Dave 'Arjuna' O'Connor]

SITREP Sat 18 Aug 2018

It's been a busy time. Pavlo setup data logging of events so we can better analyse the event data in order to track down this out of sync bug. We believe it's in the scheduling code. I have just finished refactoring ScheduleNextEvent(). This was a 2,000 line function. I've now broken nit up into a series of subfunctions and the main function itself is now a more digestible 500 lines of code. I've taken the opportunity to utilise an endProcess flag, which I hope to track and pinpoint the exact subFunction that's causing this issue. It's all pretty tedious stuff but hopefully will bear fruit. I've just finished building the game again with the new code and am about to test it. Fingers crossed.

 

[col.sanders]

Fingers crossed ,hope we have a break though ,we are all looking forward to this,there is no better operational level wargame on the market today,if someone knows of one i'm all ears.

 

[Rob]

Fingers crossed ,hope we have a break though ,we are all looking forward to this,there is no better operational level wargame on the market today,if someone knows of one i'm all ears.

Amen!

 

[Dave 'Arjuna' O'Connor]

SITREP Saturday 1 Sep 2018

Hi all,

I finished refactoring ther Scheduling code - well a good portion of it. It took me most of the time testing it all worked after the refactoring. Refactoring is a fancy word that basically means rewriting a bit of code to make it clearer and usually more compartmentalised. In doing so, you hope to catch erroneous processing paths. I found several of these. So that was worthwhile.

I was distracted a bit this week when my trusty old HP laser printer packed it in. I have a new one arriving, hopefully, on Monday. I also had to upgrade my laptop version of Visual Studio. It had the old 2010 version and it was no longer capable of running the autotesting because of changes in the MS OS and debugging code. I finished setting that up yesterday and now it's merrily autotesting the game with the refactored code. It's gone through nine complete games of the Tutorial without an error. So that's good.

On Monday I'll get back to testing the out of sync issue. So, no resolution just yet but I have made progress.

 

[RobearGWJ]

Thanks so much for the update! Can't wait for the payoff.

 

[col.sanders]

So what are You thinking about a release date,ballpark would be nice,I think we have all been waiting very patiently.

 

[Dave 'Arjuna' O'Connor]

SITREP Friday 7 Sep 2018

Hi all,

We're still working on this our of sync issue. What we've found this week after a lot of testing and stepping through line by line of the code, is that we either have a case where an extra event is created on playback of a recording or it's scrambling the order of the events when playing back the recording. Pavlo will be writing up some new logging code this weekend so we can identify the the specific events involved. Once we can do that we should be able to further pinpoint the specific processing code that's misbehaving.

I know this isn't what you hoped to hear. I'm pretty frustrated myself. But until we nail this issue I can't in all honesty release a new build.

 

[john connor]

Thanks Dave. Once this issue is sorted and the new build is ready, does it have the arty fixes we've spoken about, or are they still to be worked out? Plus, what's the plans for resolving the issues with the basing code to stop non-line units ending up in strange, exposed positions, especially on Move orders (HQs and bases out front, for example)? Is that done already, or is that still to happen? Thanks.

 

[col.sanders]

Well I'm on board when You hammer this out,really looking forward to the finished product.I like Your work.

 

[JArraya]

I've just picked up the game after a while and remembered why it is such an awesome game. I still have problems with some orders not getting through, especially when given at a Regimental level and I'm wondering if that's part of the fix?
Keep up the great work.

 

[jimcarravallah]

I've just picked up the game after a while and remembered why it is such an awesome game. I still have problems with some orders not getting through, especially when given at a Regimental level and I'm wondering if that's part of the fix?
Keep up the great work.

Though I'm not certain what you mean about "orders not getting through", but I suspect if they aren't being carried out as quickly as you'd like at the Regimental level, it's because of the orders delay function.

The game is set up to account for the time necessary to coordinate subordinate unit activities when you issue an order to a "commander" (in your statement, a regimental commander regiment in this case).

Known as "administrative lead time" in the planning stages of an operation, it accounts for the time necessary to work out the plan, notify sub-units of the plan, and organize and position those sub units to implement the plan.

It can run for a few minutes for a direct order to the lowest level unit (move a company) to several hours for a larger command (move a division).

Pages 147 and 148 of the game manual explains the basis and estimated times for "Orders Delay."

At the start of the game set up (pg. 11 of the game manual), orders delay can be set to different levels of reality from "none" to "painfully realistic.".

 

[JArraya]

Though I'm not certain what you mean about "orders not getting through", but I suspect if they aren't being carried out as quickly as you'd like at the Regimental level, it's because of the orders delay function.

Thanks for the reply Jim.
I’m painfully aware of orders delay and I have a good handle on it (I think). However, I have several instances where the orders simply never get executed. I can issue orders at 5 am, they will get to the HQ, the HQ will issue orders to the batallions and their task will even change, but they never move. I’ve run some test and there are instances where an entire day can pass with the units not moving. But if I issue a new order they execute (with the delay). I don’t see this very often at a battalion level, but often at a regimental level order. I believe I’ve seen this mentioned on a post before and also there are some examples on some of the YouTube videos out there. It’s definitely a repeatable bug.