RE: Comprehensive Wishlist

RE: Comprehensive Wishlist (Full Version)

All Forums >> [Current Games From Matrix.] >> [World War II] >> Norm Koger's The Operational Art Of War III >> Scenario Design

Message

Martin_Goliath -> RE: Comprehensive Wishlist (1/10/2011 4:04:48 PM)
quote: ORIGINAL: Curtis Lemay A very good list - although I still see the Sphere as impractical if not impossible. You are probably right about the sphere - I was surprised to find it on the wish list, and couldn't resist putting it on my shortlist! 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. Yes, lots of testing indeed! I have tried to deduce some of the mechanics by careful reading of extended log files (überdude & c) for trivial setups, but I guess I will have to wait until retirement to get the appropriate time... Martin

Oberst_Klink -> RE: Comprehensive Wishlist (2/23/2011 4:57:13 PM)
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

ColinWright -> RE: Comprehensive Wishlist (2/25/2011 4:11:18 AM)
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 It's a thought. One does have to pay the river cost to enter the river-road hex except along the road, so offhand one could make it only possible to blow the 'bridge' where roads/RR enter the river hex from a non-river hex. To gain access to that road, a unit would still need to pay the river cost at some point in its travels. It wouldn't be perfect, but it would address much of what you are complaining about -- and the current situation where one either has to lay the road one hex away from the river or accept that it can be 'blown' along its entire length is less than satisfactory.

Telumar -> RE: Comprehensive Wishlist (3/8/2011 2:50:58 PM)
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?

ColinWright -> RE: Comprehensive Wishlist (3/18/2011 8:34:44 PM)
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? Just being able to do it in the force editor would be a major help. It's a real nuisance deciding that the 317 Rifle Division should have 30% proficiency and be untried -- then have to exit the force editor, go to the deployment editor to make the change, exit the deployment editor, go back to the force editor... ...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...

Curtis Lemay -> RE: Comprehensive Wishlist (3/19/2011 4:53:15 PM)
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? I'm not discounting your idea - which is fine, but I just want to point out that a little foresight can avoid the need for this. Just set the first unit you create to veteran, and all copies of it will be veteran as well. Same for copied formations, etc.

Curtis Lemay -> RE: Comprehensive Wishlist (3/19/2011 4:56:55 PM)
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... Just wait till we have 10,000 event slots and 10,000 units per force.

Curtis Lemay -> RE: Comprehensive Wishlist (3/19/2011 5:03:17 PM)
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.)

sPzAbt653 -> RE: Comprehensive Wishlist (3/19/2011 5:12:51 PM)
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 ?

ColinWright -> RE: Comprehensive Wishlist (3/19/2011 5:19:00 PM)
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.) How do you figure? It seems to me that the program merely needs to identify when a road or rail line connects to a non-river hex. This would create the possibility that both the road and the rail bridge could be blown when only one had left the river -- but that would still be an improvement over the current situation. So it can still be blown in that case. Oh well. Still an improvement over the current situation -- where both can be blown even when neither has exited. 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. Of course, one might still feel the need to lay roads and rails one hex off the river. What this doesn't address -- and which is a greater problem -- is that a road 'along' a river still permits one to cross the river. If that rail line running along the east bank of the Volga is actually put in the same hex as the river, units (and supplies) can cross the river without assistance at any point. Amphibious tank brigades. Able to swim half a kilometer of open water.

ColinWright -> RE: Comprehensive Wishlist (3/19/2011 5:29:08 PM)
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 ? Maybe reverse that. Destructible road, destructible rail. That way, one could demolish roads through mountain passes, simulate blowing up tunnels, laying minefields, etc. Rommel can slow Montgomery's pursuit by 'mining' the road behind him. Still doesn't deal with the fact that a road/rail effectively runs down both banks of a river and permits crossing at all points, though. I don't see any way out of that except hex-side rivers (use the code for escarpments?). Happily, it's not the worst problem. One can usually just lay the road/rail one hex away from the river. Not super accurate, but it serves for most cases.

Curtis Lemay -> RE: Comprehensive Wishlist (3/20/2011 5:08:02 AM)
quote: ORIGINAL: ColinWright How do you figure? I was merely figuring that it would need to be done right. 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. Or a fork in the river. Or a tributary. Just looking at my France 1944 map, I see lots of legitimate bridges that couldn't be blown.

Curtis Lemay -> RE: Comprehensive Wishlist (3/20/2011 5:09:09 AM)
quote: ORIGINAL: ColinWright quote: ORIGINAL: sPzAbt653 Maybe a new terrain type - permanent road, permanent rail ? Maybe reverse that. That might work. Won't help existing scenarios, though.

Curtis Lemay -> RE: Comprehensive Wishlist (3/20/2011 4:49:00 PM)
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.) Actually, I was overthinking this. You can treat roads and rails separately. So, there would be a 64 x 64 = 4096 matrix for roads and a similar one for rails (they might even be identical - I don't know). Then, if the hex contained both road and rail then if either said it could be blown then it could be. 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.

ColinWright -> RE: Comprehensive Wishlist (3/20/2011 6:16:59 PM)
quote: ORIGINAL: Curtis Lemay That might work. Won't help existing scenarios, though. That's hardly a conclusive argument. One could say that about half the changes that have been made. Supply units don't help scenarios that don't have them, for example. On reflection, if anything is to be done about the problem at all, I think adding 'destructible' roads and rails to the terrain suit is the best solution. In fact, bite the bullet and add a whole new column to the terrain types display. We could also use 'super plain' terrain and something a little less violent than bocage to simulate hedged and walled farmland. As it is, we're stuck between the decidedly anaemic 'cropland' and 'impassible fortress' for our agricultural land types. A 'dry river' terrain type would allow you to think what you want about wadis and me to think what I want. Then there's... To return to the specific proposition, creating 'destructible' roads and rails does raise the problem that the existing roads and rails remain destructible under certain cases -- and should remain destructible in existing scenarios. Therefore, we'd also need a switch in the editor with a default setting of 'off' to make 'non-destructible' roads and bridges truly non-destructible if the designer so wished. That way, roads and rails could snake along rivers all the designer wanted -- and couldn't be blown except where he felt that they could. Conversely, I can thoroughly wreck I-80 behind me as I retreat over Donner Summit and prepare to defend Festung California. Of course, the problem that units can effectively cross said river at any point so long as they enter along the road isn't addressed at all...

Curtis Lemay -> RE: Comprehensive Wishlist (3/20/2011 10:28:49 PM)
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.

ColinWright -> RE: Comprehensive Wishlist (3/21/2011 5:07:38 PM)
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. I have some vague idea what you're talking about, but it all strikes me as academic. Wouldn't it be better -- and perhaps easier -- to allow the designer to simply designate which roads and rails can or cannot be 'blown'?

Curtis Lemay -> RE: Comprehensive Wishlist (3/21/2011 9:17:28 PM)
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.

sPzAbt653 -> RE: Comprehensive Wishlist (3/22/2011 12:48:55 AM)
... 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.

ColinWright -> RE: Comprehensive Wishlist (3/22/2011 4:59:29 AM)
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. 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. Just a thought...

Curtis Lemay -> RE: Comprehensive Wishlist (3/22/2011 11:45:04 PM)
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.

Curtis Lemay -> RE: Comprehensive Wishlist (3/22/2011 11:47:26 PM)
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.

ColinWright -> RE: Comprehensive Wishlist (3/23/2011 12:05:40 AM)
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. 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 -> RE: Comprehensive Wishlist (3/23/2011 12:11:18 AM)
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. 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 -> RE: Comprehensive Wishlist (3/23/2011 12:19:05 AM)
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 -> RE: Comprehensive Wishlist (3/23/2011 1:10:32 AM)
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 ... 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 ----------------------- [image]local://upfiles/24850/501ADF50A579473EA48E8590C2966D1C.jpg[/image]

Curtis Lemay -> RE: Comprehensive Wishlist (3/23/2011 2:26:00 AM)
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. Not entirely. See above. quote: 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 -> RE: Comprehensive Wishlist (3/23/2011 2:29:44 AM)
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.

Curtis Lemay -> RE: Comprehensive Wishlist (3/23/2011 2:32:17 AM)
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. I can only think of the two options I mentioned. Neither are simple.

ColinWright -> RE: Comprehensive Wishlist (3/23/2011 5:55:14 AM)
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. Now you seem to be equivocating. So you don't see any real problem with adding additional tiles?

Page: << < prev 45 46 [47] 48 49 next > >>

Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI

4.96875