These are things that will probably end up in PennMUSH sooner rather than later.
In rough order of priority/how soon it'll happen:
Nigh-unlimited numbers of flags, flags added at runtime, etc. Talek's done the spec, but doesn't have the time to implement it. So I volunteered. Now you know who to get down on your knees and beg to. :)
The cached files (connect.txt, motd.txt, etc.) are stored internally in a really stupid way. A cleaner form is coming soon, along with @readcache enhancements (Switches to just reload the cached files, or just re-index help files, and maybe a new ability to re-load access.cnf)
Warnings for lock problems and variable-exit problems. Lock: eval-lock without the proper attribute, indirect-lock where the target lock isn't readable. Variable-exit: Missing DESTINATION or EXITTO attribute.
Make vadd() and vsub() and possibly others do element-wise ops when given a scalar and a vector. vmul() already does this. scalar-vector ops aren't really defined in the linear algebra sense for the other operations, but they're useful, which is the important bit.
See Rhost's help for details.
Getting rid of compiler errors and unused stuff, mostly. An ongoing process - but Penn compiles almost perfectly cleanly with gcc 3.0.4 with almost all warnings turned on. Yay.
It's nice to support as many code-level features as other MUSH code bases, so that code written for one can easily be ported to others. So as I see nifty-looking functions and commands Tiny has that Penn doesn't, I'm implementing them. Suggestions are welcome, but there's a few that aren't going to happen in the foreseeable future, including @program and structures. Sorry.
In no particular order. I have a lot more ideas than time to work on them... and there's no garuntee that any of these will make it in.
Using pthreads/Win32 threads/Carbon threads/etc. via a general thread API, possibly one I do myself. I'm going to start simple, with an option to make hostname lookups happen in a thread rather than a seperate info_slave process. If that works out well, I'll do something I did ages ago as a proof-of-concept idea, and make all network i/o happen in one thread, and all mushcode happen in another. Having multiple threads doing mushcode is just too icky for words.
A way to restrict access to specific commands and functions on a per-object basis. Done, I just need to make it work with normal Penn.
Adds softcoded commands to the global command table. Useful for a softcoded global you don't want overridden. This will probably be done via a second master room, that is scanned after globals, and before local stuff.
First-class functions are a feature of most functional
languages that Penn softcode lacks. Instead of an
object/attribute pair to be evaluated, you could put the code
inline - something like
map(#anon/name(\%0), #1 #2
#3) instead of
map(#1234/name, #1 #2
#4). The old way would still work too, of course.
If you see these at all, they'll probably be as contrib patches or in the far future.
Keep all help files in a central LDAP tree, with individual mushes looking up the proper entries for their versions in it. news and other user added help-like files would continue to work the way they do now, just the standard 'help' files would be stored on another computer. Cute idea, but probably impracticle
A different malloc package that eliminates memory leaks. See its homepage for further information on it.
Sending all output compressed to capable clients. Penn now has telnet-option negotiation support, which is one of the two major bits of getting this working. However, Penn doesn't really produce a lot of output, so this probably isn't worth it alone. But the protocol uses zlib, so see below...
Currently, Penn uses external programs for compressing and decompressing saved databases. This is nice from an ease-of-implentation standpoint, but it means those poor people trying to run a mush under windows can't have compressed database dumps. If we do the compressing ourselves (Probably using zlib, because it'll be the easiest to just drop in to the current scheme, plus see above), dumps will go a little faster because there's less redirection of data that the OS needs to do, and windoze users will be able to use it. It's mostly a tossup between 'How it works now is Good Enough' and how much pity I feel for windows people on if this'll ever get done. But if it is, MCP should be fairly easy to add.
This stuff already exists.
These probably won't happen because they break backwards compability.
The following are old or redundant or could easily be made redundant. (In alphabetical order):
|@atrlock||Use @set foo/bar=locked|
|@chownall||Add /all to @chown|
|@chzoneall||Add /all to @chzone|
|@firstexit||Use @teleport exit=here|
|@listmotd||Use @motd/list (Except people always confuse that with @motd, which clears the motd, so maybe leave this one in)|
|@logwipe||Add /wipe to @log|
|@rwall, @rwallemit, @rwallpost||Use @wall/royalty|
|@wallemit, @wallpose||Use @wall|
|@wizemit, @wizpose, @wizwall||Use @wall/wizard|
|get||I just like take better|
|atrlock()||Use set(foo/bar, locked)|
|beep()||Just plain annoying|
|con(), exit() and next()||Does anyone use these?|
|flip()||I like reverse() better|
|idlesecs()||I like idle() better|
|items()||I like words() better|
|soundlike()||I like soundslike() better.|
|trunc()||I like val() better.|
This is happening in 1.7.5, which requires a C89-capable compiler.
Last modified: Mon Apr 15 19:32:09 PDT 2002