Category : Recently Uploaded Files
Archive   : VGAPWWIV.ZIP
Filename : HISTORY.DOC

Rick DiLorenzo

June 06 1993. VGA Planets BBS Door Interface V1.00
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Initial Release

July 03 1993. VGA Planets BBS Door Interface V1.10
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Added Desqview 'awareness' features in responce to Bill Rogers
and Ricky Schradin, SysOps who had problems running VGA Planets DOOR
Interface under Desqview.

July 07 1993. VGA Planets BBS Door Interface V1.20
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Extra fine tuning on desqview awareness. Most long loops in the door
now 'timeslice' causing the current task to give up the rest of
it's time slice back to DesqView. Stil not positive if it works
since I don't have desqview installed and have to wait for remote
sysops to test it for me.

- Fixed bug where it wouldn't let more than 1 game be played in the door.

- Fixed 'list' bug that would crop up occasionally. Wouldn't let you list
past game 1. This bug only occured after the "L" command was used
more than once in the door per session.

- Implemented the "R" (retire from game) command, before it was just a stub.
This command allows users to exit a game that they were previously entered.
Make SURE your users know not to set passwords on their games, since this
would mean the new player that takes over the retired players empire would
need to know the password to continue playing.

- Added simple "SysOp Editor" of PUSERX.DAT files so SysOps could manually
remove players from the game that were inactive. Or even EDIT the user
names to change who is playing what empires. Note, the editor.exe
is a very quick and dirty program. It works, but it's not pretty.

- Added "S" (Score) command so users could see the score.log files online.

- Added "E" (Error) command so users could view the errorold.log file that
the host makes. This way users would know if they made a mistake
in uploading an invalid .TRN file or command.

- Spoke to Tim Wisseman on the phone to ask him if he could further automate
the MASTER.EXE program to allow USERS online to configure their own
games through the door. Having master look for the answers in a .TXT
configuration file instead of them being manually entered.
The door would ask the users the questions itself, then process the
answers for 'integrity' (making sure none of the responces were
inappropriate) and then place the answers in a "ANSWER.TXT" file that
hopefully a later version of MASTER.EXE will be able to look at.
(This is not fully implemented yet).

July 08 1993. VGA Planets BBS Door Interface V1.21
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- STILL had problems running the door under systems that use DESQVIEW.
This time I called up Ricky Schradin, a SysOp who uses Desqview
to run his BBS. Stuck with him, uploading and re-uploading
.EXE files with 'fixes' and 'patches' for desqview awareness
until we seemed to find one that was bug-proof (I hope).
He also had a problem with the door not always recognizing a
LOSS OF CARRIER. We think (hope) this was caused by the desqview
problems and is now fixed. I've been testing it locally, dropping
carrier here and now. Seems to work fine. This (3rd time) will
hopefully be the final 'patch' for Desqview SysOps.
(btw the desqiew problem was the door calls to input from the user
weren't properly desqview aware, they weren't stopping desqview
from switching during critical get_character loops.)
Some thanks to Ricky Schradin (sp?) for helping me test this out.

July 09 1993. VGA Planets BBS Door Interface V1.22
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Minor flow control problems with SOME modems were still occuring. With
some modems, if you locked your BBS Baud Rate at 9600+ but someone called
at 2400 baud, the last couple of lines sent would get garbled. Since only
a few sysops were having this problem, and I couldn't duplicate it on my
end. I at first thought they were either doing something totally screwy,
or that they just had cheap modems. Found out that because I had a 14.4
USR DUAL that has great error correction, buffering, good chip-set, etc,
that my modem was fixing the flow control for me. After taking a closer
look I realized I had almost NO 'real' flow control in my code. When the
baud rate of a BBS was locked high, my door would try to send characters
to the BBSes modem too fast for it to be sent at 2400 baud to the user,
and it would lose some of it at the end. Thank You's go to Bill Rogers
for his patience in testing out the odd-some 4 or 5 'fixes' I kept on
throwing at him until we got this problem licked.

July 12 1993. VGA Planets BBS Door Interface V1.23
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Added FOSSIL and DIGIBOARD support. To use this support in
the command line paramaters of VGAPLANE.EXE you need to add
a "/F" for fossil or a "/M" for Digiboard. If using normal
com ports than don't add anything. Also make sure you DO NOT
ADD BOTH.

Example Door Batch file.

C:
CD \PCB\DOOR\VGAP\
VGAPLANE /P:C:\PCB /F
CD \PCB
BOARD

The above batch file would load the door in the FOSSIL mode,
you need a fossil driver loaded up in memory for this to work.

Note : Fossil and Digiboard support is currently in BETA mode.
Please report to me if anything goes wrong or if it doesn't
work.

July 17 1993. VGA Planets BBS Door Interface V1.24
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Minor fine tuning done on fossil interface. Thanks to Gary Hedberg
for his help beta-testing the fossil version.

- Fixed minor "S" (Score) bug where it would list the wrong game number
for the score file shown. Very minor cosmetic bug.

- Cosmetically changed the menu. Arranged commands in alphabetical order.

- Added 2 local SysOp Function Key commands.

F10 - SysOp Chat
F8 - Boot user out of Door back to the BBS

July 19 1993. VGA Planets BBS Door Interface V1.25
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- If you weren't a player in a game, when you used the "L" command to list
it, it wouldn't find your .RST or .TRN file (since you weren't a player in
that game) so it would wrongfully assume the game hadn't started yet and
would say "You have no .RST file, the game hasn't started yet". This was
only a cosmetic error, didn't effect the playing in anyway. But its now
fixed to say only "You have no .RST file to download. You are not a player
in this game." As I said, very minor cosmetic bug fix.

- Added internal Z-Modem file transfer protocol to replace DSZ.
You can all delete DSZ.COM now, the door uses it's own
routines to handle file transfers. I thought implementing
this would be a quick hours work or so. But I ended
up spending about 10 hours on this. All due to one buffering
bug that I didn't know about / didn't see which was causing
the init zmodem protocol control block to not initiate for
'no reason' that I could find.

This feature (internal zmodem file transfers) was needed
mostly for boards that ran with Fossil drivers or multi-port
Digiboards.

This feature has increased the size of my EXE from around 80K
to about 120k!! Couldn't believe how it balooned in size.
Mostly because I spent too much code/time implementing a snazzy
File Transfer Status window display for the SysOp side.


- Added VPATH.CFG configuration file. This file only has one line.
that being the PATH for the VP300.ZIP file. If this file
does not exist, it assumes VP300.ZIP is located in the current
directory.

Format :

D:\PCB\DOOR\VGAP\
^---------|
|
Last character MUST be a '\'
WARNING: Make sure there is NO line spaces, or characters spaces before
the starting of the path string.

I would advise not using this option unless you really want/need to.
Make sure you have NO spaces before or after the path string.
Make sure the path string is the FIRST line in this text file.
Make sure the path exists, and that vp300.zip exists in that path.
If any of the three lines above are not satisfied, and you opt to create
and use a vpath.cfg file, then your door may crash-n-burn.
This option was added for sysops with very small hard drives who wanted
to keep VP300.ZIP in their BBS download directories so users could
download the file from the door AND from inside the BBS, without having
to have two copies in two seperate directories.

July 22 1993. VGA Planets BBS Door Interface V1.26
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- If carrier was lost during a file transfer (remote user hanged up) the
fancy status routine would not notice and would keep on 'trying' to
complete the file transfer successfully. It was too persistant, the
transfer would continue until it was successfully completed or hell froze,
which ever happened first. Fixed.

- I've heard a few message rumours with problems with DesqView. I can't
as yet confirm if it's with the new versions of VGA Planets (versions 1.25
and on had many structural changes) or with previous ones. Sadly most
people who leave me reports just say "it doesn't work with dv" and don't
give me a version number of the door, or specifications of the problem.

- Some FOSSIL users were having file transfer problems. During downloads
it would return CRC errors or muck up. Uploads to the door would work
fine. So I added a new command line paramater to VGAPLANE.EXE. You can

now add "/S" at the end. This will turn on Software Flow Control as well
as Hardware flow control. (the current default is to only use hardware
flow control).

I.E.

VGAPLANE /P:C:\PCB /F /S

The above would use pcboard.sys, found in C:\PCB, with FOSSIL driver
support turned on, and with software flow control turned on.


August 5 1993. VGA Planets BBS Door Interface V1.30
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Added "P" command to allow viewing of Passwords. So players set a password
and forget, or if a player quits a game and a new user joins not knowing
the old players password, they can use this command.

You must keep CRACK.EXE, a new executable, in your VGAP door directory.
The door uses this utility that Tim Wisseman wrote to find the users
password.

Not this command only works in registered versions of the door.
Please support the shareware concept.

- Added the capability for players to be active in MULTIPLE games at the
same time. I.E. they can be in game 1, 2, 3, 4, & 5 all at once
if they are really hard-core VGAPers.

Note - I did NOT cripple this command. It works even in unregistered
versions. Please remember though that you only have a 30 day
lisence to run this door. After 30 days you have to register, or stop
running the door on your bbs.

- I removed the ability to retire from games though if door is not
registerd 😉

August 6 1993. VGA Planets BBS Door Interface V1.31
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Fixed minor code bug which caused major problems. The new multiple games
procedures were screwing up, it wasn't allowing players in games 2 or higher
download or upload their files. Fixed. Minor boolean value that wasn't
being set right in the code.

August 6 1993. VGA Planets BBS Door Interface V1.32
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Minor error in that when opening the door in v1.31 it would ALWAYS
tell you "you are not active in any game" even if you were. This is
minor in that it had no effect whatsoever in the running of the door.
Just a mis-print type of error.

- Minor error in the "S" and "E" command. When viewing a game that you are
in it would say you were an incorrect race. I.E. you were viewing game
3, and it would think your the third race in game 3, or viewing game 1
and it would think your the first race in game 1. Incorrect
cross-referenced variable. Did not affect the playing of the game since
the door still knew who you are when it came to uploading/downloading.

- Fixed minor grammer and spelling in the download prompt.

September 8 1993. VGA Planets BBS Door Interface V1.40
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
WARNING : This new version of the interface is for Version 3.10X of the
VGA Planets Game package only. Trying to run this door interface on an
older version (V3.00) of the game files could cause your current games to
be corrupted. Please read UPGRADE.DOC for more information. To run
this door you have to be using version 3.10X of the host files, if you
have current games using 3.00, then you must upgrade these games to new
V3.10 game files.

Author Note :

This new version has been pre-announced as "Real Soon now" quite a few times.
The reason for the 3 week delay between v1.32 and v1.40 is that Tim Wisseman
has been doing a lot of very interesting things in new released host versions
and game utilities. Every couple days he'd release some new .exe that I'd
start to fool with and include support for in the door. Particularly the new
HOST.EXE and the new CPLAYER.EXE files. But he kept up a rapid pace of
bug-fixes and minor changes that took place every few days. I didn't feel
comfortable releasing a new door interface until I felt the new game package
was 'stable' and wouldn't be radically altered the next day.

- BBSHOST has radically been changed to allow for the support of new
features.

New command line paramater.

C:\BBS\VGAP\BBSHOST.EXE 9 5

As you may recall, the first number represents the number of players
needed for a game to start. The game won't start until there are 9
players (or whatever number you put in that place) and it will also
stop an on-going game if due to retirement or inactivity the number
of players drops below that paramater amount.

The NEW command line paramater though (the 5 in the example there) is
an player inactivity setting. I.e. in the example given, after 5 days
of a player not uploading his .TRN files, that player will be removed
from the game due to inactivity. Empires that have the current player
removed due to inactivity will be set to the default "COMPUTER OPERATED"
setting. Thus the game will not be interrupted, the race will continue
to be played, but by the computer instead of the user.

Note : If that second paramater is not given, then like the first
one it will go to a default. The default is 5.

- BBSHOST now interfaces with the new Computer Controled Player feature
that is included in the new VGA Planets V3.10 CPLAYER.EXE file.
It does this through present settings and also through a new and
improved SysOp EDITOR.EXE program.

Once the required number of players needed to play is reached and a game
is started. BBSHOST will then opt to control and play any empires that
still have the "NO PLAYER YET" control name variable through Tims new
computer control utility. That way if a user on your board joins an
on-going game he will no longer be in such a large disadvantage to the other
players who have had more time to build up. The BBSHOST will control all
the "NO PLAYER YET" empires through Tim's program that envokes "fuzzy
artificial intelligence logic" to run these headless empires.

Also SysOps now have a new option of configuring games to have races that
are TOTALLY controlled by the computer that would never allow a real human
user to take over. To use this option you simply load up EDITOR.EXE, select
the game you wish to edit. Then under the player name put in "COMPUTER
OPERATED" for the empire you wish to be placed totally under computer
control.

Please remember that the only difference now between "NO PLAYER YET"
and "COMPUTER OPERATED" is that "NO PLAYER YET" is only controlled
by the computer UNTIL a real person takes over. While "COMPUTER OPERATED"
will ALWAYS be controlled by the computer with no chance for a real person
to take over.

This is because in some games you might wish for a particular race to be
soley in the computers hand, it may make the game more interesting when
your users have to 'fight the computer' as well as other players in the
game.

- For some SysOps who for some reason want to run smaller games on their
board, say with only a 5 or 6 possible players instead of 11. They can now
select only the empires they wish to be possibly played in the MASTER.EXE
program apon game initializtion, and then after making that game, use the
EDITOR.EXE program to edit that particular game to have the not-in-use
empires have the player name "NOT IN USE". This tells BBSHOST not to due
any in-activity checking, or computer controlled operations on that empire.
It simply ignores those empires entirely. It also won't allow your users to
try and join that empire. It will treat it as an inactive empire.

- Fixed spelling of the word "fascist", was incorrectly spelt as "facist"
previously in the door.

- The "R" command now defaults to "COMPUTER OPERATED" after a player retires
from that race. It is sysop configurable though, the default could be
changed back to "NO PLAYER YET" if the sysop wanted to. If you wish
to turn it back to "NO PLAYER YET" apon retiring. Then add a "/N"
paramater to the end of VGAPLANE.EXE.

i.e.

VGAPLANE /P:C:\PCB /N

The "/N" would turn the retire command back to "NO PLAYER YET" instead
of the default of "COMPUTER OPERATED".


The "R" command only works in registered versions.

- Players can configure their games now so if they miss a turn, the computer
can guesstimate at what they would have done, and then do it. Some players
may not like how the computer would take the missed turn so they could turn
this option off or on to suit themselves. This option is available
in unregistered as well as registered versions of the door.

- New version of the EDITOR.EXE sysop program. The old version was very ugly
and had a few bugs. It would always capitalize every character. This new
version will allow small characters for those BBS Drop file formats that
don't use all capitals. Please remember though that if your editing the
name to 'NO PLAYER YET', 'NOT IN USE' or 'COMPUTER OPERATED' that you must
enter it all in caps without any spaces before or after.

The editor currently only works on the NAMEs. Future versions will allow
editing of aliases, inactivity counters, etc...

- New Alias command. Players can use the new "N" command to change the
name of your empire. Instead of their real bbs name, they can change
the name to an alias. Note, the EDITOR.EXE is only for editing the
true name of a user, it doesn't change the alias selected for that user.
The alias command only works in registered versions of the door.
If your door is registered, then it DEFAULTS to allowing aliases.
If you wish to TURN OFF alias support. Than add a "/A" command line
paramater to the end of VGAPLANE.EXE

i.e.

VGAPLANE /P:C:\PCB /A

The "/A" on the end would turn alias support OFF for sysops
who for some reason want to force players to use their real names
in the game.

This works in only the registered version of the door interface.

September 10 1993. VGA Planets BBS Door Interface V1.40
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixed bug in BBSHOST.EXE. The bbshost would incorrectly search
for player turns. As a result it would always increment the inactivity
counter. Until after 5 days, every player would be removed from the
game due to inactivity. Since this isn't a change in the main door file,
but only the nightly event file, I didn't change the version number.
Simply the file name. It's VP0910.ZIP instead of the old vp0908.zip.
I also released a "HOSTFIX.ZIP" for people who already dled vp0908.zip
and didn't want to have to re-dl all the other files that didn't need
changing.

November 1 1993. VGA Planets BBS Door Interface V1.50
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- Fixed bug that would turn "NO PLAYER YET" empires into computer
operated empires due to inactivity.

- Modified BBSHOST so that if it finds "REMOTE.GAM" file
inside a /GAMEX directory than it skips running maintenance
on that game. This is to support Robert Mudryk's InterBBS
VGAPlanets Program that he is writing. Has no effect on normal
game play. PLEASE DO NOT USE THIS OPTION unless you are beta testing
Robert Mudryk's InterBBS VGAP program.

- Added "/N" command line paramater to the end of BBSHOST.EXE.
This option will turn OFF The running of CPLAYER (Computer Operation)
On "NO PLAYER YET" empires. It defaults to letting the computer
control "NO PLAYER YET" Empires until a real person takes over.
But some sysops didn't want that always turned on so I've included
the option to turn off this feature.
WARNING WARNING : THE ORDER of the Paramaters is critical. I.e.
the first paramater is number of players needed,
second is inactivity counter, THIRD is /N or
no /N. You can't put /N after only one number.
It has to be the third paramater if you are using
it.

- Allows for up to 15 games in the door. Sysop configurable.
Defaults to 5 games. To change the number of games in the door
edit the DOOR.CFG file. Note, unregistered versions only allow
maximum of 5 games. The first line of the door.cfg determines
the number of games. Must be between 2 and 15. It can't be above
5 if the door is unregistered.

Warning. Make sure you have a GAME directory for every game. Check
sysop.doc if you've forgotten how to create new games (i.e. using
master.exe).

- Configurable number of games a player can be active in at the same time.
Before the door would allow users to join as many games as they could
(as long as there was an empty slot). Now though the sysop could say
configure it so a player can only play 2 (default) games at once.
This prevents a heavily vga planets addictive user from getting an
overdose by joining every single game. To change the number of games
a user can currently be active in, edit the DOOR.CFG file.
The second line determines the number.

- Creation of new sysop configurable info file for each individual door
game. The first 3 lines of this file contains text which is displayed
to users at the (S)cores, (L)ists, and (J)oin commands. The fourth
line contains a 7 character string of Y's and N's which configure
the days of the week that the BBSHOST is to process game turns
for each game world. Going in order of Sunday, Monday, Tuesday,
Wednesday, Thursday, Friday, Saturday.
Warning : All 4 lines must exist. Even if you are using the default
of processing turns every day, you must still include the 4th
line of "YYYYYYY" after the first 3 of display text for that game.
An improper gamex.inf file could result in the crash/halting or
improper execution of bbshosts functions.

The format is that the file must be in the main vga planets door
directory. Following the format of "GAMEX.INF" where X is the game
number. This is a simple text file that can not be longer than 4
lines maximum.

Example 1. GAME1.INF

This game is sysop customized to include Wandering Tribes (I.e. no
homeworlds) each player starts off with freightors at the center of
the galaxy. Turns are processed once a day at 2 am.
YYYYYYY


The above example would display the first 3 lines of text at
the appropriate locations in the door. While the fourth line
would configure that game to process game turns on EVERY day
of the week. Please note that this file can be changed 'on the fly'
which means part way through a game you can re-configure the days
of the week setting in the .INF files if needed. But be sure to
tell the users.

Example 2. GAME2.INF

This game is configured so Alchemy and Mines are turned OFF.
Homeworlds are extra rich and minerals with large populations.
Turns are processed every TUESDAY and THURSDAY only.
NNYNYNN

These features have been added for sysops who enjoy customizing each and
every game. This way he can INFORM his users how the different VGA Planets
games in the door are setup. This is for the 'advanced' SysOp who likes
to have many different variations in his games. If the door doesn't find a
"GAMEX.INF" file, then it simply does not display anything and uses the
default of processing game turns every day of the week.

Note. Ansi codes can be included in the 3 lines of text. Plus
there are several macros that can also be used. They are listed
below

$GREEN$ : Changes ansi text colour to Green.
$YELLOW$ : Changes ansi text colour to Yellow.
$BLUE$ : Changes ansi text colour to Blue.
$MAGENTA$ : Changes ansi text colour to Magenta.
$CYAN$ : Changes ansi text colour to Cyan.
$WHITE$ : Changes ansi text colour to White.
$GRAY$ : Changes ansi text colour to Gray.
@USER@ : Macro displays the name of the user
currently in the door.
@BOARDNAME@ : Macro displays the name of the BBS system.
May not work with some BBS Drop File formats.
(I've tested it under door.sys and pcboard.sys
successfully).
@TIMELEFT@ : Macro to display the users time left.

- Help file, the command 'H' in the DOOR menu displays some help
on how to play the game. The default text displayed is stored
internally inside the .exe code and can not be edited. Some SysOps
though may wish to change the help display to some other text.
In this new version I've included code that checks for a text
file called "HELP.TXT" inside the door directory. If that file
exists it will display the contents of that file INSTEAD of the
default text that is displayed currently. Ansi codes and the
$ $ / @ @ Macros (explained further above under gamex.inf rules)
can be accepted in the file. Length is not a major consideration,
because it will default to pausing after every full page of
display.

- /T paramater at the end of VGAPLANE.EXE door load-up will now allow
players to take over "COMPUTER OPERATED" empires as well as the
standard "NO PLAYER YET" empires.


December 5 1993. VGA Planets BBS Door Interface V1.54
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- Extra drop carrier checking during file transfers.
Rare situations have occured where the door has not exited
during a loss of carrier in an upload (so rare that I can't
find out why, this version may have it fixed but can't tell yet).

- Support for unconventional Communication ports. When loading
up VGAPLANE it's a command line paramater.
VGAPLANE /P:D:\PCB /I:3:02F0

(i.e. where the first number is an IRQ file (3, 4, 5, or whatever)
and the second value is a BASE ADDRESS setting (03F8,02F8,03E8,02E8,etc).

It also needs the COM number, but it will load that from the BBS
drop file (i.e. door.sys, pcboard.sys, or whatever you have it set to).

This feature is as yet untested. It was mostly put in because of
Lyle Chritton who sent me about 30 internet email messages requesting
this feature. Why he simply can't use a fossil driver for the nodes
with unconvential Irqs is beyond me. I'm about 90% sure that this
feature will work.

The base address is in hexidecimal format, I'm NOT hundred percent
sure if the letters have to be small case or capital case. I think
both will work, but if something goes wrong, try switching from lower
to upper or from upper to lower.

The base address has to be FOUR characters. Don't add the "$", the
async unit will do that for you. It will accept any four characters
and will attempt to reassign the com port to to whatever IRQ/Address
base you give it.

/I:x:nnnn

Defaults are : Com1 : /i:4:03f8
Com2 : /i:3:02f8
Com3 : /i:4:03e8
Com4 : /i:3:02e8

The 'x' is the IRQ number. It is a hexidecimal
value from 0 to f. 'nnnn' is the port address for
communications. It is a 4 digit hexidecimal value.



- Some sysops reported that uploaded trns were being corrupted when
users were sending new 'changed' turns to overwrite old turns taken
during the same day (i.e. you upload your .trn file but then you
suddenly change your mind, and re-upload another turn, overwriting
your old one). I wasn't able to duplicate this bug locally. But
I've had more than 1 sysop report it so I've taken it seriously.
In this version it first checks to see if a players .trn file already
exists just before the zmodem upload starts, if it does exist it deletes
the file a second before the transfer is initiated.

- Support for CHKTRN.EXE, a nice utility written by Tim Wisseman to
go along with his game. After a .trn file is uploaded the door will
verify it using Tim's utility to check for staleness or corruptness.
If the file is found to be stale/or/corrupt it will delete the file and
notify the user right away. This means that stale files should be
a thing of the past. Since the door will WARN users right after their
upload is completed if their file is stale or not. If it is stale then
of course the user is expected to re-dl his .rst file and take his turn
this time making sure to upload it before the deadline. This is a
feature that should have been included in the door weeks ago. But
due to lack of programming time caused by studying for excruciating (sp?)
math tests I was unable to add this in time to version 1.50, so here
it is in 1.54.


January 13 1994. VGA Planets BBS Door Interface V1.55
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(Note, read what was new on v1.54 too!!)

- Fixed IRQ bug that Lyle found out, improper reading of paramaters.

- Took out extra carriage returns after upload process.

- Added support for Com ports 5 through 9.

- Changed the default GAMEX.INF files to make them look nicer
to the user.

Febuary 28 1994. VGA Planets BBS Door Interface V1.58
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Added support (only in the registered exe versions, i.e. call for a new
registered exe if you want to upgrade) for configurable main menus.
In registered exe's it will search for a file called "MAIN.TXT" in the
current directory. If it finds it, it will display that file instead
of the default menu. It supports the @ / $ macros that were added
in version 1.50 (read under 1.50 history for more info on them) as well
as full support for ANSI graphics. The last colour code in the main.txt
will also determine what ansi colour to set the command prompt to.

Please note that this new option would mean that SysOps who like to
keep ahead could possibly create a RIP-Graphics menu.
I'll be adding full RipGraphics detection by version 1.60.

- Added three configurable display commands. To be used in conjunction
with your own menu display. If you create a file called "I.TXT" then
if a user enters "I" at the main menu it will display the I.TXT file
to them, along with "press any key to continue" prompts added in every
23 lines (note if the file is less than 23 lines than it will skip that
prompt). If it doesn't find I.TXT in the current directory then it will
simply give the standard responce of "Input entered is not a valid command".
Plus for sysops who want extra bulletin/info display abilities the same
thing will go for command "B" / B.TXT, and "N" / N.TXT this way SysOps
if they want to could create 1 or 2 bulletins to be displayed in the door
to the user. Both I.TXT and B.TXT files would of course support $/@ macros
as well as ansi codes.

Also remember the commands do not have to be just "I" or "B" or "N".
If the user types in "NEWS" it would also display N.TXT if it exists.
If the user types in "INFO" it would also display I.TXT if it exists.
Etc....In these 3 commands it only uses the first letter. The following
characters could be anything. This gives you some lee-way when you
design your menu.


- Added external DSZ transfer support. Some SysOps didn't like or had
problems with my own internal Z-Modem routines. So I've swallowed my
pride and added a new command line paramater "/Z" which will cause the
door to use DSZ.COM (which it will look for in the CURRENT directory)
instead of the internal Z-Modem routines.

Example :

VGAPLANE /P:C:\PCB /Z

The above line which would be in your door batch file would tell
vgaplane to find pcboard.sys in C:\PCB and the /Z would tell it to
use DSZ.COM which would be in the CURRENT directory (i.e. directory
that vgaplane.exe is loaded from).


For people who are familar with dsz paramaters. My internal code looks
like this (below example is for receiving, the sending code is similar).


Exec('dsz.com',' handshake both pB4096 z pr1 rz -y -m -p
GAME'+nums[gbastard]+'\PLAYER'+nums[gamebastard[gbastard]]+'.TRN');


If your using the DSZ option make sure you have in your environment
the setting "SET DSZPORT=1" (or whatever com port your using).
DSZ will look for DSZPORT to find out what com port to send/receive on.


So if for some reason your having problems with the file transfers
(i.e. errors or crashes or simply terrible CPS) then you can switch
to using DSZ.COM instead. But if you are currently having no problems
with file transfers I'd advise you to stick with the internal routines.


- Now supports STACKED commands...i.e. "U 5" to upload to game 5!!!
Mainly added to make a RipGraphics version of the menu have buttons that
will work. I.e. a "Score 1" button, etc.... Expect RipGraphics menus and

RipGraphics detection apon opening the door to come out in the next
version.


March 8 1994. VGA Planets BBS Door Interface V1.59
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- Fixed bug in display of main.txt, where it would go up to 15 lines
and then ask for "press any key to continue". Prompt has been
removed, it will now display main.txt verbatim without any
interferance.

- Fixed stack command bug where if the stacked number was over 9
it would treat it as number 1.

- Modified bbshost.exe so if GAMEX.bat exists (where x is the game
number) it will execute that batch file (if the bbshost paramaters
for number of players are met) instead of host.exe. This way
SysOps could add there own host routines for RAM drive processing
and the like. This is only recommended for experienced VGA Planets
Sysops. This can also be used to include such utils as REF.exe
and the like. The below example is for a SysOp who had a 2 meg
RAMDRIVE for D:\, so he would copy the game1 data files to
his ram drive, as well as host.exe, it would process the game,
and then copy the data files back to the apropiate area.
Also remember to RETURN to your vgaplanets directory!!
If the gamex.bat files aren't found, then bbshost will process
the game normally itself. Also have COMPSPEC set to your command.com
because it uses this enviornment variable to find your command.com
for the shell. Also note that gamex.bat is executed right after
cplayer is processed by bbhost.



GAME1.BAT < RamDrive implementation example>


D:
MD GAME1
COPY C:\BBS\VGAP\GAME1\*.* D:\GAME1\*.*
COPY C:\BBS\VGAP\HOST.EXE D:\
D:
HOST GAME1
COPY D:\GAME1\*.* C:\BBS\VGAP\GAME1
CD GAME1
DEL *.*
C:
CD \BBS\VGAP

GAME1.BAT < REF utilitiy support example >

REF GAME1
HOST GAME1


You get the picture? Remember it will only run gamex.bat if all the
paramaters have been reached (i.e. its a "Game day", you have enough
players, etc..)


- Couldn't get the RipGraphics detection / menus in yet. But they will
be in RSN (Real Soon Now).

March 22 1994. VGA Planets BBS Door Interface V1.60
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Fixed "S X" bug (where x is the game number) the +/- sub commands
weren't working if S had a stacked number command.

- GameX.bat implementation has been slighty changed to conform to MSDOS
specifications for file executions. I.e. now it will handle the
BAT/COM/EXE standards. It will follow DOS's guidelines of first
attempting .BAT, then .COM, then .EXE. So you could 'compile'
your .bat into .exe format for greater execution speed.

- Changed maximum line length in the 3 description lines of gamex.inf
files from 100 characters to 120 characters. (the 100 char limit
was messing up ansi graphics a bit by just 'chopping' it off at the
end).

- Fixed stacked "L" command where it would display the correct
stacked L .inf file but would always display game 1 players/empires.
Fixed.

- Fixed bug in main.txt where the $ $ and @ @ codes weren't working.

- Took out ALL pauses from the I.TXT, B.TXT, N.TXT and main.txt files.
Many sysops didn't like where they were placed. The below feature
now allows you to add the pauses wherever you like.

- Added $PAUSE$ Macro support in the main.txt, i.txt, b.txt, & n.txt files.
This way you can insert a "press any key to continue" prompt in your
text files after every 23 lines or any other place you feel like.
The $PAUSE$ should be on a line by itself. It will use the current
ANSI colours. Please note, if you have a $PAUSE$ at the END of one
of the text files, then please add an extra blank line to the end
of the file, right after the last pause. Because if a $PAUSE$
is on the LAST LINE, it will ignore it, so you would have to add
one extra blank line at the end for it to notice the pause.

- Added RipGraphics Support!! Auto-Detects if ripgraphics is supported
by the remote user at door loadup. (Note, currently only RipTerm and the
newest version of Qmodem Professional support RipGraphics, other terminal
programs such as Telix have promised Rip support in future versions).
If the remote user has RipGraphics it display to him a nice RipGraphics
title screen. Please note that RipGraphics is NOT displayed LOCALLY.
If your looking at the screen locally it will look like giberish garbage.
Its only seen correctly from remote, this is a feature of RipScript
Graphics and NOT a bug. If you have RiPaint, RipDraw, or any other
RipGraphics designing programs you could edit a MAIN.RIP, HELP.RIP,
B.RIP, I.RIP, and N.RIP files for the door. It would of course only
display those files if the remote user support RipGraphics. If the
remote user didn't have Ripgraphics support, it would instead display
the .TXT file defaults if they exist. It presently has built in defaults
for the title screen, and a default main menu rip screen.
If main.rip exists, it will overide the default rip menu.
The default internal rip main menu currently only goes from games 1 to 5.

- Added support for RACE.NM files that are located within the /GAMEX
subdirectories. Some utilities (NAMERACE.EXE for one) would allow
players to change their Empire names within the games. Until now
the door was loading the empire names internally. Now the door
first looks inside RACE.NM under the "medium" sized empire names.
It will display those names (if they exist) in the "L" command.

Notes
~~~~~


- Note, if anyone is having problems with desqview, where if you have
more than 2 people open the door at the same time, one window crashes
(closes actually). I think I know why. I'm doing some special memory
saving routines that some desqview configurations MAY not like. I
can give you a special desqview friendly EXE file, it would be around 120k
instead of 61k, but besides that it will be about the same speed and
should work fine. I'd only make it available apon request by registered
sysops who use desqview and have encountered this problem. Mostly
because the memory routines deal with file data encryption (i.e.
making the exe harder to hack/crack). Taking these routines out
and making a non-encrypted exe public would make it that much easier
for unscrupulous sysops to use a hex editor and try to 'crack' the
game into registered mode. I wish I had something like the Tim Continium
on my side .