Welcome, stranger!

Please feel free to look around! In order to start building with us, please whitelist yourself. To know more about how to join us, please continue here.
If you are a member already, don't be a stranger and login!

If you want to see what awaits you inside, watch our trailer!

Elder voting process changed!

Ok, so I changed the Elder voting process now. There won’t be a possibility to propose a Master for upgrade anymore if there is another Master already in the queue. As for the current ones in the queue, it seems that there are some vetoes coming in, so we might not need to do anything about them after all. Should there be more than one candidate to promote, I will take the first submitted one only and cancel the others. They will have to be re-submitted then.

Thanks everyone who contributed to the discussion!

Elder proposal issue

Dear all, we have a small issue with the Elder proposals, and I wanted to get your input on this. This is slightly technical so please read through the explanation first:

As a quick recap, our Elder voting system is working as follows: For a Master to be promoted to Elder, all existing Elders have to vote “Yes”. If even one says no, the vote fails. You can read up on the details on the voting page.

This is working fine if one Master is being proposed for Elder, but if we have 2 (or more) at the same time, it gets tricky. If two people get all the votes for Elder at the same time, they are approved on the requirements of the current number of Elders. But since one of them was proposed earlier, the second Master theoretically should also need the vote of the first proposed to get upgraded.

This was not so much an issue in the past where Elder proposals were quite rare, but with the 2 Elders we just upgraded and the ones in the queue now, we have 7 Elders proposed in one month! This will ramp up the numbers of Elders from 10 to 17 in a quite short time. It’s not a problem as such if all the users are worthwhile candidates, but the fact that theoretically 6 people become Elders with a LOT less votes than the next one who will be promoted is an issue from my point of view. In detail that means that the 2 Elders who were just promoted, they both only needed 10 votes of those who were already Elders before them. In fact, one of them should have needed 11 votes. But as the system currently works, they got both promoted in a batch without needing each other’s votes. Now we have another 5 people who need 12 votes, but according to the theory of the system, the first one should need 12 votes, the second one 13 and so on. If all the proposals currently in the system are approved, the next proposal would need the vote of all 17 (then) Elders.

There are 3 solutions to this:

  1. We don’t care. Just let people get promoted without all Elders to approve. If several people get proposed at the same time, there should not be a cascade of the just-upgraded Elders to have to vote for the ones that are still in the queue.
    This is not recommended. It circumvents our base voting system.
  2. Let’s just upgrade the first proposed, let them then vote for the next one in the queue.
    This is technically possible, but a bit tricky. Once an Master is proposed for Elder promotion, all existing Elders get an email asking them to vote. When a Master is promoted to Elder, he does not know (yet) who else is right now being voted on. We would have to let the person know – fast. If this is late in the schedule of the next Elder proposal, the other proposed Master might time out and get denied.
  3. Let’s prevent two Masters to be proposed at the same time. Only once a Master is promoted or declined, the next one can be proposed.
    This is the most straightforward solution. It however slows down the Elder promotions, possibly substantially (up to 2 months). Specially if an Elder is voted down by someone: the system currently waits until the time given expires (which is 2 months) and only then takes the proposal out of the queue. This gives the person who voted someone down the chance to change their mind.

Generally I am for option 3 since it would make the Elder proposal something more special and not something done in “Bulk”. The consequence of this is that I would remove the other proposals and we would wait for one being promoted and then they have to be submitted again.



Server outage fixed

We had a server outage today, thanks to all the users who sent me messages.
I have by now not only restarted the server, but also found and fixed the bug.
There was a mis-configuration in the chat plugin which causes an endless loop when someone used the /tell command instead of /msg.
After weeding through 30 plugins and configurations I found the issue and fixed it.

Happy Holidays and some small news

I am off to another diving trip and not sitting in front of my computer the whole time. I am frequently checking my email however. If there is anything wrong, please send me a message and I will try to fix it ASAP.

I also want to wish everyone happy holidays and a much better 2018 than whatever this year was.

Also, I recently started a small experiment by re- generating the Empire with the same seed. It turns out it pretty much looks identical on the map. That means that (at least for version 12.2) we could update the empty lots in the empire to include all the current stone types that at right now missing, such as andesite, diorite etc.

So some time early next year I will likely replace all empty lots in the empire with new versions and test the same for the kingdom as well. As long as there are no big breaks in the borders between the lots, we should be able to get updated stone types.

I will continue to do those checks and updates for the coming versions as well.

All the best!


Shulker Box issue identified & fixed!

As you might know, we had issues with people buying shulker boxes from the shop. The money would be taken but they won’t arrive in the inventory.
I tried to identify the issue but could not replicate it. So I changed the way transactions are logged in the system and made it log the full command that is used to give items to users.
Then, VixenGold had the same issue again and kindly reported it to me.

It turns out that the issue only comes when you try to buy more than one at the same time. The system refuses to hand over 2 items at once. That is why it worked for some (they bought only one) and not others (who tried to buy more).

It turns out I had a wrong asset-config where I store how items stack. Shulker boxes were registered there as items that are allowed to stack 64 items, in reality it cannot stack at all. Assec config fixed, problem solved.

Some progress behind the scenes

Today I made some progress behind the scenes for the server.

I am using a self made debugging tool that is sending me instant messages when there are errors in the code and debug texts wherever I insert an alert in the code. That system broke some weeks ago when 2 software libraries were updated.

I have been struggling ever since to fix the issue. Partly because time constraints and partly because limited technical knowledge I could not fix the issue. Today I have finally resolved it and the system is back up and running. This is a base fix for any kind of improvement in the server, so that’s great.

The first thing I looked into was the bottlexp command and i might have solved this. I need to to one or two more tests and then we likely can reactivate the command.

I will then try to setup a temp server with the latest development snapshot to try and get a picture of the level of disruption the new version will bring.

Disasters ahead…

Disclaimer: please don’t panic on this post. We need to see what actually will happen before we come to firm conclusions. I want to give a heads-up here to what lies ahead so people don’t wonder why we don’t update to the latest version.

So Mojang just released a snapshot for the next version and described in the changes list that they changed the way blocks are named.

This is a major issue since a LOT of our code is customized to deal.with the current way. A lot of plugins areas well. If this will happen, all item related stuff will break. That means mainly deposit and shop functions but also other huge things such as per-world inventory and so on.

There are several things that need to happen to deal with this:

  • Current, maintained plugins need to be updated, we will have to wait for that (that’s the easy part).
  • Unmaintained plugins will have to be fixed or replaced. This is really tricky since the main one, websend, which we use as the one and only interface between Minecraft and my code is one of those. I am not good at all at Java and to deal with such a fundamental change might be impossible for me to deal with.
  • Then, all my code will have to change so we can deal with the new methods. This is some work, but might be feasible with some effort, but it will take a while.
  • Then, we need to change all the stored information about blocks. For the system to tell you what stuff is in your deposit, it needs tables of data that we at times created together from the wiki information. We have to recreate those tables. Maybe I can write a converter, maybe we have to rebuild it from scratch. Who knows. This can be done as a team effort – hopefully.
  • Then we have to change the databases that store such information. This can be tricky, but if done with care should be over quickly. The problem here is if we can maintain the existing data or if the change is so dramatic that everything will be lost. That would mean that all shop stuff, deposits, historical data might disappear. If the changes are more transparent, I might be able to convert it.

So there you go. The issue here is that the update to the new version might take months just to wait for other plugins to update and then again months for me to re-code everything.

The thing that makes all of this so much worse is that I am right now traveling 3-4 days a week and don’t have the time or energy to take care of such massive changes – if they happen. I will be busy likely until at least April like that. Further, my wife is pregnant again and we expect our second kid end of March where I will be busy for the next reason.

So you see where this is heading. If the changes in the Minecraft code are dramatic, we might not upgrade for quite a while unless someone with either Java or PHP knowledge steps in and helps me deal with the workload.

That said, I base all of this on the change log I linked above. Maybe it’s all harmless. Maybe it’s a disaster. We will see. Please be patient.