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.

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.