search

WMCAlliance / BukkitIRCd

BukkitIRCd was an IRC bridge plugin for Minecraft servers running Bukkit. It creates individual 'bot' users for every player to allow seamless communication.
https://wma.im
Other
5 stars 6 forks source link

Overhaul nickname detection using metadata or persistent storage #25

Open chyyran opened 11 years ago

chyyran commented 11 years ago

Because this is probably the best way to do issues https://github.com/WMCAlliance/BukkitIRCd/issues/20 and https://github.com/WMCAlliance/BukkitIRCd/issues/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 https://github.com/WMCAlliance/BukkitIRCd/issues/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 https://github.com/WMCAlliance/BukkitIRCd/issues/20 and https://github.com/WMCAlliance/BukkitIRCd/issues/3 , as well as even allowing the possibility of a command that changes ingame nicknames without breaking features.

Lunaphied commented 11 years ago

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 https://github.com/WMCAlliance/BukkitIRCd/issues/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 #20https://github.com/WMCAlliance/BukkitIRCd/issues/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 https://github.com/WMCAlliance/BukkitIRCd/issues/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/WMCAlliance/BukkitIRCd/issues/25 .

chyyran commented 11 years ago

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 commented 11 years ago

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/WMCAlliance/BukkitIRCd/issues/25#issuecomment-16541466 .

chyyran commented 11 years ago

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 commented 11 years ago

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 https://github.com/WMCAlliance/BukkitIRCd/issues/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/WMCAlliance/BukkitIRCd/issues/25#issuecomment-16541764 .

chyyran commented 11 years ago

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

Lunaphied commented 11 years ago

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/WMCAlliance/BukkitIRCd/issues/25#issuecomment-16541908 .

chyyran commented 11 years ago

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.