Monkey 1 Ultimate Talkie Edition (released)

[TRoss]

How on earth did I miss this?!
I obviously suck at lurking, too.

[CheeseMeister]

Still love this work. Anybody know the status of this getting native MIDI support in the official SCUMMVM?

[apprentice_fu]

Is there a way to toggle the subtitle mode when using ScummVM with Linux?

CTRL-q quits ScummVM when run under Linux.

Could I use a monkey.cfg created when running ScummVM under Windows?

[LordHoto]

Is there a way to toggle the subtitle mode when using ScummVM with Linux?

Code: Select all

    Ctrl-t                 - Switch between 'Speech only',
                             'Speech and Subtitles' and 'Subtitles only'

[apprentice_fu]

Sorry, my question was not specific enough.

In the "Monkey 1 Ultimate Talkie Edition" Ctrl-q toggles (according to the README that comes with the builder) between subtitles matching the voice overs and the original text, which sometimes is not identical to the voice overs.

On Linux Ctrl-q is used to quit ScummVM, so it seems this toggle of the "Ultimate Talkie Edition" is not usable under Linux.

And Ctrl-t also does not work with the Ultimate Edition. But one can change this mode in the F5 options.

[LordHoto]

And Ctrl-t also does not work with the Ultimate Edition. But one can change this mode in the F5 options.

Why doesn't it work? It should work to switch between voice and subtitles. It will probably not switch between the subtitles though.

[apprentice_fu]

Why doesn't it work? It should work to switch between voice and subtitles. It will probably not switch between the subtitles though.

You ask me ?

My guess would be there was [no (edit inserted)] (old) TSoMI with voices?

I tried it with a 1.7 beta I had installed on a VM with Windows. With Ctrl-q I get a message that the subtitles are changed.
Ctrl-t does not give a message and does not work.

Under Linux Ctrl-t worked with "The Dig" and CoMI (gave a message and changed the mode).

In the detection tables there is no entry for the Ultimate Edition. One has to choose between CD, FM-Towns and Sega-CD version, none of which where voiced.

[apprentice_fu]

I also tried Ctrl-t with the Steam talkie version of Fate of Atlantis, and it also did not work.

Both are Scumm Version 5, the other Games with voice overs seem to be v6 and later.

If I understand engines/scumm/input.cpp Ctrl-t is not supported below version [edit]6.

Should I file a bug, because the Ctrl-t behaviour also affects an official released game?

[Muyfa666]

I got curious; would it be possible to break out the fixes for all the original bugs and apply them to a standard DOS CD-version?

[Serious Callers Only]

NewRisingSun has a few fixes for monkey 1 and 2. But you're going to need data from more than 2 (!) versions of the games and be proficient around Dos and dosbox.

http://www.vogons.org/viewtopic.php?f=7&t=35820

Be warned scummvm often will not support larger NRS patches that take data off 1 or more versions of the game as it considers them 'cracked'. Even if one of the original games the data was taken off had no copy protection.

Their 'logic' is that since some of the data (even if it's a bitmap or something) was from a copy protected version and was imported into a version without copy protection this is a 'new' pirate version instead of a mod. It's what happened with the space quest IV text+audio patch.

In fact, idk if the ultimate talkie versions would be accepted by scummmvm if they include the patches to enable extra sound effects since they were taken from amiga version which was cp... so they probably don't.

The only way you'll get some of this stuff to be supported by scummvm is if the patch is exorcised of piracy-aura by being sold by gog.

But i guess for your particular request it might be possible as long as the target DOS version is not copy protected. But i wouldn't hold my breath if i were you

[m_kiewitz]

Their 'logic' is that since some of the data (even if it's a bitmap or something) was from a copy protected version and was imported into a version without copy protection this is a 'new' pirate version instead of a mod. It's what happened with the space quest IV text+audio patch.

The reason why his Space Quest IV "patch" was blacklisted, is because it's not actually a patch.

I just downloaded it just to make sure and I was able to actually play the patch as a standalone. You won't get speech that way, but text only.

Which means by any definition or 'logic' that's simply a modified pirated copy.

The proper way of doing something like that would be to write a program, which extracts the data from Space Quest IV Floppy and then create patch files, which would be applied against Space Quest IV CD. That way no copyrighted data would be distributed and the user would also have to actually own both versions of the game. At the moment the user has to own none.

Other NRS patches (well actual patches) were blacklisted, because they caused issues. You should not need them anyway (when playing the games in ScummVM), because ScummVM should fix the issues already.

[Serious Callers Only]

Their 'logic' is that since some of the data (even if it's a bitmap or something) was from a copy protected version and was imported into a version without copy protection this is a 'new' pirate version instead of a mod. It's what happened with the space quest IV text+audio patch.

The reason why his Space Quest IV "patch" was blacklisted, is because it's not actually a patch.

I just downloaded it just to make sure and I was able to actually play the patch as a standalone. You won't get speech that way, but text only.

You're out of date. There is a new version that requires data from both games:
http://www.vogons.org/viewtopic.php?f=7&t=44537

[m_kiewitz]

You're out of date. There is a new version that requires data from both games:
http://www.vogons.org/viewtopic.php?f=7&t=44537

I was just able to merge both of my versions using that batch script and start the result using ScummVM. At least my merged version wasn't detected as the blacklisted (effectively pirate) "patch". So it somewhat works.

Unless the result is a perfect match with that pirate "patch", then it definitely won't get blocked by us.

Although as I said - a better solution would be to just extract the later-modified/censored graphics from SQ4 Floppy and put them into the CD-ROM directory as patch files. That way ScummVM would not complain about the data files (resource.*) being unknown.

The SCI engine in ScummVM fully supports patch files. It even supports for example putting 256 color views (sprites) into 16 color games.

Additional note: if a signature mismatch error happens at some point, then that's not us blocking something, but a script bug. The original SCI interpreter didn't check most kernel call parameters, but we do. And if a kernel function is called using invalid parameters, then such an error will occur, so that we can fix it by either adding a workaround or creating a script patch inside ScummVM. We also check for uninitialized temp variables. Something that the original interpreter also didn't do and that sometimes caused all sorts of random bugs.

[Serious Callers Only]

One of the points of these versions is to be able to play in dos, so i doubt any scummvm patch format will be taken up. But that is a good feature for users... i wanted to use it a while ago to replace the butt-ugly Gabriel Knight 1 cd main screen by the floppy one but wasn't able to do it (different resolutions i think).

edit: oh you mean SCI had a patch file format? How forward thinking of them

[m_kiewitz]

One of the points of these versions is to be able to play in dos, so i doubt any scummvm patch format will be taken up.

The original interpreter supported patch files. Some SCI interpreters supported one naming scheme. Some others supported another naming scheme.

We support all of those naming schemes at least afaik.

There is no ScummVM SCI specific patch format. We simply support the patch format, that original SCI supported.

ScummVM even has to, because several Sierra games shipped with patch files.

edit: oh you mean SCI had a patch file format? How forward thinking of them

Yes. It makes sense the more you think about it.

Their resource-bundles are highly compressed. So in case they need to fix a tiny bit of a game for example one script or one picture, they would have needed to modify the whole resource bundle, which would have been a nightmare. Simply supporting additional files to change resource data is way better and the original resource bundles can be kept unmodified. The user can even simply delete one patch by deleting one file instead of having to save/restore resource bundles.

The original interpreter didn't support 256 color views inside 16 color games of course. That's an additional feature that I hacked into ScummVM's SCI at some point just for fun (and wanted to see, if it's possible to transplant Larry from LSL5 into LSL2).

Oh and btw. I just wanted to state that we didn't blacklist that one "patch" for fun. The ScummVM team does not support piracy in any way (see forum rule #0) and we also want to avoid any potential lawsuits. We don't do this to piss people off. If anyone would have contacted us on that matter, we would have told that person to just make such a patch properly, so that we don't have to block it. This one "patch" even caused issues inside ScummVM (at least back then), because the resource files were uncompressed. And we do all sorts of heuristics to identify games and SCI versions, which also includes looking at the compression that was used. Sierra never released a game with uncompressed resource files, so it even confused our code.