Comprehensive Wishlist

[Panama]

ORIGINAL: ColinWright

ORIGINAL: Panama

ORIGINAL: ColinWright

Everyone else who is participating in this discussion either wants (a) hexes that can be designated as bridges without constraint, or (b) hex-side rivers.

For good reason. Those are the alternatives to the current system that actually accomplish something.

See the examples posted above. Your 'matrix' does nothing. It's the worst idea since the concrete zeppelin. Worse, it would appear that somehow you've acquired the ability to impose this idea on the rest of us.

As long as we're shooting for the Moon here, when can we have a bigger unit database? And the ability to flush weapon systems out of a units TO&E so we can do away with the lame transition process we're stuck with now?

1. What do you mean by a 'bigger unit database'?

2. As to weapons transitions, I've advocated introducing an absolute cap on on how many weapons can be in a unit. That would have addressed many of the problems without excessive complication -- but as I recall, the idea ran into Blocking Detachment LeMay. The discussion is somewhere...

1. More units. More formations wouldn't hurt anything either. Best would be a dynamic db that is sized according to what the user wants. But that's probably way out of the question.

2. That idea of yours sounds like a simple and good solution.

Would also be nice to be able to reassign units to formations.

Thing is, to keep this game alive and well it has to evolve. Stagnation = death.

[ColinWright]

It may only arouse the Curtis again, but as I recall, my idea was something like this.

Let's suppose we have 'Panzer Divisionlet Colin.' We want it to make a transition from Pz IV's to Panthers, see the infantry get Panzerfausts, and go from 105 mm guns to Wespes.

So we draw it up like this:


0/12 Panthers

12/12 Pz IV H's

0/12 heavy rifle AT

12/12 heavy rifle

0/4 Wespe

4/4 105 mm guns

8/8 Trucks


Now, under the current system, the unit is perfectly liable to balloon into 'Panzer Divisionlet Colin Plus -- with the Panthers and the Pz IV's, etc. Like this:


12/12 Panthers

12/12 Pz IV H's

12/12 heavy rifle AT

12/12 heavy rifle

4/4 Wespe

4/4 105 mm guns

8/8 Trucks


However, if we impose an absolute weapons cap of weapons per category (12 tanks, 12 infantry, 4 artillery pieces, 8 transports), and cut the flow of old weapons into the pool as the new ones start appearing, the program will be forced to only add new equipment as the old equipment is lost -- the unit can never grow beyond 48 weapons. It can only acquire the Wespes as the 105's are lost, etc.

So at some point in the process it might look like this:


8/12 Panthers

4/12 Pz IV H's

2/12 heavy rifle AT

10/12 heavy rifle

0/4 Wespe

4/4 105 mm guns

8/8 Trucks


But never like this:


12/12 Panthers

12/12 Pz IV H's

12/12 heavy rifle AT

12/12 heavy rifle

4/4 Wespe

4/4 105 mm guns

8/8 Trucks


If one wanted to see it reequipped all at once, waiting until the pool had the requisite new equipment and then disbanding it should lead to the replacement unit showing up with mostly new equipment.

There are various possible simplifications and refinements. For example, if one could just impose a simple 'weapons cap.' This would allow for one weapon transition, but might cause problems with more than one. Like, in the above example, the program could hand out 12 Panthers, keep 4 Pz IV's, and say, 'what -- artillery? But you've already got 48 weapons. What do you want artillery for?'

Alternatively, one could go for more sophistication and have the program look for the newest equipment in the pool. Like even if we're reconstituting the unit and there are 12 Wespes and 7 105 mm guns in the pool, it'll say, 'Colin doesn't want those old 105's, and we've got enough of the new Wespes. We'll give him those.'

Main point is that creating a cap on either the total number of weapons or the total per category makes it possible to have equipment transitions while preventing the unit from growing beyond a specified size. Your fighter squadron can field 12 P-38's, P-51's, or some combination thereof -- but the number can't be more than 12. You can't have 12 P-38's and 12 P-51's.

[Telumar]

+1

I think what most people want to see is a hierarchical OOB with assigning/reassigning units between formations. And volume based supply. Quite a task for Ralph time wise, i know.

I also think the game needs to be expanded where it already outstands - and that is the flexibility to model more than one specific time/war/theatre. So, make it more flexible, begin with making the editor parameters (Movement Bias, ZOC cost, Movement Cost for Supply/Readiness, Engineering Build Rate etc, but also Force Proficiencies and things like Electronic Support etc) editable/changeable by the event engine. More weather control for designers, changeable terrain. Add additionally a possibility for designers to divide the map into certain areas where such parameters can be applied per area. (i think we had this years ago in a chat with Jamiam).

[ColinWright]

ORIGINAL: Panama

Thing is, to keep this game alive and well it has to evolve. Stagnation = death.

I have no problem with any of your suggestions -- in particular, being able to reassign units would be nice -- but in general, I'd add a few caveats.

First, the system shouldn't grow so complex and arcane that it's inaccessible to new users. From some of the comments I've seen, it already pushes the envelope in that respect. I got into this because I could sit down and start playing without undue suffering. That aspect needs to be kept. Else we become the secret cell of the twelve players of TOAW.

Second, the improvements have to actually be good ones. One of the worst moments in this game's history was when ACOW replaced WGOTY -- and added a whole suite of weapons going back to the Napoleonic era without doing anything to actually allow for the differences in combat in different eras. As (and here I once again risk the wrath of the awful Curtis) several people have found, even if one does have the cannon and infantry types, this game still can't do the American Civil War very well. It irritates me to have weapons that don't actually simulate anything -- since they are essentially 'what if Johnny Reb was fighting in 1943?' Well, he wasn't, and that 'musket squad' in TOAW is a meaningless superfluity in a sense.

Third, particularly as more refinements are made, changes have a cost. That is to say, something is lost as well as something gained. Like, the 'new supply rules' may be fine 'n dandy -- but you can't use sea roads with them. Some bars to cheating were imposed -- and wrecked Ben's 'Grand Strategy,' which depended on being able to load ongoing PBEM games into the editor.

I tend to like changes that are elegant -- that produce a lot of improvement while adding a minimum of additional complexity. That are actually based on military fact. That address major flaws or holes in the system.

I dislike changes that actually move away from valid simulation. That add material that doesn't simulate anything that actually existed. That involve inordinate work and complexity for minimal gain. That leave the fundamental problem untouched. Like, AA has been fiddled with three times now. Until the essential problem -- that AA's primary impact isn't how many planes it shoots down -- is addressed, we really won't get very far.

[ColinWright]

ORIGINAL: Telumar

+1

I think what most people want to see is a hierarchical OOB with assigning/reassigning units between formations. And volume based supply. Quite a task for Ralph time wise, i know.

I also think the game needs to be expanded where it already outstands - and that is the flexibility to model more than one specific time/war/theatre. So, make it more flexible, begin with making the editor parameters (Movement Bias, ZOC cost, Movement Cost for Supply/Readiness, Engineering Build Rate etc, but also Force Proficiencies and things like Electronic Support etc) editable/changeable by the event engine. More weather control for designers, changeable terrain. Add additionally a possibility for designers to divide the map into certain areas where such parameters can be applied per area. (i think we had this years ago in a chat with Jamiam).

For expanding eras, one needs density penalties adjusted. I believe we just got that.

One might also want some kind of 'negative' density requirement. Could a Civil War infantry regiment really do anything to keep another infantry regiment from marching right by it three kilometers away? Lee couldn't have meaningfully 'surrounded' the Army of the Potomac at Gettysburg by having Stuart's cavalry fan out to occupy all the hexes around the location.

Finally, supply would need to be radically different. Napoleon didn't particularly need to bring up fresh powder and shot from Paris -- it wasn't the end of the world if Kutuzov got behind him. Had it been, the Russians would have had no problem cutting off the Grand Armee as soon as it started marching East -- it would have expired long before it got to Bordino. What Napoleon did need access to was food and shelter. He had to be somewhere his troops could subsist. If one reads Civil War history, a lot of where units went had to do with the prospects for food and forage in the immediate vicinity.

It wasn't totally different from WW2 (TOAW's 'home' era). In World War Two as well, the British in Iran pulled their units back to warmer climes for the winter. Conversely, Lee certainly didn't want Grant astride the Southside Railroad. But while in TOAW, what things are like where you are doesn't matter a bit as long as you're astride a railway, in the American Civil War a railway was nice, but green meadows and full barns in the immediate vicinity were a plus too. We'd need some kind of foraging rule if we wanted to go back before World War One.

[ColinWright]

ORIGINAL: Telumar

+1

I think what most people want to see is a hierarchical OOB with assigning/reassigning units between formations. And volume based supply. Quite a task for Ralph time wise, i know...

Yeah. Hierarchical OOB's would be nice. As it is, one winds up with independent combat formations on the same plane as 'support formations' consisting of army artillery, construction units, miscellaneous-brigades-that-actually-moved-around-a-lot, and so on.

It's not a crippling problem, but it's also not particularly good simulation.

Jarek the Pole once had a lovely idea about specifying what was in all the potential subdivided units. So you could have your panzer division -- and its panzer regiment, its panzergrenadier regiment, etc. Or tailored kampfgruppes. Conversely, task forces could be assembled from components. Like, you could reinforce an infantry regiment with a tank company.

Whatever you wanted. That'll keep Ralph busy.

Less ambitiously, it would be nice if the subdivision penalty could be adjusted by the designer. In some contexts, it's quite inappropriate.

[Panama]

Could always allow the scenario designer to scale AAA lethality.

If you look at GG War in the East it would seem he's been reading the wish list. [:D]

[Telumar]

ORIGINAL: ColinWright

ORIGINAL: Telumar

+1

I think what most people want to see is a hierarchical OOB with assigning/reassigning units between formations. And volume based supply. Quite a task for Ralph time wise, i know...

Yeah. Hierarchical OOB's would be nice. As it is, one winds up with independent combat formations on the same plane as 'support formations' consisting of army artillery, construction units, miscellaneous-brigades-that-actually-moved-around-a-lot, and so on.

It's not a crippling problem, but it's also not particularly good simulation.

Jarek the Pole once had a lovely idea about specifying what was in all the potential subdivided units. So you could have your panzer division -- and its panzer regiment, its panzergrenadier regiment, etc. Or tailored kampfgruppes. Conversely, task forces could be assembled from components. Like, you could reinforce an infantry regiment with a tank company.

Whatever you wanted. That'll keep Ralph busy.

Less ambitiously, it would be nice if the subdivision penalty could be adjusted by the designer. In some contexts, it's quite inappropriate.

Yes i remember Jarek's idea, was a good one. .. a bit like in WitE now.

Agree on the subdivision proficiency penalty.

I think it's all already in the wishlist.

I have no problem with any of your suggestions -- in particular, being able to reassign units would be nice -- but in general, I'd add a few caveats.

First, the system shouldn't grow so complex and arcane that it's inaccessible to new users. From some of the comments I've seen, it already pushes the envelope in that respect. I got into this because I could sit down and start playing without undue suffering. That aspect needs to be kept. Else we become the secret cell of the twelve players of TOAW.

Second, the improvements have to actually be good ones. One of the worst moments in this game's history was when ACOW replaced WGOTY -- and added a whole suite of weapons going back to the Napoleonic era without doing anything to actually allow for the differences in combat in different eras. As (and here I once again risk the wrath of the awful Curtis) several people have found, even if one does have the cannon and infantry types, this game still can't do the American Civil War very well. It irritates me to have weapons that don't actually simulate anything -- since they are essentially 'what if Johnny Reb was fighting in 1943?' Well, he wasn't, and that 'musket squad' in TOAW is a meaningless superfluity in a sense.

Third, particularly as more refinements are made, changes have a cost. That is to say, something is lost as well as something gained. Like, the 'new supply rules' may be fine 'n dandy -- but you can't use sea roads with them. Some bars to cheating were imposed -- and wrecked Ben's 'Grand Strategy,' which depended on being able to load ongoing PBEM games into the editor.

I tend to like changes that are elegant -- that produce a lot of improvement while adding a minimum of additional complexity. That are actually based on military fact. That address major flaws or holes in the system.

I dislike changes that actually move away from valid simulation. That add material that doesn't simulate anything that actually existed. That involve inordinate work and complexity for minimal gain. That leave the fundamental problem untouched. Like, AA has been fiddled with three times now. Until the essential problem -- that AA's primary impact isn't how many planes it shoots down -- is addressed, we really won't get very far.

When i first started COW it was very intuitive, you move this unit and this unit, all very accessible. And this it is still. For comparison: When i opened a HPS/PzC game for the first time it's been a nightmare... It took me quite a while until i found out how to move a unit...
So which comments do you mean? There have been a lot of questions regarding game options and the new menue. Also note that the tutorial(s) explain GUI things with the old options.

Regarding complexity, you're somehow painting it black with your 12 disciples of TOAW. I don't want to play Panzer General.. so a bit complexity is required. Also, look at WitE (again..). This is complex, but you can leave a lot of micromangement to the computer. That's the way it should be. And the quintessence of your post i would say.

[ColinWright]

ORIGINAL: Panama

Could always allow the scenario designer to scale AAA lethality.

That's been done. However, the basic point is that even when it doesn't shoot down many planes, AA does a lot to protect targets.

Look up the history of those British vessels sunk off Crete. While the AA was banging away, not many German planes were going down -- but no British ships were getting sunk either.

It was when the formations got broken up -- and the AA ammunition ran out -- that the slaughter started.

Similarly, while I doubt that German flak inflicted crippling losses on Allied airpower in 1944-45, its presence allowed the German forces to retain some effectiveness. Had the Allies just been able to tee off on their targets the way the Germans could in 1939-1941, resistance would have indeed proved futile. Compared to the Germans in 1939-41, the Allies of 1944-45 had overwhelming air power.

Flak doesn't work by shooting down planes. That's a nice bonus, but it doesn't derive its effect from that. It derives its effect from forcing them to modify their behavior.

A classic example of this comes from the experience of the French tactical bombing squadrons in the opening days of the 1940 campaign. In common with some other forces of the period, they had a doctrine of coming in low and straight. Attacks on the first two days were quite effective -- but half the planes were getting shot down on each sortie.

Thereafter they started behaving differently. Still went on on sorties, but didn't suffer such heavy losses.

Also, didn't hit much. How flak works.

As I've said before, it's a bit like your local police department. How do you know they're having an effect? Because they shot 8532 people last year? No -- because every young punk doesn't just go out and find an old lady to beat up when he's a bit short of cash. They -- like flak -- force a change in behavior.

In my view, the effect of airpower should be -- absent flak -- several times what it is now. Aircraft are devastating against forces that have no effective defense.

However, that effect should be divided by the total AA power of the hex under attack. So a given number of aircraft attacking a given target would have a greater or lesser effect depending on the flak present. Naturally, a few planes would get shot down as well -- but that's not really the point.

[ColinWright]

ORIGINAL: Telumar

I think it's all already in the wishlist.

I could be wrong, but I have my suspicions about that wishlist...

When my mother was still alive, she would ask me to do this and that. I would tell her I'd put it down on my list of things to do.

She always found that reassuring...if you get my drift.

So which comments do you mean?

I've just noticed various newbies saying 'I don't get how to...'

Not that I'm saying we're already too complex. Just that obviously, there is some point at which those of us who are already familiar with the system will be comfortable, but newcomers would be lost.

It's a bit like the social conventions of some imaginary society. For those who have grown up in it, they're really no challenge at all. It doesn't follow that they can't get so arcane that newcomers will be at a loss.

It's just something to be borne in mind.

Regarding complexity, you're somehow painting it black with your 12 disciples of TOAW.

I'm not saying it is that way -- or even getting that way. After all, reality is the perfect simulation -- but in reality, it requires a full-time staff of a dozen to manage three units. That is not what we want. Obviously, at all times, some simplifications, omissions, and generalizations have to be made. When somebody proposes different categories of supply, for example, I ask -- well, how often does one run out but the other doesn't? If if isn't a chronic problem, do we really want to detail it?

[Panama]

ORIGINAL: ColinWright

I've just noticed various newbies saying 'I don't get how to...'

What they don't 'get how to' is read. They are usually too lazy to take the time to find the information themselves. One of the most common 'I don't get how to' is control the pop up when you are hovering over the map. Or how to get the right click menu. Both very simple but very commonly asked about.

This is a simple game. There isn't much reading to do. It's more along the lines of a Sim City game than a Victoria 2 game or GG War in the East game. Not a lot of rules.

[Curtis Lemay]

ORIGINAL: ColinWright

ORIGINAL: Curtis Lemay

ORIGINAL: Panama

We want to see something that works 100% of the time. Roads/rails that cross rivers can be blowed up. Roads/rails that parallel rivers are not bridges, never were intended to be bridges and no amount of obfuscation can make them bridges so don't allow them to be destroyed.

And, again, that is exactly what the Matrix will do. Colin is still trying to convince you that road/rails that parallel rivers are bridges and should be treated as bridges. Don't buy his Kool-aid.

As I've demonstrated by referring to three completely different rivers flowing through completely different types of terrain, a road that appears to be 'paralleling' the river is as likely to contain the bridge as any other hex containing the river and the road.

This is up there (or down there) with your 'wadis are trenches' claim. Worse, this time you are asserting that you're actually going to impose your nonsense on the rest of us.

No, it is not. And it doesn't matter how often you repeat that idiotic claim. A road paralleling a river is vastly more likely to be paralleling the river, not veering back and forth across it over and over. That's what this whole discussion is about. No issue would have ever even been raised if players were ok with their opponents blowing a huge number of such hexes. They aren't and they are correct to feel that way.

The matrix fixes that exact problem for existing scenarios, and creates a way to set which hex has or doesn't have a bridge in it at the designer's pleasure that is equivalent to a dedicated tile set. It also has the advantages of being the simplest to program, gives players a natural graphical heads-up that there is or isn't a bridge in the hex, and, finally, potentially can solve the second issue about using a road to cross a river even though there isn't a crossing there.

It's better on every point. And, note that if it is optional, it isn't imposed on anyone.

And wadis obviously have trench properties (long depression in the ground). They don't have river properties (a water barrier).

[Curtis Lemay]

ORIGINAL: ColinWright

Ummm...

Because the available graphics give them no choice?

Because in fact the road is in that hex?

Because moving it, aside from being inaccurate geographically, will create worse problems?

It seems to me that road winds up in that hex for about the same reasons anything winds up in any hex.

You want to substitute a routine that will declare some hexes bridges and others not without reference to the reality on the ground for a routine that at least has the virtue of simplicity and clarity. Currently, you put a road into a river hex, you know you're going to get a bridge. With your change, one will have to go -- 'oh this makes it a bridge. Now, how can I route things so that it's not a bridge?'

I still don't see any need for this. But, note that it is possible with the Matrix rules. See the attached version of your road-river map. Now there is no bridge in the lower hex and there is one in the upper hex. And the road is paralleling the river. And note that there are no game effects for the changes to the river. It will still function exactly as it did before.

Note that, while its appearance is not ideal, it would be wrong with a tile, too: the river crossing would be in the lower hex, while the bridge would be in the upper, and the road appear on the east, while it was actually on the west.

So, anything a designer could have done with a dedicated tile, they will be able to do with the Matrix rules.

[Curtis Lemay]

ORIGINAL: Telumar

I think what most people want to see is a hierarchical OOB with assigning/reassigning units between formations.

That seems to me to get us right back where we are now. Tie units down with a hierachy, then release them with reassignment. So, you can still send units all over the map regardless of assignments - it just adds a bit of overhead work to then reassign them to nearby formations.

[1_Lzard]

Bob,

See my responce on the other forum, please....


Kurt

[ColinWright]

ORIGINAL: Curtis Lemay



So, anything a designer could have done with a dedicated tile, they will be able to do with the Matrix rules.

In other words, the damage this will do is minimal, and can be rectified with a bit of work.

Of course and on the other hand, there's no benefit at all. How about just not doing it?

[ColinWright]

ORIGINAL: Curtis Lemay

ORIGINAL: ColinWright

ORIGINAL: Curtis Lemay




And, again, that is exactly what the Matrix will do. Colin is still trying to convince you that road/rails that parallel rivers are bridges and should be treated as bridges. Don't buy his Kool-aid.

As I've demonstrated by referring to three completely different rivers flowing through completely different types of terrain, a road that appears to be 'paralleling' the river is as likely to contain the bridge as any other hex containing the river and the road.

This is up there (or down there) with your 'wadis are trenches' claim. Worse, this time you are asserting that you're actually going to impose your nonsense on the rest of us.

No, it is not. And it doesn't matter how often you repeat that idiotic claim. A road paralleling a river is vastly more likely to be paralleling the river, not veering back and forth across it over and over. That's what this whole discussion is about. No issue would have ever even been raised if players were ok with their opponents blowing a huge number of such hexes. They aren't and they are correct to feel that way.

The matrix fixes that exact problem for existing scenarios, and creates a way to set which hex has or doesn't have a bridge in it at the designer's pleasure that is equivalent to a dedicated tile set. It also has the advantages of being the simplest to program, gives players a natural graphical heads-up that there is or isn't a bridge in the hex, and, finally, potentially can solve the second issue about using a road to cross a river even though there isn't a crossing there.

It's better on every point. And, note that if it is optional, it isn't imposed on anyone.

And wadis obviously have trench properties (long depression in the ground). They don't have river properties (a water barrier).

Sure Curtis. We recall the impressive arguments you posted at the time.

[ColinWright]

ORIGINAL: Curtis Lemay

ORIGINAL: Telumar

I think what most people want to see is a hierarchical OOB with assigning/reassigning units between formations.

That seems to me to get us right back where we are now. Tie units down with a hierachy, then release them with reassignment. So, you can still send units all over the map regardless of assignments - it just adds a bit of overhead work to then reassign them to nearby formations.

This is valid -- if there are no restrictions and/or if the designer cannot control the effect.

On the other hand, for those of us who do more than just copy SPI games, there is a recurring problem.

When we look at actual history, reassignments occur continually. Units sometimes are 'sent all over the map.' The rigid, unchangeable formations of TOAW may be relatively easy to program, but they aren't accurate simulation.

I'd suggest a 'reassign formation' value that the designer could set at anything from 0 to 100% of that turn's movement allowance for the unit in question -- for each force -- or even disallow entirely.

Then too, if formations were hierarchical, and the supply, formation proficiency levels, and form'n orders set at each level, I imagine some bright spark could come up with some interesting effects. Like, you can have your 'SS Panzer Army' appear for the Ardennes offensive. Formations that are assigned to it might be in static deployment until der tag, but would have better supply than those not assigned, and would be able to build up strength for the upcoming offensive.

[ColinWright]

ORIGINAL: 1_Lzard

Bob,

See my responce on the other forum, please....


Kurt

WHAT other forum?

[ColinWright]

And just for the record...


'you repeat this idiotic claim'

'Don't buy his kool-aid,'

'only an imbecile would draw it that way'

'I know you're full of it'

'you can repeat your nonsense indefinitely'

'this endless deluge of stupidity.'


Ever notice that the weaker the point is you're attempting to make, the more abusive you become?