Hey ho 
I currently don’t wanna talk too much about the 1.23 update so i currently just release some pictures showing some new interface designs (nope no new feature previews leaked yet)
new town profile with additional data (click to raise)
new ranking interface (click to raise)
I’ve take care of that the beta server has a fairer premium model that fits a beta testing server. it was admittedly too expensive for a pure testing and beta world. So I’ve now raised the gained nuggets by three, of course only for the public beta world, so please don’t cry
Really sorry all other 
w’re just in the pre-release phase of the 1.22 update cycle. We’ll going to roll it out in the next days.
I just added a nice addition to the signatures. You can now look up the finished quests and got rewards.
We have some new improvements and changed like the sleeper set, that has bonus on sleeping in hotels. Additionally i will now release the public changelog:
features
forts
Hey guys,
We are now testing a new build of PHP 5.3. Please revisit all kind of game features and test+report all kind of problems in the forum (yep, not here please). This helps a lot reducing problems when deploying the new version on the production machines.
I can proudly present you some new series of pictures from the 1.22 release We will add some new game features like the chat (already pre-announced in the last post). Here is a new picture of the current UI. There are different channels where you can talk to. And the best: we will have some emotions and maybe smiles too (of course deactivateble).
Chat UI (click to enlarge)
And now, behold, the holy reward box is coming to YOUR profile We will have rewards in the future that will be spread when you reach some predefined (of course secret and hidden) statistic properties. Each player has a reward box integrated into the character screen where you can select max four rewards that will be exposed in the player profile. But it is possible to look into the reward box of a player, so its only some kind of pre-selection 
Will be very funny when you start to think about some foreign reward how cool they are and favorable how the hell to get that
char (click to enlarge)
profile (click to enlarge)
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
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 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:
English