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!


Today’s development updates

Posted on by

This is a daily update on the status of the work done behind the scenes.
Our webserver is completely open source, hosted on GitHub. You can help improve the server by fixing issues here.

Bug reporting / Bug bounty

Posted on by

I have just discovered that there are several things broken on the server and nobody told me about it. I doubt that nobody has realized those so far, so I have to assume that the people who saw the issue either assumed I know about them or made the decisions not to tell me for one or the other reason.

I would like to put a message out there regarding those bugs:

PLEASE TELL ME WHEN SOMETHING BREAKS!

Please do not think that I am busy and should not be bothered! I can manage my time myself. If you tell me about a bug, I will make my own decision when to fix it.

In order to encourage bug reporting, I want to introduce a bug bounty program. Essentially I will put all bugs that are known into the GitHub issues page and if someone reports something that is not in there yet, I will give an award. There might be several tiers, depending on the severeness of the bug.

Please tell me what you think can be good rewards for bug reporting that encourage people to report stuff but are not so generous that they break the in-game economy.

Lot regeneration decision

Posted on by

So I just now ventured into a snapshot of the 1.13 version and generated a world with the same seed as our Empire. The world looks pretty much identical to ours. I think the main differences are only the ones which are already introduced before 1.13. There are however some upcoming changes that are planned in 1.13 which are not active in the snapshots yet, such as Magma blocks in underwater ravines and coral reefs in ocean biomes.

So since the 1.13 is generally quite similar but introduces some changes, I made the decision to wait with the regeneration of the empty empire lots until the 1.13 release so that we get those changes as well, specially because the rest of the world will most likely fit in 100%.

If the edges between occupied lots (which will stay the same) and empty lots (which I will then re-generate with 1.13 version) will be seamless, I will consider to do the same for the kingdom, possibly also Aether.

We can consider regenerating the darklands as well, specially to have the corals more accessible, but I am not 100% decided on that one yet. I will first do the general server upgrade, then the empty lot reset and then we can decide if it’s worth it to regenerate the darklands as well with some time to prepare for it to salvage existing structures such as rails etc.

Hope that is fine with everyone.

Version upgrade preparations

Posted on by

Dear all,

as you have seen in one of my previous posts, there were worries about the next version “breaking everything”. The issue was that a change to the way blocks are named (which has been implemented already a long time ago) would be enforced and the old naming scheme removed from the code. The worry was that a lot of plugins might break then because they were not updated at the time.

It turns out now that the spigot team (who make the adaption of the vanilla minecraft server that we use) have implemented already a mitigation to the changes that were done in minecraft to keep old plugins working. While I did not test anything yet, I think we can stay reasonably calm and looking forward for the new version to not have too many issues.

Further, as you might have read on Mojang’s news, they delayed the next update to roll it together with the one coming after that. The new update will then include new water mobs and more. So there is something to look forward to! Unfortunately, as usual, there is no confirmed release date for the next version, I am assuming something like April/May or similar. Let’s see.

However, there is the question when we will change the empty lots in the empire (and possibly also in the Kingdom). To remind you what this is about: Normally, we only re-generate the Empire lots when there are REALLY significant biome/block changes. The kingdom was on top of that never meant to be re-generated since it’s purely for building, mining and landscape there is secondary. However in the last updates that introduced Andesite, Diorite etc, the underground environment changed, but the landscape did not change too much – if at all. There is therefore now the opportunity to re-generate the empty lots in those worlds so that the underground generated according to the current minecraft version, without creating nasty breaks in the surface, landscape and biomes above ground. We could also give the opportunity to lot owners to reset their lots as a one-off feature.

The choice there is to do that now, once, or to wait for the next version to be released. We can then check if the new version generates a completely different landscape, in which case we have different decisions to make.

So what is your opinion? In general, we can always wait for the next version – and then therefore never change anything. On the other hand, we want to avoid excessive changes and workload if it’s not needed or wanted.

Elder voting process changed!

Posted on by

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

Posted on by

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.

Opinions?

 

Server outage fixed

Posted on by

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.