pwhexe: methodology and philosophy

[el cid again]

From the point of view of the game code, the "real" map is the pwhexe file - not the art players see. So what the map "looks like" in
pwhexe terms is what really matters when it comes time to execute a turn. For this reason, I believe, pwhexe ought to look as much
like the map art as possible. If you turn on reveal codes - key R - and also key Y to reveal railroads - and play with hexside details on -
you can see much of the "real map" as pwhexe codes it. This is remarkably different from what players see in art - frizzy points all over
the place. It also shows that what we are told - in the Forum and even in the manual - about trails in every direction on land - is not true.
[Turns out I like that it is not true - as you will see]

Another issue is that apparently a majority of the roads on the map are "unequal" - you can go one direction easier than the other direction -
insofar as the kind of road changes at hexside boundaries - which should not be the normal case. In many instances, it is easier to leave
a hex, particularly a city, than it is to enter, from the same direction.

When working on a pwhexe file, it is easiest to have two stations, side by side: one with the map - one with the editor. This way you can "see" what reveal codes shows - what hexsides are - in the previous editon you are changing - while you "write" changes in the editor. Otherwise, you must write notes, and work "blind" not seeing the map as you go. There are fewer errors with the two station methodology.

The editor - which is in many respects rather fine - is a beta - and slightly unstable. It appears to have a couple of problems, starting with some saves truncate the file down to a tiny subset of itself which refuses to load. This happens less in Vista than in Windows 7 - fo it is more stable in Vista. When you save - look at the file size - and if it is 2.01 mb rather than something tiny - it was probably a good save. Then try to load it - and if it loads - it is pretty good. But one more step - then put it on your machine running the map - and LOOK at the map hex sides - as you move around. The editor seems to occasionally like to select a random hex and plug in about 4 blocked hexsides. This is enough to mess up communications in many places. But if you spot it- you can fix it.

[el cid again]

Experimenting with pwhexe files in highly used areas of the map, I find things tend to work well if the pwhexe file looks
more like the map art does. When you use reveal codes, the codes show roads and rail lines that go logical places -
and are not unequal in both directions in almost every case. Trails are not in the map art - so you have more freedom
there - but you can "program" movement and supply flow to prefer routes that make more logistical and historical
sense than "no trails anywhere" - the stock normal case.

I also find working on the pwhexe file with reveal codes on shows cases where map art has a road - but the pwhexe file
follows a philosophy "put a trail under the RR track" instead. This is not the normal case - but it happens in more than
a few places - and I think the normal case (pwhexe matches the road art) ought to be consistently applied.

Another useful tool - if you have them - is to have a map work area beside your work station. That way, as you go,
you can consult maps and charts and atlases to evaluate what is/was really on any given hexside?

[el cid again]

Goving over the map, I have found many locations in the far North where things really change seasonally.
Originally I was going to change river data per se - seasonally - but living as I do in Alaska - I am aware that
rivers do NOT become "worthless" for logistics when frozen. [It is rather the opposite - it is slightly easier
to move over frozen rivers than to move in water] So I conclude that a limited automatic logistical solution is
probably preferable. Instead - as in RHS WITP - of issuing vast numbers of small craft for use on navigable
rivers - I think the civil infrastructure is best represented by trails - which "show up on the player map" in the
the form of major river art. Units can move - very slowly - down the river - using the trails. And supplies
will move (at least to a few hexes) down the trails automatically. [I am not sure if resources or oil will move?
That apparently was not the case in WITP - and nothing I have seen indicates it was changed for AE - so my
default assumption is - probably not]

What does change is wether ocean ships and military small craft are usefully able to access river systems
from the sea? Some places have very different shipping seasons than others. One problem on our map is
that the area North of the Alaska penninsula freezes over - but you can sail it in winter nevertheless! So
by changing pwhexe files seasonally, we can simulate that, and the access - or not - to river systems that
are blocked by ice. Of course - in stock pwhexe - the mighty Yukon - or the Lena - or several other rivers -
are not navigable at all - never mind they really are. But that can be changed - and in a game where the
Japanese push hard - it is an advantage to the Allies to have more depth at the map edges.

Another matter I address is ferry systems. These exist in stock. The grandest case is in Japan - where
Shikoku - an island - is linked by two "secondary roads" - to Honshu. These must be high capacity ferries.
These allow resources, oil, supplies and units to move between the islands. I use trails as "low capacity
ferries" so units in the Philippines, NEI, etc - restricted commands - can move where they really did and could.
But I make crossing all these points like crossing a river - in case it is combat contested - something new I never
did before. By defining the crossing point as a river! It also looks better than a white hexside does.
While ferries benefit both sides - in particular they benefit the Allies early on in the war - with their problems
with restricted commands in NEI and the Philippines. Ferries could also be used in New Zealand - I did that in WITP
days - but I have discovered since that the major ferry terminal on South Island was not yet built in WWII -
and I have not yet justified doing it in AE.

[witpqs]

ORIGINAL: el cid again

Another issue is that apparently a majority of the roads on the map are "unequal" - you can go one direction easier than the other direction -
insofar as the kind of road changes at hexside boundaries - which should not be the normal case. In many instances, it is easier to leave
a hex, particularly a city, than it is to enter, from the same direction.

Your conclusion is erroneous. This has been discussed by the developers, and what happens is that movement is calculated based upon how far you have moved. If you are moving from hex A to hex B, and there is a road in hex A but it only goes as far as the border of hex B, then you will get the road benefit until you get halfway. Moving from hex B to hex A, you will not get the road benefit until you move halfway (because that's when you get to where the road begins). The same is true for disparate movement rates based upon terrain.

The only way that you could test it and reach the conclusion that you did is to run an incomplete test. You must run the test for the full movement, in each direction.

[el cid again]

Thank you. My error was more fundamental still - that one could believe what one sees! I like that code - as described - and I hope (and believe) it works as indended. But still - in many cases - it may make more sense if the road goes into the hex "halfway" - at least judging from the way things are on actual maps and photographs. Good pwhexing takes lots of time - time a commerical company probably cannot afford to take - evaluating every hexside.

[erstad]

It also shows that what we are told - in the Forum and even in the manual - about trails in every direction on land - is not true.

I don't see how this conclusion can be drawn from use of the "R" and "Y" key, since neither one displays trails.

[el cid again]

I accidentally discovered - and failed to think about the implications - that one can use
"off map" locations with respect to land units, industry, supplies etc. This should not be interpreted as meaning they will work with naval units. But I just figured out what it means?

Mifune wanted to add Peshiwar - which indeed I did add - but in the "wrong" hex - just at the map edge. It belongs in 58/4 - rather than column 5 - which is one hex too far into the border area. Turns out, that is not a problem. What prevents it from working is a pwhex thing - blocked hex sides. Simply unblock em and the location may work.

On the other side of the map - I did this to add Midwest USA and Midwest Canada - then also to cross blocked hexsides with rail lines and roads - and didn't apply it backward to the matter of Peshiwar. But it seems likely there is no difference between East and West in terms of this working.

[el cid again]

I was able to add Midwest USA and Midwest Canada - then even rail lines between them - even crossing red lines - by
using pwhex to turn those lines green. That means I can probably move Peshiwar to column 4 (hex 58) where it ought
to be located - as Mifune wishes.

[el cid again]

A problem in areas with built up road infrastructures is that they seem to ignore major rivers as barriers.
This matters. Defense needs to be able to concentrate on the efficient river crossing points to be effective.
So I have taken to removing roads from the hex sides that should not have them - and indeed often which
in art do not have them - so that a major river is indeed a barrier to unit crossings efficiently - and to some
supply paths being efficient. It also looks better to have the map have the rivers with lesser bridges, "ferries"
and places with no crossings at all - where appropriate. More natural.

[el cid again]

Actually - you might have that impression - because there are so few trails to see. But R reveals trails.

If you program a trail in pwhexe.dat in a specific place it will show up with R.

[Andrew Brown]

A code for "trails" in the map data does exist in AE, but as has been explained many times, they are not "trails", but railway routes that can be traversed by non-entrained units (that is, units not using strategic movement). As I have explained many times before, the reason that trails do not exist in AE (in either map art of map data) is that the existence of "trails" is incorporated into the movement and supply costs for the different terrain types.

Andrew

[Andrew Brown]

From the point of view of the game code, the "real" map is the pwhexe file - not the art players see. So what the map "looks like" in
pwhexe terms is what really matters when it comes time to execute a turn. For this reason, I believe, pwhexe ought to look as much
like the map art as possible. If you turn on reveal codes - key R - and also key Y to reveal railroads - and play with hexside details on -
you can see much of the "real map" as pwhexe codes it. This is remarkably different from what players see in art - frizzy points all over
the place. It also shows that what we are told - in the Forum and even in the manual - about trails in every direction on land - is not true.
[Turns out I like that it is not true - as you will see]

The map and map data are intended to match. If you have any examples of a mismatch, then by all means provide the details so I can see whether there is an error or not.

Andrew

[Andrew Brown]

I also find working on the pwhexe file with reveal codes on shows cases where map art has a road - but the pwhexe file
follows a philosophy "put a trail under the RR track" instead. This is not the normal case - but it happens in more than
a few places - and I think the normal case (pwhexe matches the road art) ought to be consistently applied.

If you have specific examples of this then please provide the details. As a rule, if there is a road an railway co-existing, then the road type should be properly represented in the map data.

Thanks,
Andrew

[erstad]

ORIGINAL: el cid again

Actually - you might have that impression - because there are so few trails to see. But R reveals trails.

If you program a trail in pwhexe.dat in a specific place it will show up with R.

I think you're seeing the railway trails.

[el cid again]

ORIGINAL: Andrew Brown


The map and map data are intended to match. If you have any examples of a mismatch, then by all means provide the details so I can see whether there is an error or not.

Andrew

The biggest mismatch seems to be East Coast North America - where most of the routes have art showing major road and major rail line - but in fact there appears to be no rail line at all - although reveal codes shows minor rail line and art shows major rail line. So only the major road is really working - I think.

A much smaller example exists for the Russians - where the main rail line crosses the "forbidden zone" into the map proper. In that one hex - art seems to indicate a secondary road - and both adjacent hexes have that - but only a trail exists underneith the rail line - for half the hex. This too might slow movement or logistics - depending on how code works - or might not - if major rail line outranks secondary road entirely and the presence of both adds nothing

Otherwise, there are only a few instances where a road/railroad combination is "interrupted" in this way - suddeny the road "disappears" in the pwhexe file - but remains in art - being replaced by trail most of the time - or by nothing at all exceptionally.

There are also a few cases of apparent actual data errors - no data present of the communications sort - as if it got erased. These are easy to spot with reveal codes on - suddenly there is a gap in the lines.

Only once - in the long lines along the Eastern map edge - did I find reveal codes does not reveal the actual data below - and I am mystified how that is even possible? I assume reveal codes simply shows what is in the pwhexe.dat file - so how could it be "fooled"? For that reason, even though I can duplicate it on different stations with different operating systems, I am not certain it isn't some sort of data corruption in my network situation? But it looks solid in the context of my half dozen machines.

[el cid again]

ORIGINAL: erstad

ORIGINAL: el cid again

Actually - you might have that impression - because there are so few trails to see. But R reveals trails.

If you program a trail in pwhexe.dat in a specific place it will show up with R.

I think you're seeing the railway trails.

I am certain you are correct.

However - there are others. And in any case, you can add others. This helps "channel" movement along historical
(and actually more feasilble) routes - although probably only for short distances. If the code remains as it was once
explained in WITP days, it may be you get no supply over a distance greater than 5 hexes. I also have the impression
(which I wish was wrong) that no resources will move along a "trail."

What is the purpose of a "trail" beneith a rail line? How does a land unit use a rail line except by being on it?
Does not a rail line permit logistic movement better than a trail does? How does the trail actually do anything?
Do land units ignore rail lines for movement - and move instead at the trail rate?

[Andrew Brown]

ORIGINAL: el cid again

ORIGINAL: Andrew Brown


The map and map data are intended to match. If you have any examples of a mismatch, then by all means provide the details so I can see whether there is an error or not.

Andrew

The biggest mismatch seems to be East Coast North America - where most of the routes have art showing major road and major rail line - but in fact there appears to be no rail line at all - although reveal codes shows minor rail line and art shows major rail line. So only the major road is really working - I think.

Can you provide specific hexes please? I do not see any such mismatches.

Edit - While looking around, I did spot one half-hex in the North American off-map area that looks like it has coding for minor railway instead of the "off map railway" coding it should have. I will fix that.

A much smaller example exists for the Russians - where the main rail line crosses the "forbidden zone" into the map proper. In that one hex - art seems to indicate a secondary road - and both adjacent hexes have that - but only a trail exists underneith the rail line - for half the hex. This too might slow movement or logistics - depending on how code works - or might not - if major rail line outranks secondary road entirely and the presence of both adds nothing

You mean hex 100,4? Railways do carry supplies etc, so this is not an issue, but for consistency the "road" value of that hex could be changed to major road instead of "railway roadbed". That would make it match the other hexes in the Soviet off-map area. I think I will change that in my copy of the map data. Thanks.

Otherwise, there are only a few instances where a road/railroad combination is "interrupted" in this way - suddeny the road "disappears" in the pwhexe file - but remains in art - being replaced by trail most of the time - or by nothing at all exceptionally.

There are also a few cases of apparent actual data errors - no data present of the communications sort - as if it got erased. These are easy to spot with reveal codes on - suddenly there is a gap in the lines.

Please provide hex coordinates if you see anything unusual, and I can take a look.

Thanks,
Andrew

[Andrew Brown]

ORIGINAL: el cid again
What is the purpose of a "trail" beneith a rail line? How does a land unit use a rail line except by being on it?
Does not a rail line permit logistic movement better than a trail does? How does the trail actually do anything?
Do land units ignore rail lines for movement - and move instead at the trail rate?

The "trails" you see along railways, where no actual roads are present, are to allow land units that are not entrained (that is, are not using strategic movement) to walk along the railway roadbeds. Such movement was faster than, say, moving through roadless jungle.

For land units to use the railways themselves, use strategic movement. To use a railway in this way you need to own the bases between which the railway runs.

Andrew

[dwbradley]

ORIGINAL: el cid again


The editor - which is in many respects rather fine - is a beta - and slightly unstable. It appears to have a couple of problems, starting with some saves truncate the file down to a tiny subset of itself which refuses to load. This happens less in Vista than in Windows 7 - fo it is more stable in Vista. When you save - look at the file size - and if it is 2.01 mb rather than something tiny - it was probably a good save. Then try to load it - and if it loads - it is pretty good. But one more step - then put it on your machine running the map - and LOOK at the map hex sides - as you move around. The editor seems to occasionally like to select a random hex and plug in about 4 blocked hexsides. This is enough to mess up communications in many places. But if you spot it- you can fix it.

I recently became aware of this bug. It is indeed a nasty little bug but I have a fix in testing and I hope if all goes well to release it within a week or two. Until then use the editor with caution. Do not save multiple times within the same session. If you execute a save, quit the editor, check to see if your saved file is ok and restart the editor if you have more work to do. I apologize for this flaw and will remedy it ASAP.

Dave Bradley

[el cid again]

Testing indicates that adding or modifying roads and rail lines off the map edge works fine between varous locations defined in the stock system.
You also may add new locations IN the "columns" of hexes on the East or North Map edges. But while you can also add locations in other places
- and they appear - you cannot select those locations - or units in them. There is probably something technical we need to know to enable that.
I speculate it is how you define the map in the cam file - at least in part - but I have not yet tested this theory. I did test - previously and again today -
adding locations in the formerly off limits area. You can remove the blocked hexsides using pwhex. You can define the terrain as you wish the same way
If appropriate terrain exists, locations will appear. But while they work as lines of communications - for supplies, resources, oil or even land units -
they do not allow you to select things in them. Because of this, Peshiwar must be one hex out of location - just on the map edge - not beyond it, for example.