Having RPC stay the same until some kind of Python script is ran?

[diamondburned]

Hey, me again. I really wanted to somehow keep RPC in the background having the same info and update them when I execute the Python file. However, unless I do some super dumb hacky shit (terminate python script then run it again), I cannot get the Python script to update without restarting it. Right now I'm stuck in a loop (literally, have to run the script in loop instead of updating it when there's a change.

[qwertyquerty]

What do you mean update? Update the presence? It should update every time you do Client.set_activity

[diamondburned]

Here's my piece of script: python3 -c "from pypresence import Client; client_id = 'id'; RPC = Client(client_id); RPC.start(); RPC.set_activity(whatever)"

The issue with the script is that after python finishes, it stops RPC. What I want is to have RPC to keep alive, and I just need to do RPC.start(); RPC.set_activity(whatever) to update it. Also a way to stop sending RPC of course.

[qwertyquerty]

Well, the script relies on itself being open to keep the rich presence active, is there any reason you can't keep it open while osu! is running and somehow communicate activity updates to it?

[diamondburned]

It's kind of hard to explain, but I'll try. So you said that loops were inefficient, so I'm porting the loops to a script that regularly checks for changes and update the RPC when there's a change, instead of repeatedly pushing the same info over and over again.

Now you can immediately see where the trouble is: "update the RPC when there's a change".

1. If I have while True inside python3 -c "", that will result in the Bash script pausing forever there.
2. I can experiment with python3 -c "from pypresence import Client; client_id = 'id'; RPC = Client(client_id); RPC.start(); while true" & (process to background) and see how it updates
3. Then pops another question: If I python3 -c "from pypresence import Client; RPC.set_activity(whatever)" this, will it still update the old python3 -c from step 2?

[qwertyquerty]

Why not just run the updates on a second thread

[diamondburned]

Because it doesn't actually update :S

1. Just tried running a Python script:

   > ~/Scripts/osu-info/edge ./test.py 
   {"v": 1, "client_id": "435159602318016517"}
   {"cmd": "SET_ACTIVITY", "args": {"pid": 1453, "activity": {"state": "gyrfalcon7\n (#447764)", "details": "Idle", "timestamps": {}, "assets": {"large_image": "osu-large", "large_text": "Linux is better", "small_image": "wine", "small_text": "Lutris + staging 2.15 i386"}, "party": {}, "secrets": {}, "instance": true}}, "nonce": "1524098276.35283899307250976562"}
   (command stays here, doesn't exit)

2. Then tried updating it:

   > ~/Scripts/osu-info/edge ./test2.py 
   {"v": 1, "client_id": "435159602318016517"}
   {"cmd": "SET_ACTIVITY", "args": {"pid": 4378, "activity": {"state": "gyrfalcon7\n (#447764)", "details": "Idle", "timestamps": {}, "assets": {"large_image": "osu-large", "large_text": "Linux is better", "small_image": "wine", "small_text": "Lutris + staging 2.15 i386"}, "party": {}, "secrets": {}, "instance": true}}, "nonce": "1524098639.99868035316467285156"}
   (exits)

Script content: https://images.moddage.site/1524099202.png

I noticed that at once when I run ./test.py it actually updates, the rest of the attempts, no matter how much I spam, it doesn't update. Sometimes it even switches to the <?> box icon with no name.

[qwertyquerty]

The updates need to occur in the same program...

[diamondburned]

So you mean it has to be in the same script? I don't exactly understand what you mean. Also did I mention that I tried manually updating (somehow it works once), and it still takes about 15 seconds to apply the changes?

[qwertyquerty]

Nevermind what I said before, but your code concept of having two separate programs is working fine for me. RPC updates won't be in real-time. Unfortunately, there is nothing I can do about that, but I wouldn't expect it to take 15 seconds... Let me try a few things

[qwertyquerty]

@diamondburned Remember that if you try to do two presence updates within the timeframe of 15 seconds, the second one will simply be ignored.

[qwertyquerty]

@diamondburned also as long as I wait out the 15 second ratelimit, the presence will update for me in about 0.2 seconds.

[diamondburned]

Well that means it's quite unreliable and the most reliable way is still to use a loop :S

Welp guess I achieved nothing today

[qwertyquerty]

@diamondburned I was about to say, go back to the 15 second loop, I was very unsure of what you were trying to accomplish, I assumed you remember about the ratelimit

[diamondburned]

Yes, I do. The thing is, since stuff that are pushed over when the limit's still in place are simply dropped, I should just make it spam, so that the latest packet will have the latest change.

[qwertyquerty]

@diamondburned Don't spam too fast, I would say maybe 1 update per second, no faster. It might be flagged as API abuse if it's much faster.