[Scummvm-devel] Detecting patched games / SCI bug reports

[Max Horn]

Hi Martin,

I have the feeling that you took what I wrote in my previous emails as some kind of offense, an attack against the work you and t
Am 16.08.2010 um 00:35 schrieb M. Kiewitz:

> Hi Max,
> 
> 
>> Anyway, in the end, we are moving in a very grey area here.
>> So no matter what we do, we will leave some people
>> unhappy...
> 
> For SCI, the current commented out versions are "full" pirate versions, which means the crack is even embedded in the resource files. There is no way that a user could patch his legitimate copy that way.

[... I am not actually disagreeing with most you say, but note that Oystein and me are users, too, and I definitely think we could make such a patch. However, this is beyond the point of the actual debate ... ]

> Also most games have the copy protection embedded into the game. For example in lsl5, you need to enter the codes for getting your ticket at the airport. The pirated version of lsl5 crashes here, because the patched scripts are buggy.

Thanks, that's a nice example for one of the problems I listed :). Another example is the copy protection of Maniac Mansion, which involves entering a code to unlock a door. The typical cracked versions introduce a serious bug that affects game play later on (ironically, I think even some officially sold versions include  this crack so they didn't have to ship with a printed manual... or so).


> In this case blacklisting won't matter at all, because even if we didnt blacklist it, it wouldnt work anyway. Same goes for the pirated version of sq4. For those games pirates easily "fixing" ScummVM to make it work isn't possible. I guess if a pirate was competent enough, he would even add the copyprotection patches into our patching code and patch those games on-the-fly instead of removing the detection for patched games.

Nah, we wouldn't want to do anything to actively support cracked games.

> 
> Also startup protections only need to get done once by the user, afterwards it's possible to just load a saved game from ScummVM menu and skip the protection that way. I would personally say that cracking an original game just to skip the protection once doesn't make sense.

Sure. 

So, we all agree that we should not *actively* support such games in any way, and this is a well-established old ScummVM policy anyway, so nothing to debate here.

What we *are* discussing is whether we should have a blacklist of known pirated MD5s. You want this because it would reduce your workload quite a bit, filtering out bad reports much earlier. Much understandable, I think

Others here have voiced concern about this, fearing that this might interfere with people's right to modify their own game data. This is also understandable to a degree, though indeed, I don't see bypassing copy protection as the primary motivation there, but rather things like fan translation, and other fan add-ons, which *do* exist and are even still being newly created. But as you said yourself, those would not be on the blacklist anyway, so this point is moot. Still, there *is* some concern there by people, whether we agree with it or not.

But on the other hand, I am concerned that it would be trivial to turn such a blacklist into a whitelist. Trivial as in: change a few lines (probably exactly one), and you get all cracked versions fully "supported" (including their bugs and crashes, of course), which, in the end, would be another case of a protection system (think DRM) that hurts a few regular users, but not the real pirates... 

Now, it is down to weighing these pros and cons. And so, we get back to my quote from the previous mail:

>> Anyway, in the end, we are moving in a very grey area here.
>> So no matter what we do, we will leave some people
>> unhappy...

...


> 
>> Maybe that's because devs looked at them and didn't have
>> the resources to address them (e.g. lack of time due to
>> being busy fixing other bugs, or lack of the right game
>> version, or or or). Or maybe because they get lost in the
>> tons of constantly incoming new reports? Fact is, those are
>> piling up quicker than they can be resolved, right now ;).
> 
> Believe me, they don't get lost at all. For me I'm fixing the obvious ones as soon as possible and will look in the other ones as time fits and when i'm into those. I also can't fix bugs that only appear in games that I don't own, also some bugs only appear in specific versions and/or the saved games are not compatible. Some bugs are really special and extremly difficult to track down. And sometimes the bugs even happen in sierra sci (and most testers don't check), so they will either get patched by me (which is a pain to do) or won't get fixed at all, but much time will have been wasted (getting to a location within sierra sci means either patching scripts or getting there regulary, both wastes plenty of time).

Absolutely. Everybody who has worked intensively on an engine for some time knows exactly what you are talking about (hence I was anticipating this, and already briefly listed some of these reasons in my original email :). 

All the more reason to ask for help, so that people re-test those bugs, ask the submitter to test whether the bug occurs with the original engine, etc. etc. Some bugs have no comment at all, not even one of these. My email was meant to stimulate other devs here to step in and help out if they have some time. :).

> 
> A perfect example for this is the SQ4/floppy graphic issue. It's not possible to warp there, because you need some stuff in the inventory and gamestate, additionally the saved game is not compatible with my version of the game. So I need to play through the whole floppy version, just for this one bug that happens at the end of the game (!) and may not even happen in my version at all.
> 
> Also please keep in mind that almost the whole SCI team is currently away. Some of the left-over bugs are meant to get looked on by walter and or md5.

Ah, I didn't know that, so I hardly could have kept it in mind, but now I will :). Actually, the way you phrase it, it sounds as if I should have known -- did I miss an email on -devel ?


Bye,
Max