stimac@tymix.UUCP (Michael Stimac) (08/01/84)
Regarding the "saved game bug" the following has been posted: <You found a scroll of aggravate users> It's like taking off your plate mail and walking into a party room full of trolls. Every time I see people flaming about the "Saved game bug", I lose all sympathy. Guys, under 4.2BSD, ^Y is a delayed suspend signal. ^Y also means UP LEFT to rogue. If you get a ^Y through the game to the shell, the game won't immediatly die, but will get a suspend signal as soon as the program looks for any signals from the OS. Rogue responds (incorrectly) to ^Y by saving the game. If you want avoid this problem, and haven't written a shell script like: #/bin/csh ###/usr/local/rogue : avoids ^Y suspend signal causing "saved games" stty dsusp u /usr/games/rogue $* stty dsusp ^Y #type the real ^Y Then you have no right to complain at all. This is the third time I've posted this "fix"; eversince I put this on our system, we haven't had a saved game problem. (end of quote of previous posting) Probably the reason people keep complaining is that they don't understand your "fix" or why it applies to the problem. Many people play Rogue who know very little about Unix, shell script, suspend signals, and so on. You may feel that such persons ought not to be playing Rogue, but, there they are. For example, I understand that control-Y has two meanings in two different contexts, and I understand what a shell script is, but I am totally baffled by your assertion that "If you get a ^Y through the game to the shell". What the H*** does this mean? How can anyone get a character THROUGH the game TO the shell? Does the game pass characters on to the shell occasionally? If so, how can I prevent it? You use the word "if". This suggested that whether or not the game passes a ^Y to the shell is optional, or somehow under my control. Is it? In particular, are you saying that if a player types a ^Y, that the "saved game bug" will necessarily ensue? If people did not follow through on your suggestion the first time, you should have tried to explain things a little better instead of just repeating the same, difficult (for many people) to understand message and then complaining that no one understands it. I assure you that I, for one, would not continue to play while courting the "save game bug" if I really knew what you were talking about. This may sound like a flame, but is not meant to be. Please try to explain this more slowly for some of us who are not full-fledged UNIX hackers yet. I'd like to learn more, really... Michael D. Stimac
grw@fortune.UUCP (Glenn Wichman) (08/03/84)
bip. > Regarding the "saved game bug" the following has been posted: >> .... >> Guys, under 4.2BSD, ^Y is a delayed suspend signal. ^Y also means >>UP LEFT to rogue. If you get a ^Y through the game to the shell... >Probably the reason people keep complaining is that they don't understand >your "fix" or why it applies to the problem. Many people play Rogue who >know very little about Unix, shell script, suspend signals, and so on. You >may feel that such persons ought not to be playing Rogue, but, there they >are. >For example, I understand that control-Y has two meanings in two different >contexts, and I understand what a shell script is, but I am totally >baffled by your assertion that "If you get a ^Y through the game to the >shell". What the H*** does this mean?... Well, it doesn't mean anything, actually. [This next part is to the '>>' guy]. The shell isn't the thing that catches ^Ys, the tty driver is. And the ^Y doesn't get "through the game to the shell", it never gets to the game in the first place. In simple terms: In UNIX, a part of the kernel called the "tty driver" interprets the characters you type. Usually, these are just ASCII characters that the tty driver sends on to the program waiting for input, however, a couple of charcters are special, for instance the interrupt character. If the tty driver sees this charcter come in, rather than sending it along, it will send an interrupt signal to the program. Through the UNIX program stty, you can set your all these special charcters to whatever ASCII values you want. ^Y is one of these special characters. It means 'suspend this process as soon as it wants some input', but that's not important right now. The purpose of the shell script which was suggested in the original article is to change that character from ^Y to something else (I suggest setting it to <null> (^@), which is something you are unlikely to type accidentally). I'm also not convinced that that's all there is to the "save game" bug. -Glenn.
mac@tesla.UUCP (Michael Mc Namara) (08/03/84)
[Your purse feels lighter--More--] ********* Ok, this is a rather long (119 lines) discussion of what is *perhaps* going on with the saved game bug (SGB) If this malady no longer plagues you, hit 'q' !! ..!cornell!tesla!mac > Regarding the "saved game bug" the following has been posted: >> .... >> Guys, under 4.2BSD, ^Y is a delayed suspend signal. ^Y also means >>UP LEFT to rogue. If you get a ^Y through the game to the shell... >Probably the reason people keep complaining is that they don't understand >your "fix" or why it applies to the problem. ) In simple terms: In UNIX, a part of the kernel called the ) "tty driver" interprets the characters you type. Usually, these ) are just ASCII characters that the tty driver sends on to the ) program waiting for input, however, a couple of characters are ) special, for instance the interrupt character. If the tty ) driver sees this character come in, rather than sending it along, ) it will send an interrupt signal to the program. Through the ) UNIX program stty, you can set your all these special characters ) to whatever ASCII values you want. ^Y is one of these special ) characters. It means 'suspend this process as soon as it wants ) some input', but that's not important right now. The purpose ) of the shell script which was suggested in the original article ) is to change that character from ^Y to something else (I suggest )* setting it to <null> (^@), which is something you are unlikely )* to type accidentally). ) I'm also not convinced that that's all there is to the ) "save game" bug. ) ) -Glenn. ) Thanks, Glenn; and Michael, I hope the above has shown some light for you and others what is (perhaps) going on. I am afraid that trying to deal with as many different operating systems as we do here sometimes causes me to get slack with my terminalogy (sic). [ It was sick, wasn't it! ] While I am not the most expert UNIX (tm) hacker, what I discovered about rogue by basically trying what I could think of, with the experience of writing curses-based [^1] programs and editors is a system fix to a bug in the program. I was cavalier in my description "..lets a ^Y through to the shell..". I will try to clear up what I meant, and continue Glenn's explanation, and discuss further what I *think* is going on. Since rogue uses ^Y as a command character, they must be run- ning the game in RAW mode, which is a mode the tty driver can be set to. There are basically three modes of operation; COOKED, which is what the standard system is in -- In this mode you can type ^U to erase a line, ^W to erase a word, i.e., control characters take their normal effect, and also characters do not become available to a program until you hit return; CBREAK, -- The same control character processing is available as above (in COOKED), but characters are not buffered: they are available to the program as you hit the keys (used in programs like more where you just have to hit the space bar to continue); and RAW, where no processing of the input is done; characters pass through to the program, parity bits and all. Evidently, as far as experience in playing the game can take me, rogue goes into RAW mode for movements; otherwise ^Y's effect would be much more immediate. [ ^Y is a delayed suspend character, which will cause the current program to become suspended as soon as it reads for more input. ] Apparently, at some point, perhaps when asking the user to name a particular potion or scroll, the game goes into CBREAK mode, to allow the user ^U and delete keys. Perhaps it does not come out of CBREAK mode correctly? Perhaps during this time (due to excited game playing, the bug only occurs during the *best* games) the user types a ^Y? Anyway, if you alter the function of the tty driver, by use of the stty(1) command, so that it no longer recognizes ^Y in particular, and *any* character in general, as a suspend character, you will have neatly side-stepped the issue of where in rogue 5.3 the bug is and how to fix it in the source by removing that capability of the tty driver for the duration of the game. This can be done by 'stty dsusp u', which sets DelayedSUSPend character in the terminal driver to be Unset. To make yourself even more save, you can Unset the suspend character via 'stty susp u'. Then *nothing* can get between you and the , (except a few D's,G's and J's). Since this removes some of the features of the new tty driver from your use, you might want to reset these features after the exhausting battle. The best way to do this is with a shell script that sets up a rogue stty environment; invokes rogue; then resets the standard stty environment for your terminal. I included a simple such script in the earlier posting the above discussed. ------------------------------- 1 curses : a high level subroutine package that uses termcap descriptions of terminal capabilities to ease programmers interface with the jungle of terminals out there. Basically, if a programmer wants to add a char- acter at location X on the screen, he calls a subroutine from curses which looks in the termcap data base for what the magic words are for the terminal currently in use, and then utters them to the terminal. ************ Ok, I hope this has cleared up the problem somewhat, and again I want to disclaim that the save game bug fix (SGBF) is based on *my* conjecture about what is going on; I am just a lowly @ fighting the same battles you are, OK? ..!cornell!tesla!mac
ron@wjvax.UUCP (Ron Christian) (08/06/84)
No no no! Don't set suspend signal (normally ^Y) to ^@!! That's <control> <spacebar>!!! It's even more likely to be struck!! -- "Trivia is important." Ron Christian Watkins-Johnson Co. San Jose, Calif. (...ios!wjvax!ron)
maggie@mit-eddie.UUCP (margaret hirlinger) (08/08/84)
I don't know if ^Y is the problem or not but I have a "work-around" that seems to beat the "saved-game-bug". to wit: Always save your games when you are ready to go down the stair when you restore. I mean that you should be standing on the stairs so that your first command to the restored game is ">". I have always found that this works. I, unfortunately do not have a work-around (or fix) for the Nymph-steals- a-multiple-item and screws your inventory problem (except, of course, avoid Nymphs). Hope this helps. May none of your ","s be Xerocs. --maggie maggie@mit-eddie (maybe)
dgg@mit-athena.ARPA (David G. Grubbs) (08/10/84)
I would like to point out that the individual who claims that ^@ is produced by striking <control>-<spacebar> is using a brain-damaged terminal. The way to produce ^@ (or <control>-@) is to hold the control key down and press an @. This is usually done by holding down the SHIFT key and pressing the "2" key, though older style terminals have the @ on some other key. In any case, <control>-<spacebar> is not an ASCII character. It is a stupid design decision on the part of some terminal manufacturers (like DEC -- the VT100 is guilty of this stupidity) which results in confusion between the ASCII character set (which is rationally designed), the keyboard layout (which is not) and the contortions through which some terminal designers force us in order to produce certain characters (which is little else than arrogance).
gwyn@brl-tgr.UUCP (08/13/84)
Oh, good grief. There is very little agreement on which combination of keys to press to produce ASCII codes for NUL, FS, US, etc. The CTRL+SPACE combination for NUL is certainly easier to type than CTRL+SHIFT+2 or CTRL+SHIFT+P or whatever. On my 5620 it is CTRL+",".