Open beta of the new patch is available on Steam

[jimcarravallah]

Setting the artillery time now works and the engineers in the two Westwall scenarios are now correct as well.



. . . I'm afraid recordings are disabled on Steam.

I suggest you check your file permissions for the directory tree where steam resides.

I recorded some game action for a report on artillery effectiveness from the Beta Branch Oct 20.

I've found in the past that sometimes third parties I allow to automatically install game software on my computer include a change of read / write permissions for folders from the install. apparently to protect the software.

In addition, it seems the default Program Files X86 folder gets special attention to protect its contents by the Windows 10 operating system which in most cases can only be changed by using local computer administrator permissions.

 

[miya]

Which Overloon scenario do you mean, Miya? I just loaded both Overloons and tried starting it as Axis, then Allies and doing as you said, and got no crash. Can you reproduce it yourself on the latest steam build, and if so under what exact circumstances?

It's true that there's no recordings folder in the Steam build. That is, there isn't even a recordings folder in my install on steam. You have a folder but it's empty?

Sorry, I referred to an additional save game in the uploaded zip-file. Here I play as the Allies and just finished to give my orders for the start of the scenario.

I suggest you check your file permissions for the directory tree where steam resides.

I recorded some game action for a report on artillery effectiveness from the Beta Branch Oct 20.

I've found in the past that sometimes third parties I allow to automatically install game software on my computer include a change of read / write permissions for folders from the install. apparently to protect the software.

In addition, it seems the default Program Files X86 folder gets special attention to protect its contents by the Windows 10 operating system which in most cases can only be changed by using local computer administrator permissions.

I think that means I have to check the security settings inside the steamapps/command ops2 folder.

 

[john connor]

I suggest you check your file permissions for the directory tree where steam resides.

I recorded some game action for a report on artillery effectiveness from the Beta Branch Oct 20.

I've found in the past that sometimes third parties I allow to automatically install game software on my computer include a change of read / write permissions for folders from the install. apparently to protect the software.

In addition, it seems the default Program Files X86 folder gets special attention to protect its contents by the Windows 10 operating system which in most cases can only be changed by using local computer administrator permissions.

How exactly would I do this, Jim - check the 'permission', in order to get the game to actually make a recordings folder? I don't even have a recordings folder in my steam install. Are you using the latest version in steam?

UPDATE: Scratch that, Jim. I manually made a recordings folder and it records into it ok. All ok. Odd that I had to manually make a recordings folder though. Is that working as intended, I wonder?

 

[ioncore]

UPDATE: Scratch that, Jim. I manually made a recordings folder and it records into it ok. All ok. Odd that I had to manually make a recordings folder though. Is that working as intended, I wonder?

Yes, back then Steam installer didn't allow creating empty folders. I don't know if it is still the case but we could work around it by creating a placeholder text file.

 

[Dave 'Arjuna' O'Connor]

Pavlo,

Yes please ensure the Recordings folder gets created under Steam. I have created the Recrodings.txt file to fool the Steam installer and have updated the installer scripts. Please do a Pull.

 

[Dave 'Arjuna' O'Connor]

Fox,

I just stepped through the movement code of your first save. Interesting. What's happening is the Regt HQ is basing; 1 Bn 26 is the main force hub and its moving to the FUP. 560th Bn is the advance guard and has already arrived at the FUP. @.26 Coy is the subject of the main guard but can't move because its unit behind is too far back. That's the Pak Pl 1.26. It's unit behind should be the 1.26 Bn HQ. But it's NULL - ie doesn't havce a unit behind. I've checked the Ordewr of March for the 1.26 Bn and confirmed that the OOM has 2 Coy at index 5, Pak Pl at index 6 and 1.26 Bn HQ at index 7. So it's good. But the Pak Pl either did not set the unit behind or had culled it for some reason, yet to be determined. I'll investigate further.

 

[Dave 'Arjuna' O'Connor]

OK, I've gone back to the start and stepped through the code as it calls SetUnitBehind() for the Pak Pl. This gets called when we generate a formation and when we start a new task. At the time the Pak Pl starts its Move task, it's immediate boss - ie 2.26 Coy's order of march is confirmed but that of his boss - 1.26 Bn HQ - is not. In other words, the 1.26 Bn has other groups who have yet to generate their own sub formations and determine their order of march (OOM). As the code stands now if the OOM is not confirmed then the unitBehind remains NULL.

This is fair, because we don't want to guess and get it wrong. That would cause even more frequent formation lock ups. Eventually the 1.26 Bn will confirm its OOM once all its subFormation commanders get their act together. But what is obviously not happening is that we're failing to then revise every unit's unitBehind and unitAhead correctly. There is code that should handle that. I now need to step through it and find out why it fails.

 

[Dave 'Arjuna' O'Connor]

I have revised the code inside DetermineOrderOfMarch(). It now loops through the confirmed order of march and sets each unit's unitAhead and unitBehind properly. Touch wood. Am about to confirm this.

 

[Sapper]

I'm getting the same thing as Fox playing 'Return to St Vith' one of the 3 base operations that come with the game for free. I'm trying to send the 318th (?) through the forests and down by the creek to try and out flank any enemy on the ridge across the river. I've tried giving them 4-5 attack waypoints as well as a basic 2 waypointer (the first one turns into a setup point as per normal). They then send off the "forward guard" and they generally get about half way down the river to the little minor crossing around the bend from 'Steinebruck', the 'Main Guard' then starts to move out but they usually only get about a 1/3rd of the way down before they pull up. The whole regiment then just sits there with the 'MOVE' ^ arrow stuck on their unit squares, for hours apon hours until they seem to eventually "abandon" the attack and their status squares just revert back to empty plain white ones.

If I move or edit the already placed waypoints the units status symbols on their cards might flash a red icon or something as if the AI is trying to do whats been ordered of them but they just end up reverting to just sitting there with a MOVE arrow on their card.

Happens with the 51 Armored Inf unit too, haven't tried with the 35th Tank as I use them as overwatch on the ridge overlooking the town/bridge, but I'd guess they'll do the same thing too.

I'll see if I can get some saved game files for you guys to look at.

 

[Dave 'Arjuna' O'Connor]

My above fix saw the Pak Pl get the right Unit Behind assigned and it moved off as it should. But then I got another lock up further down the track. I'm investigating this now.

 

[Dave 'Arjuna' O'Connor]

I solved the other issue with the formation lockups. Inside the CanMove() it calls two functions when there is an order of march namely, MustWaitForUnitAhead() and MustWaitForUnitBehind(). Inside these it calls GetEffectiveUnitAhead() and GetEffectiveUnitBehind(). Alas neither was spiralling up the formation. I have fixed this and now the whole main force moves freely and arrives at the FUP.

Alas, I then noted that the scheduling code cut in as it should for a Player initiated Attack. Trouble is it was using the now based KG HQ location to determine if it was close enough now to launch into an attack. It failed and so went over to the defence. This is a downstream effect of my new Senior HQ Basing code. I need to mull over the best option to fix this. Normally, in all other mission types, I use the MainForceSubject's location. But for a Player attack where the objective is a long way away, we first conduct a Move mission and then replan (as we do in this case). But in the replan I no longer have a pointer to the main force subject for the earlier Move. I'm going to have to either pass this through the calling chain of functions, temporarily store it in the plan or redetermine it from scratch. All options have their pros and cons. It's been a long day. I'll ponder this overnight and resolve this issue tomorrow.

 

[Grognerd]

I have a problem or question with regards to "First Clash at Veve" scenario.
The First Brigade SS will not move off the edge of the map. When the 9th Panzer Div HQ came into the game on day three it would not move off the map edge.
1) I uninstalled the game as I had Command Ops on D drive. Reinstalled now it's on C and has a recording folder and I've started the scenario over. First SS Brigade exhibits same behavior.

When the artillery comes in it will be out of range on the map edge (It moves back towards the first HQ when I reattach it, unless I micromanage it. This is the real issue.

I have a recording .cor and a screen shot - would you like me to continue to play until 9th comes in?

 

[ioncore]

I have a recording .cor and a screen shot

Please attach them here.

 

[Grognerd]

ok

 

[john connor]

I have a problem or question with regards to "First Clash at Veve" scenario.
The First Brigade SS will not move off the edge of the map. When the 9th Panzer Div HQ came into the game on day three it would not move off the map edge.
1) I uninstalled the game as I had Command Ops on D drive. Reinstalled now it's on C and has a recording folder and I've started the scenario over. First SS Brigade exhibits same behavior.

When the artillery comes in it will be out of range on the map edge (It moves back towards the first HQ when I reattach it, unless I micromanage it. This is the real issue.

I have a recording .cor and a screen shot - would you like me to continue to play until 9th comes in?

When you gave the LAH its orders, Grognerd, did you untick 'basing'?

 

[Grognerd]

When you gave the LAH its orders, Grognerd, did you untick 'basing'?

Well Jim, I hope basing is something new because I've never noticed it before! Ha
The HQ moved when I unchecked basing.

 

[john connor]

This is a new change, in fact, Grognerd. The new basing code will 'base' the HQ and the base and other HQ support units, even when the HQ is given a Move order. If the order is a long order (long distance) it will base these elements and check repeatedly whether it's safe for them to catch up with the forward elements, then move them, base them again etc, staging things along the route. Applies to all HQs over Bn level. With Bn's and lower you could still see them moving ahead of their elements, especially if, for example, they are wheeled and the elements are not, and you should take this into account when plotting moves for Bn level or lower (short move legs best, into territory you have scouted or where contact unlikely). For higher than Bn if you want all the units in a formation to move to the destination (HQ included) with no basing along the way then untick 'basing'.

 

[Grognerd]

OK, got it and sorry for the false alarm.

 

[john connor]

Well, we maybe should flag up that change more, so players know, once it's out of beta. I started a similar thread in the dev forum because I didn't understand it at first. So, you weren't to know. It takes some getting used to, especially when combined with 'in situ'. At present higher HQs will STILL base (ie move HQ and HQ support units to safe locations) even if you give them a Defend in situ order, unless you remember to untick 'basing'. It gives more options this way, but you have to remember it.

 

[JArraya]

Well, we maybe should flag up that change more, so players know, once it's out of beta. I started a similar thread in the dev forum because I didn't understand it at first. So, you weren't to know. It takes some getting used to, especially when combined with 'in situ'. At present higher HQs will STILL base (ie move HQ and HQ support units to safe locations) even if you give them a Defend in situ order, unless you remember to untick 'basing'. It gives more options this way, but you have to remember it.

I think would be a good idea @john connor. I had the same confusion when my HQ stayed behind and I thought I hadn't issued the move order, but clearly I had.
The way I read it is, if you want the HQ to move, untick Basing. Is that the gist of it?