Overhaul nickname detection using metadata or persistent storage

[chyyran]

Because this is probably the best way to do issues #20 and #3
as well as a whole lot of other things, I'm going to close that issue, and describe what I mean here, as this goes way beyond issue #20

Currently, nicknames are tied to the Minecraft username of the player, with no way to change them without breaking a lot of things. This is not good.

I suggest assigning and storing the nickname as player metadata, or a form of persistent storage, while adding the param to BukkitPlayer. That way, you have access to the player's IRC nickname, as well as ingame nickname. Many methods get the Player object by using getPlayer() with the nick value in a BukkitPlayer object. The nick value is set to the player's name at start. However, if we have malleable nicknames, we can easily get the BukkitPlayer object with the nickname, and the player name.

This is the best way to cleanly solve issues #20 and #3 , as well as even allowing the possibility of a command that changes ingame nicknames without breaking features.

[Lunaphied]

I am not quite sure what you mean by tied to the username, since they are
almost completely separate. The metadata stored on a player is absolutely
not persistent as you probably know. I support the use of metadata but (I
am assuming BukkitPlayer is the plugins internal data object) I don't think
that adding that parameter makes sense. Instead of a parameter do a setter
and a getter for the metadata value on the player. All that would be left
is to use the new getter and make sure we load and set the variable when a
player joins and store its value at proper intervals. Good idea as long as
those are kept in mind.

On Wednesday, April 17, 2013, Ronny Chan wrote:

Because this is probably the best way to do issues #20https://github.com/WMCAlliance/BukkitIRCd/issues/20and
#3 #3
as well as a whole lot of other things, I'm going to close that issue, and
describe what I mean here, as this goes way beyond issue #20#20

Currently, nicknames are tied to the Minecraft username of the player,
with no way to change them without breaking a lot of things. This is not
good.

I suggest assigning and storing the nickname as player metadata, or a form
of persistent storage, while adding the param to BukkitPlayer. That way,
you have access to the player's IRC nickname, as well as ingame nickname.
Many methods get the Player object by using getPlayer() with the nickvalue in a BukkitPlayer object. The
nick value is set to the player's name at start. However, if we have
malleable nicknames, we can easily get the BukkitPlayer object with the
nickname, and the player name.

This is the best way to cleanly solve issues #20https://github.com/WMCAlliance/BukkitIRCd/issues/20and
#3 #3 , as well as even
allowing the possibility of a command that changes ingame nicknames without
breaking features.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/25
.

[chyyran]

Methods make use of getPlayer(bp.nick), which will basically break things like kicks and queries for that user. Therefore, the IRC nickname and ingame name are tied together, which shouldn't be the case. They should stay seperate.

[Lunaphied]

I see as for the rest?

On Wednesday, April 17, 2013, Ronny Chan wrote:

Methods make use of getPlayer(bp.nick), which will basically break things
like kicks and queries for that user. Therefore, the IRC nickname and
ingame name are tied together, which shouldn't be the case. They should
stay seperate.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-16541466
.

[chyyran]

Besides issues #3 and #20? Perhaps bans as well, the point is that it's not good having the IRC nickname be used as the ingame name in any case. And yes, metadata is not persistent, and while metadata is lightweight, if you have a form of persistent storage, you could have it save custom nicks the next time the player logs on.

[Lunaphied]

My comment on the issue is in favor of this idea. I understand the issues
with the display name. The names could be serialized using a simple
subsection of the config yaml file or create a second config file like a
ircnick.yml file.

On Wednesday, April 17, 2013, Ronny Chan wrote:

Besides issues #3 https://github.com/WMCAlliance/BukkitIRCd/issues/3and
#20 #20? Perhaps bans
as well, the point is that it's not good having the IRC nickname be used as
the ingame name in any case. And yes, metadata is not persistent, and while
metadata is lightweight, if you have a form of persistent storage, you
could have it save custom nicks the next time the player logs on.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-16541764
.

[chyyran]

I think something like an ircnick.yml file would be preferred so that it doesn't clutter the config yaml.

[Lunaphied]

Yes. Do you plan to work on this feature?

On Wednesday, April 17, 2013, Ronny Chan wrote:

I think something like an ircnick.yml file would be preferred so that it
doesn't clutter the config yaml.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-16541908
.

[chyyran]

Not for the time being, I might do it someday, but it seems a larger undertaking than my other pull requests, I just fixed those issues because I used to use BukkitIRCd when Jdbye was still maintaining it, and I discovered that those features were broken in this new version, and for my own aesthetic interests (Such as #26) Plus, I have my own projects to work on. :/ I'm just putting the suggestion out there in case anyone does this before I get around to it.