Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
New file formats in 1.3
#Address, Date/Time, Banned By, Until, For
#Exactly the same as banned-players, but with IP addresses.
#Name, Date/Time, Banned By, Until, For
#All values are trimmed
#<-- these are comments and will be ignored by the parser
#The reason field may contain unescaped commas (, <--). It will be loaded as split(line, 5).
Hackz0r5001,2012-12-31 12:15:09 CEST,Dinnerbone,Forever,For being unoriginal, I mean really!
Hackz0r5000,2012-12-31 12:13:14 CEST,Dinnerbone,2013:01:01 00:00:00 CEST,Being an ultimate badass hacker
#Old formats will be converted as the following:
OldMan,Unknown,Unknown,Forever,Banned by an operator.
#Name field is the person who is banned. Case insensitive.
#Date/time field is in the following format: "yyyy-MM-dd HH:mm:ss Z",
# or the literal "Unknown". Any values it doesn't recognize will be "Unknown".
#Banned by field is the operator who banned the player. Empty values will be
# treated as "Unknown".
#Until field is the same format as date/time. If this isn't "Forever" then the
# player will be unbanned at (roughly) the specified time. Unknown values are
# treated as "Forever".
#For field is the reason the player was banned. It will be displayed when the
# client tries to join. May contain format codes. Empty defaults to
# "Banned by an operator."
#Name, Date/Time, Added By, Comment
#All values are trimmed
#<-- these are comments and will be ignored by the parser
#The comment field may contain unescaped commas (, <--). It will be loaded as split(line, 4).
Santa,2012-12-31 12:15:09 CEST,Dinnerbone,He brings me gifts.
ReallyCoolDude,2012-12-31 12:13:14 CEST,Dinnerbone,I like this dude.
#Old formats will be converted as the following:
OldMan,Unknown,Unknown,
#Name field is the person who is white-listed. Case insensitive.
#Date/time field is in the following format: "yyyy-MM-dd HH:mm:ss Z",
# or the literal "Unknown". Any values it doesn't recognize will be "Unknown".
#Added by field is the operator who white-listed the player. Empty values
# will be treated as "Unknown".
#Comment is anything you like. May contain format codes. Empty values allowed.
@leafstorm
Copy link

leafstorm commented Apr 19, 2012

A couple of suggestions:

  1. Since this isn't an actual CSV file (thank Notch), it may be better to use another separator, like : or |, to delimit the fields. Otherwise people might try using a standard CSV parser library, or MS Excel.
  2. I would store "Banned Until" times in UTC to avoid edge cases with things like DST. Granted, it's probably not super-critical, but it's also not a difficult change to make.

Also, what exactly are the "format codes" in the Comment field?

Loading

@Dinnerbone
Copy link
Author

Dinnerbone commented Apr 19, 2012

  1. | sounds good to me.
  2. Format codes are your standard "make this red" or "make this bold" ingame. http://wiki.vg/Chat#Control_Sequences

Loading

@erisdev
Copy link

erisdev commented Apr 19, 2012

Is it necessary to have IP bans and account name bans in separate files? 10.37.70.23 isn't a valid Minecraft account and Hackz0r5001 isn't a valid IP address; the other fields are identical. Determine the ban type by the first value!

Loading

@Dinnerbone
Copy link
Author

Dinnerbone commented Apr 19, 2012

Good point. We can easily load from one and split at runtime. Not sure how well that'd go with backwards compatibility - it's one thing to change a file, it's another to delete it. People would probably go crazy wondering why they can't IP ban anyone.

Loading

@erisdev
Copy link

erisdev commented Apr 19, 2012

@Dinnerbone Ha, I hadn't thought about backwards compatibility. A pretty simple work-around would be to load and interpret banned-ips.txt the same way you load banned-players.txt, if and only if it exists, but never create or write to it. Maybe add a comment to the top of the file noting that it's deprecated if it does exist. Remove the backwards compatibility code a couple of major versions down the line.

Loading

@JoneKone
Copy link

JoneKone commented Apr 19, 2012

... an archive list? That leaves all the entries in the list. For future reference if somebody pardons somebody, it should leave some mark that this guy was banned before.

Loading

@credomane
Copy link

credomane commented Apr 19, 2012

Allow for the unban time to be "+#x" which would be easier to specify times in the future. It would be nice to support this in the file but I think it should be supported by the console commands at least. Having to specify a complete timestamp would suck.

I'd make sure the "+" is required to be detected as this time format for easy detection.

"+#m" = minutes
"+#h" = hours
"+#d" = days
"+#w" = weeks
"+#y" = years
I wouldn't worry about months but if you want to add them.
"+#n" = months

For example:
"+3d" would unban someone after 3 days.

[edit]
The whitelist incorrectly mentions "banned" in the description for the "comment" field. Is also incorrectly calling it the "For" field and not "comment". Minor copy-n-paste mishap from the banned-players.txt file I think. :)

Loading

@keir-nellyer
Copy link

keir-nellyer commented Apr 19, 2012

This is really cool! Looking forward to this!

Loading

@taesheren
Copy link

taesheren commented Apr 19, 2012

Whats wrong with using a single whitespace as seperator? None of the fields contain spaces, except the comment which is last.

Concerning the ban lists: I don't know about the backwards compatibility but for usability one file, called banned-players.txt, is better than two in my opinion. Just include a comment in the head of the file with some examples using names and IPs.

Loading

@credomane
Copy link

credomane commented Apr 19, 2012

@taesheren
Whats wrong with using a single whitespace as seperator? None of the fields contain spaces, except the comment which is last.
Everything. Absolutely everything. A space is way too common of a character to be using as a separator for any reason, ever.
As a matter of fact, the space is so common that the date fields contain two spaces each!
Also, the method that will be used to split the lines will explicitly truncate anything beyond the specified limit. While this limit is optional it would add a lot of needless code to use a space as the delimiter. The "|", Vertical bar, Pipe or whatever you prefer to call it is my preferred delimiter in simple (read: dumb) split functions as it is less likely to be seen in the data than other easily typed delimiters, in my opinion.

This is the function that the line are being split with:
http://docs.oracle.com/javase/1.4.2/docs/api/java/util/regex/Pattern.html#split%28java.lang.CharSequence,%20int%29

Loading

@ToastedJelly
Copy link

ToastedJelly commented Apr 20, 2012

Why not use a TAB as a seperator and (maybe) let people use a TSV/CSV parser? And prevent Tabs in comments.

To preserve Comments as extensions for mods isn't easy:

  1. List will be stored in another order in memory for performance reasons
  2. Peoplw may put normal comments in there which don't belong to an entry
  3. Possible Multiple Comment lines in front of an entry makes parsing and saving back complicated.

And I assume you want to completelly rewrite files sometimes or do you just append and read and ignore old entries for temp bans etc. (free history)?

How about letting Mods append as many TAB-seperated values after the comment as they want and recommend this format:
ModName.1.0:XXXXXXXXXXXXX
XXXX cannot include tab, but can be csv or comma separated name/value pairs etc.

Loading

@erisdev
Copy link

erisdev commented Apr 20, 2012

Honestly, I think if a plugin wants to store additional metadata about a ban, it should be done elsewhere—and using a more suitable data format. Trying to shoehorn rich metadata into a simple human-editable file is silly.

Loading

@ToastedJelly
Copy link

ToastedJelly commented Apr 20, 2012

@erisdiscord
Amen to that.

Loading

@ericpauley
Copy link

ericpauley commented Apr 20, 2012

@ToastedJelly What he said... SQL all the way!

Loading

@ericpauley
Copy link

ericpauley commented Apr 20, 2012

Also, why store it in human readable format at all? Just give admins all of the commands, and store it in a database, where everything should have been stored in the first place. Also, I hope that a suitable replacement for EBean is procured for the official modding api. I don't want to write a lot of SQL code, but I don't want to deal with EBean quirks either.

Loading

@erisdev
Copy link

erisdev commented Apr 20, 2012

@zonedabone bans are part of configuration, and configuration and logs are two things that should always be human readable IMO. Relational databases are great for storing relational data.

Loading

@Screwtapello
Copy link

Screwtapello commented Apr 21, 2012

Representing timezones as strings ("CEST") is a bad idea, because a given string does not uniquely identify a timezone (both Australia and America have an "Eastern Standard Time", for example). Also, time zone definitions can change as laws are passsed. Much better to use the +HH:MM syntax; see "time-offset" in RFC3339.

Loading

@SamP20
Copy link

SamP20 commented Apr 21, 2012

This is good for a default implementation. What we need however is the ability to replace any component of the engine with our own. For example if we wanted to store the banned playerlist in a database then we would write a plugin with the appropriate component, and get it to override the default implementation. Ofc it could be done with events too, although imo this is far more efficient.

Loading

@ericpauley
Copy link

ericpauley commented Apr 21, 2012

Loading

@Surfjamaica
Copy link

Surfjamaica commented Jul 27, 2012

Wait, so if the ban message contains commas, it won't screw it up? It just looks a bit confusing, though.

Loading

@credomane
Copy link

credomane commented Jul 28, 2012

@Surfjamaica Nah, the line is split into 5 parts. The ban message is always the last part so no matter how many commas the ban message contains it will be fine. Read this javadoc http://docs.oracle.com/javase/1.4.2/docs/api/java/util/regex/Pattern.html#split%28java.lang.CharSequence,%20int%29 It is the very piece that is being used.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment