Managing multiple alts and connections
3 views
Skip to first unread message
Ansatz
Jul 25, 2008, 12:08:42 AM7/25/08
to tinymux
This is a proposal for enhancement of Tinymux to support multiple
characters on a single player account.
Benefits:
This proposal allows for greater flexibility and power in controlling
the number of characters owned by each user. It will allow Tinymux to
enforce rules about the number of characters a user can own as well as
the number of characters that a user can use simultaneously when
multiplaying is allowed. Since multiplaying is often forbidden, it
would be possible for Tinymux to enforce that rule by making
multiplaying impossible.
Some muds allow a user to have more than one character and some even
encourage it, such as superhero muds where secret identities can only
be properly represented by having two separate characters. Because
multiple characters can be awkward for a user to manage, some
superhero muds have their players change names with the @name command
rather than logging out one identity and logging in another, but this
is far from an ideal solution and makes it difficult for secret
identities to be truly secret.
Similarly, some muds offer a wide variety of RP opportunities and make
it popular to have multiple characters and to multiplay so that a user
is not needlessly limited in the roles that can be played. In this
case, the awkwardness of managing multiple characters in the current
Tinymux is often overcome by using the @emit command to simulate
multiple characters, but this sacrifices all server support for those
characters.
In these above cases the benefits of this proposal are most strongly
felt and I think the enhancement would be dramatic. Ideally it will
completely eliminate any desire to use @emit or @name to simulate
multiple characters with a single player object by making the features
of Tinymux more closely fit with the needs of the users of Tinymux by
freely allowing them to create, manage, and delete many characters
with no awkwardness.
Overview:
Currently MUX servers have a built-in confusion between the very
distinct concepts of player and character. A player is a real-life
user who connects to the server over the internet. A character is a
fictional person who exists within the simulated environment of the
MUX. As things are now, both of these entities are represented by a
single object called a player object. This is the fundamental mistake
that has caused the need for this enhancement proposal because there
should be player objects and character objects that are distinct types
of objects.
A player object represents an account owned by a user. It has a user
name, a password, and it is able to receive OOC messages from other
players such as with the @mail command or the 'page' command. No two
players can share the same name, but there is no reason that a player
cannot have the same name as a character. A player object does not
need to have a location or the ability to emit text to a room, but it
must be able to send commands to character objects to cause those
object to emit text.
A character object represents a fictional person who is part of the
simulated environment of the MUX. A character does not have a password
and users do not connect directly to characters. Character objects do
not accept OOC messages such as from a @mail command or 'page'
command, but they do still accept messages that are considered IC such
as from a 'whisper' command.
Some practical details:
Immediately after logging on, a user has control of player object
which can be used to talk on channels, send @mail messages, or page
people. In order to begin RPing, the user will enter a command to
activate a character. Once a character is activated, everything that
character can hear will be presented to the player.
Suppose the character name is Bob, then a user might manipulate Bob
with commands such as:
> @activate Bob
> @force Bob=:waves.
The first command causes Bob to appear in the IC world with a message
like 'Bob has connected.' The second command causes Bob to wave.
Forcing works here because the current player owns Bob, but it is far
from a convenient way to RP. The problem is that 'me' is still
considered the player object but we want it to be the character
object, so we need another new command such as:
> @become Bob
This causes Bob to be the new 'me' and all commands like 'say' and
'pose' and 'emit' will be automatically forced upon Bob. If @become
is working ideally, controlling Bob will be exactly like it would be
in a current MUX server.
The above is nice because it allows someone who is playing Bob to
instantly switch to playing Jack by typing '@become Jack' as well as
activating or deactivating characters at will. If multiple characters
are concurrently active then a prefix can be used to distinguish which
messages are being heard by each active character, but that is not
ideal.
In order to allow for the sort of multiplaying that players are used
to, a player object should be able to accept multiple internet
connections and it should treat each connection separately.
Specifically, the @become and @activate commands should apply to the
current connection only. This way a user can open multiple connections
to the MUX using the same user name and password, then use the
@activate command with a different name in each connection to begin
playing two different characters simultaneously.
Another practical benefit of allowing multiple connections is that it
can allow a user to have one window open to receive pages, @mail, and
channel chats while another window is used for RP. We can facilitate
this use by having commands to control whether pages should appear in
each connection. For example, a command called @nopages could cause
the MUX to stop sending paged messages down the current connection
while they will continue to be sent down all other connections. This
works because pages are sent to players, not to characters, so all
open connections of a player are reasonable targets for paged
messages.
Maintaining privacy:
Users often expect to keep their collection of characters hidden from
other users. If two characters share the same player, there is no need
to make this known to other players. In the current MUX servers, it
can even be challenging for the server administration to determine if
two characters have the same player. For those players who value this
privacy, this enhancement should not be a cause for concern.
To allow for privacy, we must allow players to interact fully without
knowing each other's player names. This means that the page command
should accept the name of a character rather than the name of a
player. The character object will not receive the page; the page
command will simply look up the owner of the character and direct the
message that way. The player who receives the page will see the name
of whoever is currently 'me' for the player sending the page, allowing
a player to send pages as a player or as any one of his characters by
@forcing or @becoming that character.
This means that a page can be sent to a character even when that
character is inactive because the owner of that character could easily
be connected to the server. Players will know that even if a character
has disappeared the player will often still be available, so they
should be allowed to send pages to inactive characters. If we did not
allow this, then people would end up being asked for a list of alts so
that they can stay in touch when their current character is inactive.
Such questions would be embarrassing for people who value their
privacy.
Allowing pages to inactive characters creates the possibility of pages
ending up directed to players who are not connected to the server. For
privacy reasons, the sender of the page should not be informed that
the player is unavailable. Instead, the page could be either be
silently discarded or else it could be logged for the player to view
upon connecting.
When a player receives a page that was directed to an inactive
character, the player will want to respond but might not want to
reveal the identity of the current character. To allow the player to
respond using the identity of the inactive character, we must allow
the player to @force or @become an inactive character.
characters on a single player account.
Benefits:
This proposal allows for greater flexibility and power in controlling
the number of characters owned by each user. It will allow Tinymux to
enforce rules about the number of characters a user can own as well as
the number of characters that a user can use simultaneously when
multiplaying is allowed. Since multiplaying is often forbidden, it
would be possible for Tinymux to enforce that rule by making
multiplaying impossible.
Some muds allow a user to have more than one character and some even
encourage it, such as superhero muds where secret identities can only
be properly represented by having two separate characters. Because
multiple characters can be awkward for a user to manage, some
superhero muds have their players change names with the @name command
rather than logging out one identity and logging in another, but this
is far from an ideal solution and makes it difficult for secret
identities to be truly secret.
Similarly, some muds offer a wide variety of RP opportunities and make
it popular to have multiple characters and to multiplay so that a user
is not needlessly limited in the roles that can be played. In this
case, the awkwardness of managing multiple characters in the current
Tinymux is often overcome by using the @emit command to simulate
multiple characters, but this sacrifices all server support for those
characters.
In these above cases the benefits of this proposal are most strongly
felt and I think the enhancement would be dramatic. Ideally it will
completely eliminate any desire to use @emit or @name to simulate
multiple characters with a single player object by making the features
of Tinymux more closely fit with the needs of the users of Tinymux by
freely allowing them to create, manage, and delete many characters
with no awkwardness.
Overview:
Currently MUX servers have a built-in confusion between the very
distinct concepts of player and character. A player is a real-life
user who connects to the server over the internet. A character is a
fictional person who exists within the simulated environment of the
MUX. As things are now, both of these entities are represented by a
single object called a player object. This is the fundamental mistake
that has caused the need for this enhancement proposal because there
should be player objects and character objects that are distinct types
of objects.
A player object represents an account owned by a user. It has a user
name, a password, and it is able to receive OOC messages from other
players such as with the @mail command or the 'page' command. No two
players can share the same name, but there is no reason that a player
cannot have the same name as a character. A player object does not
need to have a location or the ability to emit text to a room, but it
must be able to send commands to character objects to cause those
object to emit text.
A character object represents a fictional person who is part of the
simulated environment of the MUX. A character does not have a password
and users do not connect directly to characters. Character objects do
not accept OOC messages such as from a @mail command or 'page'
command, but they do still accept messages that are considered IC such
as from a 'whisper' command.
Some practical details:
Immediately after logging on, a user has control of player object
which can be used to talk on channels, send @mail messages, or page
people. In order to begin RPing, the user will enter a command to
activate a character. Once a character is activated, everything that
character can hear will be presented to the player.
Suppose the character name is Bob, then a user might manipulate Bob
with commands such as:
> @activate Bob
> @force Bob=:waves.
The first command causes Bob to appear in the IC world with a message
like 'Bob has connected.' The second command causes Bob to wave.
Forcing works here because the current player owns Bob, but it is far
from a convenient way to RP. The problem is that 'me' is still
considered the player object but we want it to be the character
object, so we need another new command such as:
> @become Bob
This causes Bob to be the new 'me' and all commands like 'say' and
'pose' and 'emit' will be automatically forced upon Bob. If @become
is working ideally, controlling Bob will be exactly like it would be
in a current MUX server.
The above is nice because it allows someone who is playing Bob to
instantly switch to playing Jack by typing '@become Jack' as well as
activating or deactivating characters at will. If multiple characters
are concurrently active then a prefix can be used to distinguish which
messages are being heard by each active character, but that is not
ideal.
In order to allow for the sort of multiplaying that players are used
to, a player object should be able to accept multiple internet
connections and it should treat each connection separately.
Specifically, the @become and @activate commands should apply to the
current connection only. This way a user can open multiple connections
to the MUX using the same user name and password, then use the
@activate command with a different name in each connection to begin
playing two different characters simultaneously.
Another practical benefit of allowing multiple connections is that it
can allow a user to have one window open to receive pages, @mail, and
channel chats while another window is used for RP. We can facilitate
this use by having commands to control whether pages should appear in
each connection. For example, a command called @nopages could cause
the MUX to stop sending paged messages down the current connection
while they will continue to be sent down all other connections. This
works because pages are sent to players, not to characters, so all
open connections of a player are reasonable targets for paged
messages.
Maintaining privacy:
Users often expect to keep their collection of characters hidden from
other users. If two characters share the same player, there is no need
to make this known to other players. In the current MUX servers, it
can even be challenging for the server administration to determine if
two characters have the same player. For those players who value this
privacy, this enhancement should not be a cause for concern.
To allow for privacy, we must allow players to interact fully without
knowing each other's player names. This means that the page command
should accept the name of a character rather than the name of a
player. The character object will not receive the page; the page
command will simply look up the owner of the character and direct the
message that way. The player who receives the page will see the name
of whoever is currently 'me' for the player sending the page, allowing
a player to send pages as a player or as any one of his characters by
@forcing or @becoming that character.
This means that a page can be sent to a character even when that
character is inactive because the owner of that character could easily
be connected to the server. Players will know that even if a character
has disappeared the player will often still be available, so they
should be allowed to send pages to inactive characters. If we did not
allow this, then people would end up being asked for a list of alts so
that they can stay in touch when their current character is inactive.
Such questions would be embarrassing for people who value their
privacy.
Allowing pages to inactive characters creates the possibility of pages
ending up directed to players who are not connected to the server. For
privacy reasons, the sender of the page should not be informed that
the player is unavailable. Instead, the page could be either be
silently discarded or else it could be logged for the player to view
upon connecting.
When a player receives a page that was directed to an inactive
character, the player will want to respond but might not want to
reveal the identity of the current character. To allow the player to
respond using the identity of the inactive character, we must allow
the player to @force or @become an inactive character.
Xandar
Jul 25, 2008, 9:21:56 AM7/25/08
to tinymux
Is there a reason that this can't be soft coded? It takes a lot of
work. but it lets a game customize it to their needs rather than
forcing them into a single setup. There's at least two games out there
(one on Rhost and one on Penn) that I'm aware of that have done it.
Not only that, from some of what you're saying, you could use a
Robot. So there's another option.
- Xandar
work. but it lets a game customize it to their needs rather than
forcing them into a single setup. There's at least two games out there
(one on Rhost and one on Penn) that I'm aware of that have done it.
Not only that, from some of what you're saying, you could use a
Robot. So there's another option.
- Xandar
Ansatz
Jul 25, 2008, 5:09:48 PM7/25/08
to tinymux
On Jul 25, 6:21 am, Xandar wrote:
> Is there a reason that this can't be soft coded? It takes a lot of
> work. but it lets a game customize it to their needs rather than
> forcing them into a single setup.
You said it yourself, the reason this can't be soft coded is that it
> Is there a reason that this can't be soft coded? It takes a lot of
> work. but it lets a game customize it to their needs rather than
> forcing them into a single setup.
takes lots of work. I wouldn't even know how to begin to soft code
this. If you do, please share it.
I take it that you're implying that this proposal forces people into a
single setup, but I completely disagree. My proposal is at least as
open to softcode customization as the current setup. I'd say that it
is even more open to softcode customization because it would be far
far easier to use softcode to eliminate the enhancement that it is to
use softcode to create the enhancement.
All you'd have to do would be to automatically @activate and @become
and force each player to have only a single character. So I think it
is clear that this proposal doesn't force anyone into anything; it
only enhances by giving people the features that they usually want in
practice.
> There's at least two games out there
> (one on Rhost and one on Penn) that I'm aware of that have done it.
exceptionally hard to do. You've got to admit that this would be a
very elaborate and twisted softcoding operation that requires
replacing most of the built-in features of the game with softcoded
equivalents.
Do you know how they did it?
> Not only that, from some of what you're saying, you could use a
> Robot. So there's another option.
Amy Kretzer
Jul 25, 2008, 5:49:07 PM7/25/08
to tin...@googlegroups.com
> On Jul 25, 6:21 am, Xandar wrote:
>> Is there a reason that this can't be soft coded? It takes a lot of
>> work. but it lets a game customize it to their needs rather than
>> forcing them into a single setup.
>
>> Is there a reason that this can't be soft coded? It takes a lot of
>> work. but it lets a game customize it to their needs rather than
>> forcing them into a single setup.
>
> Ansatz wrote:
> You said it yourself, the reason this can't be soft coded is that it
> takes lots of work. I wouldn't even know how to begin to soft code
> this. If you do, please share it.
> You said it yourself, the reason this can't be soft coded is that it
> takes lots of work. I wouldn't even know how to begin to soft code
> this. If you do, please share it.
Many things on games take a lot of work, but most of the time they still
remain softcoded because doing them as hardcode to satisfy a minority of
games is a waste of the developers' efforts. (Please note I am not speaking
on behalf of any of those developers, just pointing what I perceive as the
general reasoning for why some things are softcoded and some things are
built in to the source.) Would this be a waste of time? That'd be up to the
developers themselves, though I imagine they wouldn't make up their minds
until they see a real demand for this kind of addition. As far as this being
something in demand, this is the first time I've heard of it in 14 years of
oRPGs, so...
>> There's at least two games out there
>> (one on Rhost and one on Penn) that I'm aware of that have done it.
>
> Ansatz wrote:
> The fact that only two games have done it is proof that it is
> exceptionally hard to do. You've got to admit that this would be a
> very elaborate and twisted softcoding operation that requires
> replacing most of the built-in features of the game with softcoded
> equivalents.
I don't think it's fair to label this as a proof. The fact that only two
games have the code could also be proof that not very many game owners want
to deal with the compexity of having multiple OOC player objects
(identities) tied to a single IC being. It's hard enough for some to fathom
tracking multiple ALTS let alone multiple identities as separate coded
player objects.
It could also be a proof that most games expect their players to maintain a
"fourth wall" between IC and OOC. After all, when you're at a tabletop
session, you don't ask your friend Ralph to sit at the table and pretend to
be Clark Kent while you're in another chair pretending to be Superman. You
rely on the GM to yell at Bubba if he uses OOC knowledge of Superman's true
identity in an IC manner--just as you would expect the Wizards on a MU* to
do the same.
I know it's tempting to code everything, but sometimes its best to draw a
line. You're going to have to trust the other players to treat IC as IC and
OOC and OOC. And what stops Bubba from simply blabbing to others: Hey,
Superman(#124) is also Clark Kent(#150) and making the code useless anyway?
If this is something very important to a particular game and its staff,
they'll find a way to accomplish it for themselves (hopefully with a minimum
of kludge).
>
> Ansatz wrote:
> Do you know how they did it?
I don't offhand but I also don't know how they did Keran's weather and time
code, since I've never taken the time and effort to break it down. (Note: I
don't use it, I'm just using it as an example.) However, I know it's
possible because it exists. Once upon a time, I didn't know how they did the
brandymailer, or the bulletin boards... All are complicated systems that an
experienced coder can figure out how to do given time and knowledge. The
trick is learning how to do it through your own effort and experimentation,
which is the responsibility of the individual coder or game staffs, and not
of the tinymux list or the developers of MUX's source code.
-----
To sum up: Sorry if this reply comes off as rude, but the general tone of
Ansatz's second note to the list seems a little bit demanding in and of
itself. It's all just my humble opinion.
Ansatz
Jul 25, 2008, 6:58:47 PM7/25/08
to tinymux
On Jul 25, 2:49 pm, "Amy Kretzer" <m...@stjoelive.com> wrote:
> Many things on games take a lot of work, but most of the time they still
> remain softcoded because doing them as hardcode to satisfy a minority of
> games is a waste of the developers' efforts.
You have a good point and that is surely the biggest weakness in this
> Many things on games take a lot of work, but most of the time they still
> remain softcoded because doing them as hardcode to satisfy a minority of
> games is a waste of the developers' efforts.
proposal. It would indeed require a lot of effort from the developers
because it is fundamentally changing the way players connect to the
server. It is far beyond any of the minor bug fixes that the
developers are used to doing.
> Would this be a waste of time? That'd be up to the developers themselves,
> though I imagine they wouldn't make up their minds until they see a real
> demand for this kind of addition. As far as this being something in demand, this
> is the first time I've heard of it in 14 years of oRPGs, so...
because it is too radical an idea. It is something that most people
want but they never thought they could have it. Anyone who has ever
tried to juggle a half-dozen alts has wanted this at least once, but
they may not have been able to put into words what they wanted. Give
this to people and they will be so grateful.
> > Ansatz wrote:
> > The fact that only two games have done it is proof that it is
> > exceptionally hard to do. You've got to admit that this would be a
> > very elaborate and twisted softcoding operation that requires
> > replacing most of the built-in features of the game with softcoded
> > equivalents.
>
> I don't think it's fair to label this as a proof.
implemented this is because only two games have wanted it. That is
possible, but is it very likely? One one hand we have an enhancement
that does good things and allows easy management of alts and on the
other hand we have a soft coding nightmare that requires breaking down
almost the entire structure of the MUX server and rebuilding it with
nothing but sweat and tears and soft code. I'm pretty sure that it is
the effort required that is the bigger issue here. They'd probably
like to have it, but they just don't think it's worth the enormous
soft coding effort required.
They are probably right that it's not worth the effort needed to
softcode this. However, I am quite confident that doing this in hard
code would be quite a lot less effort. It only requires minor
modifications to a large number of features. Doing that in soft code
requires completely replacing all those hardcoded features, but doing
in hard code means just changing a few lines.
> The fact that only two games have the code could also be proof that not very
> many game owners want to deal with the compexity of having multiple OOC
> player objects (identities) tied to a single IC being. It's hard enough for some to
> fathom tracking multiple ALTS let alone multiple identities as separate coded
> player objects.
clearly express my proposal in a way that would make everyone
understand my wonderful idea, but now I am faced with someone pointing
out a problem with my proposal that does not exist. This can only be
because I was not as clear as I was trying to be, and now it's too
late to really correct that problem. All I can do is flail around
trying to get rid of as many misconceptions as I can.
Specifically, my proposal does not include having multiple OOC player
objects tied to a single IC being. Let me be clear on that: it is
entirely a misconception that stems from my inability to express my
ideas clearly. Whatever I said that leads you to that conclusion is
not being read as I intended it. No character is owned by multiple
players; all my proposal is designed to achieve is simplifying the
management of alts.
On the bright side, you have pointed out one way in which you would
appreciate the benefits of my proposal. The hard time that you talk
about game owners having is exactly what this proposal is designed to
relieve! Game owners have a hard time tracking multiple alts in the
current setup, as you say, but with my enhancement it becomes easy.
> It could also be a proof that most games expect their players to maintain a
> "fourth wall" between IC and OOC. After all, when you're at a tabletop
> session, you don't ask your friend Ralph to sit at the table and pretend to
> be Clark Kent while you're in another chair pretending to be Superman.
People are fully able to keep their identities private on the current
system, simply because it's difficult to tell who is really
controlling each player.
The awkwardness of the current system for superhero RP is that Clark
Kent has to vanish from the world for a few moments while his
connection resets before he can become Superman, and Clark Kent can't
easily read Superman's mail. People tend to choose to find work-
arounds using @name or @emit rather than having to deal with two
separate characters.
My proposal breaks down the privacy and makes it trivial for
administration to see the alts that you have, so I put serious effort
into carefully building that privacy back up so that people would not
feel my proposal in any way causes problems. Those players who want to
keep OOC secrets can still do so under my proposal thanks to my
privacy considerations.
> And what stops Bubba from simply blabbing to others: Hey, Superman(#124) is
> also Clark Kent(#150) and making the code useless anyway?
Superman a secret is the very least of what this proposal would help
with. It also removes administration headache over alts and prevents
unauthorized multiplaying, and encourages alts when the administration
wants to encourage alts. It makes switching identities in superhero
games as natural as it should be with zero effort from the game owner.
In addition to all that it cause no practical problems at all.
> If this is something very important to a particular game and its staff,
> they'll find a way to accomplish it for themselves (hopefully with a minimum
> of kludge).
implementing my proposal then I'm afraid that minimum kludge will
probably mean using the @hook command to disable every hardcoded
command in the game and then rebuilding them all with softcode. This
would be especially kludge-ridden for commands like @set.
The reason this would be required is because when you type @become
Bob, you should actually become that character and be able to work as
Bob just as naturally as if you were connected to Bob under the
current system. When you use commands on objects, those commands
should apply to the objects where Bob is. When you use the pose
command, it should be Bob who poses. As far as I can tell, every
command now works subtly differently and that would be hell to
implement in soft code.
> However, I know it's possible because it exists. Once upon a time, I didn't know
> how they did the brandymailer, or the bulletin boards... All are complicated
> systems that an experienced coder can figure out how to do given time and
> knowledge. The trick is learning how to do it through your own effort and
> experimentation, which is the responsibility of the individual coder or game staffs,
> and not of the tinymux list or the developers of MUX's source code.
If nothing else comes from my post, I would be very satisfied by just
learning a good way to implement this in soft code. Until then, as
best I can see, implementing this proposal in soft code is at least
one order of magnitude more massive than a mailing system or a
bulletin board system.
At least with a bulletin board system you are only adding new commands
to the current set of available commands. To implement my proposal you
have to modify how every command in the game works, something which is
so impractical in soft code that I think it borders upon impossible.
> To sum up: Sorry if this reply comes off as rude, but the general tone of
> Ansatz's second note to the list seems a little bit demanding in and of
> itself.
demanding it is only because of my excitement and eagerness to see
something like this implemented, either in soft code or hard code.
I have experience with soft code, so a discussion of how to do this in
soft code would not be wasted upon me.
Suzanne Baylor
Jul 26, 2008, 1:30:22 PM7/26/08
to tin...@googlegroups.com
Ansatz wrote:
> The fact that only two games have done it is proof that it is
> exceptionally hard to do. You've got to admit that this would be a
> very elaborate and twisted softcoding operation that requires
> replacing most of the built-in features of the game with softcoded
> equivalents.
>
> Do you know how they did it?
>
>
Its not that painfully hard once you figure out what needs to be done:
Track alts somehow so you can connect logins with PCs and let people
flip (and has security so they can't pick an alt that isn't their own.)
@hook/override look to match and list the IC name and get the right
desc. This is the trickiest thing since look has so many variations (me,
here, dbref, etc).
@hook/override pose/say/semipose/emit/remit -- I used it in conjunction
with Penn's speak() function for IC language support, but it should be
fairly trivial to code manually if all you want to do is change the
speaker's name.
Put odrop, osucc, and succ on the master exit parent to grab the IC name.
Put conformat on the master room parent to list the proper IC name.
Change any softcode references to %N and [name()] to use your IC name
getting function (eg places.)
Get/Drop if appropriate to your MU (same matching issues as look.)
This was actually better, IMO, than trying to hard code it since I have
instances when I want to use use the login name not always grab the IC
name (OOC areas, OOC people, people without IC names set, staff, etc.)
Plus I have a system that'd allow for disguises or morphing (Clark Kent
becomes Superman) which is separate need from alt flipping.
In my case I have d.sheet on the player which references a sheet's
dbref. All IC info is on the sheet object. The IC name function would be
something like: [get(get(%#/d.sheet)/d.name)].
Ansatz
Jul 26, 2008, 5:22:36 PM7/26/08
to tinymux
Thank you, Suzanne Baylor, this is giving me a lot to think about.
Your rough description of how to implement it in soft code leaves a
few blanks for me to fill in, but it seems to suggest a possible
solution that would be practical to do. I am still trying to decide if
the result could be my proposal with all of its features or if it is
limited or awkward somehow.
I'd like to ask a few questions to see if I've got it right.
Suzanne Baylor wrote:
> Track alts somehow so you can connect logins with PCs and let people
> flip (and has security so they can't pick an alt that isn't their own.)
I take it that this means you are still allowing conventional alts and
tracking them somehow. So each user might still have more than one
player object, more than one password, etc. Is that right?
If so, then before a player connects he'd have to choose one of his
alts. In my proposal connecting was more abstract than that, with just
one password per user. That helped to prevent unauthorized sharing of
characters, but I suppose it's not critically important.
On the other hand, reading the rest of your advice makes me think that
instead of traditional alts you are replacing alts by objects called
'sheets' that contain just a name and a desc. Each user would have one
player object and that player object would own any number of sheets
which would probably be carried within the player object to ensure
they are always available.
If so then it would naturally make multiplaying impossible or highly
impractical, and it would almost certainly have serious privacy
concerns which would drive away some players from using the system,
but since I personally don't consider alt privacy or multiplaying to
be important, I am quite intrigued by the possibilities.
> @hook/override look to match and list the IC name and get the right
> desc. This is the trickiest thing since look has so many variations (me,
> here, dbref, etc).
If I understand your idea correctly, wouldn't @hooking "look" be
overkill? To replace the desc of a player object with a sheet object
desc, all you would need would be a @descformat. For room listings,
all you would need would be a @conformat. At the moment I don't see
any problems that "look" could cause that can't be resolved with
@descformat and @conformat.
However, I am far more concerned about other incidental appearance of
player names. Since we have no hard coded support for what we are
trying to do, the server will tend to want to blab the player object
name even if we would prefer otherwise. How do we get it to say the
sheet name when the player is moving from one room to another or
disconnecting?
It is such a shame that @odrop and @osuccess automatically prefix the
player name. I suppose the trick for moving from room to room would be
to use some trick with @tel/quiet and an exit parent, but that will
still leave the player object name blabbed on connects and
disconnects, spoiling things a bit.
Is there a way to disable the automatic connect/disconnect messages?
I'm beginning to believe that feature may be the only bit of hard code
support that is really needed here. It would be wonderful if it
already exists.
> @hook/override pose/say/semipose/emit/remit -- I used it in conjunction
> with Penn's speak() function for IC language support, but it should be
> fairly trivial to code manually if all you want to do is change the
> speaker's name.
I agree. Every mux I've ever seen has had a soft coded 'ooc' command
that simulates pose/say/semipose and they work brilliantly. I've had
long conversations entirely with the ooc command it it's exactly as if
I were using a hard coded say or pose.
> Put odrop, osucc, and succ on the master exit parent to grab the IC name.
What do you mean by 'grab the IC name'? I've been wondering about how
to deal with how the mux blabs the player object name whenever I move
from room to room, but as far as I can tell it's not possible to use
odrop or osucc to fix that. I'd love to know more details about what
you are doing.
> Put conformat on the master room parent to list the proper IC name.
> Change any softcode references to %N and [name()] to use your IC name
> getting function (eg places.)
> Get/Drop if appropriate to your MU (same matching issues as look.)
It's a bit unfortunate that we won't be able to use %N anymore. I
wonder if it is possible to use @function to override name() into
doing what we want, or if @function only works for unused function
names. At the very least, I'd use @function to create a quick
abbreviation for accessing the appropriate name of a player.
> This was actually better, IMO, than trying to hard code it since I have
> instances when I want to use use the login name not always grab the IC
> name (OOC areas, OOC people, people without IC names set, staff, etc.)
I'm sure that a hard coded system would allow for that. At the very
least it would surely be easier to modify it using soft code to create
that, then it is to implement the alt flipping that you describe above
in soft code.
> Plus I have a system that'd allow for disguises or morphing (Clark Kent
> becomes Superman) which is separate need from alt flipping.
Actually, the alt flipping system that you describe above seems to
work brilliantly for that, if I understand it correctly. Each alt is
effectively just a disguise that you call a sheet. I don't see what
you could possibly add to that to make it more effective for
disguises.
I see a few things that are needed that you didn't mention. For one
thing, we need a system for registering sheet names to prevent
duplicates. The trick is that we would have to make it impossible for
players to rename their own sheets without having the new name
verified. We would also want it to associate alt names with the dbref
number of the sheet, then the owner of the sheet would give us the
dbref of the appropriate player object.
Since the player object name will be deliberately hidden, we'll need
to let people use the sheet name in place of the player name. So we
need to modify every command that expects a player name, including
using @hook on a few more hard coded commands such as @mail and page.
'Page' is easy and I hear that there are already soft coded mailing
systems available, even though tinymux has a brilliant hard coded
mailer that will be a shame to override.
I haven't had much use for it, but sometimes carrying objects has
important IC purposes for some players in some games. This means that
we'd better @hook 'give', 'get', 'drop', and 'inventory' so that they
work with the inventory of the current sheet instead of the player
object. We could move the sheet's objects into the player object each
time a flip is done, but we'd still have to @hook give because 'give'
uses a player name.
It is a shame that players couldn't use '@desc me' to set their own
descriptions, for example, but the @desc command is one of those
things which is terribly awkward to replace with soft code.
It seems like there might be no end to the commands that would need to
be @hooked, actually. I'm probably forgetting some more issues that
would arise, but at least this seems a lot more practical to do in
soft code than my proposal.
Your rough description of how to implement it in soft code leaves a
few blanks for me to fill in, but it seems to suggest a possible
solution that would be practical to do. I am still trying to decide if
the result could be my proposal with all of its features or if it is
limited or awkward somehow.
I'd like to ask a few questions to see if I've got it right.
Suzanne Baylor wrote:
> Track alts somehow so you can connect logins with PCs and let people
> flip (and has security so they can't pick an alt that isn't their own.)
tracking them somehow. So each user might still have more than one
player object, more than one password, etc. Is that right?
If so, then before a player connects he'd have to choose one of his
alts. In my proposal connecting was more abstract than that, with just
one password per user. That helped to prevent unauthorized sharing of
characters, but I suppose it's not critically important.
On the other hand, reading the rest of your advice makes me think that
instead of traditional alts you are replacing alts by objects called
'sheets' that contain just a name and a desc. Each user would have one
player object and that player object would own any number of sheets
which would probably be carried within the player object to ensure
they are always available.
If so then it would naturally make multiplaying impossible or highly
impractical, and it would almost certainly have serious privacy
concerns which would drive away some players from using the system,
but since I personally don't consider alt privacy or multiplaying to
be important, I am quite intrigued by the possibilities.
> @hook/override look to match and list the IC name and get the right
> desc. This is the trickiest thing since look has so many variations (me,
> here, dbref, etc).
overkill? To replace the desc of a player object with a sheet object
desc, all you would need would be a @descformat. For room listings,
all you would need would be a @conformat. At the moment I don't see
any problems that "look" could cause that can't be resolved with
@descformat and @conformat.
However, I am far more concerned about other incidental appearance of
player names. Since we have no hard coded support for what we are
trying to do, the server will tend to want to blab the player object
name even if we would prefer otherwise. How do we get it to say the
sheet name when the player is moving from one room to another or
disconnecting?
It is such a shame that @odrop and @osuccess automatically prefix the
player name. I suppose the trick for moving from room to room would be
to use some trick with @tel/quiet and an exit parent, but that will
still leave the player object name blabbed on connects and
disconnects, spoiling things a bit.
Is there a way to disable the automatic connect/disconnect messages?
I'm beginning to believe that feature may be the only bit of hard code
support that is really needed here. It would be wonderful if it
already exists.
> @hook/override pose/say/semipose/emit/remit -- I used it in conjunction
> with Penn's speak() function for IC language support, but it should be
> fairly trivial to code manually if all you want to do is change the
> speaker's name.
that simulates pose/say/semipose and they work brilliantly. I've had
long conversations entirely with the ooc command it it's exactly as if
I were using a hard coded say or pose.
> Put odrop, osucc, and succ on the master exit parent to grab the IC name.
to deal with how the mux blabs the player object name whenever I move
from room to room, but as far as I can tell it's not possible to use
odrop or osucc to fix that. I'd love to know more details about what
you are doing.
> Put conformat on the master room parent to list the proper IC name.
> Change any softcode references to %N and [name()] to use your IC name
> getting function (eg places.)
> Get/Drop if appropriate to your MU (same matching issues as look.)
wonder if it is possible to use @function to override name() into
doing what we want, or if @function only works for unused function
names. At the very least, I'd use @function to create a quick
abbreviation for accessing the appropriate name of a player.
> This was actually better, IMO, than trying to hard code it since I have
> instances when I want to use use the login name not always grab the IC
> name (OOC areas, OOC people, people without IC names set, staff, etc.)
least it would surely be easier to modify it using soft code to create
that, then it is to implement the alt flipping that you describe above
in soft code.
> Plus I have a system that'd allow for disguises or morphing (Clark Kent
> becomes Superman) which is separate need from alt flipping.
work brilliantly for that, if I understand it correctly. Each alt is
effectively just a disguise that you call a sheet. I don't see what
you could possibly add to that to make it more effective for
disguises.
I see a few things that are needed that you didn't mention. For one
thing, we need a system for registering sheet names to prevent
duplicates. The trick is that we would have to make it impossible for
players to rename their own sheets without having the new name
verified. We would also want it to associate alt names with the dbref
number of the sheet, then the owner of the sheet would give us the
dbref of the appropriate player object.
Since the player object name will be deliberately hidden, we'll need
to let people use the sheet name in place of the player name. So we
need to modify every command that expects a player name, including
using @hook on a few more hard coded commands such as @mail and page.
'Page' is easy and I hear that there are already soft coded mailing
systems available, even though tinymux has a brilliant hard coded
mailer that will be a shame to override.
I haven't had much use for it, but sometimes carrying objects has
important IC purposes for some players in some games. This means that
we'd better @hook 'give', 'get', 'drop', and 'inventory' so that they
work with the inventory of the current sheet instead of the player
object. We could move the sheet's objects into the player object each
time a flip is done, but we'd still have to @hook give because 'give'
uses a player name.
It is a shame that players couldn't use '@desc me' to set their own
descriptions, for example, but the @desc command is one of those
things which is terribly awkward to replace with soft code.
It seems like there might be no end to the commands that would need to
be @hooked, actually. I'm probably forgetting some more issues that
would arise, but at least this seems a lot more practical to do in
soft code than my proposal.
Ansatz
Jul 27, 2008, 8:18:38 AM7/27/08
to tinymux
Suzanne Baylor wrote:
> Its not that painfully hard once you figure out what needs to be done:
> Its not that painfully hard once you figure out what needs to be done:
> @hook/override look to match and list the IC name and get the right
> desc. This is the trickiest thing since look has so many variations (me,
> here, dbref, etc).
In a previous reply I said that I did not see the point of overriding
> desc. This is the trickiest thing since look has so many variations (me,
> here, dbref, etc).
"look" because @descformat could be used just as well. Of course, I
only later realized my obvious mistake: We need to @hook look just so
that we can type in an IC name rather than the real player object
name. I'd realized that was necessary for several other commands, but
that one completely escaped me until just now.
So it is yet another thing which must be @hooked. I am a little
disappointed that even the supposedly easy soft code solutions require
so many commands to be @hooked. It's not as practical as I had hoped.
Perhaps it is possible to meet halfway between a hard code solution
and a soft code solution. I bet that if the developers of Tinymux knew
that people would be trying to do this, they would have developed the
hard code in such a way to make this soft coding job at least a little
easier and more natural.
The biggest obstacle to an easy soft code solution is the fact that we
have to @hook every command that uses a player name as a parameter. If
only there was a way to eliminate the need for that.
Perhaps @alias could be used that way. If we were to forbid players
from setting their own aliases and automatically set the alias to the
IC name when switching alts, then we could use 'look' and 'give' and
any similar command without needing a hook. This isn't exactly how
@alias was intended to be used, so I wonder if that would cause a
problem that I'm not seeing.
Even if that trick would work, we would still need to @hook page and
@mail, but at least the size of the problem is hugely reduced.
Jerry Van Suchtelen
Jul 27, 2008, 8:51:11 AM7/27/08
to tin...@googlegroups.com
Wouldnt it just be easier to create a command which allows a person to
'su' (super user) from one character to another? Or better yet, log
out of char a, login to char b?
'su' (super user) from one character to another? Or better yet, log
out of char a, login to char b?
Ansatz
Jul 27, 2008, 5:26:35 PM7/27/08
to tinymux
Jerry Van Suchtelen wrote:
> Wouldnt it just be easier to create a command which allows a person to
> 'su' (super user) from one character to another? Or better yet, log
> out of char a, login to char b?
I agree; that would be much easier. That is just fine if you feel that
> Wouldnt it just be easier to create a command which allows a person to
> 'su' (super user) from one character to another? Or better yet, log
> out of char a, login to char b?
the way things currently are is ideal, but let me tell you how my
friends and I like to play.
We spend a great deal of time hanging around and chatting. We come up
with ideas as we talk and then every once in a while we go and do a
little scene as a way to bring our ideas to life. We advance one plot
or another as our moods dictate. We tend to have few alts, but we have
a absolute horde of characters. You might describe it as an army of
characters that is at least a dozen strong and always recruiting. We
simply pop new characters into existence whenever we have a whim to do
so.
We don't hesitate to do it because each character is nothing more than
someone whom we build up using @emit. We certainly create no player
object for them and we have absolutely no support from the mux for
what we are doing. To be honest, we almost might be roleplaying on IRC
or something equally primitive.
In the past, the same sorts of whims have lead me to create a half-
dozen alts at least, sometimes even more, and I have known players who
had it even worse. I respect the opinions of people who feel that this
is not a problem. I have been told that some people manage such a
situation by having a half-dozen connections open at once, essentially
multiplaying every alt, but for me that is impractical.
For me, having many alts in the usual sense is terrible because each
of them has a completely separate identity with their own @mail and
with a collection of other players who only recognize me through that
alt. I have nothing against those players, but they cannot be bothered
to memorize a list of alts and I cannot be bothered to constantly
switch between alts so that none is neglected. From their perspective,
I am rarely online only because I rarely find a use for the alt that
they know. The more alts I have, the worse it becomes, so I have
learned to use @emit instead.
I can manage to play quite happily on a mux as they currently exist,
and in fact I prefer to play on Tinymux over anything else I know of.
However, I can imagine something which I would enjoy even more. I'd
just like some support for creating new alts without creating an
entirely new identity, so that if people try to get in touch with one
of my rarely used alts, I would still get the message immediately.
Many games I know have limits on the number of alts you can have, and
I respect that exactly because I know the dangers of having an
unbounded number of alts. The first game I ever played on seriously
let you have as many as you wanted and I abused that terribly simply
because I didn't know the problems it caused.
In other words, the problem that I find when I abuse alts is that most
of my characters are rarely online and so the people who want to have
a scene with those characters think they are unavailable even when I
am connected. The other players think my alts are unavailable and I
think they are unwanted because I don't know that other players want
my alts. If only I could receive messages directed at my alts while
they are not in use.
I can't be sure that there are many people out there who feel the way
that I do, but I have reason to suspect that there are. The very fact
that it seems most games have a rule that limits the number of alts
makes me suspect that if they did not put limits then alt abuse would
follow. If people would not create many alts without the rule or if
creating many alts would not cause a problem, then the rule seems
pointless. If it were a pointless rule, then I would not expect to
find a variation of it in almost every game. On the contrary, since
such a rule is common, I conclude that players would like to have many
alts but doing so causes problems.
This is why I make this suggestion. I'm doing it for those of us who
would like to go beyond the 2-alt limit that some games enforce and
would like to do it without negative consequences. I'd like a game
where having many alts is not abusive; it is just a fun way to let
your imagination run wild. And as a bonus, it would be nice to allow
game admins to more easily keep track of which alts belong to which
players.
From what I have heard, the people who hate my idea consider it a
burden or awkward somehow and they dislike the blurring of the
characters which are now completely separate. For example, they don't
like the mixing together of pages directed towards separate
characters, or they don't want to be getting pages regarding IC issues
when dealing with administrative duties. I mean those people no
disrespect, but there is nothing in my proposal which prevents people
from having as many completely separate accounts as they want.
I am in no way pressuring people into using the features I am
proposing if they don't want to use them; I only hope that the people
who don't find these features useful will consider helping the rest of
us to be able to use these features. Perhaps a few small changes to
the hard code would make softcoding this much easier.
Jerry Van Suchtelen
Jul 27, 2008, 5:34:18 PM7/27/08
to tin...@googlegroups.com
I think you are very articulate in writing and you seem to have
thought it out beyond a few minutes. However I think it may be a good
idea to have a single login and then characters connected to that
login. It would avoid having to try and keep track of peoples alts
and enforcing limits to them. Games which say 'you cant have more
then 2 characters' seem to say 'you cant possibly play more then 2
characters because we say so' and i avoid them.
thought it out beyond a few minutes. However I think it may be a good
idea to have a single login and then characters connected to that
login. It would avoid having to try and keep track of peoples alts
and enforcing limits to them. Games which say 'you cant have more
then 2 characters' seem to say 'you cant possibly play more then 2
characters because we say so' and i avoid them.
Anyways, maybe a plugin could be made so that people who dont want it,
dont have to download it.
K hall
Jul 28, 2008, 5:34:59 AM7/28/08
to tin...@googlegroups.com
Eh, some of us forbid players from having more than one alt in an area, not because we care about multiple logins or character clean up, as much, as limiting IC crossover and alt conflicts.
As far as I know there's no way to fix the issue of @names being displayed on travel through an exit, short of setting the exit QUIET. Which then causes no notice of arrival at all.
K.
> Date: Sun, 27 Jul 2008 15:34:18 -0600
> From: worldg...@gmail.com
> To: tin...@googlegroups.com
> Subject: [TinyMUX] Re: Managing multiple alts and connections
As far as I know there's no way to fix the issue of @names being displayed on travel through an exit, short of setting the exit QUIET. Which then causes no notice of arrival at all.
K.
> Date: Sun, 27 Jul 2008 15:34:18 -0600
> From: worldg...@gmail.com
> To: tin...@googlegroups.com
> Subject: [TinyMUX] Re: Managing multiple alts and connections
>
> Games which say 'you cant have more
> then 2 characters' seem to say 'you cant possibly play more then 2
> characters because we say so' and i avoid them.
Keep your kids safer online with Windows Live Family Safety. Help protect your kids.
David Cheatham
Jul 28, 2008, 8:03:30 PM7/28/08
to tin...@googlegroups.com
Ansatz wrote:
> This is a proposal for enhancement of Tinymux to support multiple
> characters on a single player account.
>
> Benefits:
>
> This proposal allows for greater flexibility and power in controlling
> the number of characters owned by each user. It will allow Tinymux to
> enforce rules about the number of characters a user can own as well as
> the number of characters that a user can use simultaneously when
> multiplaying is allowed. Since multiplaying is often forbidden, it
> would be possible for Tinymux to enforce that rule by making
> multiplaying impossible.
> This is a proposal for enhancement of Tinymux to support multiple
> characters on a single player account.
>
> Benefits:
>
> This proposal allows for greater flexibility and power in controlling
> the number of characters owned by each user. It will allow Tinymux to
> enforce rules about the number of characters a user can own as well as
> the number of characters that a user can use simultaneously when
> multiplaying is allowed. Since multiplaying is often forbidden, it
> would be possible for Tinymux to enforce that rule by making
> multiplaying impossible.
I actually wrote up a idea that almost all MUSHes should simply operate
*two* servers. One OOC, and one IC.
All OOC commands, and player creation, and all sorts of things would be
disabled on the IC server. (Well, page and ooc speech might be allowed,
for communication during RP, but that's it.)
People could connect to the OOC game, get a feel for the game, write
char apps, perhaps even watch some RP via 'camera bots' in public places
on the IC game that pipe to the OOC mush, etc.
When they're ready to RP, they connect over there also. And,
incidentally, games could share OOC servers if they wanted.
This was more for separating out OOC and IC in people's minds than
'flexibility' or 'secrecy', though. My idea being, if there's a 'game
world' with 'game characters', and a 'world to talk about game world'
with 'real people', people would be psychologically tricked into
separating IC and OOC more.
Especially if people were required to have different names on the OOC
game. They'd be a lot more willing to let 'bad things' happen to 'their'
character if they operated more like actors do...where they're *clearly*
on stage or off stage, instead of wearing their costume (name) and
wandering around the set while talking OOC to each other.
There's a whole discussion up on my (Vadiv's) blog on
http://community.pennmush.org/ but for some reason that's down right now.
Ansatz
Jul 28, 2008, 8:13:49 PM7/28/08
to tinymux
K hall wrote:
> As far as I know there's no way to fix the issue of @names being displayed on
> travel through an exit, short of setting the exit QUIET. Which then causes no
> notice of arrival at all.
For a moment there I thought you had given me the perfect solution to
> As far as I know there's no way to fix the issue of @names being displayed on
> travel through an exit, short of setting the exit QUIET. Which then causes no
> notice of arrival at all.
this problem, but when I tested it I discovered that QUIET does not
work as you describe. You still see the leaving and arriving notices
even when the exit is set to QUIET.
I thought that there might be a way to use @tel/quiet to avoid those
messages, but it seems just doing @asucc exit=@tel/quiet %#=loc(me)
does not work. Even then you still get the messages.
Is there some way to get an exit to behave normally in all ways except
instead of actually taking you somewhere, it just runs its @asucc and
stops? I expect that I could give every exit an impassable lock and
then use @afail, but that would mean that I could never use locks
properly on exits.
I really like what Suzanne Baylor has done with her system, but it
seems that it may only be possible on PennMUSH for the frustrating
reason that PennMUSH has more flexible @osucc and @odrop messages. I
can't imagine how I could be any closer while still being so far away.
Amy Kretzer
Jul 28, 2008, 10:38:49 PM7/28/08
to tin...@googlegroups.com
I think K Hall meant the 'BLIND' flag, rather than 'QUIET'.
----- Original Message -----
From: "Ansatz" <ans...@gmail.com>
To: "tinymux" <tin...@googlegroups.com>
Sent: Monday, July 28, 2008 7:13 PM
Subject: [TinyMUX] Re: Managing multiple alts and connections
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.138 / Virus Database: 270.5.6/1578 - Release Date: 7/28/2008
> 5:13 PM
>
>
>
Reply all
Reply to author
Forward
0 new messages