Closed ilonachan closed 3 weeks ago
Given that yuzu/suyu/uyuz/ichigo/whatever other fork people have made from a program that was cease-and-desisted for supporting piracy are all... well, forks made from a program that was cease-and-desisted for supporting piracy... I don't think we can in good conscience support a feature specifically requested to be used with those programs.
Just like with RyujiNX and Yuzu both releasing updates that happened to help make an unreleased game work better, RyujiNX didn't make any mention of unreleased games while Yuzu made explicit mention in patch notes. Nobody can really prove that RyujiNX was supporting piracy. But people can - and Nintendo did - prove that Yuzu was.
I don't see anything good coming from being associated directly to something Nintendo has gone after as piracy. If you'd mentioned only Cemu and RyujiNX, this would have my support. Unfortunately, out of an abundance of caution (admittedly, maybe too much, but you can never know until the hammer falls) I don't think this is a good idea.
I'm not the owner, though. That's just my $0.02
@GingerAvalanche I don't even wanna go into the whole Yuzu thing (which you are wrong about in some spots, but it doesn't really matter) because this is not a Yuzu-related feature at all. As I said, Ryujinx and Cemu have the same type of flag, it's the same level of convenience there, and it's the same amount of unusable right now. Just pretend I'm using Ryujinx, I'd say this is a useful feature regardless.
When someone from a legal team associated with Nintendo comes here and sees an issue requesting a feature to be explicitly used with a program that they've gone after for piracy, and we support that feature, it is sufficient evidence that we are supporting an illegal program. It won't matter that we pretended you were gonna use it with RyujiNX. It will matter that we overlooked that you said you were gonna use it with yuzu. End of.
If I'm being honest, I don't care what you're using. As a pillar of the BotW modding community, I'm not supposed to say that, but I get sick of having to care, sometimes. Use what you want, I can't stop you. In this context, I can't even decide not to implement your feature. I can only recommend that we not do anything that might cause what is possibly the single most legal-happy company in the gaming world to come after us. They employ multiple other companies for no other purpose than to look through things like this issue thread for things to figure out if they need to do something to protect their IPs.
Considering the fact that the time you save on clicking on BotW in the game list is likely eclipsed by the time you wait for ukmm to start up in the first place (if using it as a general springboard as you said) then I don't really see the purpose of this feature. Seems more worthy to pin a shortcut to your taskbar or taskbar menu, as it takes about the same time when ukmm is already open, and a lot less time when ukmm isn't. I just also don't see any good reason not to implement it, aside from the aforementioned caution.
Whatever we may say of a certain emulator, I definitely think it's true that on Linux in general supporting arbitrarily convoluted executable commands is probably a very good idea. I can always let it issue a complaint if you select a known Naughty Program.
That's a rather elegant solution I hadn't thought of. +1
Considering the fact that the time you save on clicking on BotW in the game list is likely eclipsed by the time you wait for ukmm to start up in the first place (if using it as a general springboard as you said) then I don't really see the purpose of this feature.
I still think it'd be useful, because normally I'd just start UKMM once and leave it open (until it crashes), then if I want to play a different mod profile I'll just close the emulator, do the thing in UKMM and press the "Open Emulator" button. It definitely feels more convenient.
If I'm being honest, I don't care what you're using.
Honestly, I think you shouldn't. Me using yuzu has nothing to do with piracy, or with UKMM. Back when there were two choices, I just picked the one that worked for me, and that happened to be the one Nintendo targeted bc the devs were apparently not anti-piracy enough. Sucks for me, but what can I do. I can't use Ryujinx rn (it doesn't detect my controller) so I'm forced to stick with an old yuzu build I still had lying around.
But if it helps, I'll stop mentioning that fact anymore. I could also edit the issue text to not bring it up, because as silly as I think it is, I get the concern.
Nicene already came up with a good solution, I don't see the need to continue the argument.
That being said, the controller thing sucks. I had a similar experience with Cemu not detecting my Pro controller and then my DS4 dying. DS4Windows wouldn't detect my Pro either, so I had to get x360ce for my controller, and HidHide for making sure Steam didn't detect both the real and the virtual controller and break. Not your problem, but maybe some of this info might help with your controller issue.
In UKMM I can currently specify the path to an emulator executable, normally yuzu/suyu or ryujinx for the switch mode (I haven't tested the WiiU side of things, but the code seems to be identical). Pressing "Open Emulator" then opens that executable. But rather than just opening the program into its main menu, I would like to take advantage of the command line option
yuzu -g /path/to/my/botw_game.nsp
, which opens the emulator straight into the game and closes entirely out of it when I'm done (Ryujinx has a similar feature, and so does Cemu). This would be great for iteration and to use UKMM as a general springboard for all my modded play needs; unfortunately this is not currently supported.Additionally my current setup has an issue where calling
yuzu
always prompts the AppImageLauncher to "Integrate" or "Run Once", but integration is broken so I always have to click "Run Once" anyway. There is a method to get rid of this popup, and it's to prependenv APPIMAGELAUNCHER_DISABLE=1
before the actual Yuzu command; this too is currently not supported.It seems to me like the "Emulator Executable" field is treated as the file path for a program which is then executed; the relevant Rust documentation confirms this. But I suggest it should be treated as a command line instead, sent directly to the system shell (eg using the workaround presented in the first example on that doc page). This would allow complex workflows like the ones described above, while losing no previous functionality. There is also no real risk of malicious actors executing arbitrary code, because the user sets the emulator path themself, doesn't usually share or receive UKMM config files which could contain a malicious value, and also triggers the action itself manually.
A workaround in the meantime could be to write the custom command into a one-liner shell script (plus shebang) and then point UKMM to that. But I believe that allowing the user to skip this step will improve UX for very little cost. The help text of the "Emulator Executable" setting could even suggest that this feature exists in the common emulators, for those who didn't know about it.