Posted by admin on November 26, 2017
Worldforge has for quite some time used IRC for official chat. However, since a couple of years the usefulness have been steadily declined. One of the main disadvantages or the IRC system is that there's no easy way to keep offline conversations going. If you're not logged in you will simply miss out on questions asked and answers given. Given the global nature of the Worldforge project, with users in different time zones, this makes most conversations fruitless.
This is why we've now moved to Gitter instead. We hope that this kind of chat functionality will be better at keeping conversations going.
Posted by admin on July 23, 2017
Atlas-C++ version 0.6.4 has been released and is now available from the WorldForge download site. Atlas-C++ is the standard implementation of the WorldForge Atlas protocol. This release is primarily aimed at developers and users who want to build the WorldForge system for themselves.
Posted by admin on September 28, 2015
Recently I've done some work on adding proper path finding to Cyphesis. This is something we (surprisingly enough one might think) have been lacking for so many years.
The work isn't done yet, but here's a short demonstration of the work in progress.
Posted by admin on September 19, 2015
I've just pushed some changes to the Ember client which makes it conform to the XDG Basedir spec.
The main difference is that the ~/.ember directory isn't used anymore. Instead configuration files are put in ~/.config/ember while data files are put in ~/.local/share/ember.
During startup the contents of ~/.ember will be migrated, and a backup will be made in ~/.emberlegacy.
Many thanks to Olek Wojnar for making the bulk of the changes.
Posted by admin on May 27, 2015
This is a big change to how the Cyphesis server works. Previously all world simulation and mind code was handled by the one Cyphesis executable, in one single threaded process. Now the server instead only focuses on world simulation and various house keeping tasks, while separate processes handle all AI code.
There's a new executable, "cyaiclient", which when invoked will use a local socket to connect to the server and act as an AI client. Many such clients can be run in parallell, each one handling one or many minds.
The advantages to this are manifold.
- It lets us better take advantage of multicore system (which is the norm since a couple of years) without having to rewrite the single threaded nature of the Cyphesis server. Each AI client is single threaded, but multiple clients can run in parallell.
- It makes the server less complex, since AI execution is handled separately. This makes it easier to reason about and work with.
- It allows for an improved workflow when developing AI code. The AI code can now be altered and restarted without the server being touched. This allows for more a more efficient iterable approach.
- More avenues for alternative AI clients are now open. The current AI code uses mainly Python. It's now much easier to implement an AI client in a separate language (Prolog anyone?).
- The door is now open for letting AI clients run on separate machines. Say, in a cloud. While the current code requires the AI client to connect using a local socket, implementing support for remote connections should be trivial.
When Cyphesis now is run it will by default spawn a child AI process. This behaviour can be tuned through the "--cyphesis:aiclients" flag. Setting it to zero, as such "--cyphesis:aiclients=0" will disable the automatic client spawning, thus allowing you to run your own client process. This is useful when developing.