#2 commandcharacter config option problems

[Jesse DeFer]

The commandcharacter config option is apparently not
honored everywhere.

For example when I redefined it from the default '/' to
'#' and hit page up at the top of scrollback, three
commands are sent to the mud:
/enable __DIRT_ScrollbackController_end
/enable __DIRT_ScrollbackController_arrow_up
/enable __DIRT_ScrollbackController_arrow_down

[Juliano F. Ravasi]

Logged In: YES
user_id=54133

This is a real nasty problem. I don't known why the mcl's
default '#' was changed to '/'. The '/' character is used by
many mud servers to control text editors and other
interfaces where normal commands can't be used. The '#'
character is the default command character on most mud
clients, so most mud servers avoid depending on input with
'#', making the '#' character some kind of standard for mud
clients.

This also shows a weak software engineering design, and a
worse bug: the backend depending on the frontend, in this
case, faking user typed commands.

Another example is the scripts/sys/color.pl hardcoded
Color.h constants (SET_COLOR, SOFT_CR, etc).

This is really annoying, and is the only think that keeps me
from using dirt for mudding.

[Bob McElrath]

Logged In: YES
user_id=10643

Sorry I know you submitted this a long time ago, I just
found it. Sourceforge does not mail anyone when new bugs
are submitted.

1) If changing the command character does not work that is a
bug and should be fixed. Perl scripts should use the
variable $commandCharacter, likewise for C++.

2) We can flame back and forth on what is better, but
hitting shift-anything so get a client command annoys me.
TinyFugue uses / by default, and that is what I use. I have
not used a client that needed '#' except mcl, and I quickly
changed it. Also '#' is a standard comment character in
perl... It's one of those things like emacs/vi or linux/bsd
-- heated flame wars, but in the end, it really doesn't
matter what the character is.

3) As to the backend depending on the front end, I have
recently done some work to fix this, so that perl can
directly call the C++ implementation rather than submitting
/commands. I agree the old way sucks. It is inherited from
mcl which read perl commands from a pipe.

4) As to color codes, the entire screen handling stuff needs
a serious rewrite, with an eye toward ncurses. MCL was
originally hard-coded to write to the linux virtual console,
and later ncurses was hacked in (but it still treats it like
the linux console and is extremely slow).

As to *using* dirt...it clearly is not ready for prime time.
If you would like to help fix some of the above issues, I'd
welcome the help! :)

[Juliano F. Ravasi]

Logged In: YES
user_id=54133

Please, don't misunderstand my reply as a flame. I was sad
because I "upgraded" from mcl, and found a bug that blocked
me from using it. The commandchar was the first thing I
changed because my mud uses the '/' character to control the
text editor (/insert, /save, etc).

The '#' is the default command char in zMUD, JMC, Pueblo (if
I remember well), MCL, TinTin+ and some others that I had
over the time.

About the colors, the problem is that my mud uses extended
ASCII characters (portuguese language, ISO-8859-1 charset),
so I used to change the color constants used by mcl to more
some appropriate codes (0x8[0-F]), and this usually solved
my problem. But the hardcoded constants that I mentioned
made it impossible to do in dirt.

These 2 problems made me give up on using dirt. I'm
currently using the old mcl.

I would like to help dirt development, but I'm currently
overloaded. Thank you for the invitation.