BFTB Build 4.4.260

[Arjuna]

Hi all,

I am uploading to Matrix a new build (4.4.260). In due course they will make it available as another public beta build. The fixes are below.

Please note that I was going to make this a final for the patch #4 but we have had some crashes on some XP autotest machines managed by one of our beta testers. I have not been able to repeat the crash on my Win 7 dev machine and I don't have an XP machine anymore. I believe the cause is probably an incompatible debug dll file. These get included in our debug builds which are used for autotesting. We had a similar problem before. But just to make sure I am releasing this release version as a public beta and request any XP users out there to please download and test and report back to me in this thread whether it ran fine or you had problems - either way I'd like to know.

Here are the fixes for Build 4.4.260:

• Ensure that StartAtDelayType is passed down through all scheduling code. This prevents attacking forces from waiting at the start of their FUP Reorg. Note this anomaly only affected attacks ordered by human players and did not apply to AI launched attacks.
• Increase max tick count of routes. This addresses Assert at MapVisitTable.cpp 328
• Use PodDoubles to eliminate data overflow inside ScenDump::ModifyPayloadSupplyQuantities(). Fixes assert at PodFloat.inl, line 277.
• Decreased the probability of supply lines being cut.
• Players' orders are disabled while Terrain Tables are recalculated. Player (or players, if it's a multiplayer game) is notified of this via a High Priority report. While the player can't issue any new orders, it is allowed to inspect units and tasks data. Once the Terrain Tables have been stabilizied and all on-going tasks adjusted accordingly, the player is notified that further orders can be issued. This fixes potential crashes after crossings are upgraded or degraded.
• Revised the handling of user-defined H Hours when mission plans are generated and slip to ensure task timings are consistent.
• Fixed a check on user-defined H Hours which under certain conditions deemed a player order with a feasible plan to be unfeasible due to timing constraints.
• Improved task duration estimation for all orders involving movement and assaults.
• H Hour Auto checkbox disabled once assaults are underway.
• Threat assessments for HQs and support units are now ignored if the Bypass option is unchecked on the order settings.

[Remmes]

Thanks again for the hard work Arjuna!

[dazkaz15]

Thanks Dave [:)]

[gabeeg]

...I just love this game.

[Txema]

Arjuna,

Thank you very much for all your work on Command Ops !!

Just one question. In other thread you said:

"As a compromise I have added a check to see if Bypass is allowed. If not then the threat assessment for HQs and support units will be ignored. By default Bypass is allowed for AI controlled forces. So as a human user you can simply uncheck the Bypass option on your task and it will ignore the threat assessment. Eventually I want to add its own task option but that can wait for now."

But this does not seem to appear in the list of fixes for Build 4.4.260... Have you finally included this workaround in Build 4.4.260?


Txema

[Arjuna]

Yes it's there. Good catch. I forgot to add it to the list of fixes. My apologies.

[Txema]

Thank you very much, Arjuna.

You are doing a really great work with this sim.

You have a customer here for a lot of years [:)]


Txema

[Jafele]

Thanks Dave, the game is becoming spectacular [&o]. There´s no doubt: Common sense+Hard work=Quality

[dazkaz15]

Just a few minor issues so far. Well minor if you think not being able to coordinate attacks is minor.

1, The bombard footprint is still open ended, no big deal this one.
2, 23 hours is put in for the default bombardment time now, but can be changed by the user so no big deal, just in convenient.
3, Units still slip time on their way to the reserve, and FUP for no good reason that I can find. (time set well in advance)
4, Bigger problem is that when they do this for a coordinated attack you can't adjust the time of the other Battalions you are trying to coordinate with, because the time just springs back again to what was set originally.
This means that reliably coordinating attacks is impossible now.

Not had any issues apart from these so far., in about two hours of game play.

[navwarcol]

ORIGINAL: dazkaz15

Just a few minor issues so far. Well minor if you think not being able to coordinate attacks is minor.

1, The bombard footprint is still open ended, no big deal this one.
2, 23 hours is put in for the default bombardment time now, but can be changed by the user so no big deal, just in convenient.
3, Units still slip time on their way to the reserve, and FUP for no good reason that I can find. (time set well in advance)
4, Bigger problem is that when they do this for a coordinated attack you can't adjust the time of the other Battalions you are trying to coordinate with, because the time just springs back again to what was set originally.
This means that reliably coordinating attacks is impossible now.

Not had any issues apart from these so far., in about two hours of game play.

The bombardment time is now set to end of scenario, but this issue was raised in tech support thread, and they have already solved it for the next patch.
I have not been able to get your #3 or #4 to happen, so I am wondering if there is something I am not doing.. are you just doing a normal regiment style coordinated attack and having it happen? I think it happened a few times to me before this patch, but have not yet had it happen in this one...

[Phoenix100]

Bigger problem is that when they do this for a coordinated attack you can't adjust the time of the other Battalions you are trying to coordinate with, because the time just springs back again to what was set originally.
This means that reliably coordinating attacks is impossible now. (Daz)

The bombardment time is now set to end of scenario, but this issue was raised in tech support thread, and they have already solved it for the next patch. (Navwarcol)

Well, I've found that the issue Daz raises about the time springing back definitely happens for me AND it happens with the bombard order also (exact same thing) - plus, unless you leave the bombard at the default settings (end of scenario) it often doesn't happen at all, time just ticks away with nothing firing. And if you change it, it frequently skips back to the original setting (so it's more than an inconvenience, Daz) - exactly as the time does now with coordinated attacks, so you can't set anything meaningful. I've had to cancel bombards and just start again, leaving the default settings and cancelling later. But even then it has been taking ages for units to start firing - as if there was suddenly orders delay on bombards (like 20 minute wait, I mean). It's true that the bombard prob was spotted and fixed - but was this aspect fixed, if the same behavious shows when setting attack times? Surely there has to be a link - something broke with setting timings generally?

Edit - I noticed the above in a multiplayer game and on testing in single player I cannot get the delay point to reproduce. ie; the bomabrds go in ok, but if you try to change duration the time just clicks back to that originally set (same issue as with attack at?)

[dazkaz15]

I hadn't realised that the bombard order was springing back as I just deleted them after the first time I thought I had turned it down, sorry about the misinformation there.

Ill set about re-creating, and screen dumping the images of the coordination problem later, with save game at the various screen dumps, then you can tell me which ones you need.

[dazkaz15]

Image 1

[dazkaz15]

image 2

[Arjuna]

OK so these are not one attack order with three Bns but three separate attack orders each of one Bn. In such an arrangement we don't have alogical link between the attacks, so there is no possibility of coordinated slipping and cribbing of timings. To support that would be a new feature and require more effort. I am not going to hold up on the final patch #4 for that. It's something we can look to later. The best thing can be done is to not allow any slipping or cribbing if the user sets the HHour. However, if not enough time has been allowed then it will abandon. Even doing this will take some time to set up and test. I would prefer to add this to our list of things to do as we progress after the final patch #4.

[Arjuna]

Re Bombardment Durations. One common misunderstanding is that you need to factor in registration times. It takes time for an indirect arty unit to register the target. In RL this means adjusting the aim of the guns, firing of one registration round, observing it, reporting back its impact loc, making an adjustment and then firing a second registration round. This process repeats till a round is on target. Typically it can take five minutes. So if you don't allow for this process when you set the time the task will end before the arty can fire for effect and hence you will see nothing.

[dazkaz15]

ORIGINAL: Arjuna

OK so these are not one attack order with three Bns but three separate attack orders each of one Bn. In such an arrangement we don't have alogical link between the attacks, so there is no possibility of coordinated slipping and cribbing of timings. To support that would be a new feature and require more effort. I am not going to hold up on the final patch #4 for that. It's something we can look to later. The best thing can be done is to not allow any slipping or cribbing if the user sets the HHour. However, if not enough time has been allowed then it will abandon. Even doing this will take some time to set up and test. I would prefer to add this to our list of things to do as we progress after the final patch #4.

Ok Dave

You might want to look into why they think they need to slip at all, for no reason that I can tell, if you get time somewhen in the future.
The slipping is a minor thing, but surely a bug, and it might be related to other problems with timing in the engine?

[Arjuna]

Daz,

Slipping occurs all the time. It is just part and parcel of how the scheduling engine works. If we turn it off and a subordinate who is a long way away from the rest of the force requires more time then we will have to abandon the mission or leave that unit out. Both are options which if implemented users would be complaining bitterly about. So instead we rework the times to fit. It's all about choices.

You have to remember that this mirrors what happens in RL. The staff do the original plan and make certain assumptions about where a particular force will be at a certain time and how it will take them to get to point A. But by the time orders are received and processed down the line things don't necessarily turn out as per the original assumptions. So adjustments are made. the boss is advised that C Coy is going to be delayed by an hour and everything slips. That is just how it works. And the more levels of command there are the more likely this will occur. That is the operational space we are in.

[Lieste]

I think the problem is that the attack is still in the future, everyone is ready, yet the attack has still been slipped...

Perhaps 'unslipping' an attack if possible once the FUP re-org is complete, back to the original time, or avoiding slipping at all if all elements are actually going to be present at the FUP in good time.

All the elements are in place, H-hour is around 2 hours away, yet the attack won't go in until after H+30.

[Arjuna]

Daz,

Sorry my apologies. I realise now that you have set a specific HHour rather than left this on Auto. My bad. OK I'll look into it.

Do you have a save taken just after your orders and before it slipped?