When dying to an enemy, the tracker occasionally reports an incorrect infantry class.

I am not certain yet whether it confuses the killing player with the victim. The error does not appear to occur when piloting a vehicle, but this is more likely down to the game no longer letting players die in vehicles (instead, they exit the vehicle first and then die as their current infantry class).

Investigation ongoing.

We're currently using existing Screenshots by other players or artwork extracted from PS2 news articles or loading screens.
These assets are therefore inconsistent and most importantly their use is not covered by the terms of service.

Over the next few days, I will go on photo safari in-game and create high resolution solution 4K ultra screenshots to use in new assets, which can then also be hosted in the repository.

A Discord application has been created and I have had lovely time playing with assets.

The assets used in the screenshot below are either available through the game's file endpoint or are based on freely available screenshots from the game's "Media" section. The latter may be replaced with our own screenshots to avoid legal questions; the API assets are covered by its terms.

The ps2data library was written back when the API was very out-of-date. Now that it is maintained again, it would be nice to leverage it again, with new weapons, continents, and alerts being added.

The existing fallback values may remain, but an optional TLRU cache would be used to query the latest data from Census/Sanctuary on launch.

Small utilities like this one don't deserve to sit in the task bar, so they should hide away in the system tray drawer until someone wants to close them.

Particularly once auto-tracking of characters and autorun on login are implemented, there is little reason to open the application itself beyond adding or removing characters.

An irregular error in the EssClient::subscribe() method causes deferred subscriptions (i.e. ones performed prior to the ESS client establishing the WebSocket connection) to fail.

This is linked to the definition order; the first subscription always succeeds, while any later subscriptions get more and more mangled in the process.

Hi,

I just tried using the app but I get the following exception and traceback:

WARNING: CPU random generator seem to be failing, disabling hardware random number generation
WARNING: RDRND generated: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
Traceback (most recent call last):
  File "C:\Python39\lib\runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "C:\Python39\lib\runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "C:\Users\user\GitHub\ps2-rich-presence\ps2rpc\__main__.py", line 10, in <module>
    from ._app import Application
  File "C:\Users\user\GitHub\ps2-rich-presence\ps2rpc\_app.py", line 8, in <module>
    from ._rpc import RPCHandler
  File "C:\Users\user\GitHub\ps2-rich-presence\ps2rpc\_rpc.py", line 15, in <module>
    from .presence import PresencePayload
  File "C:\Users\user\GitHub\ps2-rich-presence\ps2rpc\presence\__init__.py", line 8, in <module>
    from ._factory import PresenceFactory
  File "C:\Users\user\GitHub\ps2-rich-presence\ps2rpc\presence\_factory.py", line 8, in <module>
    from ..game import GameState, Ps2Class
  File "C:\Users\user\GitHub\ps2-rich-presence\ps2rpc\game\__init__.py", line 10, in <module>
    from ._gamestate import GameState, GameStateFactory
  File "C:\Users\user\GitHub\ps2-rich-presence\ps2rpc\game\_gamestate.py", line 14, in <module>
    class GameState:
  File "C:\Users\user\GitHub\ps2-rich-presence\ps2rpc\game\_gamestate.py", line 21, in GameState
    profile: Ps2Class | Ps2Vehicle
TypeError: unsupported operand type(s) for |: 'EnumMeta' and 'EnumMeta'

Installation/Usage steps:

1. git clone [email protected]:leonhard-s/ps2-rich-presence.git; cd ps2-rich-presence
2. python -m venv .
3. .\Scripts\Activate.ps1
4. pip install -r .\requirements.txt
5. python -m ps2rpc

The Discord RPC payload supports startTimestamp and endTimestamp fields that can be used to create timers.

The countdown timers would be a nice touch for ongoing alerts.

However, for this to be dependable, we would require a REST endpoint to detect ongoing alerts upon login or when switching zones.

Postponing this issue for the time being; something to look into once the ps2 map API is up and running.

Upon leaving the character manager, the GUI currently defaults to the first character in the list.

It would be more convenient to switch to the last added character, since they were likely added for a reason.

Auraxium requires asyncio-like event loops to function. However, Qt (and thus PyQt6) have their own event loop system, which makes them incompatible.

The qasync package aims to provide a Qt-based event loop that is compatible with the interface required for Python coroutines.

First step is to see if this works, or if we have to create a separate thread for asyncio and start signalling back and forth between Qt and Python.

The build, test, and release process need to be moved to CI before tackling any of the other features.

This includes:

Automated builds

• Windows builds using MSVC
• Windows builds using Clang
• Linux builds

Quality

• CppCheck
• MSVC C++ Code Analyis

Testing

• Unit tests for Arx
• Integration tests (using Qt for clients)
• Synchronization tests for PS2Data

Deployment

• Automated build & installer creation

Brief

The project currently has to monkey-patch certain utilities in the pypresence module to function.

While effective, this is not a great idea and should be rectified.

Details

The application being Qt-based means that it does not support Python-level asynchronous code out of the box. The qasync package fixes this by providing a Qt-compatible implementation of the PEP 3156 event loop interface.

However, on Windows, pypresence performs an isinstance() check on the running event loop as part of its initialisation and will replace it with the default asyncio.ProactorEventLoop if the test fails. This of course is not compatible with Qt and causes the event loop to fail.

Currently, we work around this by monkey-patching this utility function with a version that ignores this check on the "win32" platform:

Potential Solutions

• Reach out to the pypresence devs and look into the reason for the isinstance check in this package.

• If it is not necessary, we can fork/PR the library to get rid of it.

• If it is indeed required to avoid certain issues, we should investigate adding our own safeguards against whatever it was doing and ideally still fork/PR it instead of monkey-patching internal helpers.

Once #1 is sorted, the next step is to assess if the third-party Discord RPC Python implementation pypresence works with this bastardised architecture.

For no particular reason other than that I want to play with QtQuick.

The WebSocket connection currently uses s:example regardless of the GitHub repo secret.

This is fine as DBG won't throttle ESS clients anyway, but it should be rectified to correctly identify our client to the service.

Throw in a bunch of helpers for "hasField", "fieldToString", etc. so it's easy to migrate.

Needed information:

• Tracked characters list
  • Adding/Removing characters
• Option for automatically tracking chars
• Debug information (optional / advanced, logs?)
  • Streaming latency
  • API latency
  • Messages per second
• Connect / Disconnect
• Reconnect / Restart (optional)
• Rich presence controls (optional)
  • Show character name
  • Show server
  • Show current class
  • Show current continent
  • Show timer
• Help link (Repo Wiki)
• Report A Bug (Repo issues)
• Repository (Repo)
• About (License information)

If the first copy of a character is added with incorrect spelling, a second copy can be added later. On resolution, both will get corrected to the actual spelling, resulting in duplicate entries.

Since the character manager internally maps characters via their ID, this does not cause any issues in the config and duplicates are removed on next start-up.

The same check-on-resolution would also ensure that a player cannot queue up the same character lookup multiple times (different spellings, direct ID, etc.).

In addition of a nondescript "Vanu Sovereignty - Cobalt" status, we could also track the performance of the character. Namely, we could show the current KDR, KHR, KPM, streak, etc. as part of the presence window.

Need to chat up some infantry mains about which stats they care about. Accuracy is likely impossible to calculate reliably from live data (go look at Recursion if you have doubts), so session IvI might be out of the question, too.

thx Sneak for the suggestion

The Discord Presence drafts were fun but inconsistent. It is time to produce a more uniform style matching the intentions of the corresponding fields as per the RPC documentation.

Notes

• A "join squad" or "In a squad (X of 12)" button cannot be implemented as this functionality is not available in the API.
• While displaying the current character name or outfit tag is not a violation of any terms of service, it does open avenues of abuse. We will therefore never display character names or outfit tags.
• Game state fields ("Idle", "Playing Solo", "Playing in a Squad", etc.) should be settable by the user to communicate that they are open for other players joining them via Discord (i.e. DM and manual invite)

The app will have two event listeners, one always-on tracker to detect characters logging in or out, and a second one for tracking the active character.

The former should be an independent component to minimise the risk of the WebSocket subscription going bad.