New file formats in 1.3

banned-ips.txt

#Address, Date/Time, Banned By, Until, For

#Exactly the same as banned-players, but with IP addresses.

banned-players.txt

#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."

white-list.txt

#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.

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?

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

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!

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.

@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.

... 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.

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. :)

This is really cool! Looking forward to this!

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.

@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

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.

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.

@erisdiscord
Amen to that.

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

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.

@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.

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.

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.

@SamP20 Yes! There should be some system to disable bukkit components in the config and at runtime, and then have enough events to implement it on our own. (Ex. player login events for bans) -Zonedabone

…

On Sat, Apr 21, 2012 at 11:20 AM, samp20 < ***@***.*** > wrote: 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. --- Reply to this email directly or view it on GitHub: https://gist.github.com/2422512

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

@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.