Status.ehasa.org

The 2026 update rebuilt the interface and themes. The map editor gained active and shared layers, broader drawing and styling tools, and undo support. GPS tracking and event replay also developed.

Task management became a dedicated workspace for content, visibility, scheduling, targeting, hierarchy, locations and attachments. Automation, conditions and activity history support game progression. Outcomes can be shared or faction-specific.

Items and notices have their own management views. Organiser, player and public views can be restricted separately, while capture points and Flagbox diagnostics remain part of the same service.

In 2023–2024, Status used the earlier interface centred on the map, capture points, tasks, notices and faction scores. Its map editor was used to edit game areas and map features.

The English interface supported international Battlegroup events. Almost 20 Flagboxes were in use in 2023 and were also rented to other organisers. Device reliability and usability continued to improve.

The images show the earlier interface at TSTOS 22.

Data transfer problems and the slowness of the devices and the lack of memory in the arduino board caused infuriating problems over the years. Sometimes the devices didn't send data, or sometimes they just simply froze in the middle of the game. The devices were also really slow. After pressing the capture button the capture usually started after 5-10 seconds. Most of the problems were caused by the way the program was coded. It was decided to completely rewrite the program, and HTTP was ditched and replaced by MQTT. Sure, the new program brought new bugs, but at least the data transfer was clearly smoother. In any case the status is a difficult program for us because we can only test it on a large scale about twice a year at our events.

When we started planning the TSTOS parola, we realized that there would be a lot more capture points and they should be able to be controlled remotely. We also wanted to slow down the capture of flags and direct the players to also defend the flags during the capture. None of those features were possible with the previous device. That's why we had to develop a completely new one. At first, we wanted to make the new device at least a little water-repellent since the devices usually were set up already days before the start of the game. The new device got its settings from the server and functioned according to them. This wasn't completely problem-free either, because as the code got more complicated, data transfer problems and memory leaks appeared. That's why, for years, we still sometimes had to go up to the capture points to restart them.

It didn't take long before we realized that manning the flags is boring and pointless. We even started to use less the status system, because we knew it required a lot of organisers. Thats why the idea was born to replace the organisers at the flags with an electronic system. The first capture point hardware was based on an Arduino and a GPRS-shield. The device only had two buttons and it made a direct HTTP GET request to the server and the flag was captured in seconds. Although it was very simple, it worked.

The first status version was used in the Conquest 2 event. The system was very simple back then. The organisers stayed on each flag and announced on the radio to the organiser in in the middle of the game area, who then pressed the right button on the computer to mark that the flag had been taken. According to the picture, using the status in the Conquest 2 event required at least 7 organisers. One for each flag and one in the center of the game area to wait for radio messages at the computer.