-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for tty2rpi #68
Comments
Hey! Absolutely, love to add support. Let me know what needs to happen |
Consider that if you want to add something else cool to tty2rpi, there is also a different possible integration, mrext supports a websocket endpoint that informs you of current game loaded but also current game highlighted in the menu. |
Great! There are two functions in tty2rpi (on the RPi side), one simply displays the loaded Core (for example NEOGEO), the other is doing the same plus the loaded game as set in MiSTer's That said, the logic is
NEOGEO here is an example of the active Core as stated in MiSTer's I think it's up to you to decide whether to respect |
@asturur Thanks for that hint! I'm using my own socket but will keep mrext in my mind. For now I won't force my user to use mrext as a dependency to keep the setup as simple as possible. I think some or most of them or Linux beginners and are already challenged ;) |
Having a think about this, maybe there is a simpler way to get this working. Are you aware that both Remote and TapTo write the launched game to You can test this file exists to see if either is running (they create an empty one on startup), and then monitor it like CORENAME to get the full file path to the game that was launched. A couple of notes with it:
If you can support this method, you'll actually have automatic support for everything I've made rather than just TapTo. |
Thanks for the headup! I'll have a deeper look at it the next days (very busy over weekend 😞 ) and report. EDIT1: Did a quick test with the Remote, EDIT2: Ah, just explored that |
So far so good and working, but what I'm missing is that "under some circumstances" (ie while running Remote but starting something per MiSTer menu or starting an arcade core) |
Do you have the recents feature enabled in your ini? This is necessary for the game tracking service to work and update for all games. Otherwise yeah it'll only update the file when Remote or TapTo itself are the ones launching |
It's getting better and better after enabling |
In the case of Arcade games specifically they won't be populated in this file because they're cores rather than loaded files. It's intentional. You'd have to still rely on the CORENAME file like usual. I've thought about it but just decided it complicates things too much. It's actually not possible to see what .rbf file is loaded in memory, and a core can set the "corename" to anything it likes. You also can't inspect an rbf file and see what corename it would set. So it's just impossible to reliably resolve either way. If you need a unified way to get this information where Arcade counts as a "game", you could send an HTTP request to the Remote REST API to get this information. But you won't be able to wait for it to change like with inotifywait, you'd have to poll it repeatedly (which is ok too, it's not resource heavy) |
Personally I would recommend using a combination of CORENAME and ACTIVEGAME to cover all the cases. |
I see and understand, but wouldn't it be enough just to touch the ACTIVEGAME and/or to write nothing to it (leaving it empty). I'm already watching CORENAME and ACTIVEGAME (and others) but the actual situation (with Remote) requires several ifs and thens to compare which of these files has changed and what happened to the remaining ones. Sure, I can write some lines of code/logic to address this, but imho the not-touched ACTIVEGAME is an exception that leaves the usual process how MiSTer handles it's files in /tmp ... |
Fair enough! I've made a change to TapTo's game tracker that will write the corename to ACTIVEGAME if the game is an Arcade core. It'll be in the 1.5 release. A copy of it is attached. I'll make the same change to Remote. I'll try get a new release of that out soon. |
Great, thanks! Will continue tomorrow when weather changes from today's 25°C to 19°C 🌦️ |
I'm the author of tty2rpi (and co-author of tty2oled) and got a user's request to add TapTo support.
While TapTo already supports tty2oled it would be logical to add support for tty2rpi into TapTo than vice versa.
If that request is acceptable to you I would add the needed info here what variables, files and strings to use and to send... no russian rocket sience there and only a few lines of code.
The text was updated successfully, but these errors were encountered: