On Sun, 1 Dec 1996, Lars Hellsten wrote:

> This is a little strange.  Is SLMR shareware/freeware, and if so, do you
> know where I can get a copy of it on the net?  The QWK readers I've tested
> it with all seem to work, and as far as I know, the CONTROL.DAT file it
> creates follows the QWK specs completely.

You never heard of SLMR?? suprising .. anyways.. I have attached a copy of
it - it is the final version.  (FACT: SLMR was the predecestor of Silver
Express)  By the way, I'm currently writing a UNIX clone of Renegade (so I
can tie in full internet) .. where would I get the QWK / Bluewave specs??

> Not yet, but that's a great idea (I never thought of it)!  I obviously
> prefer the title screen being there, but seeing as the door does have
> completely configurable menus and a language file and stuff, it probably
> does make more sense to have such a feature than to not have it.  So I've
> put that on the "to do" list for 2.01, which should be out before the end
> of the year (I hope).

well .. I'll give you some more free suggestions .. (I seem to come up
with ideas for everything)

1) I haven't tested it out - so forgive me if it already has this: but
have it so things like the %DF (Display file) variable works.

2) This one to me seems kinda lame but may be a hit with other sysops..
create a separate executable for every menucmd in RENEWAVE, without a logo
or anything (so it just reads in renewave's cfg and then the menu/screen
files and does its thing) .. then you could have the UNREGISTERED /
Renewave logo come up when the download or upload executables are ran.
Actually - I was thinking that you could release the broken up version as
a separate release, but if you can get the door loading quick enough you
could simply add command line options such as -mc<Menucmd>  This will
allow sysops to integrate it right in with their normal renegade menus.

3) adapt the renegade style menu type files.  This way they can be loaded
into renegade's internal menu editor (if their rw menu directory is \menu)
and also people are already used to it.  Also make sure that you include
the UP_ARROW, DOWN_ARROW (or whatever they are) COMMAND KEYS so if we want
to include litebars in Renewave we can.

4) Add an ACS flag (nonstandard) that will allow us to determine whether
they are on a QWK setting or BLUEWAVE.  Actually .. another good idea if
you don't like the one I just menionted would be have the sysop define
which AC flag will be toggled (A..Z) for PACKET TYPE.  So.. let me say I
tell it to use the 'N' flag.  Then if they have BLUEWAVE the N flag in the
users account will be toggled on.  If they have QWK, N will be turned off.
Then have Renewave read in the ac flag of the user to determine if it was
changed on the BBS. 

5) Add the MENUCMD "OF" which will allow us to toggle the users' AR flags.
Let me say I wanted the users to define which bulletins they wanted in
their QWK packets.. Then I bring them to a BULLETIN CONFIG menu and they
select the bulletins, toggling flags either on or off.  then in the
bulletins to be included I set the acs to "F<flag>" and so on.

6) Increase the number of configurable bulletins to about 50.  Also, what
is your ACS system like?  I haven't tested out renewave yet, but can it
recognize access like "(A18&FA)|FG" correctly?

7) Some offline mail readers, such as sparky's 1st Reader, allow support
of advanced things such as news doors and such.  Add another section like
you do with the bulletins where it has "files to include" and a list of
files and the acs required.  So if I wanted to include USTODAY.NWS, I
would add it in, and then add the ACS.

8) Have support to run RENEWAVE (command line as well as in shell) to
upload a NETWORK REP packet) .. in addition, save sysops a heck load of
work and allow them to upload a .QWK packet.  So.. I download FREE.QWK
from FREE BBS (dumb example) and then I bypass REP <-> QWK converters and
I simply do a network QWK upload.

9) You know the download process?  where it displays the header and then
lists the message bases, new messages, sizes, etc..  Allow the sysop in
filenames and paths to add in the path to the 'header' file, and it will
load up the file and display it accordingly, and display it., Then it will
load up a 'msgscan' file, which uses a special type of variables to
display the info.. for example: 

header file may look like:

+---------------------------------------------------------------------+
| MESSAGE BASE        ECHO?      NUM MESSAGES   NUM PERSONAL   SIZE   |
+---------------------------------------------------------------------+

and the msgscan file may look like:

> @B#19 @E#5       @M#4       @P#4        @S

then it will load up this file into memory, then print it, replacing @B
with Basename, @E with echo, @M with Message num, @P with personal, etc
etc etc..  The file is just for one entry. but can be multiple lines.
This will allow sysops to add in ansi comments, etc so that you can use
full screen message gathering.  Lets say you want a box at the bottom of
the screen showing the message base, whether it is is echomail, num
messages, etc.. then in the top corner of the screen you want it to print
the number of messages total, num personal, and size .. by implementing
this the user will be able to.

10) I'm not sure if you have this yet or not, but can users add their QWK
file to their batch queue in RG? It must be possible, because when you go
into a door and come out your files are still in the queue.. or would you
have to edit the memory contents??  Would you be able  to get the pointer
addresses for the queue list?

11) Support (by sysops' definition) the SHORTMSG function.  Simply include
a base in the packet called SHORTMSGS or whatever and send any current
SHORTMSGS in the packet, and when it is uploaded (the reply packet),
simply check to see if there are any messages in there, if so, check how
long they are (again - sysop can define the max # of lines for each
message) ... and if it goes over that it won't be sent.. then if it
matches the line size then simply check if that user exists on the board
and edit their shortmsg.  Something you can do - if the short message is
over the sysop definition it will simply send that person the message in
email.  If the user doesn't exist, send the user that sent the shortmsg
email telling them it wasn't delivered.

12) Add support for mass mail.  Again, create a base called MASSMAIL, and
the user enters the message (the to field being the acs required).. then
when renewave reads it back in it sends it out.. of course this too would
be sysop definable.

13) Have a sysop toggle to translate the RG color codes to ANSI codes.
ANSI is compatible more widely than RG color codes.  This will work..
(Something tells me you already do this.. but not sure - does it convert
reply packets that contain RG color codes into ansi and put that into the
base directly?)

Well - that's all I can think of off the top of my head (I'm sorry ..
don't get me wrong - I am definately more than impressed with your program
currently - I sent the registration off last wednesday .. (first day I
looked at it) .. But why not make it known that your program is the
QWK/REP master ... then you'll be getting people begging you to port it to
other bbs systems.)...  I think all these ideas are good .. but you may
not think so .. and others may not so or they may .. hehe  Let me know
which ones you like - and I don't need credit for them - if you can
implement them - go for it :)

> This is actually a bug.  But you should be able to use .REP files locally.
> It's only a on remote uploads that ReneWave doesn't recognize the .REP
> files.  I've had no problems with uploading *.REP files locally.  As long
> as they're in your local upload directory, it should find both *.REP and
> *.NEW packets.

heheh I thought it would *ONLY* upload .NEW files .. didn't know it will
look for and load the .REP file as well... now I do..

I'm currently working on my own BBS software .. for Linux .. I'm calling
it Renaissance BBS system .. as in 'the rebirth'  it is going to be fully
multitasking and tied into the internet.  Right now me and my buddy are
trying to formulate a fido port .. (you know how they have telnet (21) and
ftp, etc) .. well the fido port will allow systems to connect with one
another directly over the internet, transmit security info, then exchange
mail and disconnect.  One thing I like about Linux is that the source code
comes with it - so you can run Renaissance on a Mac, Amiga, IBM, or Sparc
Server :)  And renegade uses the menucmds (which are in essence
subroutines) .. so if we produce the code right, then third party
developers can simply make a program to compile into it.  For example -
let us say that this BBS was actually available and not vaporware and you
wanted to put your qwk/bluewave into it.  You would simply have it edit
the source code, remove the !D, !U and OP 24 menucmd procedures and
replace them with your own, that will enable your program to actually *BE*
a part of the BBS.  The only thing is that we are going to have to
maintain an 'OFFICIAL' distribution which is distributed.  Anyways.. you
saw my ideas for your program (which is JUST a QWK gatherer .) . imagine
what kind of suggestions I would have for a BBS :) hehe 'nuff said ..
anyways.. I think this book is about finished .. so I will let you go ..

BTW - I did the 10-05 docs in RG.. and it looks like I'll be doing the
next version too.

-Dan
Ps - did you print this out?? :) hehhe 5-1 you did.. :)

Attachment Converted: "D:\Internet\eudora\Attach\slmr21a.zip"
