A collaborative web application (virtual office) presented as a 16-bit RPG video game
Full Changelog: https://github.com/workadventure/workadventure/compare/v1.18.8...v1.18.9
Full Changelog: https://github.com/workadventure/workadventure/compare/v1.18.7...v1.18.8
Full Changelog: https://github.com/workadventure/workadventure/compare/v1.18.6...v1.18.7
Full Changelog: https://github.com/workadventure/workadventure/compare/v1.18.5...v1.18.6
Full Changelog: https://github.com/workadventure/workadventure/compare/v1.18.4...v1.18.5
Full Changelog: https://github.com/workadventure/workadventure/compare/v1.18.3...v1.18.4
Full Changelog: https://github.com/workadventure/workadventure/compare/v1.18.2...v1.18.3
Full Changelog: https://github.com/workadventure/workadventure/compare/v1.18.1...v1.18.2
Full Changelog: https://github.com/workadventure/workadventure/compare/v1.18.0...v1.18.1
WorkAdventure features a new "event system" that integrates with the scripting API. In the scripting API, until v1.18, the only way to exchange data between players was to use variables. Variables are great to store data. Because you can track in real-time the changes to a variable, the variable system was often abused to send real-time messages between players.
While it did work, it was not the best solution. Variables are not meant to be used as a real-time messaging system. WorkAdventure 1.18 introduces a dedicated event system that is meant to be used for exchanging real-time messages.
The event system can be used from the scripting API to broadcast an event to everybody in a room, or to send an event to a specific player. Additionally, the event system can be used from the RoomAPI (server-side API). From the RoomAPI, you can both send and listen to events.
When you are in a bubble, the scripting API can now listen to messages sent to you, and also write messages on your behalf. This means that now, you can indeed code a bot using the scripting API. ... and guess what? There is a new tutorial just for that
From the scripting API, you can now access the hash using WA.room.hashParameters (the part of the URL after the "#"). This can be pretty useful to craft special links that enable some features in your maps.
Via the scripting API, you can now play a sound (MP3 or OGG file) to other players that are in the same bubble as you. The sound will appear to originate from the microphone of the user that runs the function. We use this feature associated to a text-to-speech engine to simulate a bot talking to other users in a bubble.
For SAAS users or users using a compatible Admin API, logged users Woka name and Woka character are now stored in the admin side. Previously, those were stored in local storage.
It means that if you connect to WorkAdventure from another computer, your name and Woka character and companion will follow you! Localstorage is still used for users who prefer to connect anonymously.
For developers of Admin APIs, there are 3 new endpoints to be implemented:
/api/save-name
/api/save-textures
/api/save-companion-texture
Noise canceling is now enabled by default in Jitsi (unless you are using Firefox). Why not Firefox? Firefox records audio in stereo and the noise canceling feature does not support stereo input so noise canceling will stay disabled for Firefox users until a proper solution is found.
We are now using the screen wake lock API of the browser to prevent your screen lock from starting when you are in the middle of a call.
We now try to display an error message if a video in a bubble should be received, but is not received. This should help users diagnose the issues. Those errors can also be reported to the analytics (Posthog)
You can now put in the URL: "#moveTo=[area_name]" or "#moveTo=[area_id]" and your Woka will automatically walk to this position when entering the map. This was already the case for areas defined in Tiled. It is now also possible for areas defined in the map editor.
The technical stack to use Jitsi as a low-level SFU has been heavily refactored. With this refactor, it will be possible, in the future, to replace Jitsi with any other SFU and support many SFUs at once. Those improvements come with a number of bug fixes too.
WorkAdventure can now be started in headless mode. In this mode, the browser will not render the "game" at all. This will be useless for regular users, but can be useful in a number of specific scenarios (this will speed up E2E tests for instance).
For this release, we put a strong focus on the bugfixes of the map editor.
We keep migrating WorkAdventure to the new design system. In this release, screen-sharing gets some additional space (the videos on the right will be smaller so that the screen-sharing can get more screen space). Also, the error dialog gets a redesign!
A big one here. We are pretty happy to have contributed a fix in ts-proto that is deployed in this new version of WorkAdventure. Another big upgrade: WorkAdventure now runs on Node 20 instead of Node 18.
Some work was done to improve the scrolling performance on maps that are overcrowded (more than 100 users packed in a small area of the map)
A big thanks to @klauserber for his first contribution. He contributed an alternative installation method for WorkAdventure: a Helm chart!
If you are implementing an Admin API, the AdminAPI endpoints have slightly changed.
The most notable changes are in the /api/room/access endpoint:
/api/room/access should now always return HTTP 200 codes (even for unauthorized access or room not found).
On a success response, you should add the status: "ok" property
On an error response, you should add the status: "error" property
You must add 2 new properties to the response:
isCharacterTexturesValid => if false, the user will be redirected to the character selection screen upon loginisCompanionTextureValid => if false, the user will be redirected to the companion selection screen upon login/api/map should now always return HTTP 200 codes (even for unauthorized access or room not found).
Note: always returning an HTTP 200 means we can be sure the endpoint is up and running. If there is an error, we can treat it properly. With an HTTP 404 for instance, it was hard to make the distinction between "the room does not exist" and "the service is not at the requested address".
A number of small quality of life changes have been done on the map editor.
Full Changelog: https://github.com/workadventure/workadventure/compare/v1.17.0...v1.18.0