SITREP
- Thread starter Dave 'Arjuna' O'Connor
- Start date
- Copy link Copy link
john connor
Member
Yes. I've mentioned this in the dev forum a long while ago. I'd given up on it being looked at until the attack code thing was sorted.
For me, it's more or less ok on slowest speed, but anything higher and everything is continually stuttering. Even in small scenarios with not much (apparently) happening. It's most noticeable on the artillery explosion graphics, for instance, which I can see frame by frame....
A separate stutter, which I also mentioned in the dev forum long ago, is really more a delay, and happens when enemy reinforcements arrive on map. But this isn't the only stutter. The general stutter on higher speeds is constant and worse.
Like you, I have a fairly high-end machine. Running windows 10 on 32GB of ram with a Ryzen 5 and an 11GB Nvidia card, the game running off an SSD.
I could be wrong, but I have a feeling that Pavlo's artillery changes of some 2 years ago (was it?) go along with this 'new' stuttering behaviour. Not sure.
For me, it's more or less ok on slowest speed, but anything higher and everything is continually stuttering. Even in small scenarios with not much (apparently) happening. It's most noticeable on the artillery explosion graphics, for instance, which I can see frame by frame....
A separate stutter, which I also mentioned in the dev forum long ago, is really more a delay, and happens when enemy reinforcements arrive on map. But this isn't the only stutter. The general stutter on higher speeds is constant and worse.
Like you, I have a fairly high-end machine. Running windows 10 on 32GB of ram with a Ryzen 5 and an 11GB Nvidia card, the game running off an SSD.
I could be wrong, but I have a feeling that Pavlo's artillery changes of some 2 years ago (was it?) go along with this 'new' stuttering behaviour. Not sure.
jimcarravallah
Member
No.
Thanks John. Aside from what you mentioned, which is very noticeable on mine, I also experience a delay, like a frozen game, when issuing orders. I will click the order and nothing happens, then a few seconds later the order gets placed.
Doing this with the shift key down for a few steps will result in a very long pause.
Doing this with the shift key down for a few steps will result in a very long pause.
john connor
Member
Dare I say this, but I think it's probably best to wait until this 'update' is done before raising these things. Everything has been frozen for so long waiting for the update. There are other problems, obviously, and I used to report them in the dev forum, but it's a very very small team and there has been for a long while no time to do anything else but try to get the attack thing sorted out, I think. I think probably a lot of people have turned to other games meanwhile. Hopefully they'll be back when the present project is finally finished. Fingers crossed.
Sadly, I agree. I have over 500 hours of play on this game and I really love it, but it's now unplayable after the artillery update. Just to test things, I rolled it back to the version before this (the supply update) and there are no performance issues. It would be great to see this game get some development firepower behind it and evolve to it's next iteration!
MarkShot
Member
This game has always been both a fantastic vision and implementation. No game does time better (the 4th dimension of the battle space), and intelligent agents which makes it the most scalable game. Most games have a natural sweet spot for units, but this game with decent hardware can easily through two orders of magnitude of units with no scaling issues for the player. I will be building a new system in a week (last 2015) with i-13900KS + RTX 4090. I am expecting lots of fun with CO2 when the last kinks are ironed out.
A few quick builds and long delays has been the history of the series. I remember Dave once telling me; I think it was BFTB that I had just 2 weeks to proof read the manual as Matrix was about to cut the gold master. It wasn't released for another 2 years.
But despite these erratic patterns, Dave has never be to abused customers, publishers, or betas. I've been a member of 4 different game teams, and I have never met (a former senior corporate manager, myself) a better manager of volunteers than Dave. His style of management gets years of commitment of team members, and it also causes people to gravitate to the areas which they are most talented and their contributions most needed.
My worst experience ever as a beta. The Beta Lead explained to me that in the evenings I am no more than a "click monkey" he called it. And with my intellect all I was fit to do was click on every button and log CTDs. By day I was an SVP in charge of software development for a US Bank with 80,000 employees. Needless to say, by the end of 4 weeks I had enough of these drunken rants from a US Army Colonel (retired).
I know Dave has personally sacrificed to keep this series alive. For him, it is not so much a business but a passion and work of art that has become central his identity. I know it is painful as gamers to wait. But I doubt any of us own but a single game. I just play something else while waiting. Dave is working hard and make good on any DLC ops you own, and I trust when he releases it will be worthy of the Panther brand.
A few quick builds and long delays has been the history of the series. I remember Dave once telling me; I think it was BFTB that I had just 2 weeks to proof read the manual as Matrix was about to cut the gold master. It wasn't released for another 2 years.
But despite these erratic patterns, Dave has never be to abused customers, publishers, or betas. I've been a member of 4 different game teams, and I have never met (a former senior corporate manager, myself) a better manager of volunteers than Dave. His style of management gets years of commitment of team members, and it also causes people to gravitate to the areas which they are most talented and their contributions most needed.My worst experience ever as a beta. The Beta Lead explained to me that in the evenings I am no more than a "click monkey" he called it. And with my intellect all I was fit to do was click on every button and log CTDs. By day I was an SVP in charge of software development for a US Bank with 80,000 employees. Needless to say, by the end of 4 weeks I had enough of these drunken rants from a US Army Colonel (retired).
I know Dave has personally sacrificed to keep this series alive. For him, it is not so much a business but a passion and work of art that has become central his identity. I know it is painful as gamers to wait. But I doubt any of us own but a single game. I just play something else while waiting. Dave is working hard and make good on any DLC ops you own, and I trust when he releases it will be worthy of the Panther brand.
simovitch
Member
Mark sums it up pretty well here. I started with the team back in 2005 and still can't wait to playtest this beast when it gets reborn.
john connor
Member
Yep. Best wargame I've ever played. Conception exactly spot on. Can't wait for the implementation to restore things to a level where I can play it again with immense enjoyment,
Rob
Member
Yup!
I've been a Panther fan since "Fire Brigade" and have every intention sticking it out for the long haul. Best game(s) ever!
Heck, I may even have a laptop tossed in the casket with me (just in case you can take it with you) when the time eventually comes......
Keep up the great work Dave!!
Rob.
I've been a Panther fan since "Fire Brigade" and have every intention sticking it out for the long haul. Best game(s) ever!
Heck, I may even have a laptop tossed in the casket with me (just in case you can take it with you) when the time eventually comes......
Keep up the great work Dave!!
Rob.
Grognerd
Member
That was the first decent computer wargame I bought! Good game for it' time.Yup!
I've been a Panther fan since "Fire Brigade" and have every intention sticking it out for the long haul. Best game(s) ever!
Heck, I may even have a laptop tossed in the casket with me (just in case you can take it with you) when the time eventually comes......
Keep up the great work Dave!!
Rob.
Dave 'Arjuna' O'Connor
Panther Games Designer
- Joined
- Jul 31, 2014
- Messages
- 3,416
- Points
- 113
- Location
- Canberra, Australia
- Website
- www.panthergames.com
Tommy,
The attrition is killing me.
I 've been in the trenches fighting the scheduling demons. With the new attack code, we have some scheduling issues. In fact, these issues have been there all along but now are made manifest. The problem occurs when the Bn HQs develop their sub-attack as part of the Bde complex attack. This used to be done discreetly up front but now is more fully integrated and occurs after the main force for the Bde reaches the Bde ReserveLoc. If each of the Bns asks for more time the boss issues new orders after each request. In the recording I am using we have the 51 AI Bn requesting first and the CCA HQ issuing new orders But these don't arrive until after the 35 Tk Bn HQ develops its sub-attack and it requests more time. But at that moment the 35 Tk Bn plan is out of sync with the CCA's plan.
I have tried accounting for the difference in timings but this has introduced other complications. In frustration, I went for a good walk and asked myself what would happen in real life. In RL the Bn commander would radio his boss and say he needs more time. The Bde commander would say 'hang fire, the other Bn has already asked for more time and I'm working on issuing new orders. Just hold till we update the plan and send it to you.'
So, I commented out a fair chunk of my recent code, and then added some new code to DevelopMissionPlan() that tests to see if the Bn is waiting on new orders. If it is, then instead of developing the sub-attack it develops a temporary filler hold mission. I also made changes to the code that processes received orders. If it's no longer waiting on new orders it will clear the hold plan and develop the sub-attack with the new timings. I just finished making those mods and compiling the game. That's where I'm at now. Tomorrow, I'll run the recording and see if that solves the problem.
The attrition is killing me.
I 've been in the trenches fighting the scheduling demons. With the new attack code, we have some scheduling issues. In fact, these issues have been there all along but now are made manifest. The problem occurs when the Bn HQs develop their sub-attack as part of the Bde complex attack. This used to be done discreetly up front but now is more fully integrated and occurs after the main force for the Bde reaches the Bde ReserveLoc. If each of the Bns asks for more time the boss issues new orders after each request. In the recording I am using we have the 51 AI Bn requesting first and the CCA HQ issuing new orders But these don't arrive until after the 35 Tk Bn HQ develops its sub-attack and it requests more time. But at that moment the 35 Tk Bn plan is out of sync with the CCA's plan.
I have tried accounting for the difference in timings but this has introduced other complications. In frustration, I went for a good walk and asked myself what would happen in real life. In RL the Bn commander would radio his boss and say he needs more time. The Bde commander would say 'hang fire, the other Bn has already asked for more time and I'm working on issuing new orders. Just hold till we update the plan and send it to you.'
So, I commented out a fair chunk of my recent code, and then added some new code to DevelopMissionPlan() that tests to see if the Bn is waiting on new orders. If it is, then instead of developing the sub-attack it develops a temporary filler hold mission. I also made changes to the code that processes received orders. If it's no longer waiting on new orders it will clear the hold plan and develop the sub-attack with the new timings. I just finished making those mods and compiling the game. That's where I'm at now. Tomorrow, I'll run the recording and see if that solves the problem.
Thanks for the update Dave, just the morale boost I needed.Tommy,
The attrition is killing me.
I 've been in the trenches fighting the scheduling demons. With the new attack code, we have some scheduling issues. In fact, these issues have been there all along but now are made manifest. The problem occurs when the Bn HQs develop their sub-attack as part of the Bde complex attack. This used to be done discreetly up front but now is more fully integrated and occurs after the main force for the Bde reaches the Bde ReserveLoc. If each of the Bns asks for more time the boss issues new orders after each request. In the recording I am using we have the 51 AI Bn requesting first and the CCA HQ issuing new orders But these don't arrive until after the 35 Tk Bn HQ develops its sub-attack and it requests more time. But at that moment the 35 Tk Bn plan is out of sync with the CCA's plan.
I have tried accounting for the difference in timings but this has introduced other complications. In frustration, I went for a good walk and asked myself what would happen in real life. In RL the Bn commander would radio his boss and say he needs more time. The Bde commander would say 'hang fire, the other Bn has already asked for more time and I'm working on issuing new orders. Just hold till we update the plan and send it to you.'
So, I commented out a fair chunk of my recent code, and then added some new code to DevelopMissionPlan() that tests to see if the Bn is waiting on new orders. If it is, then instead of developing the sub-attack it develops a temporary filler hold mission. I also made changes to the code that processes received orders. If it's no longer waiting on new orders it will clear the hold plan and develop the sub-attack with the new timings. I just finished making those mods and compiling the game. That's where I'm at now. Tomorrow, I'll run the recording and see if that solves the problem.
Hope you dont mind I have copied the answer into the CO2 forum on steam - I know a fair few people still check it looking for updates etc.
MarkShot
Member
Ah Dave,
You are not really a software engineer.
Here is what became clear through 40 years of engineering:
* Software like life is a battle against entropy. The universe naturally tends to increased entropy. We can input energy into a closed system (like a living body or software code) to reduce entropy ... but still absent of such input, entropy grows. I am not speaking in metaphor here. Computer Scientist, Claude Shannon, definitively proved the link between physics and information theory.
en.wikipedia.org
* Many software engineers like to use the analogy of a code base becoming cancerous over time, and at certain point in time, (TCO) the cost of saving exceeds the cost of rewriting.
* The above is why almost every system in existence ultimately gets rewritten. And there is also a role played by new hardware over time. You now have 24 cores or more at your disposal. I know you and Paul, multi-threaded rendering and simulation; which was genius. The map scrolls smoothly despite the clock slowing with unit count. (And the player remains engaged on the big map.)
* We can delay, but not forever prevent system rewrites. Delaying tactics such as good design leading to modular code where high maintenance modules are isolated (linking and coupling in the parlance of the field), structured coding, abstract data types, object orientation can all push back the inevitable day. But the day does approach where the repair of 1 bug introduces 2 bugs.
I think this is the war of attrition in which you find yourself. In 2000 when we met at BTS with RDOA, the code base was already huge and you and Paul had already worked on it for quite a few years.
For those of you reading along here ... I am not saying CO2 is doomed, but explaining why "attrition". Dave is a very feisty character, and not easily deterred. You will need to be patient, but Dave will deliver ... I just wanted to elucidate the larger forces afoot here.
You are not really a software engineer.
Here is what became clear through 40 years of engineering:
* Software like life is a battle against entropy. The universe naturally tends to increased entropy. We can input energy into a closed system (like a living body or software code) to reduce entropy ... but still absent of such input, entropy grows. I am not speaking in metaphor here. Computer Scientist, Claude Shannon, definitively proved the link between physics and information theory.
Claude Shannon - Wikipedia
* Many software engineers like to use the analogy of a code base becoming cancerous over time, and at certain point in time, (TCO) the cost of saving exceeds the cost of rewriting.
* The above is why almost every system in existence ultimately gets rewritten. And there is also a role played by new hardware over time. You now have 24 cores or more at your disposal. I know you and Paul, multi-threaded rendering and simulation; which was genius. The map scrolls smoothly despite the clock slowing with unit count. (And the player remains engaged on the big map.)
* We can delay, but not forever prevent system rewrites. Delaying tactics such as good design leading to modular code where high maintenance modules are isolated (linking and coupling in the parlance of the field), structured coding, abstract data types, object orientation can all push back the inevitable day. But the day does approach where the repair of 1 bug introduces 2 bugs.
I think this is the war of attrition in which you find yourself. In 2000 when we met at BTS with RDOA, the code base was already huge and you and Paul had already worked on it for quite a few years.
For those of you reading along here ... I am not saying CO2 is doomed, but explaining why "attrition". Dave is a very feisty character, and not easily deterred. You will need to be patient, but Dave will deliver ... I just wanted to elucidate the larger forces afoot here.
Last edited:
Dave 'Arjuna' O'Connor
Panther Games Designer
- Joined
- Jul 31, 2014
- Messages
- 3,416
- Points
- 113
- Location
- Canberra, Australia
- Website
- www.panthergames.com
No worries Tommy. Thanks.
Dave 'Arjuna' O'Connor
Panther Games Designer
- Joined
- Jul 31, 2014
- Messages
- 3,416
- Points
- 113
- Location
- Canberra, Australia
- Website
- www.panthergames.com
Thanks Mark. As you well know, the older we get the less capable we are of handling all that entropy - no matter how much we desire to stay on top of it. And when you have desire that can't be met, then you have attrition. It's as well, I'm a fully realised being with no attachments.Ah Dave,
You are not really a software engineer.
Here is what became clear through 40 years of engineering:
* Software like life is a battle against entropy. The universe naturally tends to increased entropy. We can input energy into a closed system (like a living body or software code) to reduce entropy ... but still absent of such input, entropy grows. I am not speaking in metaphor here. Computer Scientist, Claude Shannon, definitively proved the link between physics and information theory.
Claude Shannon - Wikipedia
* Many software engineers like to use the analogy of a code base becoming cancerous over time, and at certain point in time, (TCO) the cost of saving exceeds the cost of rewriting.
* The above is why almost every system in existence ultimately gets rewritten. And there is also a role played by new hardware over time. You now have 24 cores or more at your disposal. I know you and Paul, multi-threaded rendering and simulation; which was genius. The map scrolls smoothly despite the clock slowing with unit count. (And the player remains engaged on the big map.)
* We can delay, but not forever prevent system rewrites. Delaying tactics such as good design leading to modular code where high maintenance modules are isolated (linking and coupling in the parlance of the field), structured coding, abstract data types, object orientation can all push back the inevitable day. But the day does approach where the repair of 1 bug introduces 2 bugs.
I think this is the war of attrition in which you find yourself. In 2000 when we met at BTS with RDOA, the code base was already huge and you and Paul had already worked on it for quite a few years.
For those of you reading along here ... I am not saying CO2 is doomed, but explaining why "attrition". Dave is a very feisty character, and not easily deterred. You will need to be patient, but Dave will deliver ... I just wanted to elucidate the larger forces afoot here.
Dave 'Arjuna' O'Connor
Panther Games Designer
- Joined
- Jul 31, 2014
- Messages
- 3,416
- Points
- 113
- Location
- Canberra, Australia
- Website
- www.panthergames.com
SITREP Tue 4 Jul 23
Hi all,
I have been ploughing my way testing and fixing the attack scheduling code. The new attack code involves more plan tasks. So, there are more permeations to test and hone. Along the way I have stomped on a number or issues that would have caused attacks to abandon in past versions of the game. Right now I am knee deep in the code that handles cases where the attack has an assigned FUP. This occurs where a Bn basic attack is part of a Bde or Div complex attack. But now there is also an assigned reserveLoc and an advance route from the boss's reserveLoc to the Bn's FUP. These are now determined by the boss and passed down with his orders. The good thing with this approach is that there is no need to recalc them when the Bn develops its attack. But as I've just discovered there is no need to add padding to the timings for the sub-attacks. This was used previously to avoid slipping the plans. So more up front development and a streamlined process down the line.
Also I now only add one assemble task per attack. An assemble task is designed to bring together a force that is spread out. If this is done to bring together the Division, then there is no need to repeat the process for brigades and battalions. What you will now see for a Bde level attack is a seamless advance from current positions to an assembly area, followed by a move to the Bde reserveLoc and from there to the various Bn reserveLocs and then onto the Bn FUPs from where the assaults are launched. The force will move as one from the assembly area, dropping off forces at the various reserveLocs before reaching the FUPs. Any force who is currently near the assembly, reserveLocs or FUPs will stay put until the main force reaches it. It will then be absorbed into the main force and move on with it.
It's starting to look good. I'll try and probide some screen dumps once I finish this latest testing.
Hi all,
I have been ploughing my way testing and fixing the attack scheduling code. The new attack code involves more plan tasks. So, there are more permeations to test and hone. Along the way I have stomped on a number or issues that would have caused attacks to abandon in past versions of the game. Right now I am knee deep in the code that handles cases where the attack has an assigned FUP. This occurs where a Bn basic attack is part of a Bde or Div complex attack. But now there is also an assigned reserveLoc and an advance route from the boss's reserveLoc to the Bn's FUP. These are now determined by the boss and passed down with his orders. The good thing with this approach is that there is no need to recalc them when the Bn develops its attack. But as I've just discovered there is no need to add padding to the timings for the sub-attacks. This was used previously to avoid slipping the plans. So more up front development and a streamlined process down the line.
Also I now only add one assemble task per attack. An assemble task is designed to bring together a force that is spread out. If this is done to bring together the Division, then there is no need to repeat the process for brigades and battalions. What you will now see for a Bde level attack is a seamless advance from current positions to an assembly area, followed by a move to the Bde reserveLoc and from there to the various Bn reserveLocs and then onto the Bn FUPs from where the assaults are launched. The force will move as one from the assembly area, dropping off forces at the various reserveLocs before reaching the FUPs. Any force who is currently near the assembly, reserveLocs or FUPs will stay put until the main force reaches it. It will then be absorbed into the main force and move on with it.
It's starting to look good. I'll try and probide some screen dumps once I finish this latest testing.
jimcarravallah
Member
Leaving out the descriptions of the coding solutions, the logic used to define the sequencing of activities and coordination of forces would be at least a good outline for a military training manual chapter on the attack.
