Info about current game and core to third party tool?

RetroArch Windows devices
#1

The file content_history.lpl puts the last used game filename and core filename at the top of the file when RetroArch closes. Is there any way for external tools to get that information about the game and core currently in use while RetroArch is running? Can we retrieve information from an already running RetroArch process with command line arguments? Is there some setting to update the content_history.lpl when a game first loads instead of when RetroArch closes?

On the same topic the screenshot feature currently saves images with this name format “RetroArch-0921-121152.png”. Is there a way to change that to “RetroArch-[gamefilename]-MMYY-HHMMSS.png”? That way a third party tool can identify the currently running game file by sending the screenshot hotkey, find the most recent screenshot file and parse its name string.

#2

As it loads, it prints that stuff (anything you would find in a log file) to stdout, so if you pipe that to something else, the external program can just look for the lines: RetroArch [INFO] :: Loading dynamic libretro core from: “/path/to/libretro.so” … RetroArch [INFO] :: Loading content file: /path/to/content.ext

#3

[QUOTE=hunterk;28435]As it loads, it prints that stuff (anything you would find in a log file) to stdout, so if you pipe that to something else, the external program can just look for the lines: RetroArch [INFO] :: Loading dynamic libretro core from: “/path/to/libretro.so” … RetroArch [INFO] :: Loading content file: /path/to/content.ext[/QUOTE] Ok got it. I can append that log to a textfile by starting the retroarchprocess with these parameters in Windows:

retroarch.exe 2>> C:
ameoftextfile.txt
#4

I have run into problems with this. Reading the textfile while Retroarch is running sometimes breaks logging to the file. The log file stops midsentence. For example the end of the log file can look like this

RetroArch [INFO] :: Loaded state from slot #22.
Retro

Edit: after more tests it looks like Retroarch keeps generating stdout data but sometimes the log file is not updated to reflect that. When the retroarch.exe process thereafter is closed all the remaining stdout data is written to the log file. That is a problem of course in this case when I want to reliably read the stdout data while Retroarch is running to detect on the fly what game Retroarch loads, when it pauses and so on.

Edit2: I tried it with both cmd and with the powershell in Windows. When there is a redirect command Retroarch stops updating the stdout data (or rather Stderr because that is where the data is coming). If the process runs without a redirect then Retroarch keeps updating the log in the cmd or powershell window. The trouble is that I know of no good way to read those windows directly. Could you hunterk or someone else with Windows see if you can reproduce the problem on your machine?

Here is an quick way to test that. Hit Win+R, type “powershell” then enter. In the powershell window run this (but with the correct path to retroarch)

 "[path to retroarch]\Retroarch.exe" 2>&1 | tee C:	est.txt

Tee is a windows powershell tool that is supposed to enable both displaying output in the shell window and redirect it to a file at the same time. Now load a game and do a few commands in it (take a screenshot, save to a slot, load from a slot, etc). Without closing RetroArch toggle out to windows with alt+tab and check if the powershell window has stopped showing commands. For example the last load from a slot command may not be logged in the window.

#5

Does your program have to read the file or can you just read from stdout directly?

#6

The issue is more that I haven’t figured out any way to read from stdout directly from the autohotkey programming language that I’m using. :smiley: There may be some way, I’m new to stdout stuff. Anyway, I found a workaround now. I used the libcon.ahk library and start the retroarch process using that. The library has a bunch of functions for controlling the special console window including putting the current console contents in a variable. It is so far a very reliable way to parse the real time log that retroarch outputs.