Make changes to a game obvious and/or discussable

So, I created earlier, which runs on the “big 3” PC OSses, and I followed the bold red warning in the submission form to not even mention any non-linux platform if there’s a native version, a decision I personally disagree with btw, but nevertheless added ONLY the “Linux” tag.

Now I got an automated E-Mail from the website telling me it’s been accepted, just to see some moronperson considering themselves helpful and/or smart replaced the “Linux” tag by a “Windows” one, probably after a single glance at their horribly outdated website, even though both Steam and GOG already sell the (working; i played it) native version.

this means I had to suggest a change to a game I just submitted myself to restore the information some moderator thought they were “fixing”.

I therefore strongly suggest all of the following:

  • not changing random information without people’s notice (usually there’s a reason the information is there)
  • devising a way for admins/mods/whoever’s doing such stuff to actually contact the suggesting person instead of having the website send an automated email that doesn’t even mention the changes made
  • devising a way to log changes like this to be able to actually see who updated (or butchered, in some cases, as we see) what information for what reason and to be able to, if required, apply points 1 and/or 2 if they have been mistaking it.
1 Like

+1 for these suggestions.

I completely agree with the proposed changes.

The current system is absolutely horrible.

I’m actually admin, but only so I can change my Blizzard installers without having to poke someone to accept my change. And even getting my own installers in there and published is so much work, that I have said I’m done with it. If need arises, I might make another update…but most likely I’ll leave it like this for now.

Thing is, you can make scripts locally and test them…but there is no way you can upload them to the website like that…you have to copy paste it in “parts” after indenting parts differently. And don’t get me started on the admin side.

Now, as Strider has pointed out before: Lutris was never ment to be a Wine prefix manager. Its just a small part of Lutris. And Lutris gained a lot of popularity when they were the first to get Overwatch running on Linux easily. However, there are limited devs, and only so much time. So unless people step up and start contributing to Lutris (everything is on Github), it will take time to get everything sorted. And priorities have to be made.

you will notice i never even mentioned wine prefixes and installer scripts in my original post (because the game that prompted me to post is, even though an unknown admin seemed to think otherwise, not a windows game).

and that’s exactly my point: everyone seems to build the “wine prefix manager” part of the lutris client like crazy while the website is missing such essential features as “show me who messed with my stuff and why” or a way for the admins to contact the suggesting user before messing with their stuff.

implementing a logging/versioned system like that not only would allow us to roll back flawed installer changes but also see when something had to be changed that might be relevant for others, or just to see which admin needs a lecture on “not everything is a windows game”, like in the example in my original post :stuck_out_tongue:
also i probably don’t have to tell you the security implications of not logging changes to the payloads of what amounts to a “remote code execution engine” like lutris.

Honestly, making the installers managed through git should resolve a lot of the issues and sounds doable.

1 Like

not just installers, even whole games. just make a folder structure like this:


($INSTALLERVARIANT means things like “GOTY bought on GOG” or patches etc.)

which would also solve all kinds of ugliness we currently have with developing the installers, and the git infrastructure combined with a nice web frontend will solve all kinds of logging/rollback/blaming issues.


Indeed, I’ll fiddle with it a bit and see if I have what it takes to test that idea at least :slight_smile:

well the easiest (and ugliest, but would work as a start) way would be to replace the database for this information by just getting the values from such a file structure, and saving it to files followed by a git commit -am '$user updated {game information/installer} for $game' call when changing stuff, and then just slap some ugly readymade git web frontend on it as a quick way of testing :stuck_out_tongue:

That wouldn’t really need a test though :smiley: I don’t see how that wouldn’t work.

It’s more about testing if I have the skills to implement that within the already existing, which I doubt I have

well everything except the ugly web frontent would be 1:1 what already provides as a feature, so when that’s working parsing the output of git log --format 'something smart and easily parseable' (or getting a library to do it) and putting that into another view (because the existing doesn’t have anything similar afaik), and probably cached (and invalidate at each commit) to prevent having to walk the repo all the time when googlebot comes along, should be doable, but i don’t know how, never looked into how this website was made.

but actually using a less-ugly readymade frontend might be enough, we’re using a 3rd party forum already, and you wouldn’t have to see the git frontend as a normal user most of the time, just when you click a “show history” link on a game or installer.

Can someone summarize the discussion and create a github issue from it?

You can also add the BMU2018 tag if you want.

did that:

1 Like