New Hardware, New Systems

In our continuous pursuit to enhance our network and customer service we have recently begun rethinking our backup strategy. With the advent of new requirements following 2020 we will be required to store up to 12 months (as opposed to 4 months) of the data our customers generate on our network. This new requirement, set forth by German lawmakers, means we require much more storage space. To meet the new storage requirements we have changed our backup strategy and ordered new hardware to handle the additional data influx.

Along with the new hardware we have rolled out a new ingress system. This new system will handle customer requests for deployment of their own data into our network. With mesh becoming ever more present in our worlds we can see the increase in size of customer data. As such the new ingress system supports file sizes big enough to handle all this data.

But wait, there is more. With the aforementioned increases in customer data comes a problem for making all this data available to our customers. To solve this problem we have also deployed a new transfer system that will securely handle data requests.

With these two new systems we will be able to support the projected increase in data sizes and provide our customers with the peace of mind that up to one year of their data is securely stored and accessible in case of catastrophic failure. Further will it provide us with an interesting metric on how data is evolving and what needs to be done to future-proof our systems to handle these new loads in the future.

Developer Correspondence

Every now and then voices are heard within the OpenSimulator community actively targeting the developers being the core version of OpenSimulator, specifically with the complaint that correspondence is being ignored and user requests are not met with an appropriate response. This sentiment has lead to many not actively engaging in the channels of communication provided by the project as well as to form committees and organizations designed to “ease the connection between uses and developers” often with the exact opposite effect. While this is a valid concern for any project and communication between users and developers on any project is always strained by many factors; the core OpenSimulator developers have been doing respectively well in their efforts in communication.

This is specifically highlighted each time Zetamex has proposed changes of various degrees to the project. As you may know, Zetamex maintains a fork of OpenSimulator that leans toward extending the functionality and customizability of OpenSimulator to suit more peoples needs. Historically these changes were kept exclusive, but recently we have made a few of them available for the core project as well as engaged in discussion towards bugfixes and new features as well. This communication, while not always fruitful, has so far been fairly positive and discussion was civil, solution orientated and has produced some welcome changes and improvements.

The dialog first began over two years ago with the apparent problem of interruptions in movement of avatars on regions. These spikes and delays caused by some complex physics calculation and prioritizing were solved within a few days after testing and continuous dialog helped pinpoint the issue. What followed were changes to scripting functions like llDetectedGrab to better reflect the expected behavior and solve a rotation gimbal lock. To just yesterday, at the time of this post, solving a constant not being obeyed by an OSSL function. From the time of reporting the problem and discussing potential solutions to a fix was mere hours. Today the enhancement was properly signed off and confirmed working, further extending the capabilities of OpenSimulator.

These repeating cases of a problem being addressed and solved in a timely fashion and with great regard toward least inconvenience to users, along with careful consideration as to the extend new functionality should go with regard to performance; this, to us, shows a real commitment toward the future of OpenSimulator and displays the great passion the developers, specifically one Antonio Jose Almeida Leal Duarte aka Ubit Umarov. We believe the project has a true future with the passion that has been recently displayed toward improving and expanding OpenSimulator.

The same, however, can not be said about the other side of the coin; The Viewers. Historically changes to OpenSimulator requiring changes to the Viewers have not been met with a the same kind of passion or even understanding. Usually the correspondence is very onesided toward not implementing any features simply to support OpenSimulator. That is despite some viewers explicitly aiming toward “supporting” OpenSimulator and its development. A good example were the changes required to the syntax of OSSL after new functions were introduced. For a simple request of updating a single file to contain the new definitions based on recent changes the response was a complaint toward the rapidly changing nature of OpenSimulator at the time. Other requests to adjust viewers to better reflect capabilities within OpenSimulator were met with bewilderment as to why such capabilities were added in the first place. This, among many other instances or rejection and hostility toward OpenSimulator specific changes and issues has the relationship between the core OpenSimulator project and Viewer developers somewhat strained.

For the last few years the outcry toward a true, maintained and non-SL Viewer specifically for OpenSimulator has been widely discussed, but no instance within the community has committed itself to this. Attempts have been made numerous times, but non have so far produced an equivalent project carrying with it the guarantees and structure required to truly represent OpenSimulator as an official Viewer or associated project. Various capabilities that would be within reach of OpenSimulator are kept back by this fact and so improvements can only be achieved in the realms of bugfixing, performance and stability. New and exclusive features requiring handling on the side of the Viewers are very unlikely to be implemented.

The Viewers who have historically committed toward OpenSimulator specific versions and offered implementation of features, at the time of writing this, are not looking too healthy and an official association is not sought after by the core OpenSimulator project. Even the testing of most bugfixes and performance enhancements are made along existing, SL-first, Viewers. We dearly hope this situation improves at some point as we can see a great deal of potential in changing some of the core capabilities of OpenSimulator to better reflect current technology and code standards along with simply expanding their functionality into new realms.

We will maintain the correspondence we have with the core OpenSimulator project and aim to advance the correspondence with the various Viewer projects to attempt to create a better dialog. However it is still unlikely that one of the existing projects gains the required momentum for a true OpenSimulator-first Viewer.

As for any user of OpenSimulator we encourage to browse the links at the bottom of this post in regards to some of the features being requested and implemented into the core version of OpenSimulator. It is not always so easy to create a dialog between users and developers and this has caused and will cause friction. However, the many organizations that have so far formed to easy this dialog all have so far not managed to close this divide. More so the developers have expressed a clear distaste for the attitude and entitlement these groups have shown in the past. It is not likely the divide will ever be closed, but it can be reduced somewhat through empathy and an understanding that many things sounds easier than they are to implement. Those with ideas should not keep them to themselves, but we encourage anyone with an idea to first speak to others and attempt to gain an insight into the processes and workings of OpenSimulator before attempting to create a feature request or bug report.

Lastly, as this is the last blog post for this year, we wish everyone, users, developers and spambots happy holidays and a happy new year!

Working At Zetamex

Zetamex Network has always been about community and giving back to it. As such we love to give up and coming developers looking to practice and hone their skills an opportunity to get real world experience with working on the projects we develop. Putting the learned skills to the test and working on actual production systems, working with an experienced team and creating things that have a true impact. We have opened a new positions for internships for those looking to do just that; more information here

New year, new goals

We hope you all have had some nice holidays and survived the new-years parties without any major hangovers. We have used the last couple months of 2017 quite productively and moved to a more efficient setup, new people joined the team and new technology was deployed. As with most things the holidays have slowed things down a bit, but we expect things to start picking up again in the coming weeks.

As new-years resolution we have decided to provide our customers and to-be-customers with some insights into running a grid and what responsibilities that includes. If you are interested in opening your own grid or just curious as to what goes on behind the scenes keep reading.

The best comparison that can be made in terms of workload and responsibility, running a grid is like being the mayor of a small town. You, as the grid owner, bear the responsibility of the well-being of your residents along with all the trouble they cause each other, yourself or others. This usually goes further than most imagine however, still, it can be broken down into a few key points that are of importance.


At the moment of writing this there are over 200 grids out there that are openly accepting registrations and sit open on the hypergrid. This means that there are 200 different concepts, ideas and visions for what “the perfect grid” may look like. It is, for lack of a better word, a saturated market. This is likely not going to change either and so the competition for users, content and activity is fierce and often not all that fair either. This often leads to feuds and drama between grid owners, creators and users; everyone trying to claim a piece of the cake for themselves any means necessary. As dark of a picture this may seem to be, there is an equal opposite of genuine sharing and caring with the aim to collaborate and build a better experience for users, no matter what grid they belong to. Though, as with most things, the bad side of this is often more publicized as dirty laundry makes for greater headlines.


As mentioned previously, the responsibility for everything on a grid lies squarely with the grid owner. This means that writing up proper Terms of Service is a must. Dealing with liabilities, international laws, local laws and claims can quickly consume all your time. Lawsuits can and have happened and especially when it comes to commerce and actual money things can quickly go to court. It is important to have good knowledge over international and local laws pertaining virtual worlds, e-commerce and consumer protections. It also does not hurt to have a good understanding about content policies and copyright. These are areas often overlooked and very few grids actually have proper Terms of Service or End User Licenses covering these areas. Going into further detail or attempting to cover all bases would likely take up hundreds of pages at this point. The best option is to either seek the assistance of a lawyer or, if you like reading, read up on local laws and the laws of the countries you do business in.


OpenSim is, by definition of the project, alpha software. This means that it may not be stable, crash at any time and eat all the work you just did. While we have made some changes to it to increase stability even we cannot guarantee its stability. Making regular backups and understanding the risks is a big part, along with understanding the limitations OpenSim has. If you throw enough at it no hardware will be able to compensate and performance will suffer. Managing load and keeping users from overloading their regions is a big part of running a grid. OpenSim can handle a lot of things if done properly, but one rogue script or item can easily bring everything to a halt. Knowing these things and how to debug and solve these issues is a big part of running a grid and is of vital importance if you want to make the all so important good first impression.


Running a grid, first and foremost, is about handling money. Paying for hardware and service, collecting payments for regions and dealing with commerce. Just paying bills and making sure others pay you, however, is only a small part of it. As soon as money starts changing hands various laws, regulations and requirements come into play. From filing taxes to issuing refunds, all that needs consideration and lots of reading. While it is not directly necessary to register as business when running a grid, when things start picking up and more and more money is involved eventually it will raise some eyebrows and you might find yourself having to pay extra tax or even fines. As with the legal stuff, specific examples depend on so many things that listing them all would take up pages and we simply can’t put this much on the blog.


It can be easy to forget that each and every user is a human being and as such they have their own free will, as much as that may be annoying at times it can also be the greatest asset. Dealing with that asset is another big effort and requires constant attention. One has to realize that as grid owner, in some ways, you also represent the entire community around OpenSim. Further, since not ever user comes from SecondLife or has a Computer-Science background dealing with questions, concerns and issues in a manner from “Explain like I’m Five” to technical-moon-speak is part of running a grid. The end-user support, as it is called, is a big part of the daily tasks and can make or break a grid. As with most good deeds it is rarely recognized so beyond the work itself the commitment can be difficult to keep up. That is the other human factor in the equation. You, as grid owner, have to keep yourself invested just as much, if not more, as the users on the grid.


While having a degree is not required, having a good understanding of hardware, its capabilities and limitations does help quite a bit. OpenSim has very specific requirements in terms of hardware and it can have a massive impact on performance, stability and ultimately the money in your pocket. Beyond the physical machinery you run OpenSim on a big part of the performance comes from the network. Adequate bandwidth and connections are vital, especially if you plan to attract a worldwide audience. We generally advice on those things for our Managed plans, which have us manage OpenSim on hardware that you provide. In all that it is important to keep a watchful eye on scale and scale-ability. When a grid starts growing choosing what upgrades to make and what areas need additional hardware to handle the extra load depend not only on OpenSim itself, but also on its dependencies for Databases, filesystem and more. In all that it is important to keep an eye on what users do and if a performance impasse may not be the hardware’s fault after all.

If all this seems like a lot to consider then that is because it is. As mentioned before, running a grid is like running your own little town or a busy restaurant. It is not something to take lightly and while we generally encourage anyone looking to open a grid, we would not do anyone a good service if we did not educate about these concerns and stipulations. We hope that this has provided at least some insight into what goes into running a grid. There is plenty more that goes into all this and it is in many ways a never-ending story. Dynamic as life itself if you want to be philosophical. In the future we may touch on specific subjects with some actual examples, but for the moment this will have to do.

Adding flavor to OpenSim


The term has become more than what it originally described. Nowadays a whole culture and mindset is attached to it. At its core all it describes is that the source-code of a piece of software is available for anyone to easily view and use themselves, without having to reverse-engineer anything. Open-source and the whole FOSS philosophy is about sharing, contributing and furthering software. Many projects rely on volunteers to make additions, fix bugs or maintain compatibilities, but they are not solely bound by that either. Many projects receive help from companies using the software or even develop it in the first place. These companies usually make profit on selling the support for the software or additional pieces or versions not available in the open-source version.

OpenSim is open-source as well. It has historically been developed by volunteers aiming to create a virtual world platform similar to SecondLife. At the time of its creation it truly had the philosophy of an open-source project. Over time the people working on the project left and new ones came in. With new people came new directions and those directions now somewhat differ from what they were initially. These days OpenSim is being developed by people who have a commercial interest in the software and may want to sell any fixes or additions to it. This, as described above, does not break the nature of the open-source idea or philosophy for that matter. At the same time it does mean that the project has somewhat deviated in its course for making the software better to, well, making money. Again, no issues with that in itself, but it must be said that this does create the possibility of additions or fixes being rejected based on the commercial aspect the software is used for by its development team. This has lead to a feeling of stagnation and rejection from the development team towards the community surround OpenSim.

We have always supported the decisions of the development team and have made efforts to support them financially and with additions to code, however the response we have gotten has been rather negative. We no longer see a future for the development of OpenSim with its current development team. As a result we have decided to create our own flavor of OpenSim in order to make sure development continues under the pretense of making the software better. In technical terms it’s called a fork, a divergence from the original. We will start to implement and change OpenSim based on the needs of our customers and to an extend the feedback from the community as a whole. We will continue to support those who want to better the original OpenSim, but the internal politics and money involved for the current development team has lead to unsatisfactory state for us and our customers and we would be mad not to attempt to correct it. This does mean that beside the original OpenSim we will be offering our own ZetaSim for our customers. Additionally we will make efforts to support other forks with the same intend of furthering the development of OpenSim and contribute some of the changes and fixes we have developed for ZetaSim. We feel that is the most liberal decision we could make given the current state of development and the need to support our customers as well.

All-in-One Grid Packages

With the metaverse steadily growing, more grids pooping up almost every week, we realized many do not wish to concern themselves with a detailed breakdown of costs and rather pay a “flatrate” for everything. While we continue to offer our highly customize-able options for grid and simulator hosting, we also want to make it easier for those who just wish to have a single solution, out of the box, running with a set of options already pre-configured. The new packages are available in north America and central Europe and include the basics needed to start your own grid and build a world all of your own.

A little overview of the packages for those interested.

Grid Complete Pack
-Includes all necessary grid services
-Money Server(Podex) or/and Gloebit
-PHP Asset Server with 100GB of asset storage
-Single Simulator for your welcome or failover region
-Integration to Zetamex Website packages and future embedded control panel

Price (excl. Fees): €95.00*

Simulator Server
-As many regions as the hardware can handle
-From stable to bleeding-edge all OpenSim-Core versions available upon request
-Access to all future module additions
-Integration to Zetamex Website packages and future embedded control panel

Price (excl. Fees): €85.00*

Barebone Extension
-Full DDoS protection
-Global caching to reduce loading times
-Daily backups and coldstore for months
-Full realtime monitoring

Price (excl. Fees): €69.00*

*As usual these prices have some flexibility. Name us your budget and we will see how we can accommodate to fit your needs while keeping cost down.

We hope these new packages will make it easier to get your ideas and dreams off the ground. If this sounds like the package you have been looking for feel free to drop us a message!