Even though it's sad to see the website go, it's great that you did this for us. Thanks :)


is the best place to keep up with new development the git repo at https://forge.dotslashplay.it/play.it/scripts?

Good,
Less stupid noise and inflated entropy.

I remember I downloaded some patches from the official website (I think one removes the CD-check). But I have no Battlenet account. Do I really have create one? I hate having to make yet another account, though I could make one to throw away...

My fear is if this converts my games into the new free version that is available. I think I read there were some bad things about that version. No local network play or something like that.

Yes ;)
The main entry point to see any ./play.it-related activity would be this feed: https://forge.dotslashplay.it/groups/play.it/-/activity

Impactful news will still be shared on our blog: https://news.dotslashplay.it/ (articles on the main page are in French, but most French articles include a link to an English translation)
And of course the biggest pieces of news will be relayed here, on GOG forums.

---

I’m not sure to get what you call a "log / state file" here.
But I think what you are writing about is what our new in-development parsing tool is going to do: Game scripts database

---

Don’t worry, we’re not leaving these forums, you will still be able to share your jealousy-fuelled hate.

---

No need for any account, this thread gives direct download links allowing to download and install classic Blizzard games without using a Blizzard/Battle.net account: Starcraft - Diablo 2 - Warcraft 3 les Classic sans drm liens installeurs Fr et autres langues

Will you support Arch?

Arch Linux and its derivatives have already been supported by ./play.it since our 2.0.0 release… in June 2017 ;)
It’s the second distribution family we added support for, after Debian and its derivatives.

hmm i missed it then , read only debian and ubuntu derivatives are supported

nice
wish your new webpage will be a success

Good luck with the future project :)

Oh, I just noticed that you're working on Flatpak support. That's great :)

Super! Merci beaucoup! (Years learning French and I can't even write this correctly :-P)


Since the script is just one file, let me rephrase things.
Let me see... each game page has one part that is "fixed" (e.g., game image, description), and one part that is dynamic (e.g., list dependencies).

The dependencies, for example, can be declared in the script, along with other information (like library versions, related to the installation process, whatever). This can be defined as a variable or as a comment, in a fixed format, that can be recognized automatically. It could even be added there automatically.

The website would, regularly, parse these scripts and update the game page whenever needed (a build system like scons can do that).
If you want to support another disto, you simply adjust the template to call yum instead of apt, for instance.

What I'm talking about dependencies goes for instructions, targets, etc.. And since you are generating the build instructions, you could even test them automatically on each system to make there are not surprises.
You can even show the instructions for just one distro (for cleaner pages), that the user selects.

You could even use all this information to generate statistics, like "what games depend on X"? "X just got updated, what games do we need to test against it?" "Can we use Y instead of X? What tests do we need to run?"

After the initial rollout, 97% of the developer's time is spent just on getting the script to work.

I'm sure you thought of something no worse than this. You are all smart, experienced and capable people. I was just wondering if this is the way you decided to take.

No promise here, but this is one of our objectives for the future 2.14 ./play.it release ;)

---

Now I get it, this is indeed what we have started working on ;)

Our old API did provide this kind of information (in a very limited way). And actually still does, I stopped its development but did not take it offline.

The new tools we are working on should allow this too.

---

For now we are focusing on the first step only: to scan the games script collection, and generate a database from their contents. This database will then be used to build a collection of tools/interface upon it, but we will not start the working on these tools before the database generation itself is fully automated.

I've just written a python script to compare the MD5s from the play.it scripts with the game files on my PC to see which ones I can install. That could be a useful tool for users. (Edit to say I'm not sugesting my script, it's bad!) Or even to compare the game names too to see which games have support but for a different version (for the people who know what they're doing and can help update them).

On forge.dotslashplay.it/play.it you said you don't have any way yet of including game files with the same name but different MD5s. No idea how often that is an issue (beyond Fallout Tactics) but if you do plan to make that work don't forget to make allowances for it in the database now to save you having to change it later!

One of our contributors is working on something that sounds similar: build.it

This is a Python wrapper that:
- scans your collection of game installers
- uses ./play.it to generate .deb packages for the supported ones
- generates a full APT repository from the generated packages, allowing to to install them from any computer having access to this repository

Our database generator is already compatible with identical names for multiple installers, it uses the MD5 hash as the only unique property of an installer.

I guess it would not be very hard to update ./play.it itself to support these… Now to find some time and motivation to work on this update ;)

Hey, that is nice!

I imagine that most game updates do not break the ./play.it scripts. Has anyone done a study on this? Maybe the update is just a small change on the executable and a string update with the new minor semantic version somewhere. Or some change in a texture or geometry file somewhere. Are these not the norm?

I can imagine that it would be possible to, automatically, detect if the repacking process breaks or if the new installation of the game does not crash on startup. Manually it could also be possible to see if the game stars normally -- I don't think it would be too taxing to test this. More than these tests, maybe you can leave it to the users to evaluate and get back to you in some convenient form.

But my point is: I think that the MD5 and name check is nice to provide a safeguard, but should be easy for the user to skip them if desired (perhaps it is since the last time I tried). Unless there is some data proves me wrong, and I wish some was collected for or against this idea.