Panzer general save game editor

This is a saved game version of an edited Poland scenario
from Panzer General. Copy the game.sv0 file to the Panzer
General "saves" subdirectory, start Panzer General, and then
load the saved game from the "1" button in the saved game menu.
The saved game is a battalion level representation of a typical
Panzer Division and it is the start of a campaign game set to
medium difficulty. Note that difficulty, etc. can be changed
from within the game.
For historical purposes, the armored infantry battalion should
be upgraded to a '40 Wehr HW' as soon as that unit is available.
As near as I have been able to determine, a Pioniere Inf unit is
a combat engineer unit. It certainly doesn't have the necessary
Hard Attack Strength to represent a German Armored Infantry unit.
The Pz II unit should eventually become a Pz IV unit and the Pz
III unit should eventually become a Panther unit. The Towed AT
unit, designation Mobile Division Anti-Tank, should eventually
become a self-propelled type such as a Hetzer, StuGIII, or preferably,
a Jadgpz IV. The three artillery battalions should eventually
become a 105mm unit, a 150mm unit, and a Wespe/Hummel unit.
I included a Bridging Engineer Battalion in this scenario and
represented it as attached to the division from corps headquarters.
Actually a Panzer division had one bridging engineer company organic
to it.
Later in the war it wasn't uncommon for the other three motorized
infantry battalions to become fully armored (i.e. halftracked and
StuGIII's organic to the battalion along with a couple extra AA
platoons thrown in) so upgrading them to halftracks and '40 Wehr HW'
isn't exactly out of synch.
The Army FLAK battalion represented by the 88mm unit shouldn't be
upgraded at all. Wirbelwinds were organic to the Panzer (Tank)
battalions but there is no way to represent that so attach self-
propelled AA units from corps.
Finally, Tigers and King Tigers were attached as heavy tank battalions
from corps or army as needed. An exception would be the Panzer Lehr.
       Panzer General Saved Game Editor,  Version 1.03   2/16/95
If you have not done so yet, you are strongly advised to read the
section on the effects of editing the saved game file.  (Section 6)
It could save you much frustration.
    CONTENTS
    1. RUNNING PG-EDIT
    2. BASIC OPERATION
    3. PBEM GAMES
    4. "PLEASE REPORT THIS CODE:" MESSAGE
    5. POSSIBLE BUGS
    6. EFFECTS OF EDITING
    7. PANZER GENERAL ADD-ON SCENARIOS
    8. WINDOWS
    9. CHANGES SINCE VERSION 1.00
1. RUNNING PG-EDIT
Pg-edit will only allow you to edit files stored in the current
default directory.  You must switch to the directory containing the
saved game files before editing.  The saved game files are located
under the main Panzer General directory in subdirectory "saves".
2. BASIC OPERATION
I tried to make the interface as user friendly as possible.  The first
screen is opening menu.  From here the game to be edited is selected
by pressing the keys 0 to 9.  Note that the numbers listed next to
each file are the same as the saved game "slots" on the Panzer General
menu, with one exception.  Instead of a choice "10", a choice "0"
appears in the editor opening menu.
After a file is selected to edit, all units are listed by name on the
left side of the screen.  Even units that were in the game at one time
but have been destroyed are still listed, colored in red.  Use the
following keys to scroll through the units and move the cursor:
     Page Up     Back up ten units
     Page Down   Advance ten units
     Home        Go to the first unit in the list
     End         Go to the last unit in the list.
     Arrow keys  Move the cursor in the corresponding direction
To help keep track of your position in the list, a position counter
appears below the list of unit names.
To change any value, simply put the cursor next to the value you wish
to change and press enter.  A red edit window appears where you can
enter a new value, and a large red help window appears in the center
of the screen telling you what values you are allowed to enter.  If
you want to change a number you have already entered into the edit
window, use the backspace key.  Press enter when you are satisfied.
If the value is valid, the edit window and the help window will
disappear, and the new value will be in place.  If the value was not
valid, a beep will sound, and you will be unable to leave the edit
window until you enter a value that satisfies the requirements in the
help window.
If you accidently press enter when the cursor is pointing to a value
that you didn't want to change, simply press enter again.  As long as
the edit window is empty, no changes will be made.  If you enter
several digits into the edit window and erase them all with the
backspace key, the value will not change when you press enter.
To edit prestige, press the "P" key and the cursor will "jump" to the
prestige menu.  Use the up and down arrow keys to select the
appropriate value and edit the value in the same manner as above.
Press the "P" key to toggle back to the unit window.
To quit, press the "Q" key and follow the prompts in the help window.
If you made changes, you will be asked if you want to save them.  You
cannot use the "Q" key when you are in an edit window.
I think it's so easy that it would probably be easier to just start
playing with the interface, but please read about the effects of
editing later in this file before you do!
3. PBEM GAMES
I decided to disable the ability to edit PBEM games.  If you try to do
so anyway the editor will detect this, display an "access denied"
message, and refuse to edit the specified game.  This system is not
foolproof: if someone knows how to hex-edit, he should be able to find
the PBEM marker bytes in the game file and change them so that the
editor's PBEM test will not detect the PBEM status.  Anyone with this
ability would also have the ability to just hex-edit the actual unit
data anyway, so there was no point in trying to prevent this.
I was unsure whether to allow this feature and decided that if I left
it out I could always add it in a later version.  If you feel strongly
about the subject, e-mail your opinions to me!  I'd really like to
hear what people think about this decision.  I personally see no
reason to allow PBEM editing, so I will only add it if at least 75% of
the e-mail I receive on the subject favors the addition, because my
"no PBEM editing" vote counts the most!  :)
4. "PLEASE REPORT THIS CODE:" MESSAGE
If you load a game and hear three quick beeps, a minor error was
detected.  The error was detected, so the actual data is not at any
risk.  In this case, a message will appear on the bottom line of the
screen, asking you to e-mail me a code of 10 to 12 characters.  Please
do so!  This code will tell me the version of pg-edit you are using
along with the scenario you are playing, and where the error was found,
making the task of finding the source of the problem much easier.
When I programmed the editor, I had to specify locations where the
unit data was expected to be found in the game file.  The "please
report" message simply means that unexpected data was found in one of
these locations.  If the file contains unexpected data, the editor
should find it over 99.9999% of the time.  I tested each scenario so I
don't expect anyone to see this message, but the routine that verifies
data is correct is still included as a data security feature.
Again, this message is not the result of a bug.  It means that data
that could have caused a bug was found, and pg-edit handled the
situation exactly as intended.  Your data is safe.
To further insure the safety of your data, the editor will test a
number of other key points regarding the specified file before
allowing you to edit it.  If anything unexpected is detected, an error
message stating this will appear, and you will not be able edit the
file.
As an extra precaution, when you select a file to edit, it is opened
in read-only mode and copied into a temporary file where all changes
are made.  When you choose to save the changes, the game file is
reopened for writing and the new data overwrites the old.  If you
turn off the computer while the editor is running, it may leave
this temporary file in the current directory.  This file will have the
format "tmp*.$$$".  Any such files should be deleted.
5. POSSIBLE BUGS
I found no bugs during my testing so I don't expect you to find many.
There were two minor upgrades which I don't really consider bug fixes,
because they resulted from Perfect General writing data to saved game
files in locations I hadn't seen before, and were spotted by the data
verification routine as planned.  Both of these resulted from
saving the game at points that I hadn't anticipated; during troop
deployment, and between campaign scenarios.  Pg-edit has been modified
to handle these conditions correctly.  Pg-edit was tested quite
extensively on both campaign and scenario games saved between and
during turns, so you should have no problems editing games saved at
these points.
If you do have a problem anyway, please e-mail me!  If you can send a
copy of the saved game file that caused the bug, it would be very
helpful!  I'd even e-mail the upgrade to you when I fix it!
There is one possible bug that may show up.  It stems from the data
storage locations I discussed in the previous section.  On the rare
(about 1 in 4 000 000) chance that my data verification routine
fails to detect unexpected data, the last unit in the list will appear
to be strange non ASCII characters.  (Similar to what you saw if you
have ever tried to edit a binary file with a text editor.)  In this
case, DO NOT ALTER THE VALUES FOR THIS FALSE "UNIT"!  It contains
vital game data, and you will probably corrupt the entire file!  If
this happens to you, please send me a copy of the file via e-mail!  It
is simple to correct, and I can have an upgrade complete in minutes.
Again the chance of this error is EXTREMELY low, so you'll most likely
never see it.
6. EFFECTS OF EDITING
There are a few things you need to know before you begin changing
values.  I grouped them according to attributes.
a. Experience
No side effects of changing this value.
b. Strength
Strength is a little tricky.  First, the basics.  All units stay in
the saved game file for good.  Once a unit is destroyed its strength
is listed as 0, and it is listed in red.  By simply changing its
strength value to a positive number, it will reappear in the game with
the new strength!  As soon as you press enter, the corresponding row
immediately changes to cyan to reflect the new status as active.  Or
conversely, by simply changing a strength value to 0, any unit can be
removed!  The entire row will immediately turn red to reflect the new
status as destroyed.
Now the fun part.  You aren't limited to a strength of 10 or even 15!
The editor allows you to enter a value up to 255, but before you get
greedy, :) a value too large will cause the whole computer to lock up
when you try to load the file.  From my experimentation, I have found
this critical value to be around 40 to 50.  I left the ability to
enter values as large as 255 to encourage experimentation (report back
to me if you do!)  When you enter a strength larger than 15, but too
low to crash, the computer uses this value when computing combat
losses, but the actual digits on the unit on the game map are not the
true values.  For example, if I make a tank strength 25, the map still
shows it as 10.  When I lose 5 strength, the "magnifying glass/look
at units" window and the bottom information bar give the strength as
20, but the map icon shows 5.  The unit will still be allowed to
expend all 25 strength points though!
Now even more fun:  Campaign games saved during the deployment phase
causes certain undeployed units to be stored in x position 255, y
position 255.  The two 255 values signify to Perfect General that
the unit is to be deployed.  However, before you can deploy units,
Perfect General places non zero strength units on the map in the
(x,y) positions specified for that unit.  If you altered the
strength of an undeployed unit to a non zero value, (all undeployed
units are saved at strength 0), Perfect General will attempt to place
this unit at (255,255).  No matter which map is being played on,
(255,255) does not exist, and the computer will hang when trying to
place the altered unit.  The point is don't alter the strength of
undeployed units!  You will lock up your computer!  This should only
apply to campaign games saved during the actual deployment phase.
Finally, when reincarnating a unit you must be careful what x and y
coordinates it will be reborn at.  If another unit is now occupying
the location, you will have two units at the same location, and
Perfect General may behave erratically or even crash when it tries to
handle this unexpected situation.
c. fuel
No noticeable effects, all the way up to 255 fuel.
d. ammo
No noticeable effects, up to 255 ammo.
e. entrenchment
To be honest, I didn't play with this setting much.  Any input would
be appreciated!
f. movement.
If you add before a unit has moved on the current turn, any value up
to 255 is valid, and the range adjusts to reflect this.  If the unit
has expended its turn, no matter what value you enter, you cannot move
it again until the next turn.  I was unable to decode the way this
information is stored in the file.  Large movements BURN fuel, so
don't forget to add enough fuel to get to your destination!  (Or see
the next paragraph!)
g. x position & y position
The x and y positions are the same as those displayed in the top
information bar when you move the cursor in the game map window.  The
upper left corner of the map is listed as (1,0) (x position is 1, y
position is 0)  By changing these values, you can move any unit to any
location!  Here you have to pay attention to what you are doing!  The
editor will automatically restrict your x and y input values to those
actually on the map, so you cannot enter a value that would place a
unit off the map.  However, there are no further restrictions on what
you can place where!  It sounds great, but what I mean is that there
are no safeguards that prevent you from putting a battleship in the
center of a landmass, or a tank in the middle of the ocean!  This
causes no problems, but the "misplaced" unit cannot move from its new
location.  (Use the editor to move it again.)  To watch for this would
involve checking each map and hardcoding each map hex into the editor
as well as creating an internal database of units; a LOT more work
than I was willing to do!  So the basic point is don't move units at
random; have a clear destination in mind, and move it there.  An
interesting experiment: what happens if you put two units in the same
hex?!?!   My editor won't stop you from doing it, so be aware of what
you are doing! (I suspect a crashed system from this experiment!)
The following was contributed by Thomas Grennefors:
   "If you place a unit far behind the enemy lines with hidden units
   turned on it will be hidden the first turn!  All then returns to
   normal in the second turn, or after you move your unit."
   "If you place two units on the same hex, you get to move one first
   and then the other.  No crash.  If you place an infantry in water
   it won't be in a troop transport ship.  But it is still possible
   to move it!"
h. prestige.
No side effects of changing this value.  Be aware that after reaching
a value of 65535, prestige "rolls over" to 0.  There is also a limit
to the number of units allowed in a scenario, and after this number is
reached prestige becomes irrelevent.
i. final word
As long as you use pg-edit to make planned modifications you should
have no problems, provided you take into account the restraints
listed in this section.  However, if you simply open a saved game
and begin making changes at random, you will most likely run into
problems.  Obviously, it is recommended that you plan your changes
before making them.  In either case, back up your games before
modifying them!  Be safe!
7. PANZER GENERAL ADD-ON SCENARIOS
I wrote the code with the idea in mind that add-on scenarios might be
released.  If so, I will simply have to analyze the new scenario files
and hard code about 10 hexadecimal offsets for each scenario into the
source code (like I already did for this editor). It is a very simple
but time consuming process, taking about 5 minutes for each scenario.
As long as the saved game file structure remains the same, I could
possibly complete the project within hours after I get the new
scenarios, plus testing time.
8. WINDOWS
I had no problems running pg-edit under Windows 3.1.  On my system
(486 DX2/66) it actually ran faster!  YMMV.
9. CHANGES SINCE VERSION 1.00
a. version 1.01    2/8/95
-The data verification routine no longer flags x and y position values
 of 255 (signifying undeployed units) as being unexpected data in
 campaign scenarios saved during deployment phase.
 (Thanks Keith Wedinger!)
b. version 1.02    2/13/95
-The data verification routine no longer flags an error when reading
 core unit attributes from campaign games saved in between scenarios.
 (Thanks Gary Lewis!)
-Several minor cosmetic changes were made, the most noticable being
 the slot number and user specified label of the game currently being
 edited are now displayed below the "unit position counter" during
 edit mode.
-Several very minor program "tweaks" were made.
-Numerous additions were made to this text file. (pg-edit.txt)
c. version 1.03    2/16/95
-For units with short names, Panzer General sometimes stores several
 meaningless extra characters after the unit name in the saved game file.
 (I suspect the producers of Panzer General did not intend for this to
 happen.)  These extra characters are no longer displayed.
 (Thanks Oliver Hellwig!)
-Several additions were made to this text file. (pg-edit.txt)
Feel free to e-mail me with any comments, complaints, suggestions,
observations, etc. that you may have about this editor.  If I use your
suggestion I'll give you credit.  I'm especially interested in any
observations about the effects of editing certain values.
You are free to distribute this editor freely, provided both the text
and executable files are distributed together, and they are both
unaltered in any form.
This editor was tested with CD-ROM versions 1.0 and 1.1 of Panzer
General.
I assume no responsibility for any data loss or file corruption
resulting from the use of this editor.  As always, back up all data
before modifying it!  I have found the best way is to designate slot
10 as a backup slot, and save a game twice prior to editing; once in
slot 10, and once in a slot from 1 to 9.  Should any problems arise,
simply load slot 10.
Remember, there are several conditions that can cause an edited game
to lock up your computer.  There may be other undiscovered
combinations!  Please back up your games first!  As I discover these
conditions I hope to release upgrades that will limit or stop the
user from entering these critical values in the first place.  If you
discover one of these conditions that is not already listed, please
let me know!  The more specific you can be as to the cause of the
problem, the better!
Enjoy.
                                            Steven C. Schultz
                                            sschultz@crl.com