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.