Project Status

damien has been working on Stage's server-side visibility:


Stage limits the player view to a sphere around their avatar. Message broadcasts are also limited by range. Portals make sure the view is correct even across containers

My current effort is to limit the player view by using shaped portals between containers. This means that you will see a wedge of a room when you look through a door rather than seeing the whole room.

    me   a   |  c
     +       |      d
          b  |    e

so in the above diagram, D is an open door + would see a, b and e.

I'm not sure how efficient this will be, but just getting it working is my first aim. (probably 50% done)

nowhere reports that:

The first issue of ComicForge will be Very Soon Now(tm). The setting has been changed to Moraf in order to get some background stories for Mason.
King's Feast
Approaching 0.0.3 slowly but surely (planned for this month) and will include a hopefully functional NN plus integration in the main code.
Skill System Group
I'm working on the C++ implementation of the skill system and will do a port as soon as the api is laid out.

rsteinke updates us on the status of what he's been up to:

This has seen a few bugfixes over the last six months, but not much change in functionality. It's slowly twitching along towards 0.3, with the most major work needed being some research on 2D polygon intersection check functions, to get a decent algorithm.
I'm going to be taking this over, and making truly cross-widget-set, instead of very libuta specific. Waiting on wftk 0.6, and the widget packing spec bear is working on, before work on janus can start.
Sent James patches to allow multiple character logins over the same connection, added Perl bindings, moved the Gtk+ polling class over from silence.
Got rid of old module loader code, about halfway through moving to Eris.
Currently helping malcolm with code cleanup. I'd like to see a better mainloop (select() instead of sleep()), more efficient drawing code, and a widget packing system.

james reports the following updates:

Mac OS-X
I've been doing up ProjectBuilder files for a few libs (Atlas and WFMath so far) so these libs can be built ridiculously easily on OS-X (pbxbuild does it all). I am likely to continue in this vein since it's positively thrilling compared to autoXXXX fiddling, though I intend to keep both working. Once wftk stabilizes a bit I shall be trying to get it built as a framework too, and if people have specific things they'd like packaged I can look into it. Obviously getting a complete client going would be nice.

The Semi-Secret Project
I'm working on an idea I was discussing over Christmas to build an in-game engine for stage heavily tied to a scripting language. This will be a separate process which stage execs() (or something), and takes care of some of the in-game work. This is all very, very early days, nothing working right now but coming along steadily. As soon as it does something useful (like processing a single Atlas op off the wire from stage) I'll make a proper announcement. Anyway, this is my excuse for not doing 'overt' stage hacking.
Oh, it's called 'Indri'. After the lemur. Because the scripting engine is SpiderMonkey, the hellspawn of Seamonkey. If that sentence made no sense to you, then clearly your day job doesn't involve screaming at Mozilla ... okay, maybe it does, but not screaming at the Mozilla code.

alriddoch has the following to report:

No changes to the stable version for many months, except build files for Mac OS/X committed by James.
The development version of the code is coming along between me working on other areas. Issues with the next version of the protocol are still in discussion. The main objective of this tree is to massively improve performance both on and off the wire, implement new highly efficient codecs, support datagram communication in addition to the current stream stuff and be much more flexible about the type of entity ids so types are more efficient than string like in, or more expressive can be used. It seems inevitable that the protocol will change so much that line compatibility will be lost and the API is so fundamentally changed that major porting will be required. Every effort will be made to ensure the new Atlas-C++ will peacefully coexist with the old and that a single application can support both dialects of the Atlas protocol.
cyphesis-C++ 0.2 for Mason 0.1 has been released. Since then there have been minor bug fixes and database code has been ported to be compatible with the latest PostgreSQL release. This code is now available from cvs on a branch tagged cyphesis-0_2-stable.
The development version of cyphesis-C++, with the nominal version number 0.3 is proceeding well. The world is now persistent using the database code, and entity ids are now handled much better, and are much better at being unique.
This world builder client is poised for major development with the recent developments in cyphesis-C++. It has recently been ported to work with the now stable gtkmm 2.0 and 2.2 series. Many new world editing features are likely to be added over the next few months. It can currently connect to a server and display a simple schematic view of the world, overlaid with height data.
A stable branch that built against gtkmm 1.2 should be considered dead.
This is a new library based on ideas from munin, initially kicked off in development by me, and to be implemented by myself and others based on prototype work by munin. Its purpose is to deterministically generate world data using quasi-random algorithms based on fixed seeds. It is to be used simultaneously by both server and client to enable a rich world to be defined without having to transfer massive quantities of data between client and server.
Currently just stub files have been checked into cvs, while munin works on the prototype in matlab. The first step will be code to generate terrain height data.
This test platform 3D client has now been resurrected for testing. It will likely be used in the near future as a testbed for mercator. Currently useful if you want a very literal view of what is going on in a server, without the prettiness of sear.
This demo media server now works in principle and can be used by uclient. Intended as a basic idea to trigger further thinking and development.
process attempts a number of routine operations with a local server. It is designed to ensure servers behave, and to quickly check that normal and illegal operations do not make the server crash.
Periodic updates as the protocol has been thrashed out. process now verifies that the server is using attribute ids correctly. Server developers should verify that process runs against their server before each check-in.

lee brings us up to speed on what he's been up to:

Worlds development
Slowly but surely is probably the best phase to describe worlds development. We now have two continents, Dural and Sym. Last year saw the first version of the Duralsaur, and the groundwork for automatic creation of future Duralsuars and website. More info on or #worlds
Started development on this client side media retreval system with a hiss and a roar early last year but progress stall when no spec or help was forecoming with defining what clients want, what atlas provides and how it all fits together. I was wanting to write the media server. More info on or #muse
Thousand Parsec
After nearly a year of planning we are starting development. The server is currently written in C++ and mithro is working on the client. Looking at passing first milestone in Feb. More info on #tp