1pMARS is a team project, and we're always glad to see it ported to new 2machines, operating systems and graphical environments. If you want your 3code contributions to be incorporated into future pMARS release, please 4follow these simple guidelines: 5 6 * before you start changing the main files, request a copy of the most 7 recent code. pMARS is constantly changing, and we likely have 8 "unreleased working code" that outdates the archive you downloaded 9 from the corewar ftp site. We can merge updates to old pMARS code 10 with our current working code, but this is error-prone. Another 11 reason for letting us know about your changes ahead of time is 12 that someone else may already be working on it. 13 14 * don't send patches or diffs to the main files, but rather the entire 15 file. This is related to the previous point: you are unlikely to 16 have an up-to-date copy of the source. 17 18 * new display code should go in seperate *disp.[ch] files to keep the 19 source modular. For consistency, try to maintain the "look-and-feel" 20 of preexisting displays and user-interfaces and use similar variable 21 naming and formatting conventions. 22 23 * use a descriptive preprocessor symbol to bracket your code additions 24 to the main files. Try not to use a compiler-predefined symbol 25 (__SYMBOL__), but rather come up with a name yourself and add a 26 section to config.h that automatically #defines your symbol if a 27 compiler-predefined symbol is defined. This makes it easier to adapt 28 your code to a different compiler that happens not to predefine the 29 same symbol. 30 31 * in general, follow the examples of previous contributors, and if you 32 have any questions, let us know. 33 34Contact Stefan.Strack@Vanderbilt.edu if you plan on contributing code 35or if you would simply like to know who is doing what. 36