(First time since decades here. Had to clear that funny arabian spam first
to see whether this newsgroup is still active.)
This is a question related to roguelikes (specifically Nethack and Slashem) on the _Unix_ platforms.
Background: I am playing NH-3.4.3 based Slashem and have no colors (for HPs, messages, or menus) available.
Instead of fiddling a patch into the core code(s) I had the idea to create
an interception layer for the I/O to do the coloring so that this program could be used more universally and independent of the actual roguelike (or usable even for completely unrelated character oriented programs).
Basically I thought of a pty that would read a user definable config file with patterns and associated colors and spawn the (Slashem-) process. I/O would be connected appropriately from/to terminal and the child process. Input would be simply passed through while output from the roguelike would
be compared against the patterns and colored as defined by the config file.
But a quick test (without pattern match, just transparent I/O) did not lead to the desired effect, though. The roguelike typical one-key command input required hitting the Enter-key reglarly, so I seem to have missed something. (Seems like problems with char-by-char mode, that somehow a line-oriented mode became active.)
Without going into details, my question would be whether someone has done something similar (that works) or knows what has to be considered to make such a function work in principle.
On 05.01.2020 19:33, ootiib@hot.ee wrote:
On Sunday, 5 January 2020 15:13:11 UTC+2, Janis Papanagnou wrote:
(First time since decades here. Had to clear that funny arabian spam first >> to see whether this newsgroup is still active.)
This is a question related to roguelikes (specifically Nethack and Slashem)
on the _Unix_ platforms.
Background: I am playing NH-3.4.3 based Slashem and have no colors (for HPs,
messages, or menus) available.
Instead of fiddling a patch into the core code(s) I had the idea to create >> an interception layer for the I/O to do the coloring so that this program >> could be used more universally and independent of the actual roguelike (or >> usable even for completely unrelated character oriented programs).
Basically I thought of a pty that would read a user definable config file >> with patterns and associated colors and spawn the (Slashem-) process. I/O >> would be connected appropriately from/to terminal and the child process. >> Input would be simply passed through while output from the roguelike would >> be compared against the patterns and colored as defined by the config file.
But a quick test (without pattern match, just transparent I/O) did not lead
to the desired effect, though. The roguelike typical one-key command input >> required hitting the Enter-key reglarly, so I seem to have missed something.
(Seems like problems with char-by-char mode, that somehow a line-oriented >> mode became active.)
Sounds like problem with I/O buffering so your input is for whatever reason waiting in some buffer and not forwarded. Without precisely knowing what you did it is just useless guesses and suggestions to debug.
Thanks for the confirmation. I am aware that there's no use guessing without me posting the gory details of my pty implementation; I wanted to avoid that by restricting myself first to the subsequent [assumed] simpler question...
Without going into details, my question would be whether someone has done >> something similar (that works) or knows what has to be considered to make >> such a function work in principle.
Over 20 years ago when online multiplayer roguelikes (called MUDs) were popular people wrote lot of such filters, clients and also bots to terminals.
Yeah, that's what I assumed, so my hope for some hints in that direction.
But those MUDs had also line-entry-oriented interfaces not key-press-oriented interfaces.
(I didn't knew that MUDs were line-oriented.) My impression was that bots have been used, e.g. for pudding farming, "nethack-o-matic" bots, or other monotoneous tasks, observable in telnet based Nethack sessions (like NAO).
Keyboard entry is not as trivial to
serialize as might appear at first glance.
(Two decades ago I also wrote line-buffered ptys that worked quite well.)
Something speciality might be necessary for the "key-press-oriented input", though my hope would have been that with the standard Unix system I/O it should be feasible. - Isn't Nethack's I/O also based on select/read/write system calls?
On Sunday, 5 January 2020 15:13:11 UTC+2, Janis Papanagnou wrote:
(First time since decades here. Had to clear that funny arabian spam first >> to see whether this newsgroup is still active.)
This is a question related to roguelikes (specifically Nethack and Slashem) >> on the _Unix_ platforms.
Background: I am playing NH-3.4.3 based Slashem and have no colors (for HPs, >> messages, or menus) available.
Instead of fiddling a patch into the core code(s) I had the idea to create >> an interception layer for the I/O to do the coloring so that this program
could be used more universally and independent of the actual roguelike (or >> usable even for completely unrelated character oriented programs).
Basically I thought of a pty that would read a user definable config file
with patterns and associated colors and spawn the (Slashem-) process. I/O
would be connected appropriately from/to terminal and the child process.
Input would be simply passed through while output from the roguelike would >> be compared against the patterns and colored as defined by the config file. >>
But a quick test (without pattern match, just transparent I/O) did not lead >> to the desired effect, though. The roguelike typical one-key command input >> required hitting the Enter-key reglarly, so I seem to have missed something. >> (Seems like problems with char-by-char mode, that somehow a line-oriented
mode became active.)
Sounds like problem with I/O buffering so your input is for whatever reason waiting in some buffer and not forwarded. Without precisely knowing what
you did it is just useless guesses and suggestions to debug.
Without going into details, my question would be whether someone has done
something similar (that works) or knows what has to be considered to make
such a function work in principle.
Over 20 years ago when online multiplayer roguelikes (called MUDs) were popular people wrote lot of such filters, clients and also bots to
terminals.
But those MUDs had also line-entry-oriented interfaces not
key-press-oriented interfaces.
Keyboard entry is not as trivial to
serialize as might appear at first glance.
You are looking for interhack.
https://taeb.github.io/interhack/
On 07.01.2020 04:06, Elijah Stone wrote:
You are looking for interhack.
https://taeb.github.io/interhack/
Heh, I was sure that someone did something like that for coloring
but this is even a hole system of useful stuff. Thanks!
Just one (important) point. I read in "3. How does it work?" that
"It's just a very specialized telnet client." (to access servers
like NAO). - I'd needed some simple process usable for local play.
Has someone experiences how (or if) interhack can be used that way?
To provide some detail about my own tries, I used cfmakeraw() to
obtain the character-wise I/O (which somehow did not work). It is
described as
cfmakeraw() sets the terminal to something like the
"raw" mode of the old Version 7 terminal driver: input
is available character by character, echoing is dis‐
abled, and all special processing of terminal input and
output characters is disabled. [...]
so it at least looks like it should do what I wanted.
Janis Papanagnou wrote:
To provide some detail about my own tries, I used cfmakeraw() to
obtain the character-wise I/O (which somehow did not work). It is
described as
cfmakeraw() sets the terminal to something like the
"raw" mode of the old Version 7 terminal driver: input
is available character by character, echoing is dis‐
abled, and all special processing of terminal input and
output characters is disabled. [...]
so it at least looks like it should do what I wanted.
There are two potential layers of buffering involved. One is buffering
at the terminal, which can be disabled in a number of ways. IIRC,
cfmakeraw doesn't actually change the terminal settings, it simply
modifies an existing set of terminal settings to represent a raw-mode
version of those settings and leaves it up to you to apply them (with a system call like tcsetattr).
Note that it's probably a good idea to
remember the old terminal settings too (available via tcgetattr),
because if you don't restore the original terminal settings as your
program exits, the terminal will act weirdly after your program exits.
The other potential layer of buffering is stdio buffering, which is
involved in calls like putchar/getchar and printf/scanf. You can avoid
this either by exclusively using the kernel level system calls for
reading and writing (read/write), or by using setvbuf to entirely
disable stdio buffering on the file descriptors in question.
As a reference for this sort of terminal configuration, here's the code
that NetHack4 currently uses (omitting, for copyright-related reasons,
a small tweak required to make it work on BSD) to set up a terminal
(you'll need to adapt this for your own purposes, e.g. "fileno(ifile)"
and "fileno(ofile)" are likely to become hardcoded numbers, and "ti"
and "ti_orig" will need to be declared somewhere, with "ti_orig"
restored at the end of the program):
{{{
[snip code
}}}
Just one (important) point. I read in "3. How does it work?" that
"It's just a very specialized telnet client." (to access servers
like NAO). - I'd needed some simple process usable for local play.
Has someone experiences how (or if) interhack can be used that way?
(First time since decades here. Had to clear that funny arabian spam first
to see whether this newsgroup is still active.)
Janis Papanagnou <janis_papanagnou@hotmail.com> writes:
(First time since decades here. Had to clear that funny arabian spam first >> to see whether this newsgroup is still active.)
Well, is it?
Nomen Nescio wrote:
Janis Papanagnou <janis_papanagnou@hotmail.com> writes:
(First time since decades here. Had to clear that funny arabian spam first >>> to see whether this newsgroup is still active.)
Well, is it?
I'm still reading it. I just haven't had anything to say, and apparently neither has anyone else.
[...]
and this old code has some sphaghetti
sections and unions that give me a
headache...
if i turn the union into struct instead
at least i can get a more coherent picture of
what is going on, but it is slow debugging it
all right now. maybe i'll have it figured out
by next spring at the rate i'm going. arg!
The application of 'union' that I've seen where
for two purposes. One was actually a low-level
hack where you store there one type of data and
access it by another type definition. The other
was to save memory; distinguished by some fixed
(always present) tag attribute the contents of
the associated data was determined. I seem to
recall Nethack code that had some properties
(of objects, or monsters, or both, don't recall)
depending on the actual type. So, say, if you
have 'union' data for a spellbook you could save
there the amount of time you already spent to
read it, or in case of a tin there could be the
type of contents stored. (Just a made up example
for illustration purpose, not sure where Nethack
actually uses it.)
access it by another type definition. The other
was to save memory; distinguished by some fixed
(always present) tag attribute the contents of
the associated data was determined. I seem to
recall Nethack code that had some properties
(of objects, or monsters, or both, don't recall)
depending on the actual type.
NetHack uses it all over the place for this purpose; it is a fairly
regular source of hilarious bugs.
Is there a reason
you're writing
very narrow posts?
David Damerell wrote:
...re unions...
NetHack uses it all over the place for this purpose; it is a fairly
regular source of hilarious bugs.
Is there a reason
you're writing
very narrow posts?
probably because i am. :)
songbird
On Usenet I use (for my own posts) typically around 70-78 characters
per line; just because that (old terminal width based) value had been convention. (I similarly start using a width of 80 for coding programs,
but that's hard if you code in Java projects as I've noticed in the
past.) And for responses to posts with unlimited line lengths I often
just reformat the original text (with two key-strokes) before putting
my answer below.
To each his own.
since i don't run my posts through any kind of automatic
formatter to make them uniform or consistent it may vary
from post to post where i wrap. :)
i hate to have to scroll right to read a post with
unbroken lines.
the old convention was 70-72 leaving a bit of room for others
to quote if desired. i just out of habit use a hard return in
my posts as i hate to have to scroll right to read a post with
unbroken lines.
songbird <songbird@anthive.com> writes:
i hate to have to scroll right to read a post with
unbroken lines.
You don't have to, slrn is able to wrap messages.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 422 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 195:33:09 |
| Calls: | 8,950 |
| Calls today: | 1 |
| Files: | 13,352 |
| Messages: | 5,992,422 |