[Feature, duplicate of #78] Detect ports already on system & allow to create local packages

[GregTheMadMonk]

It would be very nice to see an option to not re-download the same port for every game individually.
For example, I already have GZDoom installed on my system, so it would make sense to run supported games through it.
Addditionally, for games lacking an official package, it would be great to be able to write manifests manually in ~/.config/luxtorpeda subfolder.

The way it can work is by separating packages into "games" and "runners", kind of like in Lutris, with game first launch sequence looking something like this:

1. Click play. luxtorpeda downloads the game manifest.
2. Game manifest, instead of command, now contains an array of compatible "runners", and looks something like this:

{
	"supported_runners": [ "gzdoom", "zandronum" ],
	"options": {
		"wad": "base/DOOM.WAD"
	}
}

3. Popup: like windows "Open With": top items are runners marked compatible by game manifest, followed by a drop-down list of all other runners (we don't know, maybe game manifest wasn't updated to include a brand new runner in its supported list yet or you've written your own one and put its manifest into ~/.config/luxtorpeda subfolder). In this case, the popup should look like this:

┏━━━━━━━━━━━━━━━┓
┃Select runner	┃
┃━━━━━━━━━━━━━━━┃
┃ GZDoom 	┃
┃ Zandronum	┃
┃ 🮦 Other	┃
┃ DoomRTX	┃
┃ NotEvenDoom	┃
┗━━━━━━━━━━━━━━━┛

4. Download manifest for selected runner. It describes how to find one already present on the system, where to download binary from, and how to treat parameters. It may look something like this:

{
	"find_cmd": "whereis gzdoom",
	"source": "https://download.gzdoom/free/no/registration.tar.xz",
	"version": "0.0.0",
	"cmd": "%binary% -iwad %wad%" // %wad% implaces wad option passed from the game
}

5. Offer to download the runner or run an already installed version, if find_cmd found one. If find_cmd failed, maybe offer to pick binary manually from filesystem.
6. If needed download/install the runner
7. Gaming time 😎

It's already possible to run ports via steam by modifying the game command line. E.g., to play Shrine II, I do:

run-game gzdoom -iwad shrine2/ShrineII.ipk3 # %command%

to ignore Steam's attempts to run a GZDoom game in Proton and run native GZDoom (run-game is a script that runs the following command with MangoHud and Feral GameMode). And while this is certainly an option which doesn't even rely on luxtorpeda, for a project like this the feature I've described (IMO) is a must-have.

P.S.: Ok I understand that this can be not what the project aims for and may sound more like "trying to tell you what to do" kind of thing, but believe me, it's not the intention, and I actually think this enhancement will make a nice addition to the program

[d10sfan]

One thing that's different from the original project is that when you download a common engine (such as gzdoom), it only downloads it once. So for the case of gzdoom, the first game that uses it will download it, and then every other one will use that same download.

It sounds like what you're asking for is a way to launch a game with luxtorpeda using an engine installed on your system as a whole, correct?

That's doable somewhat today by disabling the automatic download and then editing the cached packages.json to do whatever you want, although that isn't exactly user-friendly.

Some of these engines have some configuration or other setup that may not work correctly for an engine installed on the system, so that'd end up falling on the user to fix any issues like that.

What would be some of the benefits to running a system version of the engine versus the packaged one?

As well, what would be some examples of where an engine isn't supported that you'd be interested in? Mainly asking because normally those can be improved upon by package requests so that they can be "officially" supported.

[GregTheMadMonk]

Thanks for replying!

One thing that's different from the original project is that when you download a common engine (such as gzdoom), it only downloads it once.

Oh ok, Didn't notice that because was looking at original project package files... sorry. So, this is the big part of this issue out of the way...

It sounds like what you're asking for is a way to launch a game with luxtorpeda using an engine installed on your system as a whole, correct?

Yes.

Some of these engines have some configuration or other setup that may not work correctly for an engine installed on the system, so that'd end up falling on the user to fix any issues like that.

Well, my guess would be the if the engine is installed through, for example, a system package manager, the package maintainer is most likely to already to aim for to support as much games/mods as possible, and a player probably will understand (and should be warned) that what they're trying to do may not work. Can issues appear as a result of using steam runtime instead of your system runtime (I don't really know ho this works, so sorry if it's a stupid question)?

What would be some of the benefits to running a system version of the engine versus the packaged one?

Well, first of all, not having two versions of the same program installed on your computer :) Some (many?) users may find it bloat, and I think we both know how much people like to take this word more seriously than it really should be taken...
Some may prefer running a bleeding-edge-up-to-date version of engines (like folks on rolling releases, or people manually building git repositories, or engine developers who maybe would like to test their port with steam games) instead of waiting for the package to get updated.
Also, no one would want to go through the process of requesting a package for some unpopular free mod off steam they found to kill some time and are not even sure will play for more than 20 minutes.

As well, what would be some examples of where an engine isn't supported that you'd be interested in? Mainly asking because normally those can be improved upon by package requests so that they can be "officially" supported

Since you've explained that engines don't work now the way they used to, it's not even so much about the engines anymore. It's about being able to launch an unpackaged obscure game without waiting for a package or going through a process of requesting it. Gaming should be easier than this, and once you've installed an engine, you should be able to at least try an launch the game with it.

As an example, I've given an example of the way I launch Shrine II, which uses GZDoom having to manually edit the command line to run it in a native build. But I HAVE GZDoom installed, and luxtorpeda has GZDoom supported, so why not just give me the popup with the list of all engines and offer to write in arguments manually? I know, this way the process for the user would be similar to manually editing the steam command-line options, but:

1. The user can test luxtorpeda engine builds (if not useing a native version) without having a package in the official database
2. The user can be offered with an option to submit the generated package for revision, without going through the manual request-package-submit process. Unrevised packages may also be made available to others (the last, if implemented, should be manually enabled, like how AUR works). This can significantly speed up the process of providing support for less popular games.

And for my final word, come on, it's just a cool feature to have. I know this is not a must-have, but definitely the one that would make the program feel more complete. For me personally, and for many other people (probably yourself included), usage options in software = good. As you've already admitted, all this is possible by modifying the local packages index, so why not replace this hacky solution with a two features one of which is just a quality-of-life improvement for people who don't like duplicate programs on their computer and the other can potentially speed up package creation process for everyone?

I hope what I've written makes sense.

[d10sfan]

Interesting, I'll see what may be possible for this in the future, whenever I have a chance

[edit]
This should be available with this change: #65 (comment)

This allows you to have a user packages.json that overrides the defaults inside the packages.json that is controlled by the packages repo

[d10sfan]

This should be available with this change: #65 (comment)

This allows you to have a user packages.json that overrides the defaults inside the packages.json that is controlled by the packages repo