LPT: if u use the coli tracker and are doing smth like a scav hunt where you need to defeat x amount of an enemy, pick their exclusive drop and set a quest for like 999 of them. if you set it to count valid encounters instead of battles it will keep track of exactly how many you've gone up against.
much easier than counting drops and keeping a notebook
I wanted to write a bit about how the Coliseum Tracker works, since there can be a lot of concerns about using a script when Flight Rising has distinct rules on scripts (and generally don't allow them).
A disclaimer first, that I hope is understood by anyone who chooses to use scripts: there is always a risk with using any type of script or add-on that does anything on Flight Rising. This script is no exception.
The Coliseum Tracker primarily works by reading specific WebSocket messages. It listens for two types: the message that contains venue and enemy information (used for detecting the venue and checking for valid encounters when quests are active), and the message that contains the win and loot information.
The WebSocket messages are already being sent to your browser, regardless if you have the script or not - this entire tool was inspired by how Firefox users can filter WebSocket messages for a battle counter.
However, an important part to understand is that in order to read the browser's WebSocket messages, the script wraps around the WebSocket constructor in order to gain the ability to actually listen for messages. This is an inherent limitation with WebSockets, and the only way to read WebSocket messages in any script. WebSockets are not FR specific code, but infrastructure that the Coliseum and the tool make use of. The wrap is completely transparent. The site gets back the exact same connection it would have gotten without the tracker, the tracker just attaches a listener to it at the moment it's created. The site's own code is completely untouched. It is the code equivalent to reading the messages yourself: you have to open DevTools, go to the right tab, and click on a specific connection to actually see what happens. Functionally it is the same as if you were sitting with the DevTools open and manually tracking it.
It is however worth noting that based on a strict literal reading of the rules (Conduct, rule 12), that since the script has to wrap the WebSocket constructor, it is "interacting" with it by observing it. It isn't the literal site design, but the tool does observe part of the browser infrastructure the Coliseum uses. Players in general were probably not intended to look at the WebSocket messages, even if you can do that with tools your browser gives you.
The tracker never sends any messages, it only reads those that your browser are getting from the Coliseum. Specifically, it looks for 2 messages, both containing arrays with information.
An array is essentially an ordered list, and by looking in specific parts of it, we can read information. The loot information, when we look inside the array, can look like this:
[[20126,"trinket",1],[20133,"food",1]]
This would translate to Mirage Puffer Spines x1, Hypnotic Scallop x1. The first number is the ID of the item, the string is the (sub-)category it belongs to, and the last number is the amount that dropped.
The battle messages have a similar structure. We can read which venue the battle is in, the enemy names, and the enemy elements. There is more information in each message, but those are the only parts that the tracker listens for currently.
I have created lists that connect the item IDs to item names, categories, and which enemies drop the item by going through the game database and manually entering the information into a document (the itemIndex). This is why there can be "missing" items that only display their ID in the tool - there is no name attached to the ID, so the tool displays what it knows (ID and amount, since that is in the messages) as a fallback.
Any time a new item is added to the Coliseum, like the festival chests that are added each month, I have to edit the itemIndex to add their names, categories, and where it drops.
The only exception to how the tool reads information is how it detects the very first battle to get venue and enemy information. The loot information is always using the WebSocket messages, but the battle message doesn't appear for the first battle for some reason. Instead, the tracker has to listen to specific values. Specifically, _game.enemies and _game.room.stage.venueId. These hold information on which enemies and which venue are on screen. By checking what the Coliseum put into these boxes we can get the information that we otherwise get from the WebSocket messages.
All the information that the tool uses to keep track of loot and battles is available through the DevTools, and the tool only listens to / reads the information. It never communicates, modifies or otherwise interacts with the server, it only looks for the information it needs, and only stores information locally (in localStorage, which you can check in DevTools).
As far as I am aware, the site/server isn't even aware that the tracker exists since it doesn't send any information to the site, and you still have to play the game normally to have any use of the tracker. But it is still a script, and Flight Rising does not want players to use scripts by default.
Hopefully that clarifies a bit about how the tool works. I encourage you to look at the source code, and if you have any questions or suggestions for improvements, I'd love to talk about it ..b
And a personal note: for me, it is about making the Coliseum more accessible and enjoyable since my short-term memory and attention span are both bad. The tool helps me stay on track and reduce frustration about forgetting what I'm doing. It is the same reason I made the Coliseum Guide.
and I hope it can help other people in the same way ..b
There is now a beta branch on the GitHub page for the Coliseum Tracker, where you can find the new 2.0 version of the tracker. This version will be in beta for a while so I can collect feedback on potential issues.
If you try out the 2.0 version, please let me know your thoughts ..b Even feedback that it at minimum is as useful as the previous iteration is good (if it isn't, I'd like to fix that)
Some things that are missing and will be added before the full release include unique icons for the festival category, as well as a proper icon for the toggle button when in icon mode.
The itemIndex has been updated to include the new drops from Bamboo Falls, and the two new boss familiars have been added to the default highlight preset. If you notice any items are missing or otherwise behaving incorrectly, let me know here or on github and I'll fix it (..)b
A 2.1.0 update has been released in the beta branch of the Coliseum tracker. I don't plan on keeping this in beta for very long, just enough time to tweak things and make sure it works as intended.
This new update adds:
A new tab for the settings panel containing manual resize and position values for the main panel and the settings panel. This is primarily intended for users who can't use the resize handles and drag handles, such as mobile users. Please use caution if you use this feature as large values could move the window off screen.
New toggle contrast option in the panel tab, giving the icon style for the toggle a background when checked (using the button background + text color)
Moved toggle settings to the panel tab in settings to reduce clutter in the visual settings tab
ETA: Also added a new padding preset in case you prefer less/more padding in the layout
And some bugfixes:
Fix for moving the toggle button registering as a click, which opened the window and caused the toggle button position to not save.
Fix for the font size resetting to default on refresh
Fix for window moving the scrollbar width to the left if the panel was moved and the page refreshed without minimizing the panel
Fix for a bug where changing the column mode would not refresh the UI
All festival chests have been added to itemIndex, as well as a patch to ensure I can tag the chests as festival items through the itemIndex. A SVG has been added for the festival items, which previously (incorrectly) used the specialty SVG.
The festival chests have also been added to the itemIndex used for the Coliseum Drop Guide
The full 2.0 release of the Coliseum Tracker is now available. If you've had the main branch (previously 1.3.2) installed, the tool will automatically update, but you can reinstall it to get access to it faster. If you installed the beta version, please do a manual install from the main branch to make sure you get bugfixes!
Some data might be lost in the automatic update process, so please clear user data if you encounter unexpected behaviour.
Users who want to keep using the 1.3.2 version for any reason can access it in the 1.3.2 fallback branch. This version will not be updated, nor will the itemIndex be updated for this version.
If you notice any bugs - particularly with festival items - please report them on GitHub, in the google Feedback Form (no login required), or poke me here on Tumblr! ..b
The coliseum tracker tool itemIndex has been updated with the chests that drop during Rockbreaker's Ceremony! If you notice that any are missing or anything else strange, please let me know so I can fix it ..b
I've also updated the festivalPreset to highlight the RC items - to use it, simply download the file from the github page (click on the name of it on the linked page, and then click the lil down arrow in the top right corner to download raw file), go to the coliseum tool window on FR, open the settings, and hit 'Import' on the Highlight Preset line. Select the file you downloaded and you should be good to go ..b
the festivalPreset highlights all boss drops, eggs, festival currency, as well as the festival chests for the current festival.