Game Killer

home *** CD-ROM | disk | FTP | other *** search

/ Game Killer / Game_Killer.bin / 795.DEMITOR.DOC < prev next >

Wrap

Text File | 1990-02-11 | 24KB | 595 lines

DEMITOR version 1.0 (c) 1990 Laemming Wheeler INTRODUCTION ************ DEMITOR is a powerful editor for use with Flight Simulator version 4 (IBM) demo files. Using DEMITOR will allow you to produce higher quality demos in much less time (this means MORE flying time). Features: * Edit comments and keys; both content and timing * Cut and splice demos * Link and remove mode files * Knock out sound during stall warnings * Use MACRO command language for easy view selection * Move message bar down and up during demo * Center text in message bar for easy viewing * Use special preview format for precise demo development * And more DEMITOR is a shareware product; if you find it a useful ad- dition to your FS enjoyment, please send the $10 DEMITOR license fee to: Kyrna Wheeler KikiWare 17 Ferguson Road Warren, NJ 07060 USA Please include your return address or CIS # and specify the version you are licensing. Thank you, Laemming Wheeler DEMITOR author/Kyrna's dad CIS 71317,2616 HOW DEMITOR WORKS ***************** A simple "demo" is a file (extension: DEM) that preserves the path of the aircraft and history of keys pressed during the creation of the demo, and also stores comments (which may have been added later) in a format similar to how movies store information -- FRAMES. DEMITOR reads these frames and shows the comments and key-presses associated with each one, allowing them to be changed as desired. Demos may be more complicated: they may have MODE files attached. DEMITOR reads these too, and will preserve them or delete them as desired. While adding, removing, and editing comments are the easiest activities to understand and use, doing the same with key- press series requires some translation: the numbers found and displayed by DEMITOR are representations of the keys ac- tually pressed during the recording of the demo (the keys themselves are translations of an action desired). For example: Action desired- change the view direction to rear, left First translation- scroll-lock, PgDn keypresses Second translation - 70,79 (scan codes of the keys) You've probably learned the first translation from flying Flight Simulator; as for the second translation- better let DEMITOR do it. DEMITOR allows the entry of special comments (which shall be referred to as "macro commands") as if they were normal comments. After all the special macro commands (and comments) are entered, DEMITOR will do the translation automatically and store the results as key-press series. The macro command translation dictionary is a user- accessible text file called DEMITOR.KEY. Make a printout of this file for a complete list of macro commands supplied with this version of DEMITOR and detailed instructions on what they do, how to use them, and how to add your own cus- tom macro commands to the file. In the above example, you would simply enter a macro command "view(left,rear)" and (T)ranslate the file before (S)aving to achieve the desired effect. Since timing of comments and views is often important in demos, DEMITOR provides another way to enter comments and macro commands; the storyboard file. This is a file you create yourself (using your favorite non-formatted text editor) with the extension BRD. It simply consists of a series of lines describing which frame and what comment (or macro) should be inserted. In our example, if you wanted to perform the view change at frame 51 the line would look like this: 51,"view(left,rear)" DEMITOR allows you to (I)mport the entire collection of com- ments and macro commands. (T)ranslate the result and (S)ave the file and you now have a demo that switches the view direction to left, rear at frame 51. If in review you feel that the view switch should take place one frame earlier just change the frame reference in your story board file (to 50,"view....). Reload the original demo into DEMITOR, (I)mport, (T)ranslate and (S)ave. There's a lot more we'll get into later. First let's go through the menus to get a taste of all the options, and then discuss how to use them in a practical situation (go through the next section lightly; you can come back for the details when you need them). DEMITOR MENUS ************* GENERAL ------- DEMITOR.EXE and DEMITOR.KEY should reside in the same direc- tory as your demos. Type DEMITOR<enter> to get started. The file DEMITOR.KEY must be present for DEMITOR to work. A hardcopy listing of DEMITOR.KEY should be made and kept handy as a reference. When filenames are requested the extension is optional and understood to be DEM (exception: in the splicing menu where the first file may be either DEM or MOD and must be specified. LOAD Menu --------- (S)elect demo: asks for the name of the demo to be loaded (L)ist demos: gives a listing of demos in the default direc- tory (U)tilities: enter splice menu (allows linking of modes to demos, demos to demos, and stealing a mode from another demo for linking) Load Notes: No extension is required for LOAD (always .DEM) If the requested file does not exist, another filename will be requested. UTILITIES (Splice menu) ----------------------- You must enter the names of two files that you intend to connect together. The first may be an existing demo or mode file; the second, an existing demo file. When entering the selection for the first file you must include the extension. When two valid files have been entered (in any order) DEMITOR analyses them and proposes the splice formula it will use. This formula is not changeable directly but will serve as a confirmation to those familiar with the details of demo splicing that their choices are correct. There is one com- bination that DEMITOR needs some further input about to clarify your intentions: when the first file is a demo with a leading mode and the second, a demo file without a leading mode. Here you are given the choice to do a straight demo to demo splice or to "steal" only the leading mode of the first file and link it to the second. When ready to do the splicing an output file selection menu will appear. The output file must be a demo and if no exten- sion is entered DEM is assumed. It is forbidden by DEMITOR to save back to the source file. Progress in splicing is displayed with file sizes during the splicing operation. Completion and acknowledgment will return you to the LOAD menu. MAIN menu --------- (I)mport: bring in a storyboard file (V)iew: read and search frame contents (T)ranslate: interpret and activate all macro commands (M)ark: enable frame numbers to be shown onscreen during playback (S)ave: enter save menu IMPORT ------ This function requires a "storyboard" file existing in the same directory having the same name as the loaded demo and a .BRD extension. If this file is not present this feature will do nothing. See story board notes later on. MARK ---- This feature will put the frame # into all uncommented frames of the loaded demo. This is never used on final "takes" but on intermediate review copies. Be careful when naming the review copies in order to avoid confusion ("now, let me see, I think I called it..."). Because comments that are not immediately followed by another will last on the screen longer than otherwise, using (M)ark will cause artificially shorter screen life of com- ments, during the review playback (no big deal, just take that into account). (M)arks also consume memory and bring you a bit closer to FS4's demo size limit (unspecified but you'll know it when you reach it). TRANSLATE --------- This feature will look through the loaded demo and identify macro command instructions for key press insertions or spe- cial effects and automatically implement these. If some in- structions appear to be missed it will be due to misspelling or that they do not appear on your current DEMITOR.KEY file. A good way to check for macro "misfires" is, after (T)ranslation, go into (V)iew and find (C)omments: this will show all comments in sequence, one by one. Since a success- ful (T)ranslation of a macro command results in that command being removed from the comment section of the frame, any missed macros (e.g.- zooom(in) [should have been zoom(in)]) will still be present and (V)iewable as a comment. (T)ranslation does not automatically take place when you use the (I)mport function. You must (T)ranslate the (I)mported and/or edited frames subsequent to their entry (if they in- volve macro commands; regular comments need no (T)ranslation). This is so you may save the raw entries if you choose (e.g. - to make a nice review copy of a demo, (I)mport then (T)ranslate then (I)mport again. When you run this demo it will display the commands as it executes (hopefully) their actions. If you do this DEMITOR will warn you that you are saving an un(T)ranslated file; just say yes, proceed anyway, in this special case). (V)IEW (brings you to Frame view/edit menu) FRAME VIEW/EDIT menu -------------------- (F)rame #: (N)ext: (P)revious: find (C)omment: or (K)ey: (E)dit: <esc>: First select the frame to be displayed by any of these methods: (F) allows a specific frame # to be entered (N) displays the next frame (P) displays the previous frame (C) will find the next commented frame (K) will find the next frame containing special keys per- taining to view mode changes, view direction changes, map or menu calls (E) allows editing of the currently displayed frame. Good for manual touchup of comments and keys, any key-press ex- perimentation, and removal of extraneous key press sequences (careful, here, that you don't screw up due to related keypresses appearing in multiple frames- see Strategic Considerations). Longer-than-standard comments are allowed (up to 70 charac- ters) When saving you may choose to have the comments cen- tered in the menu bar during playback or left-justified as usual. Editing by hand is not generally recommended for use in con- junction with the Import feature except on initial cleanup of your demo (if you're using the import feature it's better to make corrections to the storyboard file, and the mode instead of correcting the modified demo by hand in order to retain maximum flexibility in the development process). To delete an existing comment, (E)dit (C)omment <enter>. To delete existing keys, (E)dit (K)eys <enter> (a harmless 0 will remain for that frame). For example, let's say you used a map during the recording of your original demo, but have decided that the map display is not helpful to the purpose of the demo, and you desire to remove it: first identify what the key series is for map (look at the DEMITOR.KEY file and observe that "map(on)" = one key [69]. Next, fire up DEMITOR, load the demo and locate this key (either use (V)iew and find ...(K)ey or make a marked demo and observe the frame number at which the map turns on). Choose (E)dit (K)eys and type in the all the keys in that frame except for the [69]. The demo, when saved will not have a map on com- mand and therefore the map will no longer appear, as desired (if you're a perfectionist, you can knock off the map-off keys [69,69], as well, in the same manner). This "cleaned- up" demo now becomes the original for the purposes of the remaining editing or storyboard use. <esc> returns you to the main menu SAVE menu --------- (S)elect: to enter the name of the demo to be saved (L)ist: to get a listing of demos in the default directory <esc>: return to main menu (for those times when you remem- ber something you forgot to do; like (T)ranslate) before saving) When (S)aving you'll be asked about some options: If the file has modes attached you will be given the option to keep them or drop them. If the file exists you will be asked if you want it over- written. You will be asked if you want the message text centered. While this option offers excellent readability, it will result in a larger file; so if you are pushing the FS4 demo size limit with your creation you just might want to answer no to this one. (M)arked frames are never centered for ob- vious reasons, no matter what the reply to this question is. No extension is required when selecting the SAVE file (it's always DEM) It is forbidden by DEMITOR to save back to the source file. The program does terminate after saving. To terminate the program without saving choose Q at the MAIN menu. DISCUSSION ********** STRATEGIC CONSIDERATIONS ------------------------ You have more options available to you with DEMITOR so you may choose to alter your strategy when actually recording the original demo (compared to pre-DEMITOR approaches). For example, where the pre-DEMITOR strategy might have been to squeeze in every single possible view mode and direction commands into the demo as it's being recorded (how else could you get them in there?), with DEMITOR you might choose just the opposite - including only those commands that enable you to fly the demo properly; you know that you may add, move or delete these entries as you desire, after the demo has been recorded. The next step after recording an acceptable version of the demo flight is to watch it a few times in order to decide when and how it should be annotated (where to put what com- ments) and when and which additional view changes are needed (and, perhaps, which existing ones are no longer needed - [e.g.- you might have consulted your map <Num Lock> to help you find your way but decide not to keep it because it doesn't support the purpose of your demo]). This is an excellent time to use the (M)ark feature: run DEMITOR, load your original demo, and choose (M)ark, then save to a DIFFERENT! filename (you might add an "M" to the name). This (M)arked demo is the one to review and take notes about. The frame numbers that appear will help you with the timing of the ideas you want to implement. In ad- dition to opportunities for comments and view commands, you should also note any particularly sensitive areas that you want to make certain not to disturb. These areas are characterized by occurring over a span of frames, not just within one frame only. A good example of this is when a menu is called up during a demo- it is rare for all the keys to be recorded for that action in one frame only. Therefore, even though DEMITOR *appends* the key series resulting from (T)ranslating a macro command to the keys already in the designated frame, it has no way of know- ing for certain if these existing keys are part of a larger sequence that may be disturbed by extra keys showing up. So by noting any sensitive areas you may easily be able to avoid asking DEMITOR to disturb these sections inadver- tently. A corollary to this is; if you see any inexplicable funny stuff popping up suddenly in a once-stable area, you may suspect the possibility that you have inadvertently asked DEMITOR to stick some keys where they shouldn't go. This will be rarely, if at all, a problem but it's best to be forewarned, hence the disproportionate verbiage. When you do have a good idea of what you're going to do mapped out (hard copy, I hope) you pop back into DEMITOR and call back the original demo (not the marked one). If you definitely want to get rid of something permanently (like the map views- see previous example) then use the frame view/edit functions to do this (do it in conjunction with those notes you took). After deleting every thing you don't want, (S)ave this as a new demo and use this cleaned- up version as your original. How you introduce the comments and view changes, etc. depends on the quantity and the degree of confidence you have in knowing where these should occur. Few changes and high confidence means use the editor directly to enter the info (if you are using macro command instead of entering key sequences directly, you might consider saving this file before you (T)ranslate it to make changes easier to do if necessary. Extensive comments and view changes, panel switching, etc. and uncertainty over timing (needs ex- perimentation) would imply using the story board technique. You'll quickly develop your own comfortable style once you start playing with a few demos and see what each part of DEMITOR has to offer. STORYBOARD FILES ---------------- These files must have the same root name as the demo on which it's intended to operate and the extension BRD. A storyboard file is an ASCII text file that you create which describes the macros, and comments you want to place in the demo and their locations (frame numbers). The format is [frame number],macro or text surrounded by quotes . . 0,"documentation comments" . . -1,"end of file" See the example DEMITOR.BRD If you (M)ark a freshly made demo and observe it running on FS for a few cycles you should be able to get a good idea of comments and view changes you'd like to use, and where. Make some notes and use EDLIN or a non-formatted word processor to generate a storyboard text file. It's best to have the steps in order of frame number but not necessary (just confusing). In the event of duplicate frame numbers being present, the one with the latest postmark wins. In the event that a frame number is larger than the total frames in a demo, it will be ignored. There is no limit on the number of entries in a storyboard file. Comments longer than 70 chars will be truncated. If you have a typo in a macro it will show up as a comment in the demo, after (T)ranslation for easy identification. MINI-TUTORIAL ------------- Fire up DEMITOR, load DEMITOR.DEM, (I)mport, (T)ranslate, (I)mport again, and (S)ave (yes, you want to proceed...), choosing the centered message option. Fire up FS4 and take a look at what you just did! Try again, using the (M)ark op- tion, or add a comment of your own, or ... ERRORS/PROBLEMS --------------- Troubles may show up in two ways: DEMITOR exiting with an error message (for example- if it cannot recognize a mode attached to a demo, say the $8A linking byte was left out during a manual link) or FS4 has difficulty in "flying" the edited demo (if you have loaded up one or more frames with too many keys [no, I don't know what's too many; it seems to depend on what the keys are trying to do and the machine it's running on]). If the latter, first reboot your system and retry the demo (just in case you are seeing the effects of a previously ob- tained electronic hernia) before concluding that the trouble is with the current demo. LIMITATIONS (known) ------------------- Frames: 2000 Macros in the KEY file: 100 Embedded Mode files: 10 in addition to leading mode REFERENCES ---------- Microsoft Flight Simulator version 4 manual DEMOS.TXT: Jim Ross' instructive text on how to make demos; found in CIS GAMERS LIBRARY 10 ACKNOWLEDGMENTS --------------- The humor, constructive criticism, infallible bug-hunting, hours of dedicated demo discovering and the friendship of the BETA team, Jim Ross and Mike Ward, have been a reward in itself for the author. Encouraging discussions with Rick Lee and Jeff Horrocks, en- thusiastic flight simulator Section Leaders on CIS, and Chris Manrique of SubLOGIC Corporation helped immensely in trying to sort out what's important to FS4 fans. The original demo creator, himself, Hugo Feugen of Bruce Artwick Organization, not only contributed encouragement and wishes for increased popularity and use of the demo capacity of FS; he provided the key to splicing demos and linking modes. Finally to the (unsuspecting) suppliers of test material (demos) that I used to test and exercise the developing editor prototypes: Charlie Gulick (RCFLYING: by far the most key presses), Jeff Givens (VEALSILS: longest, most memory intensive), and Rick Lee (his creative HIJACKER will become a classic), I give my thanks. Thanks go as well to all those demo-makers, showing the potential for this most share-able aspect of FS4. LEGAL STUFF ----------- Flight Simulator is a registered trademark of SubLOGIC Cor- poration used under license by Microsoft Corporation. Microsoft is a registered trademark of Microsoft Corpora- tion. IBM is a registered trademark of International Business Machines Corporation.