mudcoders / guildmud Goto Github PK

As described here: https://www.gammon.com.au/gmcp

1. Use sqlite3 to store: world data (map, users & objects) and state.
2. Have a minimal persistence memory to sqlite3 time.
3. Have a highly coupled memory data model to sqlite3 (persist at struct member/variable at database field type)
4. Because (2 & 3) we expect the programmer to have some SQL knowledge.
5. Minimal set of objects to be persisted: Room, Thing, Exits, Tags (a kind of trait that can be attached to anything), Player, Non Player.
6. Define a set of functions per object (4) to persist/update/retrieve from/to the database.
7. Create a versioning system of database schema so it can be upgraded without user action.

As a preparatory task for adding testing, I propose to remove src/Makefile and create a single Makefile in the root directory.

This new Makefile will compile all the *.o files (except main.o) to a libguildmud.a library and then link it to main.o.

Doing it this way will help to link the tests to libguildmud.a without having to exclude main.o.

Comments?

I know Mudlet supports a subset of MXP, but it's not universally supported (tintin++ doesn't, as far as I know). I'm curious what everyone's thoughts are on supporting it? This is a pretty good explanation of what you can achieve using it:

https://www.gammon.com.au/mushclient/addingservermxp.htm

Reminder to check!

Currently guildmud is using the old unix crypt(3) function to encrypt user passwords.

Before PR 6 guildmud used the OS crypt, but this required some external linkage and was not supported by some unices. To ensure compilation in as many OS as possibles PR 6 added the crypt code from unix v7 to the guildmud basecode.

The problem is the standard crypt has been broken for more than 10 years and we need to provide something more secure.

Current standard is to deploy bcrypt. My proposal is to deploy bcrypt, but before that I need your opinion:

• Should we expect the user to install it so we can link it?
  or
• we include the three src files (it adds up as an extra 60 kbytes) to our codebase reducing compiling complexity?

For review, package can be found here, filename is crypt_blowfish.1.3.tar.gz

Comments?

Nevermind the shadows on the cave wall we don't even know what the cave is made of yet. Plato is disappointed that he has no where to talk about how much socrates didn't know.

What is our concept of space? Rooms? Dimensional coords? A mix of things? My zone-locale-room design?

We must discuss!

As described here: http://tintin.sourceforge.net/mssp/

As described here: http://tintin.sourceforge.net/msdp/

We are leaning towards using SQLite as our data storage solution. How we go about tying it into the other systems hasn't been discussed. The first steps would likely involve refactoring the existing data storage capabilities of SocketMUD to leverage SQLite. Should there be an option to duplicate data to flat files as well?

When starting guildmud and there's no ../help directory to load the help files, program segfaults.

rogersm@iMac10,1:~/Dropbox/dev/guildmud/src$ cp ./guildmud /tmp
rogersm@iMac10,1:~/Dropbox/dev/guildmud/src$ cd /tmp
rogersm@iMac10,1:/tmp$ ./guildmud
Segmentation fault: 11

Will investigate, but taking into account code is not checking for opendir(3) return code, this should not be too difficult.

Now that we have Travis CI integration, we need a test suit. I propose to use Check.

It's small, easy to use, and documented.

Are we ok to move to Check or do you prefer something different?