Slitherine

quote:

ORIGINAL: Curtis Lemay

A very good list - although I still see the Sphere as impractical if not impossible.

quote:

ORIGINAL: Curtis Lemay

quote:

ORIGINAL: MarGol
(1) Detailed game engine documentation

While desirable, I doubt there's anyone who has that info. And trying to discern TOAW's operation via poking around in the code is a fool's errand. It would have to be determined via rigorous testing.

Also, note that the Wishlist is just for code issues. Somebody once posted a list of scenarios he wanted designed. That's fine, but not for this document. I don't even include equipment suggestions anymore, since one can do that oneself. Same for graphics wishes. So, sorry, no documentation requests for the list - regardless of their merit. Gotta stay on topic.

quote:

ORIGINAL: Oberst_Klink

I might be off subject, but - the roads/RR parallel to rivers. Are there any plans for a routine that simply prevents that they're treated as bridges? When blown up (because they're treated as bridges) you need RR engineers to fix'em. This would be a good thing to change. Not *wasting* resources on poxy detailed naval combat stuff (I can't listen to it anymore). *sigh*

quote:

ORIGINAL: Telumar

What about adding an option to the menue in the Force Editor like Edit -> Modify Current Force/Formation -> Units Veteran Status !!?? This could swap all units of the force or of the selected formation from untried to veteran (or vice versa). Should be easy to code (from my amateur's perspective).

It's annoying, very annoying, to have to go through the entire force and manually change each single unit from untried to veteran. And why on earth has noone until now ever proposed this?

quote:

ORIGINAL: Telumar

What about adding an option to the menue in the Force Editor like Edit -> Modify Current Force/Formation -> Units Veteran Status !!?? This could swap all units of the force or of the selected formation from untried to veteran (or vice versa). Should be easy to code (from my amateur's perspective).

It's annoying, very annoying, to have to go through the entire force and manually change each single unit from untried to veteran. And why on earth has noone until now ever proposed this?

quote:

ORIGINAL: ColinWright

...and while we're on the subject, it would be nice if one could return to where one was in the force editor. Said 317th Rifle Division can easily be about twenty pages down in force two. When one comes back to the force editor, one keeps having to start over again with the first unit in force one, change forces, and scroll down, and down, and down...

Same thing (more or less) with the event editor. One opens it, knows the event one is interested in is somewhere in the 600's, and has to scroll down, and down, and down...

quote:

ORIGINAL: Oberst_Klink

I might be off subject, but - the roads/RR parallel to rivers. Are there any plans for a routine that simply prevents that they're treated as bridges? When blown up (because they're treated as bridges) you need RR engineers to fix'em.

quote:

ORIGINAL: Curtis Lemay

quote:

ORIGINAL: Oberst_Klink

I might be off subject, but - the roads/RR parallel to rivers. Are there any plans for a routine that simply prevents that they're treated as bridges? When blown up (because they're treated as bridges) you need RR engineers to fix'em.

Anybody interested in doing the heavy lifting on this? We would need a matrix showing which river/road/rail combos could be blown and which could not.

(Note: That's 64 x 64 x 64 = 262,144 permutations.)

quote:

ORIGINAL: Curtis Lemay

quote:

ORIGINAL: Oberst_Klink

I might be off subject, but - the roads/RR parallel to rivers. Are there any plans for a routine that simply prevents that they're treated as bridges? When blown up (because they're treated as bridges) you need RR engineers to fix'em.

Anybody interested in doing the heavy lifting on this? We would need a matrix showing which river/road/rail combos could be blown and which could not.

(Note: That's 64 x 64 x 64 = 262,144 permutations.)

quote:

ORIGINAL: sPzAbt653

quote:

ORIGINAL: Curtis Lemay

quote:

ORIGINAL: Oberst_Klink

I might be off subject, but - the roads/RR parallel to rivers. Are there any plans for a routine that simply prevents that they're treated as bridges? When blown up (because they're treated as bridges) you need RR engineers to fix'em.

Anybody interested in doing the heavy lifting on this? We would need a matrix showing which river/road/rail combos could be blown and which could not.

(Note: That's 64 x 64 x 64 = 262,144 permutations.)

Maybe a new terrain type - permanent road, permanent rail ?

quote:

ORIGINAL: ColinWright

How do you figure?

quote:

The only other problem I see is when a road/rail moves to an adjacent hex that contains a different river. However, it will still have to leave the river at some point -- and the program would permit the bridge to be blown there.

quote:

ORIGINAL: ColinWright

quote:

ORIGINAL: sPzAbt653


Maybe a new terrain type - permanent road, permanent rail ?

Maybe reverse that.

quote:

ORIGINAL: Curtis Lemay

Anybody interested in doing the heavy lifting on this? We would need a matrix showing which river/road/rail combos could be blown and which could not.

(Note: That's 64 x 64 x 64 = 262,144 permutations.)

quote:

ORIGINAL: Curtis Lemay





That might work. Won't help existing scenarios, though.

quote:

ORIGINAL: Curtis Lemay

That's almost doable. You make a 64 x 64 map, and fill out each row with the 64 river possibilities and then fill out each column with the 64 road/rail possibilities. Then go through each hex and put a contaminated tile in each hex where the road/rail crosses the river at any point. Then just convert the results to hexadecimal and you have the matrix. Quite a project, but humanly possible.

quote:

ORIGINAL: Curtis Lemay

quote:

ORIGINAL: Curtis Lemay

That's almost doable. You make a 64 x 64 map, and fill out each row with the 64 river possibilities and then fill out each column with the 64 road/rail possibilities. Then go through each hex and put a contaminated tile in each hex where the road/rail crosses the river at any point. Then just convert the results to hexadecimal and you have the matrix. Quite a project, but humanly possible.

Thinking some more about this, if you use XML to make the map, it might not be that difficult. You would only need to enter a code for each possibility, and you would have copy & paste ability as well.

quote:

ORIGINAL: ColinWright

Wouldn't it be better -- and perhaps easier -- to allow the designer to simply designate which roads and rails can or cannot be 'blown'?

quote:

ORIGINAL: Curtis Lemay

quote:

ORIGINAL: ColinWright

Wouldn't it be better -- and perhaps easier -- to allow the designer to simply designate which roads and rails can or cannot be 'blown'?

Creation of the matrix might be difficult - but, as I've been pointing out, that can be outsourced. Once it's created, though, the actual programming task is trivial. And it is better in that it doesn't require all maps to be redesigned to benefit.

That doesn't discount that some new terrain types could be added too. But expanding the tile count will probably be non-trivial.

quote:

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.

quote:

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.

quote:

ORIGINAL: Curtis Lemay

quote:

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.

quote:

ORIGINAL: Curtis Lemay

quote:

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.

quote:

... 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 ...

quote:

ORIGINAL: ColinWright

quote:

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.

quote:

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

quote:

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.

quote:

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.

quote:

ORIGINAL: Curtis Lemay

quote:

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.