Log in

Fuzzball TinyMUCK Development Journal
[Most Recent Entries] [Calendar View] [Friends]

Below are the 20 most recent journal entries recorded in Fuzzball TinyMUCK development discussion community's LiveJournal:

[ << Previous 20 ]
Saturday, April 1st, 2017
8:14 pm
Alpha 3
Alpha 3 is live.

Check out the latest release and notes at https://github.com/fuzzball-muck/fuzzball/releases .

Please send any questions, concerns, or any other feedback to feedback@fuzzball.org .

Friday, September 30th, 2016
10:22 am
Alpha 2
We're now alpha2.

There was more of a focus on code cleanup this time, but there are certainly some added functionality and enhanced features.

Check out the latest release and notes at https://github.com/fuzzball-muck/fuzzball/releases .

Please send any questions, concerns, or any other feedback to feedback@fuzzball.org .

Friday, April 1st, 2016
11:54 pm
Alpha 1
FuzzBall MUCK has now reached alpha1 status.

I want to thank Keet, Shane (digitalcircuit), Strain-113, Winged and Wog for their contributions up to this point - and anyone else I'm forgetting!

I have put a summary of what has changed up on fuzzball.org; please take a look using the link under Active Development, Changes.

I do plan to enhance that summary with more details and examples. Soon.

Please feel free to send questions, concerns, or any other feedback to feedback@fuzzball.org.

Thanks again!
Tuesday, August 11th, 2015
9:17 am
Bugs squashed
Here are the issues that have been addressed in the last few weeks, for fb7:

- Macros in MUF created with an non-alpha initial character were effectively "hidden" from listing via 'show' or 'abridged'. Now listing macros show ALL entries. This fix has also been packaged into fb6.17.

- STRTOF now works with integers. For example, :: 2 STRTOF :: now yields 2.0 instead of 0.0.

- INTOSTR no longer returns garbage when used on a value resolving to -2147483648. It also now only works on an argument with a numerical component (ints, floats, refs, variables)

- Non-wizards could set locks that refer to @-properties. This now gives a Permission Denied error.

The fuzzball distributions and documentation now have a new home - fuzzball.org. Currently it just a DNS redirection, but a full domain transfer is on the horizon and will allow more services to be hosted there.

Welcome TigerMUCK to fb6! Tigerwolf has gone through the upgrade process and is testing the current software. He so far hasn't reported any major issues.

Next post: new features!
Friday, July 10th, 2015
8:53 am
Recent changes
I want to thank you all for your patience while I close on, and move into, a new house. Though I am continuing the fun-filled process of unpacking, I wanted to give an update on the recent updates - notably the last distribution of FB6, and the work that has gone into FB7 so far.

The last version of FB6, available through sourceforge, is fb6.16. It includes the following changes from the August 2014 release of fb6.13:

- {ltimestr:} now can approximate years and months for the given timespan.
- The ENTRANCES_ARRAY primitive was copied (mostly) over from the ProtoMUCK codebase.
- @tunes can now be defined as #1-only, restricting read and write access.
- Setting a @tune can no longer be forced.
- Certain string @tunes are can now be (re)set to blank. These are:
-- dumpwarn_mesg
-- deltawarn_mesg
-- dumping_mesg
-- dumpdeltas_mesg
-- dumpdone_mesg
-- ssl_keyfile_passwd (now also #1-only)
-- pcreate_flags
-- reserved_names
-- reserved_player_names
- Fixed bug #268: {list:} improperly appends from environment.
- These @tunes have been added:
-- max_force_level (#1-only, default 1): the maximum number of times a force can occur in the same command.
-- recognize_null_command (default no): enables ‘@@‘ to act as a do-nothing command.
-- strict_god_priv (#1-only, default yes): controls whether GOD_PRIV also prevents #1’s items from being controlled by wizards.

FB7.00a development has started, and can be viewed at https://github.com/fuzzball-muck/fuzzball. The following items are reflected in that code:

- More code and binaries related to compression have been removed.
- New @tunes cipher_server_preference and cipher_server_preferences have been added.
- The new FULLDEPTH primitive returns the full stack depth. DEPTH now returns the number of unlocked items, improving backward compatibility.
- The @showextver command has been reimagined as @hashes, which displays the SHA1 hash for the source files, as well as the git hash if available.
- Code to set and clear standard locks and properties has been refactored (as a first step). No behavior change has been noted.

Thanks to Henri, Wog, Keet, and Winged for their contributions to the above.

Any questions, ideas, or other feedback? Feel free to post here or send me an email at fuzzball.muck@gmail.com

Sunday, May 31st, 2015
8:27 am
Hello all! Wyld here. I want to thank Winged for giving me the opportunity to share in this project’s vision. But just who am I? Briefly: I was introduced to MUCKs in the mid-90’s, and was immediately hooked. Over the next several years, this player of FurryMUCK became a programmer, server administrator, wizard, and head wizard across a variety of MUCKs. My contributions to the software started in fb6.00a27.

I can bet that many of you have a similar experience, and I’m counting on all of your expertise. There have already been some discussions about future tasks, such as:

* Documenting every file, function, compiler directive, @tune, etc. to help understand past decisions and assist in improving maintainability.
* Auditing available documentation (both in-server and in-package) for correctness.
* Improving registration and dispatch of user commands, MPI functions, and MUF primitives.
* Unifying floating point handling in MUF, and adding it to MPI.

This is in addition to reviewing the outstanding bug reports and feature requests from Sourceforge. Speaking of SF, we are in the process of transferring the code and issues to GitHub. You should hear more about those details soon.

I look forward to hearing any questions, feedback, guidance, or ideas for future tasks you may have.

Sunday, May 17th, 2015
9:25 am
Roadmap, and passing the torch
It's been a long time, and I'm sorry for it.

At this point, we're taking a new, more utilitarian view toward version numbering: A major release and all of its point releases will compile with the same compiler and library set.  When the major release number is changed, you can expect the compiler requirements to move forward.  fbmuck 7 will require a newer version of gcc to compile, though the specific lower bound has not yet been established.  It will be, at a minimum, GCC 4.

Now, over the past decade, development on fbmuck has languished.  I take full responsibility for this, and I believe that I haven't been an amazingly good steward of the codebase since I ended up with it.  My life has had lots of twists and turns that have drawn my attention away from it -- I've had to move many times, I've been shot in the back with a Glock 9mm pistol, and I was homeless for 17 months to boot.  (To be fair, I've been told that I did actually do better than I give myself credit for, because without me it would have been completely abandoned, and when I could pay attention to it I did get a few new features that otherwise wouldn't have gotten in.  I think this is more a consolation than anything substantial.)

Most notably, I never completed the Unicode implementation.  This is my greatest shame, though it heads a long list.

There comes a time when one realizes that one is simply incapable of fulfilling the duties taken on.  I've reached that point, and in order to serve the MUCK community (the administrators, wizards, and users) in the best way that I can, I've arranged to pass the administration and maintenance of the fbmuck project on.

The new project lead is Wyld (Wyld on FurryMUCK, mcclure on sourceforge).  I will be available to him to help him understand the code, no matter how incomplete my own understanding is.  He will decide if fbmuck stays on SourceForge, or moves to a new home.

It is my hope that the project will be more active, and that he will pay it more attention than I have been capable of.  Good luck, Wyld.  Please take care of the project, better than I could.
Friday, November 28th, 2008
10:24 am
Bug found in fbmuck v6.08cvs

I tried to send this bug report to Winged on his hotmail account, but since this email is now years old and I got no reply, it my not be valid/used any more. Also tried the Wiki on SourceForge but for some reason it returns "504 Gateway Time-out"...

I found a bug in fbmuck v6.08 (cvs), in the p_error.c file, thanks to the following gcc v4.3 warnings:

p_error.c: In function 'prim_is_set':
p_error.c:207: attention : array subscript is above array bounds
p_error.c: In function 'prim_set_error':
p_error.c:166: attention : array subscript is above array bounds
p_error.c: In function 'prim_clear_error':
p_error.c:123: attention : array subscript is above array bounds

It occurs that the author used "loop = ERROR_NUM;" to exit a "while(loop < ERROR_NUM)" loop instead of a break, and (s)he did so in the wrong places (i.e. before "loop" was used in another member, thus leading to wrong tests and an out of bounds subscript).

The attached patch uses "break;" instead, where appropriate.



diff -urN fbmuck-6.08/src/p_error.c fbmuck-6.08-patched/src/p_error.c
--- fbmuck-6.08/src/p_error.c	2005-07-04 22:59:21.000000000 +0200
+++ fbmuck-6.08-patched/src/p_error.c	2008-11-15 21:56:04.000000000 +0100
@@ -119,8 +119,8 @@
 			while (loop < ERROR_NUM) {
 				if (!strcmp(buf, err_defs[loop].error_name)) {
 					result = 1;
-					loop = ERROR_NUM;
 					fr->error.is_flags = fr->error.is_flags & (~err_bits[loop].is_flags);
+					break;
 				} else {
@@ -162,8 +162,8 @@
 			while (loop < ERROR_NUM) {
 				if (!strcmp(buf, err_defs[loop].error_name)) {
 					result = 1;
-					loop = ERROR_NUM;
 					fr->error.is_flags = fr->error.is_flags | err_bits[loop].is_flags;
+					break;
 				} else {
@@ -203,8 +203,8 @@
 			loop = 0;
 			while (loop < ERROR_NUM) {
 				if (!strcmp(buf, err_defs[loop].error_name)) {
-					loop = ERROR_NUM;
 					result = ((fr->error.is_flags & err_bits[loop].is_flags) != 0);
+					break;
 				} else {
@@ -245,7 +245,7 @@
 			while (loop < ERROR_NUM) {
 				if (!strcmp(buf, err_defs[loop].error_name)) {
 					result = loop;
-					loop = ERROR_NUM;
+					break;
 				} else {
@@ -305,7 +305,7 @@
 		while (loop < ERROR_NUM) {
 			if (!strcmp(buf, err_defs[loop].error_name)) {
 				result = loop;
-				loop = ERROR_NUM;
+				break;
 			} else {
Friday, June 20th, 2008
1:37 am
Is there a command to find all players who have logged in in the past week or so?
"Is there a command to find all players who have logged in in the past week or so?"

The answer is 'yes'.

@tune aging_time = 7d
@find =P!@

The 'aging_time' @tune is used to define how long something must be unused for it to be considered 'aged' (the help page for @find says that '@' is used to show things longer than about 90 days, but it's actually controlled by aging_time).

So, the effect of that last command is to find all players that are not 'old' (i.e., that have a lastused time less than aging_time ago).
Monday, October 1st, 2007
9:20 pm
{otell} fixed

Revision 1.35 of src/mfuns.c fixes a long-standing spoofing bug in {otell} (to the best of my knowledge). There's something similar but less critical in {tell}, I'm pretty sure, but I don't have enough energy to do anything about it at the moment. Try {null:{tell:{name:me} foo\rbar,someone}}, for instance. Guh.

Anyway, figured I'd post here to notify, and just in case anyone else here felt like doing the other half. Let me know if there's anywhere else I should have put this message instead. z.z

Current Mood: drained
Tuesday, March 20th, 2007
5:45 am
A bit of notification of what we've been doing:

1) We got Dr.Cat's code out of the main driver. It's in olddecompress, if you need to decompress your databases (not necessary if you were using 6.04 or later without the '-compress' option, or if you were using the '-decompress' option, or if you #undef'ed COMPRESS in config.h). The driver will refuse to load your database if you don't.

2) We have 8-bit support. However, this is ISO 8859-1, NOT full Unicode. Yet. This is documented in the file 'docs/8bit'.

There's a couple caveats to this:

1) Player names cannot contain 8-bit characters. This is by design, for security purposes. (7-bit terminals cannot reference 8-bit characters; this would prevent a lot of meaningful interaction between those 8-bit names and the 7-bit terminals.)
2) Thing names cannot, by default, contain 8-bit characters. This is @tuneable. (The reason why is because things can be easily created to grief, and without 8-bit terminal support there'd be no way to block them or sweep them.)
3) Exit, room, and program names by default CAN contain 8-bit characters. A room name isn't used very often (except in 'look'), exits simply cannot be referenced (but can't easily grief), and programs otherwise can't interact.

Any 8-bit character that, with the high bit stripped, would map to an unprintable 7-bit character is treated as unprintable, and stripped.

0xff (ISO 8859-1ÿ (y with diaresis)) is still stripped by the telnet support code. This is because there is no way to effectively determine if a given descriptor supports telnet escapes, and no way to effectively test that a given escape will not be harmful to the client.

Now. I have purchased a copy of the Unicode Standard 5.0, and I'm researching how to deal with it, and one of the largest problems that I'm coming across is "how can I notify the client that I support UTF-8 without being too pushy about it?" This is especially important when you consider that, in order to support MCP, the first line /must/ be precisely as specified, with no extraneous characters within that line.

See, my first thought would be to encode a Byte Order Mark (U+FEFF) into UTF-8 (yielding 0xEF 0xBB 0xBF), and put that at the beginning of the text that it outputs. I can't do that because of the MCP requirement; the next thought would be, I could put it at the beginning (followed by ) before the welcome.txt, but that would add another line on top of the MCP negotiation line already emitted. I don't really want to put 3 characters at the beginning of the first line, since that would throw off non-aware clients and their text rendering. I could negotiate it using MCP, but that would get rid of all the non-MCP-aware clients out there. (Though MCP could be used to negotiate a character set for non-Unicode aware MCP clients.) Any thoughts on what the best way would be?

In order to do the charset translation, I plan on using GNU iconv. I haven't decided how to handle Unicode internally yet.

And this doesn't even begin to address the problem of "multiple descriptors with different client capabilities connected to the same character". The ability to have multiple sessions logged into the same character and have the output echoed to all of them is used by several folk on a regular basis, and I don't want to disable that.

So. This is going to be an interesting time, indeed. :)

Tuesday, November 21st, 2006
2:11 am
Possibly exploitable bug
I just committed some patches to CVS, and packaged and uploaded a 6.07 release. These patches fix a few buffer overflow errors in MPI that might be remotely exploitable for arbitrary code execution, if the malicious programmer can work around all the limitations muck strings and the bug impose.

Umm, I recommend folks upgrade to 6.07 fbmuck code soon-ish, just in case.

Current Mood: annoyed
Friday, September 8th, 2006
7:28 pm
LXR cross-reference
Hello, a year ago I set up an LXR cross-reference for the fbmuck 6.05 and HEAD code. Just wanted to say I fixed the nightly HEAD updates.

Friday, April 21st, 2006
5:36 am
CVS versus SVN...
Would it be worth it to change from CVS to Subversion? CVS is faster, but doesn't provide a conceptual overview of a filesystem with changes applied as cohesive units. Soliciting comments...
5:18 am
Winfuzz issues...
Okay, there's a couple of issues that I've found with winfuzz, specifically compiling with VC++ 2005 Express Edition (the free one that can be downloaded, for the moment, from Microsoft).

1) rwho.obj is no longer valid.
2) makefile.win assumes that OpenSSL is in use, and doesn't provide an easy way to disable it unless you know what you're looking for.
3) VC++ 2005 EE doesn't include odbc*.lib, which are referenced by the linker, but aren't used in any way in the code.
4) defines.h isn't created by makefile.win.

Any thoughts?
Sunday, April 16th, 2006
1:34 pm

I have a refactored version of log.c sitting in my src/ directory now. I'm somewhat reluctant to check it in yet, however, as I'm not sure whether some of these discrepancies from the original should be preserved. In attempting to preserve behavior, I had to add three flags to a new vlog2file function: prepend_time_stderr, prepend_time_file, and append_newline. The discrepancy between the first two is because log_command mysteriously prepends a timestamp when outputting to file but not when outputting to stderr. The third exists because log2file does an implicit newline append, whereas none of the other log functions seem to do that. I see that other source files use log2file, also.


  • Would it be cleaner to globally make log2file not append a newline, and then add newlines to the format strings everywhere?
  • Shouldn't the prototypes for a lot of these functions have const char * rather than plain char *?
  • Do any programs depend on the strange behavior of log_command not prepending a timestamp when forced to use stderr, or can that be merged into a single prepend_time value?
Thursday, December 22nd, 2005
11:46 pm
Patches for current CVS sources of fbmuck
Here is a collection of patches I use to compile the current CVS sources of fbmuck (v6.06):

  • fix_warnings_and_debug: Removes compilation warnings and fixes a problem where the DEBUG compilation option is enabled by mistake, because of a bad #define in db.h (#define DEBUG DARK)... Also fixes version date stamping issues when compiling on non-English localized computers (problem in mkversion.sh where 'date' is used without setting the proper LC_ALL environment variable, leading to weird date in @version, when accented characters are contained in the month name).

  • log_ssl_error: fixes compilation failure on systems with "old" openssl libraries.

  • null_command: adds a "@@" null command (MUSH/MUX-like), suitable for pinging the MUCK and prevent being disconnected for inactivity. This command is fully ignored (it doesn't interfere with READ calls, for example), but for the idle timer, which it resets.

  • sigemerg: Allows to shut down the MUCK cleanly on receipt of an EMERG signal (kill -12): I use it to shutdown the MUCK automatically when the UPS detects a power failure: it's less useful with fb6 as kill -15 won't issue a panic event like it did in fb5, but I'm still using it for it tells to the users that something went wrong on the computer instead of telling "shutting down normally"...

  • clear_passwords: I use this one to store unencrypted passwords in the database, as I need this so to extract them automatically twice a day in order to sync the Apache passwords so to give access to MUCK users' restricted areas of the MUCK website... Please note that this patch is NOT suitable for use with a database already holding encrypted passwords (but it may be used with a fb5 database).

  • logrp: allows to log RPs into a RPlogs directory... I use this to provide users with HTML logs of some of the MUCK's public areas, as well as to allow them to get private logs for their own room if they so wish... Please, note that this patch is a quick'n dirty implementation and makes no check on the validity of the filename passed to the new _logrp primitive (it's not a problem for me as this primitive is for use by wizards only and I'm the only wizard on my MUCK, but it'd need some serious improvements for use on MUCKs with two or more wizards). For now, all the checks are done into the MUF program I use to log the RPs, but they should be moved into the C sources of the server.

About future developments of fbmuck, I'd like, before even considering implementing more features into fb6 (and therefore adding more bugs... :-P In this respect, the UTF-8 issue is quite scary and its usefulness is more than disputable...), that the currently known bugs would be first fixed... I describe two of them here and the second one (name matching bug) is particularly annoying (the first one may be worked around simply by a '@set #0=_listen/null:$nothing').

Oh yes... Another, last thing... Why insisting on using an old, deprecated and security holes plagued version of libpcre (v4.3), while the latest one (v6.4) seems to work just fine (I'm currently running a fb6 server linked libpcre v6.4) ?...

Sunday, November 6th, 2005
4:24 pm
Wiki down?
siege is talking about starting a Wiki for FBMuck, so I was going to point him to the official Wiki. Except it seems to be broken at the moment. Anyone know what's up? The error I get is just as follows:

Fatal error: Call to a member function on a non-object in /home/groups/f/fb/fbmuck/htdocs/includes/ObjectCache.php on line 409

Current Mood: confused
Sunday, September 25th, 2005
3:57 am
Oh yay, a bug that I'm not sure what to do with...
If resolver can't be executed, fbmuck leaks UNIX sockets. HLM is running into this bug -- every time it saves, it gets a SIGCHLD from the dumper process, as well as handling the SIGCHLD from the resolver process. When this latter occurs, it attempts to respawn the resolver, which creates another UNIX domain socket.

I'm not sure why fails to the writing of the resolver socket aren't being caught and the socket thus closed; however, there are MUCKs (HLM included) that don't want to use the resolver. Some additional code needs to be put in to support this, and it needs to be a configure-time option. (The use of the resolver itself should be a configure-time option -- as well, it'd be nice for sysadmins who want to install things centrally if they can have many MUCKs running on their machine all use a single resolver process.)

Anyone want to undertake that task?
Tuesday, September 13th, 2005
1:54 pm
Name support with UTF-8
Here's a question for all and sundry...

How should player names handle UTF-8 encoding?

I foresee problems with players trying to page someone named something like Pètrå, when they don't have the keys on their keyboard (or the knowhow) to type the extended characters. Or worse, some name like གྷཛཨསཥ. (A bunch of Tibetan squiggles to me.)

Should non-ASCII chars be disallowed in player names? Only allow ISO-Latin-1 chars, and strip diacriticals and accents for purposes of name lookups? An @tune to specify what code pages are allowed?

Current Mood: tired
[ << Previous 20 ]
My Website   About LiveJournal.com