Comprehensive Wishlist version 12

[JAMiAM]

ORIGINAL: Jo van der Pluym

ORIGINAL: Curtis Lemay

I was vaguely aware of the Special Forces issue. It seems like an ACOW bug - the designer's choice in the reconstitution panel is being ignored. Are there any others besides those two?

I am only sure of these two. Mayby there are more, but I don't know it.

Not a bug. It was explicitly stated in the CoW manual, as it was in the TOAW III manual. Hence, a feature.

[Jo van der Pluym]

ORIGINAL: JAMiAM

ORIGINAL: Jo van der Pluym

ORIGINAL: Curtis Lemay

I was vaguely aware of the Special Forces issue. It seems like an ACOW bug - the designer's choice in the reconstitution panel is being ignored. Are there any others besides those two?

I am only sure of these two. Mayby there are more, but I don't know it.

Not a bug. It was explicitly stated in the CoW manual, as it was in the TOAW III manual. Hence, a feature.

Then for the wishlist the following wish to delete this feature. And let SF say have 3 to 5 times increased Reconstitution time.

[Curtis Lemay]

ORIGINAL: JAMiAM
Not a bug. It was explicitly stated in the CoW manual, as it was in the TOAW III manual. Hence, a feature.

I think that's a holdover from the original TOAW I manual that was never updated. When the unit reconstitution choice was added to the replacement editor, it obviously should have superceded that condition. Perhaps the default condition in that editor for those units should be "don't reconstitute", but the option should still work.

This is like if we now discover that the new flanking rules don't work and someone points to the manual's description of flanking as proof that they shouldn't work.

[a white rabbit]

ORIGINAL: vahauser

Overall, I agree with Mario that the wishes should be prioritized.  For example, I would make the pre-20th-Century stuff a lower priority than the PBEM stuff.

..[:'(]..

..and then he wants leaders..

..errrr

[Curtis Lemay]

The Wishlist document has now been revised a 7th time. See the same post #1 in the Scenario Design board:

tm.asp?m=1540287&mpage=1&key=&#1540287

Last time's lull in additions must have been a fluke, since the growth of the document was greater than ever this time. I switched from 2 to a 2.5 month update interval, though.

Some of the additions are just reorganizations, but there were a lot of new items. Also, I changed the color of the "completed" items from green to blue in hopes of making it more readable.

[Boonierat]

I noticed yesterday that riverine units can't be deployed on canals in the scenario editor, was it a bug or intentional? I checked the revised wishlist and didn't see it mentioned.

[Curtis Lemay]

ORIGINAL: Boonierat

I noticed yesterday that riverine units can't be deployed on canals in the scenario editor, was it a bug or intentional? I checked the revised wishlist and didn't see it mentioned.

Do riverine units move on canals? The manual doesn't list that. Regardless, there is an obvious work-around that we use for similar issues (deploying a naval unit on a anchorage hex, for example).

[Boonierat]

They do move along canals yes (both types) and I'm aware of the work-arounds. Still I see no reason why they couldn't be deployed on canals.

[Curtis Lemay]

ORIGINAL: Boonierat

They do move along canals yes (both types) and I'm aware of the work-arounds. Still I see no reason why they couldn't be deployed on canals.

As I said there are other similar cases. Rather than fix them all individually, it would be easier to make some sort of general fix. I'm thinking of something like the switch we have now that turns auto-contouring on and off. We could have a similar switch that turns deployment permission on and off. With it off, you could deploy anything anywhere; turn it on and the rules are imposed.

[rhinobones]

ORIGINAL: Curtis Lemay
We could have a similar switch that turns deployment permission on and off. With it off, you could deploy anything anywhere . . .

That certainly sounds risky . . . like a scenario design function just looking for a train wreck. Maybe you want to clarify what you mean by “deploy anything anywhere”.

Regards, RhinoBones

[Curtis Lemay]

ORIGINAL: rhinobones

ORIGINAL: Curtis Lemay
We could have a similar switch that turns deployment permission on and off. With it off, you could deploy anything anywhere . . .

That certainly sounds risky . . . like a scenario design function just looking for a train wreck. Maybe you want to clarify what you mean by “deploy anything anywhere”.

I meant "deploy anything anywhere". Whatever risk would be involved, if any, would be incurred by the designer. The power to do this exists now, via the workaround (change the terrain to a permissible one, deploy, then change back). This would simply enable designers the ease of doing so without the tedious workaround.

[Curtis Lemay]

The Wishlist document has now been revised an 8th time. See the same post #1 in the Scenario Design board:

tm.asp?m=1540287&mpage=1&key=?

[Curtis Lemay]

The Wishlist document has now been revised a 9th time. See the same post #1 in the Scenario Design board:

tm.asp?m=1540287&mpage=1&key=?

Of interest this time are the few new items that have turned "blue" (i.e. been implemented).

[Curtis Lemay]

The Wishlist document has now been revised a 10th time. See the same post #1 in the Scenario Design board:

tm.asp?m=1540287&mpage=1&key=?

[Curtis Lemay]

The Wishlist document has now been revised an 11th time. See post #1378 in the Scenario Design board:

tm.asp?m=1540287&mpage=46

Note that I can't yet delete the version 10 document from post #1 of that thread (permission denied). Just ignore it for now.

[Curtis Lemay]

The Wishlist document has now been revised a 12th time. See post #1748 on page 59, in the Scenario Design board:

tm.asp?m=1540287&mpage=59

Note that I still can't delete the version 10 document in post #1, or the version 11 document in post #1378 on page 46 of this thread. Ignore them. The version on page 59 is the latest version.

[Oberst_Klink]

Smashing! And a happy new year and forthcoming 3.5 version!

Klink, Oberst

[r6kunz]

very nice list. Nice seeing the so many in blue.
Did bringing back diacritical marks make the list?
Will there be a call for new/revised scenarios?
Looking forward...I am not a fan of smileys, but [&o]
cheers

[Anchovy]

Some of my wish-list that I can think of right now. How about allow in-game HQ assignments and 'command radius'?

1. For example, a player can transfer units between two HQs. If the two HQs are separated by a large distance, then the unit being transferred takes significant hit on readiness coupled with minor hit on proficiency.

2. HQs without assigned units and reinforcements not under any particular HQ upon appearance. This would allow reinforcements to be assigned to a HQ as a player sees fit. Likewise, this would allow stand-alone HQs to pick up units later on.

3. Include 'command radius' as part of HQ's attributes. Higher-level HQs have longer 'command radius' than lower-level ones. Assigned units outside this 'command radius' are penalized -- slower readiness/supply recovery, higher likelihood of failure in communications check -- unless they are within the 'command radius' of higher-level HQs. This should discourage units arbitrarily spreading out behind enemy lines.