Matrix Games Forums

Only thing left now are the hexsides. [:-]

EDIT: Got hexside rivers to repack. Still need to stress test this, as I did a lot of surgery involving new/old code.

Sorry for disappearing on you guys like that.

I think I have a workable set now.

I disappeared to do a lot of things -- "gee, I'd like to work on MAPGEN, but...it's so nice outside..." etc etc

Until we had a rainy friday night and I had nothing better to do...

http://alternatewars.com/Scratch/MAPGEN ... ble_v1.zip

Got around to final polish to the manual; it got to be pretty late (11PM) by the time I was finishing up, so I half-assed it yesterday.

Anyway, here's the full completed manual. Place into your \DOCS folder.

Has anyone tried this out yet?

Thinking about for v1.5 updating it to dump/repack from "quads" of 4883x3901~ pixel images in addition to the one huge 9766 x 7803 file and the "standard" WITP map splits.

Reason for this is a 32 bit transparent 9766x7803 image is about 872~ MB in Photoshop, which might be too much for some people's computers (as well as slow).

Meanwhile, a 4883x3901 image is only 218~ MB; it's still beefy, but not "kill your computer dead" beefy.

Thinking about writing a program to dynamically generate Stack Limits according to a variety of factors:

Terrain Type
River/Water hex adjacent?
Road/Rail access?
etc

Any interest?

Yes, sent you a pm Ryan.

Ryan i know i have to be careful around land and border areas, but while painting deep sea can i ignore the hex divisions and just paint a bunch of blue or have to respect the hexes?

Edit:i mean hexes need still to be shown in sea areas?

MAPGEN Block II 19.6 MB ZIP

Designed to be unzipped to your WITP:AE main directory and run from there.

Source code is included in /SOURCE, documentation is in /DOCS

Files generated will be placed into /DUMP.

The program will read the files from /DUMP when rebuilding PWHEXE.dat

I've included a zipped up copy of the original PWHEXE.dat from the latest WITPAE because you won't back it up.

MAPGEN DUMP: Dumps the PWHEXE.dat file into different graphical layers.

MAPGEN REPACK: Repacks the graphical files back into the PWHEXE.DAT file.

MAPGEN MAPART: Combines the 41(!) BMP files in the \ART directory for the in-game map into one really big PNG file which is also pixel accurate with the dump graphics files that DUMP generates. Also splits the big png files back into 41 BMP files when you're done editing the big file in photoshop.

LANGUAGE USED: Python 3.x; using the following libraries:

Colorama 0.3.7
Pillow 4.0.0

and packaged into executables by PyInstaller 3.2.1 (that's why each file is so big, it includes an entire python distribution instead of just what the program needs to run, unlike most programming langauges that build executables)

Thanks Ryan

I am curious why Computer Control Zone and Country Code are stated to be "not needed?"

I doubt that we can know all the places code refers to either (sans documentation either
of the original program or most of its patches). We certainly cannot know what FUTURE
programmers may write referring to them. So I think it is good form to use them.

That said, having reworked the pwhexe.dat files manually - almost certainly more than anyone
else has (I have evolved many dozen variations and will need about 42 for my current project)
I can say it is clear that the original pwhexe.dat files (and important mod versions) do not
code all fields in all hexes. Simply correcting this results in significantly improved performance
by the game program. Improved in the sense of fewer strange behaviors. Mysterious things that
were impossible before no longer are (in particular in terms of where things may move).

In spite of my reservations about not using all the designed fields, I believe the future belongs
to automatic map generators. It is too hard to do such massive maps by hand.

I am curious why Computer Control Zone and Country Code are stated to be "not needed?"

Because Dave Bradley's "Map Data File Formats for AE", which I used as the base for my initial tests to prove I could make MAPGEN; says about those fields:

2.3.13 Hexagon Control (Byte 37)
Not Defined

Note: See the discussion in 2.3.19 below

2.3.14 Computer Control Zone No. (Byte 38)
00 = NW
01 = NE
02 = E
03 = SE
04 = S
05 = SW

Note: This appears to be a vestige of the old game, since computer control zones have not been
implemented in AE. So the assumption is this serves as a place holder should future versions of the game support this function. It has not been tested by me to see if changing these produces any effect.

..........

2.3.13 Hexagon Control (Byte 37)
Not Defined
Note: See the discussion in 2.3.19 below
2.3.14 Computer Control Zone No. (Byte 38)
00 = NW
01 = NE
02 = E
03 = SE
04 = S
05 = SW

Note: This appears to be a vestige of the old game, since computer control zones have not been
implemented in AE. So the assumption is this serves as a place holder should future versions of the game support this function. It has not been tested by me to see if changing these produces any effect.

...........

2.3.19 Hexside Control (Byte 43-48)

Not Defined

Note: It was my thinking that these six bytes and the field (byte 37) that sets hexagon control were intended to provide definition for first turn anomalous situations where Allied and Axis units were in the same hexagon. Hexagon and hexside control in contested hexes is partly a function of previous turns. On the first turn no such previous turn history is available. Limited testing by me has shown no discernible effects from setting this field to non-zero values so it may be that these bits are not currently used by the game code. They are all set to zero in the stock file.

And regarding currently unimplemented stuff, such as:

PWZONE.DAT (Entry Zone and Off-map Port Data)
PWZLINK.DAT (Entry Zone and Off-map Port Link)

Because each record is short enough and is fully described by Dave Bradley in his MAP FORMATS; it wouldn't be that hard to write a dumper program to dump either to a CSV file, which could be edited in excel and then redumped back into the files.

Hi Ryan - really nice work on this! However, I think Dave Bradley was wrong in stating that "country code is not used in AE". For one thing, start up any game and press the "4" key and the map will fill up with country codes (thx BBfanboy). Also there's a number of hard-coded *things* in AE which appear to be linked to the country code.

1) Strat Bombing VPs - The manual notes that Allies and even Japan can get VPs from strat bombing of industry, but only in certain regions. Although that *might* be handled by a listing of specific base hexes, it seems much more likely that the game code uses the country code designator.

2) Russian activation - Another instance where it seems likely that the game code would be looking specifically for Japanese forces to be present in a hex with code 90 (Soviet) or 91 (Mongolia). Likewise, the count of AVs for the Manchukuo garrison might also be calculated this way (code 105).

3) US Defense activation - Apparently the Japanese can invade Alaska or the Aleutians without activating this event, and sure enough that region is code 11 whereas the West Coast (10) is different

4) Vietnamese Activation - Here's another instance where the country code seems like the easiest way to detect the presence of Chinese units, even in hexes that don't have bases.

Anyway, it does appear the game makes use of Country Codes, so it would be helpful if your program included the ability to modify them.

Thanks for letting me know what goes on. Here's the results of 2 minutes' work

and thinking about it, it makes sense as it lets the AI know what areas it has to defend -- while offensive actions can be timed by scenario scripts.

ORIGINAL: RyanCrierie

Thanks for letting me know what goes on. Here's the results of 2 minutes' work

Thanks, that will be very helpful!

In the category of "extreme minutiae", there is an island just south of Celebes called "Kalao", and for some odd reason it's the only island base hex on the map that can't be amphibiously invaded. You can see this for yourself by launching the December 8 scenario as Japan and directing one of your amphibious TFs to attack it - you'll get a "can't be done" message.

Anyway, can you spot anything unusual in the Hex codes associated with this location? I don't see "un-invadable island" listed for any of the codes, so it would be interesting to know if there is something there which is currently undocumented.

Edit: Looking at the MapGen installation instructions, it says "Designed to be unzipped to your WITP:AE main directory and run from there". However, the zip contains several folders and files, so that means they'll all mix in with the existing WitPAE file structure. For example, it's not intuitive that a subfolder called "DOCS" is associated entirely with MapGen. Anyway, if they could all be grouped in one subfolder, it would a nice improvement (i.e. just put the existing structure under a higher level directory called "MapGen" or something similar).

What would be the reason for Philippines color?

Kull you do have amphibious landing zone code - in mapgen green and red, that could be the reason for Kalao issue. I didn't verified.

ORIGINAL: Dili

What would be the reason for Philippines color?

Not sure, but it's a way to separate the starting US-owned regions into 4 groups:
- West Coast (10)
- Alaska (11)
- Pacific Islands (12)
- Philippines (13)

The oddity is the three yellow hexes (code 15). Buried in the middle of Indochina and Borneo (non-base hexes) and not used at all, from what I can see.

Kull you do have amphibious landing zone code - in mapgen green and red, that could be the reason for Kalao issue. I didn't verified.

Bingo. That's exactly what it is! Looking at the other non-amphibious zones, they are applied mostly (but not exclusively) to "Swamp" hexes. Kalao is "Jungle" (as are the two islands above it, which can be invaded), so this looks like a map error.

Finally got around to testing your latest version, looking good! Already found a minor error I made myself for a custom map.

In terms of performance I get 11-12 seconds to dump most hex types on an Athlon XP 3000+, a CPU that's closing in on 15 years by now. About a minute for the hexsides, 9½ minutes to dump the whole lot. Not bad at all, not like I have to stick around watching it doing its thing anyway.

If you want to be really nice you could include some kind of error checking in the dump process or packing process. Say if you have two adjacent hexes then you are unlikely to want to have a "green" (all land movement allowed, sea movement blocked) hexside from one side while from the other side it's a "blue" (all sea movement allowed, land movement blocked). The other improvement I can think of is generating the strategic and weather map images. Especially the weather map as it uses pwhexe.dat data.

As for straits, you have a bit of a question mark on it in the readme. From my recollection testing it you need both a hex type strait AND hex side strait for the CD gun portion of it to work. Unless you have both CD guns won't fire against ships moving past the hex. Though don't quote me on that as I might be remembering it incorrectly.

f you want to be really nice you could include some kind of error checking in the dump process or packing process. Say if you have two adjacent hexes then you are unlikely to want to have a "green" (all land movement allowed, sea movement blocked) hexside from one side while from the other side it's a "blue" (all sea movement allowed, land movement blocked). The other improvement I can think of is generating the strategic and weather map images. Especially the weather map as it uses pwhexe.dat data.

I am trying to do that for island hexes that i don't want naval forces to traverse from one specific side to another, but i don't know how it will work out. This is a test was just to easy the work to not have so many red.

Example here of Greece


What i wanted was an hex that could be entered from say 2 sides but they would not be interconnected. So any TF would have to move out from hex it entered.

As for straits, you have a bit of a question mark on it in the readme. From my recollection testing it you need both a hex type strait AND hex side strait for the CD gun portion of it to work. Unless you have both CD guns won't fire against ships moving past the hex. Though don't quote me on that as I might be remembering it incorrectly.

Probably right comparing both in map there are hexside straits without hex straits, bit all hex straits have hexside straits.

The problem with having two different hexside types on adjacent hexes is that you can't see it ingame clearly. Anyway I wasn't suggesting that it'd would automatically do anything about it, just spit out an error log so you could manually inspect those areas.