About uncovery

Owner & admin of this server.

Blog registration & changing usernames

As you know, we have been using the blog for whitelisting for quite some time. With the changing username, there are 2 issues coming up:

  1. If you change your username and comment on something, nobody will know who commented, since the name in the blog will be different than in-game.
  2. If you abandon a username, someone else can pick it. But they won’t be able to whitelist here, since someone else who does not use the username in Minecraft anymore, still uses it as their log on the blog.

to identify users, I already store the new UUID in the wordpress table, so I can link a website user to their minecraft persona, no matter if the username in the game changes.

So to fix point 1., I have to make sure that the username shown in the blog stays updated to whatever your in-game username is. The good thing is that there is a so-called “Nickname” on everyone’s profile. If I manage to prevent users from manually changing it, I can update it to always show the username that the minecraft profile has.

To fix point 2. I have to either allow users to register with ANY username and ask them for their current minecraft username and store that one along with their UUID for identification, or I have to set their username on the website to their UUID. Since it would be quite annoying to register and login with the UUID since nobody remembers that 36-digit code, I would have to change the login and registration pages to ask the users for their current minecraft username and lookup the UUID with the code to fill their login-form automatically. While this is cleaner, it also seems more complicated.

The good thing is that the solution for point 1. has to be done in both cases to solve 2., so if I fix that one, it would a good step ahead to solve the issue. This is why I asked the question here, and hope to get an answer soon. To all those who currently set a custom nickname on the website, sorry but that will go away.

 

Big, [not so] bad news: Bukkit is [not] dead. What next? [Update]

This is developing fast. Updates are underlined.

Please read this here. Essentially it means that the platform on which our server is running, will not be developed further by the original team. What does this mean?

  • We will most likely not be able to upgrade to 1.8
  • We will be able to continue running with what we have, but for the time being, but there will be no updates, no changes, no new versions of the game. No new blocks, no new features. It’s a 100% standstill.

The only valid option for us to work with future versions of Minecraft are the following:

  • Someone picks up the work and develops the code further, despite the issues about licensing that is described in the article above. There is still the spigot community, but they have only worked with an optmized bukkit code, and it’s questionable if they will be able to pick up the additional work that is not done anymore by the bukkit guys (Twitter says they won’t Sorry, misread that, they will).
  • Mojang takes over the Bukkit work and makes it available under a proper license, since there are only very few servers that actually work without it. (seems that this is a valid alterantive as we can see here and here)
  • Mojang finally releases a proper plugin-system which attracts the most important developers that make this server what it is, namely the creators of Websend and Worldguard to work with it. The risk is however that the gap between the end of Bukkit and the first proper native plugin-system for Minecraft will be so far apart that the plugin devs stop working and do not pick it up later anymore.

The main problem finally is that the biggest features that make this server run are the lots and the custom code that we have on the server. Without the protected lots and the work that I put into the system the server basically boils down to a vanilla minecraft server where the only protection that we have against idiots would be a tough whitelist test – all using a manual whitelist approval instead being able to automate stuff.

What will I do?

Well I will keep the server up and running as long as possible. I put 3 years of work into it and will not just drop it like a hot potato. But I will slow down/stop the work on preparing for 1.8 for the time being until I have a reason to believe that there will be actually a possibility to ever get this version.

Seing the mojang team will take this over, there is a high chance that this will continue. The question is if this will speed things up or slow them down. So far, so good, we will see what happens. Please continue building. Nothing to see here.

Settler Application improvement

I made the Settler test even more fool proof user friendly: It seems that some users could not find the radio button on the lots to select a lot. Now, instead of having to click on the radiobutton, you can click anywhere on the lot to select the radiobutton.

On top of that, the “next” button on the top changes to “Choose lot EMP_A1” or whatever lot the user chose. I hope this will reduce the questions.

Some progress

I now converted the donations, the stories, the banned users, the whitelist, the Unc-accounts and the karma system from usernames to UUIDs.

Further, I implemented a cascading system that tries to retrieve UUIDs from 4 different sources for a user, namely the blog-registered users, another database to store new users, todays logfile (it registers the UUID of every user that even tries to login on the server, stuff found there is then written to the previous database for later usage) and if all those fail, tries to get it directly from Mojang. I needed to do this since I now need to have the UUID even before the user is registered and if I go directly to Mojang too often, they block me for 1 hour.

There are still a bunch of items left that I need to convert to UUIDs, but there are 2 main plugins that I use on the server (logblock and worldguard) that store important information and so all code that I write right now has to work with both usernames and UUIDs.

I will have to wait until those two are updated and then change all the code accordingly. I assume this should be all feasible before we would be otherwise able to upgrade to 1.8, so this item should not be delaying any upgrades.

The same procedure as every year

So since the time of the year is around the corner again, I would like to make some statements for the uninitiated during the festive season of looming server upgrades!

  • When will we upgrade? As soon as we can. First 1.8 has to be released. Then, all the vital systems that other people have to upgrade (spigot, plugins) have to be enabled so we can run the server with the vital functions at least. Whatever does not work then that is not 100% needed, will be disabled and enabled once it works. Then, I have to make sure that all the stuff we customized for the server works fine. Since there is this massive upgrade from usernames to UUIDs, it might take a bit longer.
  • How long will that take until it’s done? No idea. It depends on other people most of all (see bove), and on the time that I have. So don’t ask me. It’ll be done when it’s done.
  • Will you reset any worlds? Only the Darklands. Everything else will stay as it is.
  • Will there be a temp server to check out the 1. features? No. There will be no temporary server for 1.8.

New Citizen status regulation

We had repeating cases of users who registered and never came back for months. Then, they would show up again, after having spent no time on the server at all, and become Citizen status immediately. To stop this issue and on top of that reward people who are online a lot in the first weeks after registering, we have now a new way to determine when someone becomes Settler: After they have been online, in the game, for more than 60 hours.

As before, you can see how far you are to become Settler on the sidebar Server Status box. It will show now the hours you have been online, and if you are Settler, how many more hours you need to become Citizen.

I am convinced that this is a much fairer way to determine who should get Citizen status and therefore benefit the community. Users who reached Citizen status already will not be affected by this change, only existing and new Settlers.

Newly promoted Citizen because of this scheme are:

  • stephdeg
  • kaizlin
  • allicrev
  • beau1201
  • wickedXxxxlego
  • Papa_Jynx
  • gamergirlxoxoxo

Congratz!

Oh, yes before I forget, the idea was from pinebenj! So if you had your upgrade delayed because of this, make sure to throw a cake a him :D

Hunger Game revival

AS you know, we have not used the hunger games for a while. The issue was that we always used a new world to do them, but regenerating new worlds while the server was online proved to be very difficult and often either failed or crashed the server.

So I now had a new idea how to do that differently that might be easier to do:

I can generate a worldguard region (the same system that we use for lots) that has an entry/exit flag set. This would disallow anyone who is inside to leave it (except when they die) and anyone outside to enter it. What we most likely cannot do is to shrink the region over time as we did with the other system, but still it would be a proper hunger game – in the darklands. We would pick a random spot somewhere some million blocks out and create a region, set the “no exit” flag and then, when everyone is inside and the game start, we set the “no entry” flag and we are set.

I will have to go through the code of the old system and see what we can recycle. No ETA yet, but I just tested the flags and this seems quite easy to do – much easier than the old system for sure.

Darklands Challenge, anyone?

I have been thinking it would be fun to have a darklands challenge:
You buy a “ticket” for some Uncs (how many, that’s the question) and the system would teleport you to the darklands, but very, very far out (i.e. 200k blocks+). And your challenge would be to try to come back.

Anyone interested in that? If so I could make that, since it’s not difficult. But I would like to hear everyone’s opinion first.

New Shop Manager!

In an effort to further streamline and simplify the website, I have now created a shop manager, similar to the lot manager. At this moment this includes only the personal shop & deposit pages as well as the help informations for shop and deposit, but will eventually grow to host a much more versatile, 100% recursive database where any information can be called through one interface and replace the pages related to the shop in the “Features” menu.

There will be also a revamp of the main menu once the current shop pages in the main menu are removed to make navigation simpler than it is today.

Go-Go Usericon Gadget!

Since I had some quite frustrating day yesterday preparing the server for UUIDs (the server was down for over 1 hour) I now dropped into a more rewarding gadget-frenzy and added a list of usericons to the frontpage that shows all users that logged in during the last 49 hours. The colored bar next to them shows if they are still online or not, and hovering above them shows when they have logged in last time…

have fun!

Code speed-up

I made the userlist now use UUIDs instead of usernames, and now it loads in a few seconds instead of half a minute.
I also optimized the code loading the 2D map, and that one should now also load in 5-7 seconds instead of 20-30.

Yay!

Preparing for 1.8

I have worked in the past months here and there to prepare for the rough outlines of 1.8 by introducing a table of UUIDs (long series of numbers and letters which will replace usernames in the code) and block names (which will replace block numbers).

So far the backend of the whole thing works, and I have the new data for pretty much everything and everyone. The issue however is that the code still uses numbers for blocks (in the shop for example) and usernames to identify people (pretty much everywhere). It is time now, with 1.8 coming, to end that.

So right now I am going through the whole code form top to bottom and change every time where someone is identified with a username to their UUID. At the same time, I have to go through all the tables, add a UUID field, populate that with the UUID that matches the username in the line and then change the code that calls the table to use that new UUID field. Then I can remove the username field from the table.

The biggest advantage of this is that I do not have to deal with differently capitalized usernames anymore: Users used different capitals in-game than when registering on the blog. Some plugins who use tables use capitals, others do not. If I am not sure if 2 tables use the same methods, lookups between two tables have to be done with a “IF a LIKE b” instead of “IF a = b”, which is much, much slower. For example, the fact that the user list takes more than 30 seconds to be generated, is because of this issue.

So expect some small bugs while I am working on the code :). It will probably take 1-2 weeks, depending on what comes up.