I’ve seen quite a few requests for getting an image of the battlemap. So here is it, free of any attackers. Feel free to use it for your battle planning.
However be warned: Sometime with the upcoming releases, we’ll introduce custom maps for each fort. Then the map will be layouted depending on the fort size and the building levels.
Since the introduction of fort battles, the players have developed a strategy to weaken the enemy by letting low level players join the opposite side. While this is a quite valid strategy, it is still nerving and not wanted. As a result we made a decision at the end of the development of 1.21 to pull a feature that we wanted to have in 1.22 into 1.21: The mustering page.
Since this feature got in so late it is not so well tested and the user interface is initially not so obvious. So let’s explain it here shortly:
When you are a member of a directly involved town (means the attacking town or one of the fort members) and you are a councilor or a founder of one of these towns, then you are allowed to muster the troops that are joining the battle. You will see the recruiting button once you are taking part in the battle (so you have to join). Then the screen shown above is opened and you can see everyone who has joined the battle already.
By clicking now in the status columns in the cells, you can give players a star or a red cross. The star means that this player has precedence to enter the battle. If the player has a red cross it means that the player will only allowed to join the battle if there is still space left in the battle. You can also remove a precedence by toggling the cell again.
Once you have changed the status, you will notice that it turns orange. This means that you have modified your list, but it is not yet sent out. To do that, you click on “muster” or, if you think you do not wish to change anything, on “cancel” so that nothing is changed at all.
You will also see who has changed the player’s precedence rating, so you might spot people who shouldn’t modify the status of a player (i.e. spies). It is of course possible that a member town has a spy that modifies the list to the attacker / defender’s favor right before the battle starts, but well, you should take care who you promote in your town or who you invite…
A minor addon to this feature did not made it into 1.21 yet – since such a spy could do such a change in the last moment before the battle starts, it would be quite hard to make out who changed the rating of the players. In order to keep this information, it’ll be sent to all players that are taking part in a battle. But this feature is not yet in 1.21.
Today we decided to open the gates again and let some of you join the public beta to experience new releases and help making the game better. Moreover i wanted to remind everybody that the public beta is a sandbox where we want players to test and try stuff out and report us the bugs and ideas.
Ah, almost i forgot to tell you about when we will open the doors 
Proposed date: Fr, 07. Aug 2009 around 13:37
New limit: ~ 2500 (raised by 500)
I wish you all good luck
We have updated today the beta and a few additional smaller feature leaped into 1.21.
Fortbattle rule
First, there’s an overview on the rules for a fortbattle. That should clear any doubts on how the battle is being judged and when it’ll be a loss or a win. If we change anything in the future, i.e. the number of rounds that a battle takes, this will be automatically shown in this fact sheet.
Then there’s a still-to-be-improved feature that shows which towns are fighting on which side:
List of defending towns
In this case, you can see which towns are defending the town already. That list includes the main defenders (fort owners) and also every town that has at least one member having joined the battle already. Picking the right side should now be simpler.
Last but not least, there’s a security feature that should greatly help you to identify attacks on your account:
Login attempts are now shown when you log in.
By the time, most of all wanted features are now on the beta. 1.21 is running quite smoothly and we are looking forward to switch to 1.21 once we consider it stable.
A feature that still needs some tweaking is the XP gain for battle participation. But we should be able to fix this till the end of the week.
The gravestone overview
We are updating the beta world to 1.21
Maybe some of you already know this bug, but it has not occurred too often so i will first tell you the beginning of the story. After rolling out the fort battles globally and some times has gone, we got some reports about hanging fort battles. The times goes down to 0 seconds and then the game just hangs. The next round will never be toggled and because of this nobody could move anywhere not only inside the battles but also outside the battles. So this was of course a serious problem. Indeed we had already set up some nagios monitoring scripts that told us just in time when a battle began to hang but we were forced to restart the java server (that seemed to work so it was something non-deterministic). And as we already blogged, there is currently no journaling implemented so a restart of the server equals a complete battle reset. Don’t worry: I’m currently working on the journaling 
We can proudly announce that the bug with hanging fort battles should be fixed now. Because of the fact that it was a non-deterministic problem, it was really pain in the ass to find it, but that was more because it was some kind of “nested problem”. First at all we looked the logs up, we searched for any kind of suspicious entries but we don’t found anything suspicious and that surprised us a bit. First at all we guessed its a deadlock, so we watched out for blocked threads. For all those who don’t know what a “deadlock” is, just take a look at the picture on the right and then it should be bloody clear
We invested some time on trying to reproduce this bug, but without any success. So we had to wait until the symptoms reappear on one of the running daemons to perform some checks and trace analysis on the running application. We thought with our monitoring tools this should be no problem, but it was the opposite. Every time the monitoring notified about a occurrence a sys-admin was faster and restarted the server so it was already running when we logged in After notifying those to not do anything so we can perform our analysis then problem don’t wanted to reappear for quite a time.
During this time we have already implemented a Watchdog that checks for deadlocks or deadlocked monitor periodically in the running application. And then the long awaited moment came, just after we restarted some of the java servers because we made a quickfix update, we got two crashes at the same time. First thing we did was calling the sys-admin staff and remind them to not do anything, guess a not too exhausting wish We were pretty sure to grep some messages in the logs about deadlocks, but what do we see? Yes, nothing! 
This was in fact strange, so I used jstack to get some information about the current threads, states and whose stack traces but the output affirmed that no thread was deadlocked, so: WTF! So by painfully going manually through the code, tracing what the issue could be, we got the right suspicion about the problem, which was then confirmed by staring at the server screen: the master thread was not there, not running, nothing, so it died. But WTF: This should be logged so something is really messed up. But sometimes the easiest solution for this behavior is the right one: This was never written to the log file and indeed, after checking I found out that the stderr pipe was not logged so i fixed the init script (with some kind of sub-shell piping) and we ended up with some ConcurrentModificationException. This was exactly the opposite of what we guessed at the first point, we had no deadlocks, we just didn’t synchronized enough
Shortly we tracked down the problem (thanks to the now existing log entries) to just one small block of code that we now synchronize and the queasy adventure ended abrupt. But hey, just look at the good part:
The flash client for the fort battles has been developed in an extremely short time (compared to the rest) and due to this, it is not as efficient as it could be. I fixed the worst issue in the drawing algorithms of the client about 2 weeks ago: The sectors.
Sectors and onlinestate of players
The reason was the algorithm of how the sectors have been drawn: For each cell, the algorithm checked the borders of the sector, and if the cell is next to different sector, a border is drawn on that side of the cell. So this check was done 4 times for each edge of the rectangle and for every rectangles on the map. This is a stable and simple approach, however, also one of the slowest approaches.
In order to fix that, I changed the approach of drawing the sectors: Instead of checking each cell one by one (about 600-700 cells), I wanted to draw each sector one by one (there are about 50 sectors). Therefore, I needed to determine the sector boundaries at first. This can be done ahead of time when the map is loading, so that algorithm for detecting these boundaries can be somewhat complex as long as the description of the boundaries can be easily used afterwards. Detecting the outline is in general a simple algorithm – also known as left-hand rule [1]: If you are in a maze and you want to find all possible ways, you can simply stretch out your hand and keep it on the wall. That way, you are traversing the complete maze – at least if it is an ordinary maze. Though this excludes mazes where there is a center maze where the walls are not connected with the walls on the entry of the maze, but for my problem, this doesn’t matter.
Actually, I tried at first a much simpler approach even, but that would have worked only for convex sector shapes, and we have a couple of concave sectors (If you don’t know the meaning of concave and convex, you might look it up here[2]).
I find graphics programming often very nice because even the bugs can look pretty:
Wrongly implemented left hand rule
So what went wrong here was that my “left hand” left the “wall”. Quite wrong. After a while the result looked like this:
The correctly found sector outlines
Which is looking more correct. It also looks funny because I also used a small trick to detect problems in my border tracing: During the implementation it happened, that my algorithm did not notice that it traced a part that it had visited before, so my border description contained redundant information.
To see these multiple lines, I drew the outlines with random vector offsets at each point. This gave the output such a scribbled look. You can also see that way, that I already stripped the points away between the corners – if a line stretches over a couple of cells, the initial algorithm would record points at each corner of the rectangle. These points are not required to draw the sector, so I tweaked the algorithm to reduce the amount of drawn vertexes:
Removing the unneeded points when drawing a straight line saves time during drawing.
If the algorithm had still these unneeded points, it would have become visible when drawing the outlines with random vector offsets.
The performance win of this improved technique was not crucial but in deed measurable. There are other parts that could be optimized, but as this improved already one of the worst algorithms, this can now wait a bit.
[1]: Maze solving algorithm: http://en.wikipedia.org/wiki/Maze_solving_algorithm
[2]: Convex Hull: http://en.wikipedia.org/wiki/Convex_hull
The global rollout was done without major or even minor problems during the update phase. This pleased us a bit, after the final rushing and some problems we reported about, it was not easy to make a statement. It just can’t be as worse as the 1.18 rollout, but after such experience you never know
After we spent some time to harden the 1.20 release and crush the most casual bugs we now rolled out a hotfixed version. We fixed some user reported bugs as well as those we caught up on our central syslog monitoring tool where every unexpectedly raised exception and error will be logged. Using this technique and fighting against every entry improved the code quality a lot and helps us to get a global overview about whats going on. But now i want to tell you about what we fixed exactly:
But sorry guys, too poor that i guess none of you would ever see this, so here it is:
Don’t be fooled by this screenshot – we banned more than just one playerDue to a recent ugly take over of a town on the beta, we devs have just been busy cleaning up the beta. Seems like a multi took a town and kicked out all other players. We won’t restore ownership of that town, but we got rid of a couple of players on beta now. Apparently we gathered quite a few multis / passwordsharers on the beta – turned out that noone was responsible for that job till now. We are going to take care about that so that our precious development time is not going to be spent on managing the beta world. Although it’s been a quite interesting break. And I guess that some players are now at least a bit satisfied (or not…).
Anyway, I had no experience with banning players, so I took a lesson on how to hunt multis today. Don’t say you haven’t been warned.
By the way, this is not what I was referring to when I was saying that I would appreciate more cheaters on the beta. Multi account, password sharing and stuff like that are still bannable offenses.
And meanwhile … – I haven’t been blogging so much recently because there was not so much to blog about, but I have a couple of topics I am working on… for example the one on “how to cheat”. But that’ll need some time. But it’s on my list, really!
Just a small announcement: We have raised the limit on the beta world to 2000 players.
English