ReportRTS
Development builds of this project can be acquired at the provided continuous integration server. These builds have not been approved by the BukkitDev staff. Use them at your own risk.
Commands & Permissions | Follow my progress on Trello | IRC: #ReportRTS (irc.esper.net)
ReportRTS stands for Report - Realtime Ticket System, it is designed to be a easy to use and feature rich support system.
Features
- Supports multi-server setups using BungeeCord.
- Uses MySQL, this allows you to easily display information from the database.
- "Caches" open tickets to reduce access time.
Usage
Notes
Metrics
To determine popularity of versions, features, and lingering usage, plugin installs are automatically tracked by the Metrics plugin tracking system and forwarded to mcstats.org for analysis. Basic server information (Version, player count used) is tracked. If you don't want to help or are paranoid, edit plugins/PluginMetrics/config.yml and set opt-out to true.
UUIDFetcher
Does not collect data at all. Simply used to retrieve a player's UUID from Mojang's API if he does not have one in the database prior to ReportRTS version 1.2.0.
Version checking
By default ReportRTS checks dev.bukkit.org for ReportRTS updates, you can disable this by setting versionCheck to false in the configuration.
Developers
Maven repository
<repository> <id>projectinfinity-repo</id> <name>ProjectInfinity repository</name> <url>http://ci.regularbox.com/plugin/repository/everything</url> </repository> <dependency> <groupId>com.nyancraft.reportrts</groupId> <artifactId>ReportRTS</artifactId> <version>1.2.3</version> </dependency>
Support me!
Why support me?
All the more motivation to continue work on this project. During it's two years of existence I have received a total of $270 and promises that never saw the light of day.
Say if I have spent a total of 500 (this is an example number, in reality it is much higher and just keeps increasing) hours working on this project. That gives me a total of $0.54 an hour, compare this to the average wage of a McDonalds worker in the US which is $7.81. Had they worked 500 hours they would have made $3905.
If you find that this project has helped you, please consider donating to this project.
@ProjectInfinity
you mean change the charset in database? but they are already utf8-default on both schema and tables, any other clues? how about the plugin side? any configuration I can set to utf8?
@chaseoes
Disable VanishSupport in the config.
Also wanted to point this out: https://github.com/ProjectInfinity/ReportRTS/blob/master/src/main/java/com/nyancraft/reportrts/command/ModlistCommand.java#L26
Edit: I derped your question, ENABLE VanishSupport in the config is what you're looking for.... Right?
Can you add a canSee check to /modlist? My players are using it to tell if a staff member is invisible or not (since they're hidden from the tab list etc).
@kalijason
And Chinese does not work either in game? I'm using utf8. I don't know if there's more I can do. You can experiment by changing the charset used and file new requests and see if they are stored correctly.
@ProjectInfinity
http://www.tiikoni.com/tis/view/?id=9671493 please check this screen shot, they are chinese in the comment
@kalijason
Unfortunately I don't know what the problem is. Could you take a look at the database and see if the characters are stored correctly?
Hi, I'm from Taiwan and running a 1.7.2 R03 server with mysql
I just met a problem that user try to /modreq xxx xxx xxx (xxx contains chinese words) and everything works normally, but after I /done the ticket, all the comment becomes "??????", any ideas? mysql encoding is set to UTF-8 and i'm on linux with UTF-8 encoding
@PhanaticD
I have found the issue, exactly why it's failing where it is, is still unknown and unfortunately still put on hold until UUID is done. But at the very least we know where the fault lies.
@TheBoomer
I have gone far from overboard with the update, in fact I have many places not even used UUID. The only UUID related changes are all related to storage.
I will never look up usernames using mojang's website as a normal thing, so do not worry about that. I was considering releasing a standalone ReportRTS data migration JAR that you just run on your server outside of Minecraft. The plugin would still add UUID fields to the DB, but it would not go through the hassle of checking Mojang's site for names.
I think a lot of devs get hung up on "the name of now" concept and "we must have an accurate, 100% totally representing this slice in time in the real world" representation of uuid/names that end up being the focal point for 'I have to do a bajillion lookups to get the accurate information for offline players" etc...
Realistically, it shouldn't matter if Joe101 logs out, changes his name to Joe102, and Bob then changes his name to Joe101 and we want to now do something like ban Joe101, pay his account money, or such. Most of what we want to do applies to the account we knew as joe101 when he was last on the server, we dont need to know that his current in real life name is joe102 even though he hasn't logged on (cause if he had, that nulls the complex scenarios folks dream up anyways). We have no intention to care his name is currently Joe102, or nor do we care that the uuid of Joe101 does not at this very second match the uuid cached on the server, but, instead really refers to old Bob now.
I've seen a lot of fancy "must be user friendly" scenarios like "so then their friend Carol, who knows both of those players in real life, owes 'Bob' money, and knows that his name is now Joe101, so Carol is told in real life to login and to pay Joe101 (bob) the money in game so there's the world-exploding process, since none of the accounts has yet logged back into the server following these namechanges. Do a lookup on the name argument every time to get realworld-now, and its now paying an account that belongs to bob, 'properly executing the wishes of Carol' (meanwhile, 20 other players who dont know about these real life namechanges are paying Joe101 money expecting it to go to Joe's account, which will be Joe102 as soon as he logs on aka, their wishes are cast aside) So you go the other route, and any player paying Joe101 is putting money into that account of Joe, except for Carol, who has now accidentally payed Joe, and not real-life Bob, because of extremely rare circumstances in which real-moment knowledge of truenames and account ids, real-moment impacts of various players not having logged in since changes, and real-moment combinations of namechanges lead to one extraordinary conflict of the 99.999% scenario, which is to simply refer to the offline players by their id known on the server as of that moment. Its easy to dream out complicated scenarios in order to 'plan an air-tight system' but the reality is we have to be able to separate realtime-now away from ie typos, and focus on 'how is this uuid/name lookup relevant to the server. Just cause joe, bob, and carol had a convoluted system and carol accidentally paid the wrong person, doesn't mean that the world ends - yes, its a 'malfunction' in 'their reality' but it doesn't open a singularity in the server-reality, nor require exhaustive work-around code to address - Carol's action gets addressed as a goof, but only because it is the players faults who are involved, telling Carol to pay joe101 to really pay bob, without having the decency to login and establish this new fact with the server.
{Hopefully Bukkit will deal with the fact that bob's logging in as Joe101 would conflict with the earlier Joe101 being invalidated, and be so kind as to update the prior Joe101's records for us to now reflect Joe102 ... im sure it will }
Same as I would rather make a typo when executing a command on a playername on my server, misspelling FiddleDiddle as FiddelDiddle, and getting a 'no such player on server' response, rather than 'oh no, a name that doesn't match known identities here, I better go and see if anyone in the world has made such an account name, and yes, someone has, so here is the uuid of that player who has 0 relationship to the server except for that slight typo in the name, so now time to create a profile for them, make a bank balance, and give that person the $20 from this command..."
So other than the "one-time" migration effect to go names to uuids to update the database, a lot of the real-world-now-expensive-website-lookup processes shouldn't really exist.
event.getPlayer() will still return the now-player doing something, always, with names and uuids both ... I've seen folks scramble to then figure out how to take this event-handling by now-player-right-here and deal with doing lookups to get the real at the moment name, etc, etc.. .hasPermission("x") will still work against that player object ( with a lot of faith in the permissions handlers to come up with their solutions for keeping the group/permission/player stuff sorted correctly )
It is easy to get stuck in the mindeset of having to jump in and pull out almost all the wires 'cause we gotta replace em with fiber optic now!' and I've suffered some 0 productivity evenings just staring at one of my plugins trying to comprehend everything that needs to go... until the shock wears off and all the 'must deal with users changing names 3 times while offline and not having been online since two changes ago, and another person with that name now has it but hasn't logged in yet either' ..crap.. thinking can be cleared out of the way, and then how it impacts "THIS" plugin function is a lot more clearer.
Half of my own plugins also would be so much easier to wrap up as done if I were to wipe my server clean and start fresh with them, they'll work beautifully forward in time, but its that between now and when the systems have migrated to become that day zero that is getting to me. Fortunately, I only have myself anxiously waiting for me to finish those plugin upgrades...
But yeah, some issues require a whole new way to key rows in tables, changes that can be small or major, depending how you need/decide to have a key identifier (like some of mine that will be using uuid+name pairs as an ID in a new table to cross-ref the data, instead of just changing name to uuid in the main table, etc...)
Best we can do is not dive in ripping out wires but instead, think about which ones are required or benefit from modifying, and once we have an attack plan... sleeping on it a day still ;)
@TheBoomer
Thank you! Unfortunately it isn't as easy as you think, lots of classes are having to be changed and some are just causing me to scratch my head while thinking "How the hell am I supposed to solve this?".
It is coming along nicely however and I hope to get a dev build up soon so it may be tested (I would expect names/UUID to be a little wonky as I haven't decided yet if I should stop sending names altogether or just send UUID and retrieve names from server every time, the latter does sound a little bit excessive).
Now you're almost up to 20 cents per hour. Been using over 2yrs now, appreciate having it.
UUID incorporation not difficult, UUID migration... PITA...
At least yours can wait until its done and is independant (too many economy-cross-releated plugins that have to be all go at once...).
@PhanaticD
Been unable to check for it.
I am currently working on the UUID update which requires a fairly large rewrite and a migration plan (sigh).
@ProjectInfinity
any luck? this is a very annoying bug
@Tallcraft
Awesome, thank you!
@ProjectInfinity
Thanks for your ongoing support! I've been using this plugin since ever; one of the most important components for my server. Used that fancy paypal button. Not much, but better than nothing to show some support. ;)
Currently working on the transition to UUID as opposed to usernames. Other bugfixes/features are put on hold until then!
@PhanaticD
I'll see if I can replicate the issue.
finally using this now ur build server is back, tpid no longer seems to teleport you to the modreq location after switching cross server
@Tendonsie
I responded in your PM.