Panzer general save game editor

PLITCH - Free & Premium Game Trainer
Secure Software (Virus checked, GDPR-compliant)
Easy to use: get ready in less than 5 min
More than 5300+ supported Games
+1000 Patches every month & Support
                        Text file description
                        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