el cid again
Posts: 16922
Joined: 10/10/2005 Status: offline
|
I look at AE as a system. Originally an electronics technician and machine language programmer, and a pioneer of early digital computers (even pre-electronic digital computers, which used relays), I think in terms of how the program works more than in terms of art. Most of my time involved with maps is down at the level of the codes which define the "real map" from the computer's point of view. Art is simply what players see and has essentially nothing to do with how the program works. Reworking some pwhexe.dat files to fold in improvements designed for RHS Level II, I discovered I needed to look at weather zone, country code and sub-map numbers in an area where these were not defined by stock. Essentially RHS Level I is based on stock maps and ignores these codes for "off map areas." But RHS Level II uses Andrew Brown's "extended map" art - and needs to have corresponding pwhexe.dat files for three rows of hexes. Unlike Andrew's pwhexe.dat files - mine make every visible hex in his map art functional. Because AE was not properly documented by its original programmers, there are probably functions for these codes that we do not know about. In any case, it is good professional practice to define every field as it should be in the context of the design. This means that every function using a field will work as well as possible (to the extent the code functions as designed), and that any future code seeking to exploit that field data will also work as intended. Because of these codes, and many others, I am skeptical about the idea of using the AE engine with non-AE map systems. However, to the extent it can work, it is probably a good idea to think about the values in these (and other fields). In the context of modifying an AE map of some kind, it is certainly a good idea. Do not ignore these codes, particularly in the original "off map area" where their definitions will not work for a new on map area.
|