Posts on May 2012

Easy KAG server renting

Do you want your own KAG dedicated server? Jrgp our webmaster, the man behind has made a new dedicated service for renting King Arthurs’s Gold servers.

KAG Servers is the easiest place to rent the King Arthur’s Gold servers. It has free FTP access and instant deployment. It’s as simple as choosing the number of slots, paying via paypal, and your server will be started within seconds!

Located in Florida, USA

.60/slot for public,
.50/slot for private (USD)

So if you want to have your very own KAG server, host the game with possibly your own game mode, rules and maps, head on to: now.

A brief discussion about IPv6

Firstly, King Arthur’s Gold will be participating in the World IPv6 Launch on June 6th, in that we have every site/server for King Arthur’s Gold IPv6-enabled.

WORLD IPV6 LAUNCH is 6 June 2012  The Future is Forever

The World IPv6 Launch is a joint effort by content providers, Internet Service Providers, and hardware vendors to make appreciable progress in deploying IPv6.  It is a follow-up of sorts to last year’s World IPv6 Day, where many content providers ran tests with the public for 24 hours to see if there were any unforeseen problems and to gauge the impact of advertising IPv6 availability on their sites.  As was hoped, it was a non-event, as was Facebook recently enabling IPv6 on their site permanently.

I urge you all to call your ISPs and e-mail your favorite sites’ support asking what their plans are to support IPv6.  IPv4 exhaustion is continuing to push forward the deployment of NAT at large scales, which will come at a cost to gamers and other applications which frequently rely on port forwarding.  As the quality of IPv4 connectivity degrades over time, IPv6 will increasingly prevail as the higher quality means for two endpoints to talk to each other.

Beyond that, I have been working carefully to make the new server registration/list components of the KAG API compatible with IPv4 and IPv6, and respecting server owners’ preferences for whether IPv6 is preferred by clients (assuming the client and server both have IPv6 connectivity).  The game netcode itself does not support IPv6 yet because the underlying library we use does not support it, however a medium-to-long term goal of mine is to extend it to support IPv6 or replace our netcode with something else.  Here is a basic overview of the logic that is being built in currently:

  1. The server owner enters into their configuration whether IPv6 should be enabled (default on), whether IPv6 or IPv4 should be preferred by clients (default to ‘whichever performs better, or IPv6 if they’re pretty much the same’), and what IPv6 address to bind to (defaults to auto-selecting one)
  2. The server registers with the API.  If the preference configuration is 0 (select the better performing protocol or IPv6 if they’re the close) or 6 (prefer IPv6 absolutely), the server registers with IPv6 as its main identifying address in the server list.  If the server is IPv4 only or the preference is set to 4, the server registers with its IPv4 address as its identifier
  3. Some other steps go on to allow the server to list its other address, if it has one, so that it is confirmed as owned by the server and allowed to be used to identify the server
  4. When a client requests the server list, it is filtered by all criteria the client supplies (documentation will be available on the wiki soon, describing how the server list/filter API works).  The client will receive the full list of servers matching the filter criteria including their IPv4 and IPv6 addresses.  The client will ping servers over both IPv4 and IPv6 to gauge performance, assuming it has IPv4 and IPv6 access.  IPv4-only servers will not be displayed to IPv6-only clients, and vice-versa.
  5. The client will have a configuration setting for its own preference for IPv4 or IPv6, however I have not figured out exactly how this will work in cooperation with the server preference.  Possibly the server preference being 0 will mean “defer to the client’s setting”, and the client will default to using whichever performs better (or IPv6 if latency is within X%). 

Other notes –

  • The new server registration API will eventually refuse to list servers that it cannot connect to.  This will prevent servers behind a firewall (without port forwarding) from being listed in the master server list
  • You can view my own personal post from a couple years ago here.  This has the general logic that the above workflow/design is based on.
  • I have no idea when we’ll get around to adding IPv6 support to the actual game code unfortunately.  It is something I would like to do, however I have not investigated enough to understand what the scope of the project would be and what our options are for implementing IPv6 least painfully.

If you have any questions about IPv4 exhaustion, IPv6 deployment, or how KAG/gaming will likely deal with these in the future, take a look at the following links and head to this forum thread:


Re: Modding

Gotta say guys, we don’t have time to answer all the PMs we’re getting about how to tweak such and such variable or how to figure out a certain aspect of modding – please ask on IRC and try to figure it out yourself, because you’re more likely to get an answer that way.

I’m getting 12+ PMs a day on the forums about bugs, water and modding vars, where the information is either freely available, available by consulting other members of the community, or should become pretty clear upon inspection. Answering these is unmaintainable and wastes a lot of development time.

As such, please ask on the forums or IRC about modding, and search for bugs. Report bugs at the latter address as well, for those that don’t know – be sure to include as much useful information as you can. We simply don’t have time to make a game, answer queries in specific threadsandhelp you out with modding your zombies. If you can’t figure it out, someone else will be able to help you.

For bonus points, if you figure something new out, put it on the wiki so that it becomes public knowledge.


This week’s cool stuff

Things that we’ve been working on this week:

  • Water (with simple tide/waves)
    This is quite a bit of fun – it still needs some tweaking to suit gameplay properly but making a diving board and fighting underwater are enjoyable.
  • Wooden blocks (weaker, but only cost wood)
    These can be used for rapidly fortifying areas (make full use of those mats) and to construct less vital parts of towers.
    It might become necessary to build these before building stone blocks, but we’ll see about that down the line. For now, wooden towers!

    (With the two above additions, its only a matter of time before we introduce fire…)

  • Shield bashing is back in the game, with variables now bound to config vars in gamemode. We’re still working on dealing with lag as there’s a fair bit of warping with latency, but it prevents the slash2win strategy that’s applied in knight combat this build. We had a lot of fun bouncing Rayne down hills to get it more balanced, but it’s possible to re-create old giant shieldbashes and to make shield bashing happen just from walking into someone and so on.

There have been a few fixes (/loadmap now works for configs, and /savemap doesn’t append .kag no matter what, a few technical things) and Ryan/FLAB is making good headway with some more API stuff that will reduce server load quite a bit during peak times, but most importantly we’re working on block colliders that can move around, carry players and crush them against walls.

Its early days yet, but this should lead to config defined building blocks, and building blocks larger than one tile. It’s also already lead to Michal testing a rudimentary smasher, which was a smashing success. You can have a look at the video here as I cant figure out how to embed into this post, heh.

Forum Thread Here


Build 394 fix for dedi on older linux distros

Hi all, FLAB here –

Unfortunately due to how we set up the new build system with the release of build 393/394, the dedicated server would stop working on CentOS/RHEL/etc 5 and other aging distros with older glibc/glibcxx.  I have replaced the node in our build system which builds the linux versions with CentOS5 so that we can generate more portable binaries.

If your server was broken as part of the 393/394 update, you can manually fix it (without having to redownload/reconfigure your server) by replacing the following files in your server folder:



Sorry again for the inconvenience, we will take more care to prevent this in the future!


What’s coming next

Zombie Fortress feels like a whole game in itself but KAG is definitely not finished!

We are officially heading now towards version 1.0.

We will be adding (trying to add) all the features that we promised over the months and which you can see on the in-game buy poster or website. Not all of them will probably make it because if a particular feature is not fun or doesn’t really work or is simply not doable we won’t do it. But on the other hand we will add other elements which are better, more fun and more fitting. So expect to get what you desire and expect to get awesome features you don’t expect!

I’ve started work on water and wooden structures and will be moving on shortly to vehicles and siege machines. This will be exciting! Be sure to come back for updates!


Heads Tweak

A few of the heads had some pixels go wrong for one reason or another when putting them in-game. An update fixing this should make its way out to you in the next 10min or so, shouldn’t affect gameplay at all.

This is mostly just so people don’t raise eyebrows at their KAG patching. Enjoy your slightly more colourful braveheart face and fixed eyes on the samurai and rice worker heads.


OS X 10.5.x issue resolved

With our move to the build system we also started building the mac build on OS X 10.6.  We did not have the build done in such a way that the output was compatible with OS X 10.5, so any of you with OS X 10.5 probably had your KAG installs break if you updated in the past 48 hours.

In the event that this is you, your KAG won’t launch at all after updating to build 393 or 394.  We have a new KAG build out which is compatible with 10.5.x and 10.6.x.  To remedy this, do the following:

  1. Drag your current KAG installation from Applications/ to the trash (or right click/move to trash, etc)
  2. Download KAG again from
  3. Unzip and drag the KAG app to Applicatoins
  4. Try running KAG. It should update to build 394 and work properly if this fix works
  5. If you need additional help, head over to this forum thread for assistance
For anyone else who came here wondering why their mac build updated on 10.6 or 10.7, this is why.  No other changes were introduced.


Autoupdate issue resolved

There was an issue with the auto update system for KAG which would have caused new installs from the website not to update for the past 12-14 hours (since 393 was released).  This is resolved now, and any of you who were stuck on an old build like 345 should be able to update now just by opening the client.

If you continue having problems, head to the KAG Forum for help


Last chance to get KAG for only 9.99$

I forgot to raise the price for KAG after the official Zombie Fortress Multiplayer release. We promised it so we are doing this after todays hot-fixes. So this is really the last chance to get the game and play online against zombies for 9.99$. New price will be 12.99$.

Buy Now

Good news is, if you can’t pay with PayPal, Credit Card or Google/Amazon – you can pay with your mobile phone through Zong (a PayPal company). Zong has probably every country covered so you can pay for KAG with your phone wherever you are. Just click on the little red Zong button and check if you can buy it now. After entering your phone number you will receive a PIN code. After entering this PIN code you will get a KAG code to unlock the Full Version. It’s that easy. No SMS or anything else. See for yourself.


Social Media

Stay up-to-date with our latest news - make sure to follow us on Social Media!