Trekker
A Qmodem 4.3 Hostmode
Illustrated and designed by David E. Chandler '95

CREATIVE INTERFACE DESIGN, inc.

Introduction

This product is intended as a RIPscrip and RIPterm teaching tool that will 
allow everyday users to utilize the compactness and efficiency of 
RIP (Remote Imaging Protocol).  Although many BBS' are supporting RIP, 
they are doing so in a necessarily crude fashion..., the just released 
RIPterm 2.0 recognizes only Native RIPscrip (Scripting primitives like text, 
lines, shapes, buttons and text windows/mouseable areas), so there are 
concerns for the time investment and effectiveness of the product generated.  
Another crucial issue is ownership and control of graphics and concepts.  
Creative Property is something which often seems prohibitive when dealing 
with the concept of giving a user all the graphics necessary to run the 
system, and even the code which makes it all run.

In order to resolve the issue of Creative Property it is necessary that the 
Sysop reconcile their investment of time and creative energies to the purpose 
of creating something with merit.  If the concepts, artwork, and execution of 
the screens is something efficient and artful, then users will appreciate the 
service, and in fact, may even begin to offer artwork and design 
suggestions...this kind of interaction generates a sense of stewardship, 
which translates into a fanatically loyal userbase, something every BBS 
needs.
	
In order to foster a greater understanding of the simplicity and efficiency 
of RIPscrip, I have cobbled together a hostmode for what I believe to be one 
of the most ubiquitous and sturdy communications programs ever made for 
Dos: Qmodem 4.3 (Shareware, The Forbin Project).  So why Qmodem 4.3?  Well, 
it has a nifty set of redefinable screens, and it manages users just like a 
BBS, which makes it ideal for learing how to setup a BBS using RIPscrip.

Effective RIPterm 

The most crucial step in learning how to create things for RIP is learning 
how to utilize RIPterm as a testing tool.  Although I've never been rich 
enough to purchase Telegrafix's RIPaint program, I heard that a version of 
RIPterm is included with it, and for good reason, unless you own two phone 
lines, and have a vast deal of faith in the playback utilities that let you 
preview your screens, only RIPterm itself will behave properly, for you, and 
for any user looking at your screens.   The key to all this is utilizing 
LOCAL PLAYBACK, which involves calling up a screen by making a keystroke 
macro telling RIPterm which file to display.  Setting this up is not too 
complex, when in RIPterm, press [Alt-k], press e and press a key combination
like [alt-1] thru [alt-9], all of which are unused by RIPterm itself.  

A local playback call looks like this, 
$>prelog.hst$
	This playback call will summon the prelog.hst screen, which in turn will
	make playback calls from within itself to call up the other screens for
	the user.

This hostmode was tested in exactly this fashion, and depends on local 
playback calls at the user's  terminal to maximize efficiency...there is no 
need to even poll the host system for screens when the RIPscrip exists at 
both ends, because the user has all the necessary graphics on thier end.

For anyone with problems letting other people have both RIPscrip and all the 
icons, this may seem like your giving away the farm...and in a way it is, 
but when you consider the complexity that one screen can represent, it will 
become readily apparent that a user can customize thier own screens, create 
thier own icons and rename them to ones you have already created, and 
exercise their own creative choices...and the bottom line here is that  
the user is learning by changing something only they can see,  and the fix 
is only a download away.

There is a downside to all of this though...RIPterm 1.54 was the last version 
of RIPterm which will still support Dos-Only hardware, RIPterm 2.0 uses BMP 
files, WAV files, and will operate only in a 386-Protected mode environment, 
which leaves many people and myself out of the game (until I get a better job 
or inherit some money, HA!) because we are stuck with older machines; however, 
this also puts new pressure on BBS software to include new features to 
support RIPterm 2.0, and after seeing the rather lame support from the Tucson 
BBS community for RIP, I really don't see RIP taking off soon, unless the 
mass conversion of PCX/GIF/MPEG>>BMP files is something a lazy sysop is 
willing to risk legal problems with, especially for pay-boards, this goes 
double for Lazy-no documentation reading-Tucson sysops.

In summary, I would like to warn Sysops and Users alike away from 
GIF>>PCX>>ICN file conversions for Ripterm Vers. 1.54...there are two main 
reasons for this, 
1) GIF's are usually 256 colors, and there was a recent legal battle over 
	this format...2) when you convert an image from 256 colors to 16, the 
	resolution and color schemes are trashed...and if the image was scanned, 
	then any attempts you make to change the image will stick out like a 
	sore-thumb, unless of course you know what you're doing.(rarely happens)
	There is usually more merit to producing original graphics in the 
	640 x 350 EGA mode than to import them, with clip-art coloring being a 
	shinning exception, you can fill in the colors and modify these black and 
	white images, which are readily accessible, and they can greatly simplify 
	your illustration job.
De Re Going Native...

You may see the term Native RIPscrip used as a descriptor in the documentation.  Native RIPscrip is used to describe any of the commands that RIPterm uses in order to draw, imbed text, or alter the image on the users screen.  This Native RIPscrip is MODEM DEPENDENT, and as such the speed of the user's Modem is crucial in executing this code.  However, Icons are not restrained in this fashion, and by using a FULL-ICON interface that it is possible to transcend the communication hardware limitations, and empower even a 2400 bps user with screens that draw several times faster than any Ansi counterpart.  The faster the Hard drive and CPU the user has, the better the ICON interface will operate, and when comparing PCX interface communications software, RIPterm simply blows everything out of the water...

Disclaimer Section

Although an ugly part of this document, it is necessary to point out that 
TREKKER is FREEWARE and has been designed to work specifically with only 
two pieces of communications software, namely RIPterm 1.54 & QModem 4.3 
(Shareware version).  As such, any misuse, loss of data, and any dammage 
incurred to the user (physical, mental, virtual) of this product shall be 
the sole responsiblilty of the user and in no way whatsoever shall CREATIVE 
INTERFACE DESIGN, inc. be responsible.  

	Although RIPscrip  is fairly goofproof, there are always those people who 
	neglect the documentation.  This select group are destined to suffer, 
	and I imagine that unless the user of this product reads the documentation 
	included in the RIPterm 1.xx archive, they are not going to obtain any 
	enjoyment or usefulness from using RIP or this Hostmode. 

About the Author-

	David E. Chandler is a Computer Sciences Major attending 
	Pima Community College in Tucson, AZ (3rd Yr).  
	His RIP credentials include, donating/illustrating/Implementing-Assisting 
	the full-icon interface for The Thieves' Guild BBS 1-(520) 321-1265,  
	and creating two interfaces for other Tucson BBS's, 
	LightSpeed Space Station (a Trek Theme board where TREKKER's Graphics were 
	developed) and Babylon-69, both of which do not currently support RIP 
	for their own reasons (nothing having to do with RIP itself).

	You can contact me at Fido 1:300/508  (This is the Thieves' Guild)
	or (snail-mail)
	David E. Chandler
	2505 N. Dodge Blvd Apt E-1
	Tucson, AZ 85716-2601  
	
	If you want a reply, I can netmail (fido) or if you include an SASE, 
	I will be more than happy to write you back.  
