#lispfurcproxy

Furcadia is slowly doing all the things to make me work on lispfurc more.

.ini login is slowly becoming deprecated in favor of character accounts. I’ll need to wireshark the new (account) style of logging in once the update is pushed out and make a lispfurc wrapper for logging a particular character name in with a particular description. Basically, your own database of characters, once the Furcadia\Furcadia Characters folder goes to hell.

FurEd is slowly becoming deprecated in favor of the web furre editor. I'll need to be able to hook it into lispfurc so an user can edit all they want and then send the new color code into lispfurc.

After I tweak the proxy around a little bit, the next thing I want to create is a persistence proxy. Something that acts as a microserver - basically keeps your character always connected to Furcadia's main server and you are able to transparently connect your main character in and out to the proxy with the official client, getting all the whispers your character gathered while staying in the semi-offline state. That would be fun for keeping characters online who need to stay online, like, for keeping dreams online. Implemented on some high-availability server to assure highest possible uptime, with some basic trust when it comes to handling login information, that would be a fun third-party addition to Furcadia, I hope.

Then, fix the mess that DragonSpeak is, implementing my own DS engine in lispfurc and fixing all the stuff I consider broken in DS in a way that is transparent to the clients, even the official one. It would greatly simplify the protocol when it comes to DS without removing any functionality present in it, for example, implementing a single way of moving furres around without walking animation and a single way -||- with walking animation, compared to the many DS lines that are currently sendable, each of which the client has to implement to be able to comprehend the changing dream state. n+1 ways of doing the same thing is n too many when it comes to the number of possible messages you get from the server and conserving bandwidth isn't a problem anymore; it's no longer 1998.