@Albedo,你可以在命令行运行Wine游戏助手进行诊断,打开终端,粘贴以下命令并回车:
/opt/apps/net.winegame.client/files/bin/winegame
如果wine游戏助手窗口没有打开,终端上显示了错误信息,可以截图发到这里。
@胡椒舰长,是。
@SCV,更新到0.5.10.3应该可以解决问题。
已知问题6
DXVK的卸载方式与wine 7.0+不兼容。
@穴儿,好吧,确实有一些细节上的不同,
fastboot flash boot_a magisk_patched-24100_03mKX.img fastboot flash boot_b magisk_patched-24100_03mKX.img
我已经更新到 https://hu60.cn/q.php/bbs.topic.102529.html?floor=0#0 了
@穴儿,答案是 https://hu60.cn/q.php/bbs.topic.102529.html?floor=0#0
你甚至都没试一下就来问了?
@罐子,我之前就看到了,但是我还没有解决问题的思路。
@bigfuji,呃好吧,我没有麒麟990,所以我没测过
如果你测了不兼容,那应该就是不兼容吧,我可能要把“兼容麒麟”的提示去掉了
@bigfuji,你的CPU是什么?
飞腾(FT-2000/4)只能安装标有“ARM64专用”的项目。
鲲鹏(kunpeng 920)只能安装标有“64位exagear”的项目。
龙芯只能安装标有“龙芯架构专用”的项目,目前只有“启动自定义游戏”一个。
补丁 7b625b1 没有完全解决问题,它只兼容 winehq-devel,不兼容 winehq-staging。
我的测试方法:
安装 deepin 20.5,安装所有更新。
编译安装 https://github.com/winegame/dde-dock/tree/5.5.12-fix-wine-tray (带有 7b625b1 补丁的 5.5.12 版本)。
重启
dde-dock
:killall dde-dock
安装Wine游戏助手:
sudo apt install net.winegame.client
打开 https://winegame.net/games/wine-tray-test/ 安装“2a. winehq-devel,托盘图标无反应”和“2b. winehq-staging,托盘图标无反应”,安装到不同的目录。如果在网站上点击安装没反应,可以在Wine游戏助手内搜索:
启动2a和2b,会发现2a的托盘图标可以点击,2b的托盘图标不能点击。
同样的,带有wine-staging补丁的 lutris wine、proton 等均不能点击。
已知问题3
因为打不开第二个安装窗口,
requires
和extends
的自动依赖安装功能无法正常工作。该问题由0.5.9版本引入。
在统信发布修复更新之前,提供一个不太优雅但能用的缓解措施:
- 安装stalonetray软件包:
sudo apt install stalonetray
- 启动并结束
stalonetray
程序,它会从dde-dock
处夺走wine托盘图标收纳能力:stalonetray &; sleep 0.1; killall stalonetray
- 现在再启动wine程序,托盘图标就不会被dde-dock接管,而是直接漂浮在桌面上,并且可以正常交互。
我得到一个积极的响应:
我以为我上个issue被删了,原来是转移到这里了:
https://github.com/linuxdeepin/developer-center/issues/2262看到了相关修复:
https://github.com/linuxdeepin/dde-dock/commit/7b625b1ab7bcc32bf15382e01267d096858c89d4希望这个补丁尽快发布到 UOS / Deepin 发行版中,让wine游戏助手用户早日摆脱托盘图标噩梦。
@SCV,更正,实际上set_regedit_file并没有发生在默认wine前缀(~/.wine),还是发生在你指定的wine前缀。只是执行这条指令时,会把~/.wine也顺手创建出来。
也就是说,这个Bug对功能没有影响,你说的问题可能是其他问题。
如果你在winegame.net网站上编写安装脚本,必须先点击“保存草稿”,然后点“测试该脚本”才能生效,不保存直接测试就还是未修改时的脚本。
或者你可能是受到了这个问题的影响:
修复了依次安装多个游戏时,为前一个游戏设置的函数库顶替可能错误应用于后一个游戏的Bug。如果你曾经在终端看到过如下提示,说明你触发过该Bug:
DLL override 'n' mode is not valid
已知问题1(已在0.5.10.3中修复)
0.5.10.2有一个重大问题,执行注册表文件的操作(set_regedit_file)会发生在默认wine前缀(~/.wine),而不是用户指定的安装文件夹。
lutris 0.5.10.1 也有这个问题。
看起来我得自己修复一下,并且提交给lutris。
更正,实际上set_regedit_file并没有发生在默认wine前缀(~/.wine),还是发生在你指定的wine前缀。只是执行这条指令时,会把~/.wine也顺手创建出来。
@SCV,不行,因为wine安装目录lib文件夹里的dll会被优先使用,除非你先把这里的dll删掉,位于wine容器里的内建dll才有机会加载。但是这样就修改了wine安装,影响了其他程序。
由于无法调整这个加载顺序,想在不修改wine的情况下实现加载其他dll,只能伪装成“原生”。