home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Black Box 4
/
BlackBox.cdr
/
bbs_opus
/
oac121.arj
/
OACOMP.116
< prev
next >
Wrap
Text File
|
1990-07-31
|
4KB
|
72 lines
Changes made for version 1.16
In the .DOC file I mentioned that a local token file could be in the
same directory as the OACOMP.EXE file. It couldn't. Now it can.
New switch: /COL=nn defines the standard colour used. If defined, the
warning messages will appear in bright green on black, and error
messages as bright white on red. The colour defined with the /COL=nn
then defines what colour to return to afterwards. If not defined, no colour
change is ever done by OACOMP.
The problem people have had with getting the key checking codes to work
have now finally (I hope) been solved. The error was in the documentation
that I used when designing OACOMP, which stated that
^PK### If user doesn't have keys ###, end file.
^PP### If user doesn't have keys ###, skip rest of line
^PN### If user have keys ###, end file.
^PO### If user have keys ###, skip rest of line.
when in fact it was
^PN### If user doesn't have keys ###, end file.
^PO### If user doesn't have keys ###, skip rest of line
^PK### If user have keys ###, end file.
^PP### If user have keys ###, skip rest of line.
ie. they had the reverse meaning of the one documented. This is now fixed.
I have tried it out on my own OPUS 1.13 and it works, IF you use the format
[LineKey]xxx This is only shown if user has key x.
[LineKey]xxx [LineKey]yyy This is only shown if user has both key x and y.
In previous version, I forgot to empty the SAVE/LOAD stack between each
file if compiling multiple files in one go (with wildcards). This could
lead to erroneous reports of stack overflow, if you had imbalanced
SAVE/LOAD in your previous files. Such an imbalance is now flagged as
a warning and reported to screen.
A minor glitch exist in the way that Opus/Avatar COMPiler packs the
repeated byte sequences. If you want to use the command
[NLineKey]PPP <whatever>
OACOMP will translate this into ^PPPPP and then pack the four P's into
^P^Y^DP which is incorrect. This glitch has not been solved yet, but
now at least you are aware of it. You can avoid this problem by typing
[NLineKey]ppp <whatever>
ie. use lower case P's to prevent packing. The same goes for the [LineKey]
token (which uses O character).
Due to popular demand (sounds great, right?) Opus/Avatar COMPiler can now
compile .OEC files with lines longer than 255 characters. To enable this
feature, you must use the /LONG switch on the invocation of OACOMP. You
can turn this on permanently by issuing the command SET OACOMP=/LONG in
your AUTOEXEC.BAT file.
*** NOTE: If you specify the /LONG switch, OACOMP will perform two passes
on the file. First to compile it and then to pack it. If the
compilation result in lines longer than 255 characters, OACOMP
will not pack it correctly. Specify /PACK- in these cases.
To enable compilation of .OEC files with lines longer than 255 characters,
I had to make some adjustments to the internal workings of the compiler.
This means that if you use the [<operator> <privilege> QUIT] command in
any of your .OEC files, you *must* terminate the line after the token.
Previous version of Opus/Avatar COMPiler did this for you, but this version
doesn't! This means that a construct like:
[EQ AsstSysop QUIT]This is not shown to AsstSysops
*must* be coded as two seperate lines:
[EQ AsstSysop QUIT]
This line is not shown to AsstSysops