[Scummvm-devel] Fan translated versions of games

[Max Horn]

Hi Simon, all!


Am 27.11.2010 um 17:35 schrieb Simon Sawatzki:

> The MI patches are NOT supported already. I have tried with current daily build and I get an error due to a present monkey.cfg.

Thanks for clarifying that. It actually would have surprised me if it had worked, and so I was already wondering -- after all they must have deeply modified the game data in order to piggy back speech on it. And that requires modifying the engine, too, of course, so there is no way this can be supported by the merely tweaking the detection code!


> 
> The creator of the patch makes a modified version of ScummVM available. The problem is that he can only provide the source code and the Windows binary but no builds for other ports. So it would be a good idea to include it in the official ScummVM build (however not in the way of MD5's as they might change).

To me it is not that clear cut  whether it would be a good idea to add support for this, or not. In principle, of course I'd say but. But first we'd have to see the code we would have to add. So far, there was no patch submission, and AFAIK the authors have made no effort to get this into ScummVM.
In addition we'd also need to verify whether it complies with our criteria for adding support (esp. on the legal front), but that shouldn't be major hurdle if they did nothing stupid :).

So, if this is important to you, why not go ahead and talk to them about this? :).

> 
> I'd like to add that I feel generaly that ScummVM became "ScummVM for Prisoners" over the years.

Hard words :/.

> 
> At the beginning, all the games were detected by data file names. Every version could be detected. Then the MD5's came. It was a nice additional help for users to get the settings. Still, when the users wanted to set other settings ("wrong" settings like for language etc) it was possible as well as setting up games with unknown entries.
>   Then there was suddenly the point when only games were detected that had MD5's avaiable in the database. If this entry was not present, the detection fails.

This is not the case for at least the SCUMM engines, which tries hard to support good fallback detection, and I know of no fan mod that doesn't work with it, unless it is buggy -- well, there is one exception, namely the speech mod, of course. But that extra code, so the detection code is not at fault.

If you do know of counterexamples, I am very much interested to learn about them!

Other engines also try to provide fallback detection, or even only detect based on filenames. But not all do this, as good fallback detection is hard for many engines. 


> Even when the user tries now to manually set up an entry from a game in scummvm.ini, ScummVM wants to know better and says that the game could not be detected when the player wants to start the game via the available list entry.
>   This a very annoying state for me: Fan patches can not be played by ScummVM, even if they contain major improvements and bugfixes. I would wish that we could reobtain the state that we had before MD5's were obligatory, thus giving more freedom to patch developers and patch distributions.

Can you please give specific examples of fan patches that are not supported, so that we can look into this? Much better than to discuss abstractly, and without any frame of reference. Also, every engine is a story of its own when it comes to support fan patches. Don't make the mistake of incorrectly extrapolating from one engine to another, and from ancient ScummVM versions (which only had a small handful of engines) to modern ScummVM with a multitude more engines.

In many cases, supporting fan patches is *not* a trivial matter of doing lax detection. With lax detection, those fan mods may start up, but they don't necessarily will work correctly. This kind of false support helps nobody. But of course there might be cases where we indeed could support (bug free, clear on copyright) fan mods by improving our detectors. It's definitely good to learn about these, so that devs can look into it.



> After all, doesn't ScummVM have a competition with DOSBox?

No, not at all. Never was, never will be. We aren't business trying to steal market share from each other. We even share some code, and I wish the DOSBox people all the best, I really admire their project. If someone prefers DOSBox for whatever reason, I'll be happy to let them use DOSBox, and vice versa. 


> Or would you prefer if all your users would abandon ScummVM in favour of other solutions because the freedom is taken away and good improved versions are denied to play?

I'll ignore this question, as it seems to me that it is purely rhetorical, and that you are exaggerating our "evilness" a bit here, and also how much users seem to feel "locked in"... :). 

But I am happy to discuss any issues people may have with detection, now that they have been brought up by a user for the first (!) time. As long as the discussion stays civil and objective, that is :).


> 
> These were my thoughts on the matter for the moment. I guess the discussion will heat now up. I hope there will be some suggestions to solve this matter.

Well, your post was indeed written in a way that made it a bit flammable... May I suggest that using terms like "ScummVM for prisoners" risks alienating people? If you goal is generating flames, and making people not want to listen to you, say such stuff. But if your goal is actually starting a constructive discussion and seeing things improved, then a more friendly, positive and constructive attitude will go a looong way towards this. :).


Cheers,
Max