Divisional Assets...too strung out?

[barbarossa2]

Hello PG!

Am playing away at COTA and LOVE IT...well, most of it.

I was gaming away as the Germans in the "Maleme historical campaign" and on the first day of action, this occured...

As shown in the attached picture, most of my German regiments are advancing on Galatas, which was taken and consolidated. The para regiments were then ordered on to the north east and to take a blocking position on the main road to the east of Galatas.

As expected, without orders, the divisional assets (Div HQ, Div arty, and Div supply) all stayed put in in the area surrounding the prison.

I forcibly extricated the Div. HQ and ordered it into Galatas. It did so, as shown in the image. However, the rest of the div assets which were still attached to it (supply and artillery), stayed in the area around the prison, and just sat there. Until the road opposite the Aghye to Sikalia road became an enemy car park (500 meters away!!!!). At that point, I gave up hope that the DIV HQ unit would order them to move, and did it myself. However, it was too late. The pictured enemy units coming up from Aghye managed to catch the Div supply unit in the open and engage it...just after night fall.

The 7.3 Para company was dispatched by me to provide a little security as I saw the problem developing.

This is a similar problem to one I encountered in HTTR...and it concerned me a lot. And my dad (again, a company commander and general's aide in cold war Germany), said that it was a bad place to have this stuff. (Please note that I realize that I am NOT an expert in military practice...which is why I often have to ask my dad if this stuff "feels" right)

What is your advice for better controlling divisional assets in these fluid situations. Is there no better way to do the AI for this? And do you have someone on your staff who can spot these situations, which would probably not occur in real life...and then recode?

Is what is shown here in the image even a problem? Surely there must be someone out there who was involved in operational planning on a divisional level? What are your thoughts? I would like to forward this image to my dad to ask him what he thinks...just out of curiosity. NOT that he understands German divisional doctrine, but he has a better clue than I do.

BUT!!!! I am glad to be back in the AA community. It IS fun. And I know I did the right thing with my money and am happy to be supporting Panther!

Thanks...

Chris

[Arjuna]

Chris,
 
From the look of your screen dump, all but one of the units circles are under the players direct command. SO they are there because you ordered them to be there. I do not that the Base's Info Box has a pink background, so it's waiting on orders. The 1/3 mortar unit is not under your direct command but under the command of its attacking Bn HQ. It's difficult without an earlier saved game to know whether this is was placed there at the commencement of its Bn's attack or was dropped off during the assault.
 
In general the arty and depot basing code works well. Though there are cases, particularly where the enemy surround you where it's probably best to give them orders directly. If everywhere is under enemy influence then they will probably just stay put, rather than up and move and get shot.
 
Re Ordering HQs to Move and arty/bases not moving. When you order the boss to move and he has long ranges arty and depots under command these will use the bassing code to determine their best locations. We don't as yet have an option to override this ( on the wish list ), so if you want them to move to a particular spot, you have to do that yourself.

[barbarossa2]

Thanks for the reply Arjuna,

Correct...the units circled, as pictured, are under my direct command at this point. I believe I had already given up and tried to order them out of there.

You stated, "Re Ordering HQs to Move and arty/bases not moving. When you order the boss to move and he has long ranges arty and depots under command these will use the bassing code to determine their best locations. We don't as yet have an option to override this ( on the wish list ), so if you want them to move to a particular spot, you have to do that yourself."

If I understand this correctly (so I can explain it to my friend who is new to this and I sold this product to (through Matrix, of course)):
1. There is a subroutine which determines the best placement of long range artillery and supply bases.
2. It is good at doing this in static situations.
3. It is not good at doing this in fluid situations.
4. When we order the divisional HQ around, the div long range artillery and div supply will continue to use the normal placement subroutine, which does not excell in fluid, dynamic situations.
5. As such it is better if we give orders to the divisional artillery and supply units ourselves.

I think this is fine. Again, I realize AA is a work in progress.

However, in HTTR, the problem was I would often order my artillery to a safer location (seeing enemy units coming in a fluid situation), then a few minutes later they had been ordered by HQ right back to the poor location I had ordered them out of (assuming somehow they had to be reattached for this to occur...is this true?).

QUESTION 1: If I detach my divisional artillery/supply by giving it an order to go somewhere else, does it perform the SAME artillery/supply support roles as it would if it were "attached"? And just as efficiently?

QUESTION 2: Do I need to watch out for the same situation with regimental and battalion assets?

Thanks!

Chris

P.S. Holy Sh%t! I am just digging into the new suppy rules... and WOW. I am impressed! If it is actually working like this (and why shouldn't it be), this is AWESOME. I wish we could see these transport columns somehow.
P.S. As you will all notice, I evacuated the SUPPLY DROP ZONE in the above example (DUHHHHHH!...but I was just teaching myself the COTA system in my first game...and I paid the price on day two of the scenario).

[keystone]

In my opinion I think the command AI does pretty well. Sometimes you want Div. command of some sub-units and not others, those others are usually arty and bases. Unless I want to move them for range or logistics reasons I leave them in place. As for operating out-of-command, I haven't noticed any lack of fire missions or supply(Except in the COTA long scenerios-Arjuna is fixing this). In your example when you are dropped in an open area, get those units to a non-enemy LOS location as soon as possible w/o waiting for Div. orders. And use your ground units to screen them until they do. Also do not reattach them, they always tend to end up under fire, and when it's over you have an extra inf. co. instead of fire support or supply.

[Arjuna]

Chris,
 
It is not that the AI is good at basing in static situations and bad at doing so in dynamic ones. Rather it's good in nearly all situations except where the enemy surround you - in other words where there is no demonstrable safe area. In such circumstances it will usually stay put ( which is what it is doing in your example, though it may close up with the HQ ( it just depends on a whole range of factors ).
 
I invariably leave the majority of my arty under AI control. If I'm commanding a Division and it has three or four long range arty units then I will command 1 or 2 and leave the AI the rest. All I am looking to for is a few assets with which I can intervene as and when I see fit.
 
In your example, what I would recommend is that on the drop order your base and arty units to defend where you think things are going to be the safest. Arty on Defend will provide on-call to any subordinates, unless you specify the RestAfterBombard option, in which case they won't. Once your paratroopers clear out a decent sized area then reattach one arty unit. When the HQ it is now reassigned to replans it will redeploy the arty, watch where it is goping. If it's acceptable, then reattach as many of the others as you like. if not, order the arty unit back to a safe location and wait until you have secured a larger area.

[GoodGuy]

ORIGINAL: Arjuna

In general the arty and depot basing code works well.

Yes, depot code works well, imho, but the arty still gets its sorry butt in dangerous situations, hehe, in terms of being moved right through enemy lines by its HQ.

EDIT: it improved big time compared to HTTR, no question......but...ya know.... [:)]

[Arjuna]

GoodGut,
 
Actually that is not so much caused by the basing code but the force allocation code - eg the arty unit on the east map edge gets assigned to the HQ on the right map edge and the only way to move there is through the enemy. I have written a lot of code to try and prevent this and it's about as good as you can get without route finding. When we get enough cpu speed we can use route calcs and this will obviate the problem. To use them now would slow the game down such you would get noticeable pauses in play.

[GoodGuy]

ORIGINAL: Arjuna

To use them now would slow the game down such you would get noticeable pauses in play.

I have 2 questions:
1) I do have noticeable pauses while playing now anyways, so why not use 'em now?

I do have the following specs:

AMD 64 3200+
1 GB RAM,
GeForce 7600GT 256 MB RAM
SB Live
MSI SATA2 mobo
SATA 2 HD

I know that these aren't top notch specs, but one should think that my system's specs should be sufficient to provide continous play within COTA. It seems that they aren't.

The most notable freeze happened to me a few hrs b4, playing Tempe Gorge (where I had another CTD - the type of CTD i just reported in the support forum). After playing the scenario for 10 mins on "fast" it felt like the CPU kinda groaned under the heavy cpu load, and it started to get choppy. Going back to "normal" cured it for a min, but then it froze completely. The task manager displayed 100% cpu usage. The freeze lasted for like 4 mins......I had enough time to read and answer an email, before I could go back to COTA.

This happened in HTTR on veeeery huge maps with 200+ units, for example. But I've experienced this in COTA and HTTR with only ONE enemy unit left on the map as well.

That said, I tend to think that it's not the limitation of today's CPU's, but something in the PG-engine's core would escalate to a state where "something" would eat up all cpu cycles. I doubt that the current engine is so "heavy" that it would insist on having a 4.x GHz CPU and 2 GB RAM. Besides, I've tested COTA on a 4 GHz puter, and still got the freezes, in HTTR (without the resource hog [not my term, someone brought it up in the forum]--> COTA's supply system) AND in COTA.

Btw, i'm not talking about freezes occuring after bridges had been demolished (recalc. tables).

Let me add that I'd describe myself as a "heavy" FF player....I use to play on "fast" speed usually, especially on large maps, where i'd just switch back to normal or pause the game when I'd encounter dangerous situations, or situations that have to be analyzed carefully. Using FF that excessively might be one reason..... the freezes don't appear that much when playing at normal speed mostly. But once the game got to the "freaky freeze" state, even "normal" wouldn't be playable in a continous play style, which means that there'd be regular freezes, where giving a new ATTACK order may trigger a new (or additional) freeze (from some 10 secs to 3 or 4 mins).

2) So, should I quit playing with FF?

I'm looking forward to your input.

[Arjuna]

GoodGuy,
 
What you describe is NOT normal. I have an old 2.6 P4 and run on "fast" all the time. Occasionally when a higher level HQ ( eg Div ) replans it will pause maybe for a few seconds but nothing anywhere near a minute, let along several. I suspect that there is something seriously not right with your machine. Can you send me a DX report? What OS are you running? Do you have any other tasks running when this occurs, like compilers or 3D modelling software or other cpu intensive apps? How old is your hardware?
 
I have not received any other reports of this behaviour. Has anyone else experienced something similar?

[GoodGuy]

I assembled this rig like 3 months ago, brandnew parts. The only "old" part is the soundcard, my SB Live value, it's around 4 yrs old.

Since I don't have similar problems in other games or applications (resource hogs like Battlefield2, Far Cry, Flight Sims, DTP-programs, 3D-animation software etc., audio producer tools etc. work like a charm) i can narrow it down to HTTR and COTA.

I'll send a DX diag report.

[Arjuna]

GoodGuy,

I did some testing with a test scenario, changing the location of the final and intermediate waypoints. I did this for quite a while, fast, slow large distances, small distances, with and without orders delay and still no CTDs. I understand you are not having problems with other apps, but in the absence of anyone else reporting similar problems with COTA, and the fact that I cannot repeat the behaviour then I have to assume that it is something to do with your machine.

For RDOA and HTTR the most common cause of hardware related issues was with sound cards. Could you please try disabling your sound card and testing if the problem of the delays still exists?

I wonder if it is the 64 bit chips you are using? A couple of our beta testers have tested COTA on 64 bit processors and it worked fine. I'm not sure if they were AMD chips or not. I will ask them. ( James, can you please confirm? )

Anyone else running on a 64 bit processor? Are you having problems?

GoodGuy, is it a dual core processor?

[GoodGuy]

No, "regular" 64-bit AMD cpu, "single" core.....

I just changed the "hardware acceleration" in the DX setup. This uses to tone down / correct sound processing problems in conjunction with playing 3D games (mostly FPS). In some FPS full hardware acceleration could cause massive drops in frame rates as well, it does not cause high CPU loads (like the ones I reported here) usually.

These kinda issues mostly appear if using a Soundblaster Live card, they might appear with Audigy cards as well, not sure.

It deals with some hardcoded flaws within the card's firmware/chipset, a detail Creative never admitted. Also, the drivers never seemed to be fully compliant with DirectX versions above 7 a/b, nor could they fully correct the chipset's (or the layout's) shortcomings.

On top of it, customers had severe (additional) issues when combining a SB live with a Geforce-based chipset from the same manufacturer (Creative Labs). That combo was almost unusable, VIA chipsets might have added to the fuss, back in those days when there were Geforce 256 cards only (Geforce 1).

I'm using Windows' default drivers atm (these are pretty stable ones, from 2001), no issues here in other apps/games, so I did not touch the hw acceleration when moving to WinXP.

On a sidenote, I used to play HTTR on an AMD 1700+ rig, with 768 MB RAM, Win 2000 pro, AND this same SB live.
I got the same kind of freezes, and I know for sure that the hardware acceleration was set to basic or even minimum. So I could spot no reason for the freezes.

The 4 GHz -puter (where i tested HTTR + COTA) has.....guess what?... a SB live platinum (basically like my Live Value, just with additional outputs, IIRC). Bummer !

Playing COTA with "basic" hw acceleration right now, and at "fastest" speed. The Malta scenario seems to be a good test environment (plenty of units), and I've not come across anything besides some "choppy" gameplay, which should be normal if playing at "fastest" game speed, with all those units / and this large map.

Longest hiccup was like 3 seconds, when ordering a new attack. It's 4 a.m. over here now, so I'll do some more tests tomorrow, with "basic" and "minimal" hw acceleration.

[GoodGuy]

Damn , i wanted to hit the hay 2 or 3 hrs ago....lol.....anyway, just finished Malta playing Axis. The longest freeze was 10 seconds, but still excellent, as these freezes seem to appear rather at dawn (lol?...whatever) or when giving an attack order on a Div level , which i do rarely, since the performance on a div level is mediocre, to say the least. *cough* [;)]

No i didn't remove the card. I just changed the DX settings to basic hw accel. An old trick most FPS gamers (who own these damned SB live cards) know.... I never thought about changing it for a plain 2D game. I used to change it regularly on my old rig (let's say full hw accel. for audio productions, basic for 3D gaming), too.

Well, the rig still has hiccups.... up to 10 secs (rarely !!!, really), a tick more frequently 1-5 seconds on fastest game speed. My guess would be that the latter appears to be somewhat normal. I'll test some more maps tomorrow (err today ;p) with minimal hw accel.

I'm not fully convinced that the evil freezes are gone yet, but if so, you might want to include that hint in the readme. Most readme files of FPS games use to list that trick/issue nowadays, since everyone and his mom used to have SB live cards.

G'day.

[Arjuna]

GoodGuy,
 
So let me get this right. You have made a change and you no longer get the 3 minute delays? What was the change? Was it just the hardware acceleration or was it that plus removing the sound card?
 

[HansBolter]

I get very short feezes, on the order of 5 seconds, about once every real time hour of game play. I got them on my old machine and I still get them on the new one. I refer to them as "cpu crunches". Everything gets moving again just fine after the 5 second freeze.
 
My old machine was:
 
Athalon 2700
1 gig pc 2700 ram
GeForce 5600 256m video
 
The new machine is:
 
Athalon 64x2 4200 Dual Core
2 gigs pc 6400 ram
Geforce 7950 512m video
 
The real noticeable difference is that I can run Oblivion on th enew platform where I couldn't on the old one.

[HansBolter]

Chris,

It's always interesting to note how different people take different approaches in wargames.

We take very different approaches toward securing Prison Valley.

Take a look at mine. I am not sure at what period in time your SH was taken but mine is late in the day on Day 2.

The 1st Bn lands NW of the prison and attacks directly south and to the east of the lake trashing the Greeks on the hill to the south. Then it veers nw and attacks through the town by the lake to Kurtomados, It left a couple units there to screen and the rest of the BN is now executing an attack order to help at Galatas. By day 3 this will be the most tired batallion. This has been the workhorse batallion of this entire drop area. They will rest while the other batallions gear up to assit the Gebirgsjager's coming attack on the city.

The pioneers land way to the west and attack eastward on the same hill as the 1st BN guaranteeing the Greeks on the hill will be routed. They then proceed to the light woods to screen for the divisional assets deployed in the woods. They only attacked hard the first day anad a little bit on the second and can now rest a bit on the third. They will then be moved north to help in the coming attack on the city with the Gebirgsjager.

The 3rd BN starts depleted and initially hits Galatas and then pulls out to the SE to screen the divisional perimeter. The 10.3 company, the flak and the 1.LL all made it back to the divisional perimeter from their dispersed drop locations. Most of this batallion's units are detached and placed at key defensive positions. The batallion will be reconstituted soon to start the attack westward.

The 2nd Bn reinforced Galatas allowing the 3rd to to slip SE to cover the divisional perimeter. They are holding the town awaiting the additional suport that is coming from the 1st.

The divisional and regimental HQs, bases and artillery are deployed in the light woods and the town in the middle of the secured divisional perimeter.

My game is now near the end of day 3 and the 1st BN helped clean things up at Galatas as the Gebirgsjager are arriving in the locale along the coast road to the north.

One important key in paratroop operations is to establish a secure divisional perimeter where rear area units can harbor in realitive safety. I spend the first day making shock attacks (high aggro/max rate of fire) to literally chase the standing enemy off the immediate battlefield so I can establish my perimeter encompassing as many first day objectives in the process as I can.

[James Sterrett]

Yes, I run it at home on an single-core AMD 64-bit processor ("XP 3700+") without these hitches.

I am also running with Windows XP64, and -- possible cause here -- could not find a good set of drivers for an SB Live sound card. We have two computers, and the one intended to get our old SB Live card is running on motherboard sound (AC 97) instead; we couldn't get reliable results from the SB Live. (The other computer has an SB Audigy with 64-bit drivers.)

These computers both have an nVidia motherboard chipset - v4, if memory serves.

Edit: The once per hour "crunches" Hans mentions do sound familiar, though I'm not sure if my memory of this is from the desktop or the laptop (a 2Ghz Pentium with 498MB RAM).

[barbarossa2]

Hans,

Thanks for the interesting info on how you take prison valley.

I really need to say that what I did was in my FIRST COTA game, and I hadn't even read the rules. So, I wasn't aware of the fact that I even had to hold onto prison valley to keep supply up (it had been a year since playing HTTR as well). I was really just screwing around, trying to refamiliarize myself with the GUI, hoping the artillery and supply unit placement routines had been improved.

Of course, without supplies, the operation was a failure by the end of day two, but I had learned my lesson, and, after reading about it, was awed by the new supply model I would have to deal with.

Thanks!

[Arjuna]

It is quite normal for machines to pause for a few seconds every now and then when the AI is replanning. However, it would be extremely rare for these pauses to last more than a few seconds.

[GoodGuy]

15 seconds max, scenario Spartans at the pass.... Sound hw acceleration on "none" now. Playing on "fastest" game speed, depending on amount of issued orders (it seems), I'd say I get those freezes every 15 minutes real time, usually 5-10 seconds.

I'd do some more testing, but (with my playing style) I get a CTD once every 2 games.