Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Custom Ban messages for Ant-Alt #5

Open
ttk2 opened this issue Oct 17, 2012 · 8 comments
Open

Feature Request: Custom Ban messages for Ant-Alt #5

ttk2 opened this issue Oct 17, 2012 · 8 comments

Comments

@ttk2
Copy link

ttk2 commented Oct 17, 2012

Instead of saying 'banned by operator' add the message to the ban list as the same line put into the server log telling the player what alts they are currently banned for.

@Exultant
Copy link
Owner

As far as I can tell the Bukkit api doesn't provide any way to write anything to the banned-players file except to set a player as banned or not banned.
It might be possible to parse and overwrite that file with an external script though.

@ttk2
Copy link
Author

ttk2 commented Oct 18, 2012

we could try operating outside the bukkit api and writing to the banned
players list directly (could be a very bad idea)

On Thu, Oct 18, 2012 at 8:32 AM, Exultant [email protected] wrote:

As far as I can tell the Bukkit api doesn't provide any way to write
anything to the banned-players file except to set a player as banned or not
banned.

It might be possible to parse and overwrite that file with an external
script though.


Reply to this email directly or view it on GitHubhttps://github.com//issues/5#issuecomment-9564311.

@Celdecea
Copy link

Further research confirms what Exultant said. Furthermore modifying the ban file will not be visible until restart and if a save occurs after modification at best we lose data.

I recommend using a separate log or data file for this information.

@ttk2
Copy link
Author

ttk2 commented Oct 23, 2012

As far as I am aware the reason for a ban is passed into a log file like
this /ban [username] could we just use that command format
ourselves by piping it into the command as console text chat?

On Tue, Oct 23, 2012 at 12:35 AM, Celdecea [email protected] wrote:

Further research confirms what Exultant said. Furthermore modifying the
ban file will not be visible until restart and if a save occurs after
modification at best we lose data.

I recommend using a separate log or data file for this information.


Reply to this email directly or view it on GitHubhttps://github.com//issues/5#issuecomment-9691121.

@Celdecea
Copy link

I don't think it is supported by bukkit yet even if you did it that way. (see https://github.com/Bukkit/Bukkit/blob/09ef15e95036f0b22ecffe686ebbc0ea137c803b/src/main/java/org/bukkit/command/defaults/BanCommand.java#L26). I tested on dev and my own server; confirmed that the command will still use "Banned by an operator" even if a different reason is included.

The setBanReason method appears to be an mcp thing and not available from bukkit.

Inside Minecraft there is player list attached to the server. This file loads the ops.txt followed by white-list.txt, then some properties, then loads banned-players.txt. The files are immediately resaved and closed. Minecraft handles the ban command by looking for the reason argument, and even calls the method to set the reason before "putting" the ban, which forces a save and close. The reason doesn't make it into the file, but after an hour of reviewing the code I can't see why it doesn't.

The file is only loaded when the server is started (specifically when the server object is created; the new command is at the class level in the property definitions, i.e. a default value instantiated object).

A separate ban plugin seems to be the going recommendation because of the limitations. I can't blame bukkit at this point because it appears to be waiting for some Minecraft code to get fixed.

@ttk2
Copy link
Author

ttk2 commented Oct 24, 2012

No ready to waste our time with this then. Fighting against
Mojangs inconsistency is what we have to do for every plugin, may as well
save our effort for something more than 'you know that would be cool'.

On Wed, Oct 24, 2012 at 12:00 AM, Celdecea [email protected] wrote:

I don't think it is supported by bukkit yet even if you did it that way.
[source](

https://github.com/Bukkit/Bukkit/blob/09ef15e95036f0b22ecffe686ebbc0ea137c803b/src/main/java/org/bukkit/command/defaults/BanCommand.java#L26).

I tested on dev and my own server; confirmed that the command will still
use "Banned by an operator" even if a different reason is included.

The setBanReason method appears to be an mcp thing and not available from
bukkit.

Inside Minecraft there is player list attached to the server. This file
loads the ops.txt followed by white-list.txt, then some properties, then
loads banned-players.txt. The files are immediately resaved and closed.
Minecraft handles the ban command by looking for the reason argument, and
even calls the method to set the reason before "putting" the ban, which
forces a save and close. The reason doesn't make it into the file, but
after an hour of reviewing the code I can't see why it doesn't.

The file is only loaded when the server is started (specifically when the
server object is created; the new command is at the class level in the
property definitions, i.e. a default value instantiated object).

A separate ban plugin seems to be the going recommendation because of the
limitations. I can't blame bukkit at this point because it appears to be
waiting for some Minecraft code to get fixed.

On Tue, Oct 23, 2012 at 5:34 AM, Justin [email protected] wrote:

As far as I am aware the reason for a ban is passed into a log file like
this /ban [username] could we just use that command format
ourselves by piping it into the command as console text chat?

On Tue, Oct 23, 2012 at 12:35 AM, Celdecea [email protected]
wrote:

Further research confirms what Exultant said. Furthermore modifying
the
ban file will not be visible until restart and if a save occurs after
modification at best we lose data.

I recommend using a separate log or data file for this information.


Reply to this email directly or view it on GitHub<
https://github.com/Exultant/PrisonPearl/issues/5#issuecomment-9691121>.


Reply to this email directly or view it on GitHub<
https://github.com/Exultant/PrisonPearl/issues/5#issuecomment-9699977>.


Reply to this email directly or view it on GitHubhttps://github.com//issues/5#issuecomment-9727942.

@Exultant
Copy link
Owner

All of the custom ban plugins that I have seen work by kicking players as they log in and setting the 'kick message'.
This was originally how the anti-alt feature was implemented in PrisonPearl but we soon discovered that caused HeroChat to break because it wasn't able to deal with players being kicked on login.
I had some vague plans to re-implement just the features of HeroChat that we actually use (which would hopefully fix that problem, among others) but that would be a significant amount of effort just to address this issue.

@ttk2
Copy link
Author

ttk2 commented Oct 24, 2012

Like in said. Not worth it.
On Oct 24, 2012 12:50 PM, "Exultant" [email protected] wrote:

All of the custom ban plugins that I have seen work by kicking players as
they log in and setting the 'kick message'.
This was originally how the anti-alt feature was implemented in
PrisonPearl but we soon discovered that caused HeroChat to break because it
wasn't able to deal with players being kicked on login.
I had some vague plans to re-implement just the features of HeroChat that
we actually use (which would hopefully fix that problem, among others) but
that would be a significant amount of effort just to address this issue.


Reply to this email directly or view it on GitHubhttps://github.com//issues/5#issuecomment-9749240.

rourke750 referenced this issue in Civcraft/PrisonPearl Sep 13, 2014
replace player.getname with pp.getImprisonedName
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants