Angband borg-friendly?

[ClaytonAguiar]

Hi,

After reading the borg-related recent posts, I thought about it:

Does exist any standard approach/implementation/technique/feature like Windows DDE that can be used the same way in the Linux, Windows and Mac ports of Angband?

This could lead to an interesting feature: borgs, bot players, etc., created by users as separate, plugin software. What would be necessary:
- Add code to "listen" and "answer" the bot process, which would be another application. A protocol would be, probably, needed. No privileged information here, just an equivalent to the information shown in the screen (perhaps the simple screen dump would be enough and easier to implement).
- Adjust the user-input code to accept input from keyboard or from this secondary input source.

It would be funny to see a character played by a "ghost" player (like the 3.0.9 borg), and the developers hurrying to annouce: "My borg implementation is better", "Mage-optimized borg" or even "The best angband borg ever"

[fph]

You mean something like a pipe, or a simple TCP server+client?

[ClaytonAguiar]

Originally Posted by fph

You mean something like a pipe, or a simple TCP server+client?

Both could be used. The TCP/IP approach would add undesired side effects: a network-ready O.S. with TCP/IP protocol installed. I think almost every machine that runs angband today has TCP/IP installed (except NDS, I guess). This would lead to two different releases. Some people here wouldn't be happy

Pipes: I know Windows has support to named pipes for interprocess communication. But what about Linux and Mac? The implementation for these OS'es would be similar?

[Pete Mack]

Pipes (and named pipes) are an original UNIX feature dating back to 1972. Windows borrowed them much, much later.

[fph]

Pipes: I know Windows has support to named pipes for interprocess communication. But what about Linux and Mac? The implementation for these OS'es would be similar?

This is a bit like when an American woman asked me if we do have pizza in Italy... baby, we basically invented it

I suppose the biggest issue now is whether the Nintendo DS has them (pipes, not pizza). But even if it doesn't, I guess it wouldn't be hard to #ifdef out all the related stuff from the DS port.

[Zikke]

Originally Posted by fph

This is a bit like when an American woman asked me if we do have pizza in Italy... baby, we basically invented it

I suppose the biggest issue now is whether the Nintendo DS has them (pipes, not pizza). But even if it doesn't, I guess it wouldn't be hard to #ifdef out all the related stuff from the DS port.

There's a difference between invented and perfected

[Pete Mack]

I don't think the input is a problem--after all, you can redirect standard input. The difficulty is how do you do the map? Right now, the borg works by screen scraping. To do that over a pipe, you basically need to implement another terminal interface, (maybe main-borg.c)

[PowerDiver]

Originally Posted by Pete Mack

I don't think the input is a problem--after all, you can redirect standard input.

The game does not read standard input, at least on the linux boxes I use. It grabs the keyboard directly. I tried to "tee" standard input to save keystrokes to log for movie action and it did not work.

Is there an easy way to make it read from stdin?

[d_m]

Originally Posted by PowerDiver

The game does not read standard input, at least on the linux boxes I use. It grabs the keyboard directly. I tried to "tee" standard input to save keystrokes to log for movie action and it did not work.

Is there an easy way to make it read from stdin?

So first of all, I assume we're only talking about the main-gcu port. Most of the other ports are not using anything like STDIN to get their data (e.g. they are reading X events, or SDL events, or whatever).

In the terminal, the input is coming from the controlling terminal, which isn't just a file descriptor but is actually a PTY. The different is that the curses code uses various ioctls and stuff to change the input between blocking/non-blocking IO, as well as various other things that curses does. So if you want to be in the middle logging input, you can't just use tee but you have to actually allocate your own pseudoterminal, set it up, etc.

I started writing a script to try to "wrap" angband, passing the data back and forth asynchronously so you could have a log of input and/or output while still playing the game. I'm not optimistic about how well it will work given the potential buffering issues and the fact that curses does a lot of pty-level hackery that you'd have to make sure to actually intercept and pass off to the "real" terminal.

I guess the short answer was "no".

[Sirridan]

Originally Posted by fph

This is a bit like when an American woman asked me if we do have pizza in Italy... baby, we basically invented it

I suppose the biggest issue now is whether the Nintendo DS has them (pipes, not pizza). But even if it doesn't, I guess it wouldn't be hard to #ifdef out all the related stuff from the DS port.

http://akkit.org/dswifi/

I'm not too keen on nds coding, (and I don't have the adapter yet to try) but here's a lib that should do tcp-ip