rob05c / gomud Goto Github PK

Implement RFC 2946
https://tools.ietf.org/html/rfc2946

Until this is implemented, all communication is plaintext over TCP, including user names and passwords. This is unacceptable.

This is something I really, really want to add, but it will only be a high priority after other basic functionality exists.

Implement persistence of dynamic data (e.g. rooms, players).

Probably via sqlite3.

Currently, telnet commands are sent when 3 codes are received. This is insufficient and brittle.

Listeners should forward all telnet command codes to a telnet manager for that connection. The manager should buffer command bytes until a complete command is received, or a new IAC is received.

The telnet manager should also be able to take over listening to handle advanced telnet options which involve messages without the command bit set. Alternatively, the telnet manager could be able to request non-command bytes.

Due to concurrency, the listener may process necessary non-command bytes before it receives the divert message from the telnet manager. Because of this, the manager may not be able to run concurrently with the listener.

Messages sent to clients must also go through a telnet handler. E.g. compression, encryption.

Implement rfc 2941
http://tools.ietf.org/html/rfc2941

Specifically, implement the SSL option.

Special characters should be disallowed. Character names should only allow alphabetic characters.

Any other input, such as communication, should remove special characters, such as backspaces and bell characters.

Sanitized input must still be sufficient for admin script commands.

character names now only allow alphabetic characters

Note because of NPC scripting, input, at least from users who can create (admins?), must allow all characters necessary for writing javascript.

An in-game help system. This ultimately needs to be a navigable hierarchy of files.

Ideally, commands/classes/subjects will auto-generate help files. E.g. when a new command is created, part of that command's structure includes usage help text.

However, a single command listing available commands and their usage will suffice for the current small command set. YAGNI applies.

A help command now exists.

This case will remain open until a complete system exists.

The current commands and such are far too primitive to need a complete system yet. Therefore, this case's priority will be reduced until such complexity exists.

Implement configuration files

Current config settings needed:
port
cryptographic hash algorithm?

preferred Telnet Encryption algorithm?

Implement rfc 855.
http://tools.ietf.org/html/rfc855

This may be as simple as parsing and rejectiong unimplemented options.

Add NPCs.

NPCs should:

• be in rooms
• be able to own items
• be dynamically scriptable

Dynamic scripting allows all sorts of other dynamic things, such as aggro, attacking players, picking up items, saying quest lines, giving players items in response to quest events.

NPCs can be created now via the createnpc command. However, they currently differ from items only in that they can't be picked up.

NPCs are now scriptable.

Items should have advanced interaction commands. Examples include: ring, shake, open, close, poke, throw.

These would require custom functions for each individual item. These functions should probably be dynamic, e.g. Python, so object interactions can be created by admins in-game, rather than requiring a developer, a recompile, and a restart.

Players must be able to log off. This should be doable via a command (quit), as well as automatically by the server when a connection is forcibly terminated.

Currently, there is no framework in place to manage players which exist but are not "logged in." Possible solutions:

• Delete players from memory structures. Players are loaded from the database upon connection.
• Store players in a separate "disconnected players" structure
• Store players in the same structure, with a "disconnected" flag

I am leaning towards the first option. If there are ever a large number of players, storing all existing disconnected players in memory will be expensive.

Storing players in the same structure seems bug-prone. It would be easy for a routine to fail to check the disconnected flag.

Persistence (i.e. a database) is yet to be implemented. It must be implemented first for the first option.

The Wiki install page should have detailed instructions for Ubuntu, Windows, and OS X. Specifically, the go-v8 installation instructions need more details.

Implementing this will require attempting to install and run gomud on clean installs of these operating systems, and recording the exact steps performed.

Many things store Ids. Everything possible should be changed to store Accessors instead. This will let them bypass the manager bottlenecks.

Implement rfc 857
http://www.ietf.org/rfc/rfc857.txt

Implement MCCP (Mud Client Compression Protocol)
http://www.mudbytes.net/index.php?a=articles&s=mccp

This has the rfc label because, while not actually an RFC, it is similar in style and scope to the rfc issues.

Note this is not high priority, because with modern internet speeds, compression generally actually slows down a connection. However, we should implement it for users who sit in Siberia and have only telnet.

Rfc 854 telnet protocol specification
http://tools.ietf.org/html/rfc854