Talk:Unity Games Working On Linux (User Ported)
- Just saw there was a discussion posted here. Can you elaborate, Boss ;)? I've seen that User:Interknet took some care about the page since then, so might as well be fine. If you have anything in mind, I guess none mind if you try to edit something, as that's what's wikis are for after all :). I look on the page from time to time, but at this moment it's mostly Interket's side project, though I'm glad that this list exists, as it's currently the only editable place where users can document their findings on running the Unity games natively, with previous info being scattered only in forums and other sources linked in that article.
- As far as page naming goes (I assumed that's what you meant by title?), I think that a few pages on the wiki could use some name changes actually. We don't have a guide to follow, with it being a relatively small wiki after all, and some pages names are either unneedlessly lengthy and vary with capitalization, particularly from the Main Page#Games Lists section. Maybe follow the wiki style and rename them as "List of whatever"? It's a bit the whole wiki related issue though and for the time being, I don't mind the page sitting under the current name until something is agreed - or to be moved to something else if someone feels so, as long as the links leading here will get corrected :) Faalagorn☎/✓ 23:01, 5 June 2017 (UTC)
- I'm glad to see how far this page has come compared to when it was started. I kind of gave up on the whole thing after my last edit to the page because I got addicted to a game that only worked on Windows and have been tainted. Anyway, title wise if someone can suggest a better one then I don't see the problem. Hopefully the page continues to grow and it to be a team effort. I'll possibly end up with results for games not listed here at some point. Wish there was a directory with all the Linux launchers for each version of Unity continuing from the last ones though, less painful to test 'em all. --Interknet (talk) 22:10, 19 July 2018 (UTC)
Single or multiple tests per game?
I've mostly finished merging the loose test entries from the Seegras' blog and adding the ones from GOG forums. I will add a few more loose tests and test a few games. So far I've kept one entry per game, though I made a separate entry for Republique, as the error encountered on Steam was different than the one encountered on GOG. Theoretically they could be merged, but more of such situations can pop up from the differences between platforms, OSes (porting from macOS) and so on – also in case one game version works and another doesn't it could be beneficial to keep both for historical reasons. Some people can opt to play an old "native" version instead and it is even possible to download an old version of the game from Steam – or have an old version installed that they don't want to update for whatever reasons.
So, I was wondering whether or not should we follow the Performance impact of Mesa glthread and WineHQ AppDB and keep multiple test entries from different people/situations? IMO the current table fits more of a style similar to them of test results done rather than being de facto a database of a game working so it could be a good decision to list multiple tests over time. Of course it would still be possible to update old result with new data, if the differences are not significant and someone would just want to "bump" it. Opinions? Faalagorn☎/✓ 04:17, 15 December 2017 (UTC)
I was thinking whether it would be beneficial to have some extra information added to the table – namely the executable (project) name of the game for reference and also the link to the logfile after instructing to run the game with
-logfile file.txt and link to the files used for testing for troubleshooting? That way someone more avid could potentially assist the problems of games not running further. Faalagorn☎/✓ 22:25, 17 December 2017 (UTC)
EDIT: And also some way to note whether or not the 32-bit or 64-bit versions were tested, probably. Faalagorn☎/✓ 23:48, 17 December 2017 (UTC)
Source of mscorlib.dll
I tried using this method, and mscorlib.dll wasn't provided in linux64_withgfx_nondevelopment_mono. Where is it supposed to come from?