There are two ways of using NotEye:
1) As a "terminal emulator" with fancy features for roguelikes. This does not replace the Curses dynamic library (as Quendus presumes), it just works as a terminal emulator. In this case, the game is written using Curses or whatever language/library which outputs to a terminal, and the game script in Lua gives it a graphical interpretation. This does not require any changes to the underlying game (for example, NotEye simply works with DoomRL without any collaboration from DoomRL -- but there are some problems, for example DoomRL uses exactly the same character for medkits and bloody doors, theoretically the game script could invoke the "look" command to tell them apart, but this is not very practical -- if you are the author of the original game and you have full control on its output, this should not be a problem).
For smooth movement, just use the function applymoveshift(pic, id) -- "pic" is the sprite of the being, and "id" is its unique identifier. NotEye remembers the location of each "id", thus if it detects that it has moved, it moves it smoothly to the new location. If you have some reliable method of telling which monster is which (for example, each monster has a different character/color combination which is fixed) then smooth movement should be done easily.
2) The NotEye library interacts directly with the game (thus, for example, NotEye can ask the game about the ID of the monster at the given location, and use this info for smooth movement). For programming, this is convenient -- it is easier, more powerful, and less error-prone to just get the information from the game itself, instead of reading its screen. This is done in Hydra Slayer, PRIME, and ADOM. (Originally Hydra Slayer used method (1), but method (2) gives extra power, so it uses method (2) now, although NotEye should still work in a limited way with the "pure console" Hydra Slayer.)
To play the game via ssh: in (1) there is no problem, NotEye will not know that the game is run via ssh and happily interpret it. In (2), you could use the remote NotEye's Curses output on a remote machine, play it via ssh, and connect the local NotEye to this ssh -- but then the local NotEye would have no access to this special information. NotEye comes with its own streaming protocol, though, which solves the problem somewhat. You run the remote NotEye as a "server", and connect the local NotEye as a "client" (warning: there is no security for this yet). I think it should be possible to tunnel NotEye protocol via ssh, too -- tell the remote NotEye that you are playing via ssh and local NotEye, and it will communicate with the local NotEye via ssh using the NotEye protocol -- but this is not yet implemented (just a quick idea I had at the moment).
(All the C/Python/Java/Pascal samples use the NotEye library, export a "monsterids()" function to the Lua script to support smooth movement, and make sure that monsterids information is included when streaming using NotEye protocol.)
