Xpilot Patches by Fishy

I'm not much of an xpilot hacker, but I have made a start at some patches, and hope to add to these over time. The README.synrg in the patch above explains what it is for.

Below, I outline my ideas for future patches:

/cset command

I have actually made a small start at this command. The basic concept is borrowed from U's /set patch, which allows the operator of a server to change server parameters via the talk-window. (It's like 'o' at the xpilot command line.)

But /cset, rather than changing server settings, changes client settings that would normally be changed via the "Config" menu. I find the Config GUI interface to be rather clunky, making it impossible to make changes in mid-game without sitting out a round or getting shot at. The key-oriented /cset interface would be much more efficient. Also, when coupled with the "talk keys" patch (included in U's patches) /cset could be made to do some pretty sophisticated things, e.g. change a whole bunch of settings at once.

/exec command

I would like to code a client-side /exec, much like irc has /exec. In fact, I have started looking at the ircii source code, and a Unix programming textbook, but I'm afraid to say it is rather a lot to digest. You see, although I have coded professionally for 14 years, my C is weak, and practical experience programming in Unix nearly non-existent.

Anyone who'd like to help with this one, please drop me a note. (In fact, anyone who'd like to help with any of these ideas, I'd love to hear from you!) I can be reached at synrg@sanctuary.nslug.ns.ca.

/ping command

A logical second step to exec would be to write a few "canned" exec scripts. The /ping I envision would ping the server you are connected to by default, write a brief summary, and perhaps give some stats more useful than simply min/avg/max latency and percentage loss.

With parameters, it would allow you to alter the host being pinged and other ping command-line parameters (note, specific to the OS it is run on).

Rather than build /ping into the client, I would look for a "ping" script in lib/xpilot/scripts/ and execute it via /exec, as these scripts would be system-specific, and should therefore be easily modifiable by sys admins.

mailboxes

This patch, unlike the ones above, would be a server-side patch. It would allow pilots to leave messages for pilots who are currently not on the server.

The server would keep track of every nick to connect to the server by creating an empty mailbox file (e.g. /var/lib/xpilot/mail/Fishy). If someone tries to send a message (e.g. "fishy: hey there!") to someone not presently on the server, but who has been on the server before, then the server will reply: "Fishy is not here, type Fishy:: to leave a message". The double-colon directs the message to Fishy's mailbox (e.g. /var/lib/xpilot/mail/Fishy). The next time Fishy connects, he will be shown as many of his messages as fit, and then be prompted: Type /mail to see more messages.

A user may type /mail 1 at any time to view messages from the beginning (or /mail n to start at the n'th message).

Typing /mail [pattern] will search your messages for [pattern] and only show matching messages.

I think the messages should be deleted only when the user tells the server /mdel (or /mdel 1-4 to delete the first 4, etc.). Another idea would be to simply dump the messages after the user has read them.

Then, there is the issue of passwords. Mailboxes should be password-protected. When you connect to the server under a certain nickname, you will be asked to set your mail password via /msetpass [yourpassword]. Thereafter, in order to view your messages, you must type /mpass [yourpassword] before typing /mail.

Getting a bit fancier, a handy extension would be /mforward. In order to use this, you would first need to type /msetforward [youremailaddr]. /mforward will forward your messages to your email mailbox so you can reply to them there. Once the messages have been forwarded, they are automatically deleted from the xpilot mailbox. Of course, this is assuming that you have the sender's email address to send the response back to (that is your own problem. You could always check the FFA if you really have no clue :)

Finally, to use with /msetforward is /msetautoforward, which would turn on auto-emailing of any messages sent to you on that server in your absence to your emailbox. For this, the server would have to run a cron job that periodically does any of the autoforwards set for users of the server.