Hello @ThisNekoGuy, Proton is primarily intended to be used as part of Steam for Linux. Third party packaging that separates the downstream fork of wine used in Proton from the rest of the project is not supportable.
If you can reproduce this issue with Proton from Steam or a full build of Proton, then there would be something for a Proton dev to ponder.
Closing as not supportable.
Considering this is the Wine fork part of the dealio, not Proton, this does make things a bit confusing.
I wonder if the issues area here should simply be disabled if issues are not expected to be reported here?
That said, perhaps this should be an issue of its own, but I got here from an issue from a very different places as you might imagine. :]
if issues are not expected to be reported here
They are expected to be reported here but ONLY if issues occur while using Proton within the Steam ecosystem. If you can reproduce it by running the game from inside Steam (e.g. by adding it as a non-steam game), the issue probably won't be closed. Every downstream fork of Proton should instead use its own issue tracker.
This isn't Proton yet though, but the Wine fork before it, and if I remember right-like, this issue doesn't seem to be happening with vanilla Wine so it's already introduced somewhere in this fork, before the Proton sauce added on top of it, meaning I think this should be a useful report/thing to look into here.
This wine fork has special patches to work within Proton, also considering the Steam runtime it's supposed to run with. Proton is not just some sauce added on top. It's a runtime container, and this wine fork runs embedded in it with some additional, Proton-specific patches and fixes (one prominent example is forcing a fixed user name so prefixes become portable between different unix users, some other patches are tailored to the exact libraries which the Steam runtime provides). This also includes special behavior fixes which are applied depending on the steam ID of the game. So to test it, you'd need to at least run the game inside the bwrap container that provides the Steam runtime, and maybe also provide the steam ID via environment.
If this is especially about the wine-proton package in Gentoo, that ebuild should probably revert some of those patches before compiling. But still, that build won't run inside the Steam runtime container then, and lacks the proper environment setup (which can actually affect time keeping in video streams).
And maybe exactly that is the problem here: The build maybe requires some behavior of a library from the Steam runtime which the native Gentoo environment does not provide. Thus Valve is correct here by saying that running outside of the Steam runtime is not supported. And Valve is correct by saying that it's a downstream fork because it is compiled within a different build environment and run within a different runtime environment - even if the ebuild compiles the package unpatched: It's essential to this wine project to be run inside the Proton environment as provided by Steam. Maybe Valve could properly describe it on the project home page, and maybe add info to the new issue page about when exactly an issue could be reported here, or where to go otherwise.
Does this problem also happen with the Tkg or GE builds? Those are properly patched to run outside of the Steam runtime, and they have their own issue trackers. If it can be reproduced with those versions, it should be reported there. Chances are high that someone then discovers a similar problem within the Steam runtime and may suggest a patch here for Valve to merge or upstream to wine HQ.
If the problem can be reproduced by running it inside the Steam runtime container (which should be possible by adding the game as a non-Steam game to the library, and adding the Gentoo build as a compatibility tool), then it's probably fine to report here (or in the Proton issue tracker).
I'm also sure, if a patch would be provided to fix the problem, and it applies only to this wine fork and does not apply to upstream wine, Proton devs will consider it for merge into bleeding edge if it looks fine and doesn't cause any obvious problems. They've done so for one or another patch I've provided in the past, and which couldn't be applied to upstream wine. But they cannot support or test/fix problems here for non-Steam games, especially if not even running inside their tested and supported environments. They rely on upstream wine for that.
Right, my understanding so far was that issues not present in vanilla upstream WineHQ Wine, but present here, would be valuable to catch before the Proton additions, but it does seem like that is not the case.
I'll try to make sure that it is also documented clear-like in any related (Gentoo Linux) documentation.
Thank you.
Yes, that's probably the way to go. Each custom Proton variant (or rather its wine build) carries a patch that explicitly logs to the wine log not to report problems to Valve but to a different issue tracker instead. Usually, a readme asks the same. It's up to the maintainer of those "forks" to fix the problem by pulling patches from upstream or add an own patch, and if that works, it can be suggested here as tested and probably working.
That said, I've installed said ebuild on my own systems some while ago. But I've never used it yet because I'm not sure if it reverts some of the Proton-specific patches (like static username, which makes prefixes incompatible with upstream wine builds).
Is there a way to actually make it a compatibility tool available for choice inside of Steam? That may be nice.
proton 9.0x1 2024-11
I'm not sure as to the reason why but, when using this (the Valve fork of Wine - 9.0-3), videos that play in the GOG re-release of Alpha Protocol play at a substantially accelerated rate for some reason. Some videos loop because they're designed to, but this causes many others (like in-game TV news broadcasts) to quickly end before dialogue is even finished and causes lip sync to break for some videos.
This doesn't really affect the game's playability, but it comes off as very strange (to witness) given I know the game isn't supposed to behave this way.
Side note (unrelated?): the game hangs when attempting to close it from the main menu and gives a message like this and with a 100% reproduction rate: