dwbradley
Posts: 197
Joined: 3/21/2004 Status: offline
|
quote:
ORIGINAL: Andrew Brown quote:
ORIGINAL: dwbradley So my questions are: What portions of my description are not correct? Does the table in 8.3.1 and accompanying text still reflect the most current release(s) of AE? Thanks for your patience in wading through the above. Dave Bradley Dave, you have pretty much got it. The "trail" code (value of 1 for road type) still exists in AE, but it is used, exclusively, for allowing non-entrained movement along railway lines, which would be slower than true road movement, but faster than following a foot trail. Although the road value of 1 is used exclusively to represent railways (for non-entrained movement), there is indeed nothing stopping modders from using this value to represent trails or minor roads if they want to, and use it anywhere on the map, regardless of whether a railway is also in the hex. To reiterate, yet again, how foot trails are represented in AE - they are NOT represented in the pwhexe data. They are assumed to exist in every hex because, pretty much, they DID exist in every hex. The movement rates on foot trails are not fast when the terrain is bad, because I believe that is accurate. But the big difference between the old WitP and AE is that the supply costs of bad terrain are greatly reduced to account for the ubiquitous existence of foot trails in most places. For example, in the old WitP, you could not move more than 1 off-road hex away from a supply source before your supply path was exceeded and your units could not be resupplied. In AE, you can move 5 hexes through jungle terrain, away from a supply source, before you exceed the supply range. You have a lot more ability to move "off road" in AE, due to the impled existence of trail networks. Why was it done like this? Because there are foot trails all over the place. If you draw ALL of them on a map you will have a spider web of foot trails all over the place, even in places such as PNG. Just to repeat - the map was left moddable on purpose - there is nothing stopping people from modding it as they wish. I am just explaining the design philosophy behind the absence of trails from the map data (and map art) in AE. One other correction - movement rates between two adjacent hexes are NOT based on the average of the two movement rates for the two terrain types (if there are no roads present). Consider the following example, of two adjacent hexes, one with jungle and the other clear: 1) If it was an average of the two movement rates, an armoured unit would have a movement rate of (3 + 30)/2 miles per day. That is equal to 15.5 miles per day. To move between the two hexes, a distance of 46 miles, would tale 3 days. Too fast. 2) How it is meant to be calculated is as a combination of two half-hex moves. So for 23 miles (a half-hex) of jungle, the rate is 3 miles per day, meaning that it should take 8 days to travel the half-hex of jungle. For the 23 miles of clear (a half-hex) the rate is 30 miles per day so it should tale 1 day. So the total travel time to move to the next hex would be 8 + 1 = 9 days. This is the correct value. You can see that the second way of calculating movement rates (9 days to move 1 hex of half jungle half clear) is more accurate than simply taking an average of the two movement rates (resulting in 3 days to move the same hex). Andrew PS: I HOPE that is how movement is done in AE. I specified that method in the design documentation at least (but I am not a coder)... Andrew, Thanks for the reply. And thanks for correcting that bit of sloppy thinking on my part about mixed-rate movement. I ran a quick test on an armored unit moving from a clear hex to a forested hex. This should present the same results as your example. The unit moved at a steady 6 miles per day, taking 8 days to complete the move. This is very close to your specification with the difference probably being some rounding or other smoothing in the code (I'm guessing). Dave
|