Comprehensive Wishlist

[Curtis Lemay]

ORIGINAL: sPzAbt653

... allow the designer to simply designate which roads and rails can or cannot be 'blown'?

Hmm ... well ... if the program recognizes that a unit has moved onto a 'bridge' hex, thus allowing the 'destroy bridge' option to become available, it does seem that a designer option to 'block destroy bridge' or to tick a 'permanent bridge' flag would be simple. In my simple mind, that is.

But where is that info going to be saved? If it's a new map parameter (like "Distance Hex") then that will require the Map Format to be revised to incorporate that new parameter (while still handling old map formats from old scenarios). Nothing simple about doing that.

If, like Colin wants, it's a new tile type that has a parameter that prevents/allows it to be blown, then that, obviously, requires those new tiles and whatever overhead new tiles require in order to be used in the editor and recognized in the game. I don't really know how easy or difficult that would be, but we haven't added any new tiles yet, in multiple years of coding.

Contrast this to the matrix. Somewhere in the code is a line that works out to something like:

"IF (river AND road) THEN allow bridge blowing"

This would be modified to something like:

"IF ((river AND road) AND matrix(i,j)) THEN allow bridge blowing"

Where i is the index to the river pattern and j is the index to the road pattern. It doesn't even require an additional line of code - just a modification to an existing one. The matrix itself would be a Constant Array included in the code. Or, it might be externalized with folder hierarchy so designers could edit it as desired. And remember, this helps all existing scenarios without the need for designer editing.

[Curtis Lemay]

ORIGINAL: ColinWright

It's not exactly an ideal solution -- but one could get around that by allowing tile substitutions. Not all tiles are relevant to all scenarios. One doesn't need bocage for a Western Desert scenario. 'Arid' is pretty irrelevant to Northern Europe.

?? If I understand you, that can be done now - but it only changes the appearance of the tile, not its parameters. For that, you've got to have a new tile type with a new parameter.

[ColinWright]

ORIGINAL: Curtis Lemay

ORIGINAL: sPzAbt653

... allow the designer to simply designate which roads and rails can or cannot be 'blown'?

Hmm ... well ... if the program recognizes that a unit has moved onto a 'bridge' hex, thus allowing the 'destroy bridge' option to become available, it does seem that a designer option to 'block destroy bridge' or to tick a 'permanent bridge' flag would be simple. In my simple mind, that is.

But where is that info going to be saved? If it's a new map parameter (like "Distance Hex") then that will require the Map Format to be revised to incorporate that new parameter (while still handling old map formats from old scenarios). Nothing simple about doing that.

If, like Colin wants, it's a new tile type that has a parameter that prevents/allows it to be blown, then that, obviously, requires those new tiles and whatever overhead new tiles require in order to be used in the editor and recognized in the game. I don't really know how easy or difficult that would be, but we haven't added any new tiles yet, in multiple years of coding.

Contrast this to the matrix. Somewhere in the code is a line that works out to something like:

"IF (river AND road) THEN allow bridge blowing"

This would be modified to something like:

"IF ((river AND road) AND matrix(i,j)) THEN allow bridge blowing"

Where i is the index to the river pattern and j is the index to the road pattern. It doesn't even require an additional line of code - just a modification to an existing one. The matrix itself would be a Constant Array included in the code. Or, it might be externalized with folder hierarchy so designers could edit it as desired. And remember, this helps all existing scenarios without the need for designer editing.

But this last takes the decision out of the hands of the designer. What if he wants a bridge to be blowable that 'the matrix' doesn't think should be blowable? Like if at that point the road crosses from one bank to another? Or if the road is running along a steep river canyon and can in fact be destroyed at any point? Consider I-70 running down the Colorado. It could be 'blown' at almost any point over certain stretches.

Any solution that leaves the choice up to the designer is ipso facto vastly superior to any solution that doesn't.

[ColinWright]

ORIGINAL: Curtis Lemay

ORIGINAL: ColinWright

It's not exactly an ideal solution -- but one could get around that by allowing tile substitutions. Not all tiles are relevant to all scenarios. One doesn't need bocage for a Western Desert scenario. 'Arid' is pretty irrelevant to Northern Europe.

?? If I understand you, that can be done now - but it only changes the appearance of the tile, not its parameters. For that, you've got to have a new tile type with a new parameter.

Indeed. Of course I meant the parameters as well as the appearance. I already mark up the appearances no end.

Anyway, it's just a subsidiary consideration. Even if the game itself can only handle twenty four terrain types, or whatever, that may not prevent having a suite of alternate terrain types that the designer can plug in.

Alternatively, open things up to allow editing of the parameters of the existing terrain types. Like, if I feel like it I can reduce 'bocage' to a terrain type that existed somewhere outside of Norm Kroger's imagination.

[ColinWright]

Terrain types that are not present or needed in all scenarios, and therefore potentially available for changes.

'snowy.' 'jungle.' 'bocage.' 'contaminated.' 'peaks.' 'alpine.' 'mountain.' 'arid.' 'dunes.' 'dense urban.' 'dense urban ruin.' 'deep water.' 'shallow water.' 'flooded marsh.' 'improved road.' 'unimproved road.' 'anchorages.' 'rail lines.' 'destroyed rail lines.'

...and probably some others.

Additional terrain types that would be useful.

something that blocks supply but not mechanized movement.

something that blocks mechanized movement but not supply.

terrain that can change from 'marsh' to 'flooded marsh' and back again.

'super open' terrain.

blowable roads and rails.

[sPzAbt653]

... If it's a new map parameter (like "Distance Hex") then that will require the Map Format to be revised to incorporate that new parameter ...

I have no idea, I was just throwing in an observation, that the program, somehow, somewhere, knows that it is not to destroy bridges in some cases and to allow it in others. Give the designer a choice to intercede the programs choice right there in the editor, if desired. As I said, in my simple mind.

-----------------------
Destroy Bridges
No Bridge (or whatever term is best appropriate)
Repair Bridges
-----------------------

[Curtis Lemay]

ORIGINAL: ColinWright

ORIGINAL: Curtis Lemay

...Or, it might be externalized with folder hierarchy so designers could edit it as desired...

But this last takes the decision out of the hands of the designer.

Not entirely. See above.

Any solution that leaves the choice up to the designer is ipso facto vastly superior to any solution that doesn't.

At this point, any solution that requires designer intervention is inferior to any solution that doesn't.

[Curtis Lemay]

ORIGINAL: ColinWright

Even if the game itself can only handle twenty four terrain types, or whatever, that may not prevent having a suite of alternate terrain types that the designer can plug in.

I doubt that the number of terrain types would be the real issue.

[Curtis Lemay]

ORIGINAL: sPzAbt653

[quoteI have no idea, I was just throwing in an observation, that the program, somehow, somewhere, knows that it is not to destroy bridges in some cases and to allow it in others. Give the designer a choice to intercede the programs choice right there in the editor, if desired. As I said, in my simple mind.

I can only think of the two options I mentioned. Neither are simple.

[ColinWright]

ORIGINAL: Curtis Lemay

ORIGINAL: ColinWright

Even if the game itself can only handle twenty four terrain types, or whatever, that may not prevent having a suite of alternate terrain types that the designer can plug in.

I doubt that the number of terrain types would be the real issue.

Now you seem to be equivocating. So you don't see any real problem with adding additional tiles?

[ColinWright]

ORIGINAL: Curtis Lemay
At this point, any solution that requires designer intervention is inferior to any solution that doesn't.

! As far as I'm concerned, the primary appeal of TOAW is the ability to design scenarios.

Given that, if I'm faced with a choice between having to specify parameters where I might be content with a built-in setting, and having a parameter set for me other than I would wish, I'll take the former.

Anyway, there are always default settings. For example, I simply haven't ever bothered to tamper with the attrition divider -- never seen a clear need. That doesn't 'require' my intervention, and I suspect you'd have to go out of your way to 'require' designer intervention in any respect.

We could create a thousand optional terrain types, and even allow the parameters for each to be altered by the designer. The defaults would still be there.

[ColinWright]

ORIGINAL: sPzAbt653

... If it's a new map parameter (like "Distance Hex") then that will require the Map Format to be revised to incorporate that new parameter ...

I have no idea, I was just throwing in an observation, that the program, somehow, somewhere, knows that it is not to destroy bridges in some cases and to allow it in others. Give the designer a choice to intercede the programs choice right there in the editor, if desired. As I said, in my simple mind.

-----------------------
Destroy Bridges
No Bridge (or whatever term is best appropriate)
Repair Bridges
-----------------------

You definitely get a prize for clarity with this one.

[sPzAbt653]

Yeah, but I lost in the practicality department.

We did some terrain changes for D21 (changed dunes to look like spooky Finnish forests) but then had to include a separate .dll file. Don't know why, but again that goes to lack of knowledge in these matters.

... the primary appeal of TOAW is the ability to design scenarios.

I definately agree, but that's just me. I know some hate editing.

[Curtis Lemay]

ORIGINAL: ColinWright

Now you seem to be equivocating. So you don't see any real problem with adding additional tiles?

There would be far more involved than just increasing the tile counter. For example, there's implementing the tiles' new features.

[Curtis Lemay]

ORIGINAL: ColinWright

! As far as I'm concerned, the primary appeal of TOAW is the ability to design scenarios.

Given that, if I'm faced with a choice between having to specify parameters where I might be content with a built-in setting, and having a parameter set for me other than I would wish, I'll take the former.

Anyway, there are always default settings. For example, I simply haven't ever bothered to tamper with the attrition divider -- never seen a clear need. That doesn't 'require' my intervention, and I suspect you'd have to go out of your way to 'require' designer intervention in any respect.

We could create a thousand optional terrain types, and even allow the parameters for each to be altered by the designer. The defaults would still be there.

If the solution requires designer intervention then it only benefits those scenarios that will yet be edited by their designers. That's only a tiny fraction of the existing scenarios, and only a fraction of even future scenarios. If it doesn't, on the other hand, then it benefits all scenarios. All vs. a tiny fraction.

[ColinWright]

ORIGINAL: Curtis Lemay

ORIGINAL: ColinWright

! As far as I'm concerned, the primary appeal of TOAW is the ability to design scenarios.

Given that, if I'm faced with a choice between having to specify parameters where I might be content with a built-in setting, and having a parameter set for me other than I would wish, I'll take the former.

Anyway, there are always default settings. For example, I simply haven't ever bothered to tamper with the attrition divider -- never seen a clear need. That doesn't 'require' my intervention, and I suspect you'd have to go out of your way to 'require' designer intervention in any respect.

We could create a thousand optional terrain types, and even allow the parameters for each to be altered by the designer. The defaults would still be there.

If the solution requires designer intervention then it only benefits those scenarios that will yet be edited by their designers. That's only a tiny fraction of the existing scenarios, and only a fraction of even future scenarios. If it doesn't, on the other hand, then it benefits all scenarios. All vs. a tiny fraction.

'A tiny fraction' implies that you see a short future for this game. If otherwise, then the 'tiny' fraction will keep growing. It's like buying a new truck. Makes sense if you're planning to stay in business.

Conversely, fixed 'improvements' depend on the programmers' ability to evaluate the impact on all scenarios -- including those yet to be created. As has already happened, such 'improvements' often have a regrettable impact on not merely scenarios yet to be written but those already created -- which generally, were designed to take advantage of/compensate for aspects of the program that have now been 'fixed.' Like, I was happy with the 'inaccurate' equation for flak that existed. That got 'fixed' and it knocked everything all to hell -- and presumably knocked things to hell in every scenario in which airpower played a major role.

As a general rule, given a choice between suffering through the often apparently whimsical notions the programmers have of what is or is not an improvement, and simply having defaults that stay the same while adding the ability to modify things if the designer sees fit, I'll go with the latter.

Take flak values, early turn ending, and the need to beat back graphics changes -- sometimes with only partial success. Whatever you might think of the various changes that have happened in these areas, as far as I've concerned they've been primarily an irritation that only forces me to go back and readjust things so my scenario still works.

On the other hand, innovations that work by leaving a default in place: supply squads, command squads, the attrition divider, etc -- well, these are great. Some I go to town with, others I ignore -- and no harm done.

Obviously, in not all cases is it possible to have a 'default' and equally obviously, in some cases, there has to be a default. Still, where a choice exists, and as far as the future direction of innovation goes, I'm all for defaults rather than hard-wired change.

[ColinWright]

ORIGINAL: Curtis Lemay

ORIGINAL: ColinWright

Now you seem to be equivocating. So you don't see any real problem with adding additional tiles?

There would be far more involved than just increasing the tile counter. For example, there's implementing the tiles' new features.

So long as the 'features' are just variations on the existing suite of effects on combat, and on movement and supply, I don't see how this can be a case. So we make a 'many hot chicks' terrain type that costs 5 MP's for a unit to cross the hex but doesn't affect combat. So what? Where's the challenge?

[Curtis Lemay]

ORIGINAL: ColinWright

'A tiny fraction' implies that you see a short future for this game. If otherwise, then the 'tiny' fraction will keep growing. It's like buying a new truck. Makes sense if you're planning to stay in business.

I see it lasting less than a century. Considering that there's probably 1,000 scenarios out there that will never be edited again, that's about what it would take for that fraction to even become "middling". And it will never be "All". "All" is always going to be better.

Some things need to be optional and some things don't. Take the Ant Unit fix. Making it optional would have been an unnecessary cost. TOAW is full of features that aren't optional and don't need to be. Limiting bridge-blowing to hexes that actually have bridges in them doesn't seem to me to need to be optional either. It's not like it's subjective. There is either a bridge in the hex or there isn't.

Now, if you want to simulate something else with the bridge-blowing feature, that's still possible - just put a bridge in the hex. But, I would think that needs to be handled via a separate feature. There are critical differences. First, since there was no actual bridge, then fixing it shouldn't require bridge repair ability. Maybe SeaBees, but not true engineers. Maybe not even SeaBees, if, for example, it was just felled trees or such. Second, ferry ability shouldn't be useful for overcoming it at all.

There are similar issues such as upgrading a road from normal to improved, or excessive tracked traffic degrading a road from improved to normal, etc. There are issues with bridge blowing, too - should engineers be required to blow bridges over major rivers?; should bridges over major rivers be harder to repair than normal bridges?

There could be more refinement of bridge-blowing using these matrices - we could blow a rail bridge while leaving the road intact if it lacked a bridge (or vice-versa). It would even be possible to address that other problem you listed: Unit's that enter river hexes by road could be so flagged - then they could only exit the river hex by road or to a hex "on the road-side of the river" unless it paid the river cost. Identifying the hexes that were "on the road-side of the river" would require another matrix that held that information.

[Curtis Lemay]

ORIGINAL: ColinWright

So long as the 'features' are just variations on the existing suite of effects on combat, and on movement and supply, I don't see how this can be a case. So we make a 'many hot chicks' terrain type that costs 5 MP's for a unit to cross the hex but doesn't affect combat. So what? Where's the challenge?

I don't really know how difficult it would be. I do know that no new tiles have been added after years of programming.

And, the matrix idea really is trivial, as I explained before. Wouldn't even require a new line of code.

[ColinWright]

ORIGINAL: Curtis Lemay

ORIGINAL: ColinWright

'A tiny fraction' implies that you see a short future for this game. If otherwise, then the 'tiny' fraction will keep growing. It's like buying a new truck. Makes sense if you're planning to stay in business.

I see it lasting less than a century. Considering that there's probably 1,000 scenarios out there that will never be edited again, that's about what it would take for that fraction to even become "middling". And it will never be "All". "All" is always going to be better.

It's beside the point to some extent, but many of these scenarios are garbage to begin with, and in any case, you yourself and your predecessors have cheerfully chewed them up with the various changes that have already been made.

Open up a scenario made under OPART I, and you can get helicopter noises (and movement rates) when you move what was intended to be World War One Turkish infantry. The flak values have gone all over the map. Early turn ending isn't what it used to be. Artillery now has an AT value.

This value attached to 'not wrecking existing scenarios' is only pulled out when it suits. When it's your idea (or that of your predecessors), the bulldozer goes right through the archeological dig without a care.

As things stand, any older scenario would need to be carefully vetted before play and probably reedited to work as intended. So it's the purest hypocrisy to argue for protecting these ancient treasures when really, it's a matter of the proposed change not being to your liking for some other reason entirely.

I'll grant we shouldn't make a change that renders the whole suite of earlier scenarios unplayable. But don't suddenly go over to 'the change in air temperature might wreck the frescos on the ceiling.' This obviously has never been a genuine concern.

Some things need to be optional and some things don't. Take the Ant Unit fix. Making it optional would have been an unnecessary cost.

Probably. But even there. Did you comb the existing bank of scenarios to see if there was one that made use of their previous ability to slow advances to produce a desired effect? Seems perfectly possible to me -- and yet somehow I doubt if you checked...

TOAW is full of features that aren't optional and don't need to be. Limiting bridge-blowing to hexes that actually have bridges in them doesn't seem to me to need to be optional either. It's not like it's subjective. There is either a bridge in the hex or there isn't.

One can just as easily redefine this as 'either the road can be temporarily rendered unusable or it can't.' Then suddenly there's no reason why the ability to destroy bridges should be confined to river crossings at all.

Now, if you want to simulate something else with the bridge-blowing feature, that's still possible - just put a bridge in the hex. But, I would think that needs to be handled via a separate feature. There are critical differences. First, since there was no actual bridge, then fixing it shouldn't require bridge repair ability. Maybe SeaBees, but not true engineers. Maybe not even SeaBees, if, for example, it was just felled trees or such. Second, ferry ability shouldn't be useful for overcoming it at all.

If you want to call them 'bridges without rivers' rather than 'destructible roads,' that's fine with me. Call them anything you like...

Otherwise, I think you're getting lost in distinctions that the game doesn't make in the first place -- and that don't even exist in reality. Engineers do fix things besides bridges. A lot of the various engineering forces that existed didn't have anything like the combat ability TOAW assigns them. Here, you're wandering into some completely imaginary terrain of a finely crafted weapon that isn't there and doesn't particularly accurately simulate anything that existed in fact.

Actually larger bridges were rebuilt by specialized bridge-building units -- and these would only have been used in combat in a pinch, and then would have been less than elite troops. A lot of ex-civil engineers and navvies stumbling about with the rifles they hadn't fired since basic training...

I already go through changes to get rail repair units that can fight (as some could), and 'engineers' that can't (as some couldn't). It's not like there's some well-thought out and detailed scheme for simulating all the possible variations in military construction units in place. There isn't.

So forget about this aspect of your argument. It has nothing to do with anything -- least of all TOAW. The game itself just says 'some kind of specialized combat/battlefield engineering ability? Engineers. They'll be who fixes your bridges.' It doesn't go into it deeply at all.