home *** CD-ROM | disk | FTP | other *** search
-
- Amiga Empire Maintenance by David Wright
-
- If, during a game, you should happen to have a power outage, a system
- failure, GURU, or you don't properly shut Empire down, it is quite likely
- some data will be corrupted.
-
- This is because Empire stores a large amount of data in RAM while the server
- is running to increase speed. If the system just gets turned off without
- letting the server write the data to disk, it is possible for the data on
- the disk to become "confused" or corrupted.
-
- The best way to avoid this is to make sure you ALWAYS shut down the Empire
- server before turning your machine off or rebooting, and be sure and wait a
- few secs for AmigaDOS itself to write out it's own buffers. You should also
- avoid running other software if you are not sure it can be trusted. It is
- very exasperating to have a program tromp on the input handler leaving you
- with no way to shut down Empire.
-
- Of course, there is not much you can do about power failures, and this
- document is about recovering or correcting your data after one of these
- problems occurs.
-
-
- Prevention
-
- In this case it is certainly true that an ounce of prevention is worth a
- pound of cure, and after the first time an irate user leaves you a message
- about losing an entire sessions worth of moves, you will certainly want to
- do what you can to prevent it from hapening in the future.
-
- In the ideal situation you will have a system similar to mine, with a
- complete uninteruptable power system capable of running the host long
- enough during a total power outage to properly shut down the game, and
- some kind of power conditioner to boot (Give me a call at 216-228-1400
- and I will tell you the type of power system I reccomend for any Amiga
- system).
-
- Of course, I understand that this is most likely NOT the environment most
- people have available to them, and Amiga Empire has about all the
- features you should need to insure maximum data integrity.
-
- Depending on the level of protection you need, and the kind of system you
- run (and are running on), you can turn on various flags that will enable
- "flush" modes ranging from only at system shutdown or deity command (as in
- Empire 2.1w), to a super safe system which flushes the buffers every time
- a country logs out, a client shuts down, and a normal country using the
- flush command while they are online.
-
- All of these flags are completely indipendant, so you can customize the way
- Empire works to your own needs.
-
- If you would like the serial client to flush the buffers when a country
- logs out, you may use the FLUSH command line option or WorkBench tooltype
- (for more info on SEREmp, see the SEREmp manual). Note that this ONLY
- affects SEREmp if you are running it in the standalone mode (where SEREmp
- itself answers the call). SEREmp does not do any kind of flushing when
- it is used in the single call mode, as that is affected by the next flag.
-
- If you would like Empire to flush all buffers every time a client terminates,
- you can set this inside Empire itself. Use the "edit flags" command to
- change the "Flush buffers on client termination" flag to YES. When this is
- enabled ANY client terminating will flush the buffers, including the
- local client (empire), and the Empire front-end (Empfe(when used in local
- mode)). There is no need to set the SEREmp flush flag if you are going to
- be using it in single use mode if this flag is turned on. This flag will
- stay set until you edit it again.
-
- If you would like any country to be able to flush the buffers, you may use
- the "edit world" command to change the "Allow normal users to flush
- buffers" flag to YES. With this set, the flush command will show up on all
- active countries command list, and they may use it to write buffers to
- disk multiple times while they are online.
-
-
- Repairing Problems
-
- The most common problems relate to item counts not matching the number of
- items actually on disk, for example, Empire thinking there are 50 ships
- while there are only 45 stored on disk.
-
- You can identify these kinds of problems by using the "verify limits"
- command. This will go through the database files that grow during use
- and try to read in as many items as it thinks there are.
-
- You should always use this option FIRST after having a system
- crash!!!
-
-
- Watch the numbers, and if it hangs up somewhere, remember what the last item
- displayed was. After reloading the software (if needed), use the
- "edit world" command to bring down the count of whatever item the system
- printed before crashing, and set the correct limit to that value. For
- example, if the system crashed while trying to read ship 3, reload Empire,
- and edit the world so that the "next ship" field equals 3.
-
- In general, the first thing you should do after a crash to use the
- "verify all" command to check the limits as described above, and then to
- check all other items if the limits are OK.
-
- You should always (at least in most cases) answer "yes" when Empire reports
- it found a problem. It is probobly better to let Empire fix the problem
- and have someone lose a single ship (whose number will appear in the log
- anyway, and so can be given back) than to have Empire blow up later and
- cost someone an entire assault, naval battle, or even totally hose the rest
- of your data.
-
- While Empire will LET you answer "no", YOU DO SO AT YOUR OWN RISK!
- Because of the limitless ways that data can be munged, Empire may fail
- during other tests if you fail to correct a problem it reported
- earlier!
-
- If there are a lot of errors in the data file, you can save yourself the
- hassle of typing in "yes" or "no" all the time by using one of the shortcut
- keys. You can use the "a" key to indicate "yes to this and all future
- questions", and the "q" key to indicate "no to this and all future
- questions". So, for instance, to use the verify command in a purely scanning
- method, and not correct ANY errors that occur, you would use type "q" at the
- first error that occurs. (But did I mention that this is not advised?)
-
- Key summary:
-
- y = fix this error
- n = do not fix this error
- a = fix this and all future errors
- q = do not fix this or any future errors
-
- Since all errors found appear on both the screen and in the log, it is very
- important to have the log somewhere safe, not in an unrecoverable RAM
- disk or on the same drive as the files you are trying to verify.
- And since the errors try to give you as much info as possible, you may use
- the log to try and rebuild the file by hand, if you don't trust the
- verify command to do it right.
-
- When dealing with inter-related items, it is always better to verify a file
- again if a related database reported an error. For instance, if you were
- verifying the ship database, and it found an error relating to fleets,
- it would be wise to reverify the fleet database after you have corrected
- the ship database. One good way to do this is to use the "verify all"
- option, which will run ALL the verify tests. If your database is correct,
- you should get no errors. (This can take some time!!).
-
-