Initial Auxillary Command Proof of Concept #1227
Conversation
|
I am so, so sorry it has taken me so long to review this!!
I would like to ask though, while I entirely understand the purpose, what makes this different from custom commands? They run in the same prefix as the game, and can run before, or after (inject), or standalone. I am reviewing the code on my phone, I basically wanted to reply to say I've seen this and thank you for the work, and to get a bit of discussion going. Maybe I'm missing something for what this is meant to accomplish, but I thought we wanted multiple start commands?
Feel free to just copy the strings you have for By the way, it seems like your branch is slightly out of date with |
|
i felt like custom command was a little too co-mingled with being able to replace the main launch command, as well as launching alongside of it. I thought it would be easier to add a new option, and it would be easier to add a multi-select to this. ( skill issue on my side ( more so laziness ) i'll redo it anyway you'd like though. what i was getting at with my explanation above was a lot of games, if they write to shared memory, a named pipe, the event log or anything that isn't accessible from linux, you have to run something along side the game in proton/wine, in order to bridge that resource over. Or if you don't, any mod or companion app that you might want to use, will be windows based, and also have to run inside the proton/wine space. So it does make sense that you'd want more than one of these auxillary commands and I should expand this pull request from the get go to do so. also: yeah, i see the diff is really noisey, i don't know why i didn't notice that. I'll try to redo it and figure out what went wrong. |
This is my first draft from the results of our previous conversation about multiple startup commands.
I turned it into something called "Auxillary Command".
This stems from a need in the simracing community (and flight sim community). These games often have shared memory files which contain continuously updated data from the game. To make these shared memory files accessible from Linux, we need to run a helper program in the wine/proton process. This way companion apps can run natively on Linux and have access to the shared memory.
Here is more info about the status of shared memory with wine.
https://bugs.winehq.org/show_bug.cgi?id=54015
Outside of the SimRacing and Flight Sim space, there are other games which might rely on Named Pipes or Shared Memory. Basically it could be used for some sort of compatibility/companion app that needs to run alongside at the same time (or before) the game actually runs.
I know it isn't ready yet, this is the first draft, I'm just getting the ball rolling.
P.S. How do i go about doing all the translations?