Welcome to the LnLP Forums and Resource Area

We have updated our forums to the latest version. If you had an account you should be able to log in and use it as before. If not please create an account and we look forward to having you as a member.

SITREP

JWW

Member
Joined
Feb 4, 2019
Messages
3
Points
1
Age
70
Location
Monroe, LA
I've been having a rethink on all of this...We'll monitor how this works.
Hi. I'm taking another look at CO after a long time away, that is, since CO1 on Matrix. I downloaded the core and was getting reacquainted with the game, but this thread had me wondering if I wanted to get involved and purchase additional modules and then try to keep up with everything, including additional upgrade costs. If I'm reading this right, then your business model would be like most other games. You buy the core game (or in this case get it free, basically as a demo) and buy the DLCs and that is your only cost. Updates/upgrades are free. That would make me as a potential new buyer much more comfortable.
 

GeoNL

Member
Joined
Jan 26, 2019
Messages
41
Points
8
Age
31
Location
Netherlands
I

Now this means we forego revenue and god only knows we need it. But we'll be relying on your support in buying our data modules. We'll monitor how this works.

It's admirable to find that not everyone would opt for the easy way in this. I have seen many devs on Steam choosing the easy way and asking money for upgrades without even half the effort that you (and the associated people) put into this (let's not even mention the whole early access crap that has been on Steam for so long, only a few exceptions not misusing it).

The positive thing about Command Ops (1/2) (in my eyes) being on Steam, is the increasing exposure. Not many people on Steam knew about Matrix Games therefor not people would find out about Command Ops. Except just the diehard WW2/strategy/boardgame fans.

Although, my exposure to Command Ops wasn't due to Steam. It was way back with Airborne Assault HTTR, when I was 11 years old.. My dad used to play it all the time, it is still his favorite WW2 strategy series to date. And that is saying something, since he has far less patience with games than I have. It grew on me too. Back then I used to play against my dad and didn't have a real clue of what was going on at that age. Now more than a decade later I very much appreciate the game in a more defined way. I even venture in map and scenario creation now, where as of now I have spent much, much more time in than actually playing the game.
 

Rosmarus

Member
Joined
Mar 23, 2015
Messages
13
Points
3
Location
Helsinki, Finland
I've been having a rethink on all of this. It's obviously very confusing to most people. I've also found out that it's going to take a lot of developer resources to implement this on Steam. So, I'm going to forego charging users to update their data content. We'll do this for free. Each time we put out an update that requires conversion of data content, we'll provide new versions of the data modules for existing users to download. You still won't be able to automatically convert stock scenarios using the editors but you will be able to convert non-stock data - ie the stuff you generate.

The core engine will still be free. You will not need to maintain multiple versions of the core or data- just the latest core engine and the latest version of the data you have purchased.

Now this means we forego revenue and god only knows we need it. But we'll be relying on your support in buying our data modules. We'll monitor how this works.

Now this has a bitter sweet taste to it. It's not often I'd like to throw money at developers and they have to refuse but at the same time I'm also happy for you guys. Hopefully you can find other ways to get your well earned income!
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
SITREP Wed 20 Feb 2019

Sorry fellows. I should have chimed in earlier. Testing of the latest beta build highlighted two significant and maybe related issues. The first is a dreaded out of sync issue and the second appears to be a case of a Receive Orders Events being processed in the wrong order. The latter may be the cause of the former. I've traced the probable cause for the ROEs being processed in the wrong order, but I'm wrestling with the best way to solve it. At the moment I may have to revamp the Game Event Loop, which is extremely low level code and could have collateral damage to other things. I've asked Pavlo to take a look at this issue and I'm waiting on his advice right now.
 

Seb3brv78

Member
Joined
May 4, 2017
Messages
17
Points
3
Age
36
Location
France
I've been having a rethink on all of this. It's obviously very confusing to most people. I've also found out that it's going to take a lot of developer resources to implement this on Steam. So, I'm going to forego charging users to update their data content. We'll do this for free. Each time we put out an update that requires conversion of data content, we'll provide new versions of the data modules for existing users to download. You still won't be able to automatically convert stock scenarios using the editors but you will be able to convert non-stock data - ie the stuff you generate.

The core engine will still be free. You will not need to maintain multiple versions of the core or data- just the latest core engine and the latest version of the data you have purchased.

Now this means we forego revenue and god only knows we need it. But we'll be relying on your support in buying our data modules. We'll monitor how this works.

Hi, I've been a fan of CO2 for some years and I'm quite enthusiastic about the game. I was willing to pay for the new upgrade in order to give you more means to develop CO2. I thought it is perfectly justified as you put an huge amount of work in the upgrade.

I plan to buy the modules (already three) but I have a cheap budget and it won't be for now.
So I hope you will meet a big success and increase the number of people ready to buy modules. Good luck!
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
SITREP Friday 22 Feb 2019

I have just uploaded a new beta build 5.1.38 to our beta testers. The main change here is the new avoidance code I have added to the route finding for forces with no line unit (eg forces with just HQ and/or arty). These will now apply a modifier to enemy controlled territory. This increases the travel cost to enter a grid that is enemy controlled. It won't prevent it, but it will make it less likely.

Changes
- Removed option to hide Control Box from Options view. This is now done by toggling the Control button on the Tool bar
- Disabled autosaves on replays
- Exit FPCommonAI::GetValueInRange() if min and max values are the same
- Added mAvoidEnemyControl member and DetermineMapControlAvoidance()to FPRouteInput
- Added back in call to GetTaskChecksums() to GameDiagnostics' GetGameChecksum()
- MapSearchParams now applies an avoidance modifier for enemy controlled areas to the travel cost of routes if there is no line unit within the force
- Ensured ScenForceGroupUtils' GetBridgeCount() returns a long rather than a bool
- ScenForceGroupUtils' SplitForceByReachabilityAndReasonableRange() no longer calls CullNonLineUnitFGs(). These will now use the avoidance modifiers to avoid enemy controlled areas.
- Inside PlanMove:: ProcessReachableFGs() ensure forces with no line units redetermine their route
- Inside PlanMove::ManageTimingsForInterimTasks() handle multiple next tasks properly
- Inside ScenRoute::CanMove() ensure forces in successive lines formation factor in the unit ahead and unit behind rather than using hub offsets.
- Ensure unit pathing tool ceeded with caution factor, so it avoids enemy firepower

We still have a few issues to deal with, including a formation lockup and an out of sync issue. The latter maybe related to our event processing code and we're going to revamp this and see if that addresses it. Fingers crossed.
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
SITREP Friday 1 March 2019

Hi all,

I have just uploaded a new beta build for our testers. It's 5.1.39.

Changes
- Removed trailing comma from GameRecordFieldType enum. I believe this causes out of sync problems.
- Added assert to confirm returnedFieldType inside GameStateRecord_ReadFieldType()
- Ensured message variable made safe by casting to sprintf_s() inside GameRecorder::RecordOrVerifyState()
- Disabled checksum checking code within ScenMoveEvent-ProcessEventSelf() and ScenRealForce-DetermineFrontageAndDepth()
- Added code to handle cases where there is no order of march or no valid OOM index when determining partialMinute value inside ScenTaskEvent::SetTask()
- Doubled reasonableRange value when determining whether to split a force that's moving in formation - SplitForceByReachabilityAndReasonableRangeFunction:: operator()
- Added HasOrderOfMarch() to ScenForceFormation.h
- Ensured ScenRoute::MustWaitForUnitAhead() handles cases where the subject is already ahead of its unitAhead.
- Added ScenScenario::GetRemainingEffEventCount() to handle mods for different event types
- Added assert to ensure we have a valid inTask within TaskDoctrine::CreateDefendEvent()

Note the main things here are:
  • the fixes to the formation movement code that should ensure units wait for their unitAhead. This was seeing mortars and HQs leading the charge.
  • fix for the out of sync bug. Essentially I believe this was caused by a trailing comma in an enum used to determine the return field type in the recording. There are three types - nothing, playerAction and checksum. Pavlo cites that the C standard was changed in 1999 to allow for trailing commas in enums. But when I removed the trailing comma, all of a sudden I didn't get out of sync problems. I suspect MS did not fully implement this change in standard. Their compiler doesn't assert when it finds a trailing comma but it probably doesn't ensure that any lookup doesn't overun the enumerator.
    • I have to admit that I have only done limited testing over a two day period. But I did manage to run a recording that was for five days of game time in one of the larger BAB scenarios and I have just run a multiplayer test of the tutorial for a day and a half of game time without a hitch. The testers will try and break this using both debug and release versions of the game. Hopefully they won't succeed and we can put this to bed.
 

john connor

Member
Joined
Oct 22, 2014
Messages
2,488
Points
63
Age
60
Location
Brussels
SITREP Friday 1 March 2019

Hi all,

I have just uploaded a new beta build for our testers. It's 5.1.39.

Changes
- Removed trailing comma from GameRecordFieldType enum. I believe this causes out of sync problems.
- Added assert to confirm returnedFieldType inside GameStateRecord_ReadFieldType()
- Ensured message variable made safe by casting to sprintf_s() inside GameRecorder::RecordOrVerifyState()
- Disabled checksum checking code within ScenMoveEvent-ProcessEventSelf() and ScenRealForce-DetermineFrontageAndDepth()
- Added code to handle cases where there is no order of march or no valid OOM index when determining partialMinute value inside ScenTaskEvent::SetTask()
- Doubled reasonableRange value when determining whether to split a force that's moving in formation - SplitForceByReachabilityAndReasonableRangeFunction:: operator()
- Added HasOrderOfMarch() to ScenForceFormation.h
- Ensured ScenRoute::MustWaitForUnitAhead() handles cases where the subject is already ahead of its unitAhead.
- Added ScenScenario::GetRemainingEffEventCount() to handle mods for different event types
- Added assert to ensure we have a valid inTask within TaskDoctrine::CreateDefendEvent()

Note the main things here are:
  • the fixes to the formation movement code that should ensure units wait for their unitAhead. This was seeing mortars and HQs leading the charge.
  • fix for the out of sync bug. Essentially I believe this was caused by a trailing comma in an enum used to determine the return field type in the recording. There are three types - nothing, playerAction and checksum. Pavlo cites that the C standard was changed in 1999 to allow for trailing commas in enums. But when I removed the trailing comma, all of a sudden I didn't get out of sync problems. I suspect MS did not fully implement this change in standard. Their compiler doesn't assert when it finds a trailing comma but it probably doesn't ensure that any lookup doesn't overun the enumerator.
    • I have to admit that I have only done limited testing over a two day period. But I did manage to run a recording that was for five days of game time in one of the larger BAB scenarios and I have just run a multiplayer test of the tutorial for a day and a half of game time without a hitch. The testers will try and break this using both debug and release versions of the game. Hopefully they won't succeed and we can put this to bed.
Can you just tell me what we look for, please, Dave, to try to witness this particular, hopefulky fixed, out of synch issue? Is there any particular circumstance to look specially at to see if it's there? And how will it show - as an assert? Thanks.
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
A game goes out of sync in two ways. First, if you are replaying a recording and second, if you are playing a multiplayer game. The way it manifests is that a checksum is stored in a recording or in the transferred data package between players. Then when the recording is replayed or the other player runs the game a check is made to ensure that the current checksum equals the recorded or stored one. If this is not the same then it asserts and you will get an option to continue with validation, without validation or to break into the debugger. The latter option is only relevant if you have Visual Studio installed on your machine - ie to us developers.

So to test for this run the game in single player mode to a certain point; note the scenario time; then replay the recording to that time. If it asserts before you get there and the assert is from the Game Recorder (it will tell you) then the game has gone out of sync. Otherwise all is good.
 

john connor

Member
Joined
Oct 22, 2014
Messages
2,488
Points
63
Age
60
Location
Brussels
Sorry. Accidentally posted here instead of in dev. But good for everybody to know, perhaps.
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
SITREP Sat 9 March 2019

I spent the week primarily working on the formation lockup issue. This is when a force that is moving in formation just stops for no apparent reason. It often occurred when a force assaulted in Successive Lines.I had earlier changed it so Successive Lines used the same code used for road column. This eschews the offset algorithm used by the other formation types in favour of a sequenced algorithm that checks to see if the unit must wait for the unit ahead and/or the unit behind it.

Trouble is that successive lines actually used line formation for its sub groups. Eg a Bn advancing in successive lines arranges its companies in a series of lines. So I had to make changes to accommodate that. But then I realised we also allow for road coulmns to change the formation type of the advance guard or main guard if its threatened. Eg the advance guard runs into enemy, it can then change from road column to say arrowhead or line to bring more firepower up front. The code was not handling those cases. This required a more comprehensive solution. I implemented that this week.

It now determines whether or not a subGroup is governed by Order of March (OOM). Basically any subGroup that moves either ahead of or behind the hub is governed by OOM. If so, it uses the sequenced algorithm, otherwise it uses the old offset algorithm. It can interweave these two methods for the same formation, such that you can have the hub, filler groups, advance, centre and rear guards all being governed by their OOM while flank guards use the offset system.

During testing for this I also discovered that the new sequenced method was not handling cases where the unit ahead or unit behind were still to join the main route or had already left it. That was another source of lockup. I am in the middle of testing that. Hopefully that will be all that is required to address this issue and we can get the build out.
 
Last edited:

JArraya

Member
Joined
Apr 16, 2015
Messages
113
Points
18
Age
49
Location
UK
Great stuff Dave! Really looking forward to the update. I'm thinking of starting a YouTube series once it comes out. Not enough propaganda for an awesome game!

One question, will the scenario packs need updates?
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
SITREP Friday 15 March 2019

Hi all,

Been a very busy week. I hoped to put out a new build this afternoon but testing threw up a little conundrum with the new formation movement code. I've completely overhauled this code in order to address the formation lockup issue. This morning I finally saw no lockups and forces were moving in formation freely, smoothly and in the correct march order. It was very nice to see. But auto testing threw up an issue with a particular case. It occurs when a force is moving in successive lines and one of its line subGroups only has two subGroups within its formation. These end up being a leftGuard and a rightGuard, but neither are in line with the main order of march. they are offset to the left or right. It works fine when there are one, three or more subGroups, but not two. I need to work out how best to handle this case. It's complicated because. I'm going to break for the weekend and ponder this. Inspiration usually comes when you stop trying to push for it. I'm sure I'll nut this out early next week.
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,415
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
SITREP Thursday 4 April 2019

Hi all,

I am just putting out a new beta build for our testers. The main focus has been on fixing formation lockups and HQs leading the charge. It's involved a complete overhaul of the formation movement code.

Changes:
- MapVisitTable - updated max path tick count to 500,000,000 to handle increased tick count now that we factor in mnap control to all avoidance routes
- ScenForceFormation - Various tweaks to DetermineUnitBehind()and ShouldHaveUnitBehind()
- ScenFormationSubGroup - Tweaks to IsGovernedByOrderOfMarch() to handle cases where we can have non road column and non successive lines formation types in nested subGroups - where we may have a battalion advance guard in line as part of a brigade road column.
- ScenPlanScheduling::StartProcessingTask() - ensure we determine the formation unitBehind as well as the unitAhead and store this with the subject
- ScenRoute - Major overhaul of formation movement code. We now use two integrated algorithms. One is the Order of March (OOM) algorithm primarily used for road column and successive lines. The other is the Offset algorithm used for other types of formations. But the code now handles cases where we have subGroups using an offset formation type as part of an OOM type. A lot of attention has been given to:
- removing formation lockups
- ensuring higher HQs do not get ahead of their advance or centre guards
- ScenCommonAI - DetermineRouteInput() now sets the AvoidEnemyControl flag for all avoidance routes as well as when there is no line unit. So map control is factored into most routes now.
- ScenScenario - Mods to GetTodaysFirstLight() and GetTodaysLastLight() to cater for cases where the scenario ends on the last day before first light. This was causing the ScenSide::ScheduleDailyAir() to fail
- ScenSide::ScheduleDailyAir() - ensure no CAS flights are scheduled on days where the scenario ends before first light.
- TaskDoctrine::AssessRecovery()- ensure a full replan is done if the abandoned plan has no current bossTask - ie if the boss is no longer doing this.

Note I am still to address the issue with units running out of basics. I hope to get onto that next. But I will be away next week.
 

JArraya

Member
Joined
Apr 16, 2015
Messages
113
Points
18
Age
49
Location
UK
Dave,
Will the latest update include dismounting troops?
 
Top