Of course, nobody would want that!
Up until now I thought that using the datausr.lab (without the .patchr) would have been enough, since we're not distributing game data files, but unofficial fan made additions and modifications. Although, I can see what YakBizzaro meant with "considered a derived work". But since I'm not very familiar with copyright law, I could very easily be mistaken.
If there is someone more knowledgeable, please share.
We're far from distributing, but if we'd share it as a clean datausr.lab, do you think that that's far enough from ResidualVM? Or do you think that it would be better with the .patchr additions? Because frankly I'm not sure how that works... Are the .patchr autonomous files, or do they need to be there side by side with the other files?
Grim Fandango Deluxe - Original Thread [Locked]
Moderator: ScummVM Team
-
ezekiel000
- Posts: 443
- Joined: Mon Aug 25, 2008 5:17 pm
- Location: Surrey, England
This is my own understanding of the copyright issue, I'm not a lawyer.
As long as no original grim files are included I don't thing you need to worry, if you use any of the original textures, animations or models in the new lab then it's a problem.
Modelling copyright characters is IP copyright infringement but unlikely to be a problem as these are to be used in the original game and not a new game.
The Monkey Island speech project needed to use a patch because it needs to modify the original game files where as replacing grim models you are adding files without modifying the original game data.
As long as no original grim files are included I don't thing you need to worry, if you use any of the original textures, animations or models in the new lab then it's a problem.
Modelling copyright characters is IP copyright infringement but unlikely to be a problem as these are to be used in the original game and not a new game.
The Monkey Island speech project needed to use a patch because it needs to modify the original game files where as replacing grim models you are adding files without modifying the original game data.
Well, IANAL (I Am Not A Lawyer), but as far as I can see, any "Manny"-model is clearly a derivative work of the original Manny-model (same goes for the rest of the models and textures etc).
This puts it in what I think of as a grey area, but then again, there are quite a few cases of fan-made "High Resolution Packs" for various games out there (Duke Nukem 3D might be a decent example). I think that you'd be more in the clear if your data was .patchr-formated, as then the data would be clearly dependent on the original data files (and not for instance a solution similar to the OpenGFX-files for OpenTTD, which aim to replace the need for original game data).
Now, the original game did support any amount of data???.lab-files with higher numbers getting higher priority, the only adjustment we did in ResidualVM was to add a "datausr.lab" which had "the highest priority, even above the patch". This is for now the main extent to which we support any user-patching of the game data (but there might be nothing preventing us from for instance making the texture-loader look at file-formats instead of which game is played to select the files to load, and thus be able to load 24 bpp TGAs instead of MATs).
However, preferably, there should be atleast some divide between the two projects, as ResidualVM aims to be a game-engine for the original data (game data which we need to be rather carefull not to share), while Grim Fandango Deluxe aims to improve upon that game data, and thus is rather required to share derivative works of that data. So, in MY opinion (not to be confused with any consistent view among the other devs, as I have not talked to them about it), you should probably set up some web page separate from ResidualVM for the actual "show-and-tell-and-share"-part of your project (similar to the talkie-monkey-island-stuff). Perhaps you could approach Mixnmojo about it?
All that being said, Lucasarts has had a tendency to not care so much about their old IP of lately (but they also tend to change their minds quite often), which means that right now they might not care. Still, they are not as relaxed wrt it as for instance Sierra has been. (OTOH, the Zak McKracken 2 guys are still alive and well, but they did go the route of "keep the characters, but make entirely new assets").
Hope this clears up something, and as I said before, I quite appreciate your work.
This puts it in what I think of as a grey area, but then again, there are quite a few cases of fan-made "High Resolution Packs" for various games out there (Duke Nukem 3D might be a decent example). I think that you'd be more in the clear if your data was .patchr-formated, as then the data would be clearly dependent on the original data files (and not for instance a solution similar to the OpenGFX-files for OpenTTD, which aim to replace the need for original game data).
Now, the original game did support any amount of data???.lab-files with higher numbers getting higher priority, the only adjustment we did in ResidualVM was to add a "datausr.lab" which had "the highest priority, even above the patch". This is for now the main extent to which we support any user-patching of the game data (but there might be nothing preventing us from for instance making the texture-loader look at file-formats instead of which game is played to select the files to load, and thus be able to load 24 bpp TGAs instead of MATs).
However, preferably, there should be atleast some divide between the two projects, as ResidualVM aims to be a game-engine for the original data (game data which we need to be rather carefull not to share), while Grim Fandango Deluxe aims to improve upon that game data, and thus is rather required to share derivative works of that data. So, in MY opinion (not to be confused with any consistent view among the other devs, as I have not talked to them about it), you should probably set up some web page separate from ResidualVM for the actual "show-and-tell-and-share"-part of your project (similar to the talkie-monkey-island-stuff). Perhaps you could approach Mixnmojo about it?
All that being said, Lucasarts has had a tendency to not care so much about their old IP of lately (but they also tend to change their minds quite often), which means that right now they might not care. Still, they are not as relaxed wrt it as for instance Sierra has been. (OTOH, the Zak McKracken 2 guys are still alive and well, but they did go the route of "keep the characters, but make entirely new assets").
Hope this clears up something, and as I said before, I quite appreciate your work.
-
YakBizzarro
- Posts: 37
- Joined: Wed May 18, 2011 8:10 am
I agree with somaen about the need of a separate space for the Deluxe project from the ResidualVM forum, not only for a copyright reason, but also for the obvious technical advantages.
PatchR needs both the original gamefiles (provided by the user) and a patchfile to transform them. The idea is to avoid the distribution of the whole modified file, but only the portions that differs from it.
It' quite easy to use, once you have created a new version of a file, the diffr tool does all the dirty work to create the patchfile.
For example, let's assume for example that you have the new model of mannysuit.3do in the folder "new" and the original one is in the folder "org". You can generate the relative .patchr file with a command like:
diffr old/mannysuit.3do new/mannysuit.3do mannysuit.3do.patchr
Now only mannysuit.3do.patchr have to be distributed, encapsulated in a datausr.lab. The file new/mannysuit.3do isn't required anymore, since ResidualVM recreate it on-the-fly from the old mannysuit.3do (contained in data000.lab) and the patchfile.
PatchR needs both the original gamefiles (provided by the user) and a patchfile to transform them. The idea is to avoid the distribution of the whole modified file, but only the portions that differs from it.
It' quite easy to use, once you have created a new version of a file, the diffr tool does all the dirty work to create the patchfile.
For example, let's assume for example that you have the new model of mannysuit.3do in the folder "new" and the original one is in the folder "org". You can generate the relative .patchr file with a command like:
diffr old/mannysuit.3do new/mannysuit.3do mannysuit.3do.patchr
Now only mannysuit.3do.patchr have to be distributed, encapsulated in a datausr.lab. The file new/mannysuit.3do isn't required anymore, since ResidualVM recreate it on-the-fly from the old mannysuit.3do (contained in data000.lab) and the patchfile.
It really is easy 
Well, once we complete the process I guess we can patchr all of it. At least, I think we should... I imagine we'd save some space too... As for the separate space, I agree, but I'd like to hear from JohnnyWalker first, since the original initiative is his...
On a side note, I might not be that active in the coming month, but I'll try to keep up.
Well, once we complete the process I guess we can patchr all of it. At least, I think we should... I imagine we'd save some space too... As for the separate space, I agree, but I'd like to hear from JohnnyWalker first, since the original initiative is his...
On a side note, I might not be that active in the coming month, but I'll try to keep up.
I don`t remember whitch version is stable work on Mac Os.
It seems two versions earler.
In newer versions game is done, but control keys u, e, s, p, a, d are remap on oter keys. I tryed this on both my MacBooks (MacBook and MacBook Pro) Mac Os respectively 10.6 and 10.8.
For example key i remap on Fn+m.
In older version all is work fine.
I use this [EDITED: LINK REMOVED] version Grim Fandango. It`s version are include russian subtitles.
Sorry for bad english.
It seems two versions earler.
In newer versions game is done, but control keys u, e, s, p, a, d are remap on oter keys. I tryed this on both my MacBooks (MacBook and MacBook Pro) Mac Os respectively 10.6 and 10.8.
For example key i remap on Fn+m.
In older version all is work fine.
I use this [EDITED: LINK REMOVED] version Grim Fandango. It`s version are include russian subtitles.
Sorry for bad english.
Ok, ok. Pirated so pirated.
But this pirated version work fine on previous ResidualVM. And work fine on actual version of ResidualVM in Windows XP. Throubles is only on Mac Os.
I totally held this pirated game on previous ResidualVM. At beginning to the end without any problems.
So you can give me previous release of Residual VM?
A am russian. And I love this game very mutch. But I can`t play it without russuan subtitles. And my children too.
But this pirated version work fine on previous ResidualVM. And work fine on actual version of ResidualVM in Windows XP. Throubles is only on Mac Os.
I totally held this pirated game on previous ResidualVM. At beginning to the end without any problems.
So you can give me previous release of Residual VM?
A am russian. And I love this game very mutch. But I can`t play it without russuan subtitles. And my children too.
Hum ... He is running a pirated version of Grim Fandango and it's bad, but do you really think that his current keyboard mapping problem is related to the fact that his iso is pirated ?
It may be worth a bug report, don't you think ?
Mutabor > As the others said, you should really try to find an original version of the game. And please open a new topic (this topic is not about the bugs found in the game) in this forum to discuss about the mac os version of residualvm.
It may be worth a bug report, don't you think ?
Mutabor > As the others said, you should really try to find an original version of the game. And please open a new topic (this topic is not about the bugs found in the game) in this forum to discuss about the mac os version of residualvm.
I know he started it all, but things are going so slow right now. This project needs a better manager that is not inactive all the time and handles the task allocation. Without a manager i don't see this going anywhere. People who already work on the project will lose interest quickly if the manager is constantly inactive, because things are not progressing. I've seen many projects die that way.Nitrus wrote:As for the separate space, I agree, but I'd like to hear from JohnnyWalker first, since the original initiative is his...
In my opinion Mr. Walker should hand over the leadership to somebody who is willing to take a LOT more time for this project.
Or, you know, instead of starting a process of fighting and mutiny (sorry was looking at EMI yesterday), you could perhaps divide the larger ideas between you, replacing one project-king with another doesn't solve many problems (i.e. you still have a single point of failure for leadership), dividing the tasks among you does.