Opened 13 years ago

Closed 13 years ago

Last modified 12 months ago

#2810 closed defect (fixed)

MORPHOS: Asking for "SCRIPTS.CLU"

Reported by: SF/xzit Owned by: fingolfin
Priority: low Component: Ports
Keywords: Cc:
Game:

Description

i have posted some info on the forum.

http://forums.scummvm.org/viewtopic.php?t=2154

XzIt

Ticket imported from: #1548205. Ticket imported from: bugs/2810.

Change History (22)

comment:1 by SF/xzit, 13 years ago

Sorry about the Forum link, here is copy/paste. :D

When starting Scummvm 0.9.0, everything is fine. all my games work. except one "Broken Sword 2".
When i try to start it, it asks for a file named "SCRIPTS.CLU".

I went into the game dir and found the file... seems it can't find it anywhere, even when i try copy it some other place.

The thing about this is that in the version before 0.9.0 i got this error never had it before.

X

comment:2 by SF/sascha_silbe, 13 years ago

I've got a similar problem (asking for scripts.clu) on Linux with any of the versions I've installed (0.8.0, SVN from some months ago and SVN from today).
From what I've seen on some forum this file should have been on the CDs, but it isn't (german version of the game, called "Baphomets Fluch 2").

comment:3 by eriktorbjorn, 13 years ago

> I've got a similar problem (asking for scripts.clu) on
> Linux with any of the versions I've installed (0.8.0, SVN
> from some months ago and SVN from today).
> From what I've seen on some forum this file should have
> been on the CDs, but it isn't (german version of the game,
> called "Baphomets Fluch 2").

Are you quite sure you've checked everywhere on the CDs? The
reason I ask is that the file name "SCRIPTS.CLU" is not
hard-coded in the Broken Sword 2 engine. It gets all the
information about where each game resource (sound,
animations, etc.) is located from three files:

* resource.tab which maps the unique resource IDs to
resource file number and ID in that file.
* resource.inf which maps resource file numbers to file
names. (It's a plain text file, actually.)
* cd.inf which tells where each resource file is supposed to
be found. (CD 1, CD 2 or hard disk.)

In other words, if ScummVM expects to find SCRIPTS.CLU, the
original interpreter would have as well. In the English
version, it's expected to be on the hard disk, so I would
guess it's on CD 1 somewhere.

(I have no idea why it's not working on MorphOS, though. I
suspect a bug in the file handling code specific to that
platform.)

comment:4 by (none), 13 years ago

AmigaOS4-build

Same here, BUT only if the video files reside in the main
game dir. As soon as i move them into a subdir called
"VIDEO" SCRIPTS.CLU is found again, but no video is played
(only NARRATOR dummy comes up)

comment:5 by fingolfin, 13 years ago

Priority: normallow
Summary: MorphOS: Asking for "SCRIPTS.CLU"MORPHOS: Asking for "SCRIPTS.CLU"

comment:6 by Kirben, 13 years ago

The Amiga file system backend doesn't actually check if a
directory exists in child().

The MorphOS file system backend doesn't have any code for
child() at the moment.

So would be best to contact the current maintainers of both
ports, since file backends need to be updated.

comment:7 by Kirben, 13 years ago

Does this problem still occur in AmigaOS4 builds of ScummVM
0.10.0svn? as changes were made to the Amiga file system
backend about a week ago.

comment:8 by (none), 13 years ago

It's gone, as far as i can see, thank you

But i have still the problem with the (now not even
the downloadable MP2's) not working video files

I'll file a new bugreport

comment:9 by (none), 13 years ago

See bug #1565633
https://sourceforge.net/support/tracker.php?aid=1565633

Maybe the MorphOS bug can be squiahed with solution,
too? MOS and AOS aren't that far from one another.

Sadly i cannot test nor patch, i don't have MorphOS
and no ability to code :-/ ...anyone?

comment:10 by fingolfin, 13 years ago

Owner: set to fingolfin
Resolution: outdated
Status: newclosed

comment:11 by fingolfin, 13 years ago

The issue reported here has already been fixed. If you encounter other problems, please file new seperate bug reports.

comment:12 by Kirben, 13 years ago

Owner: fingolfin removed
Resolution: outdated
Status: closednew

comment:13 by Kirben, 13 years ago

There have been no changes to the MorphOS file system backend, so I don't see how this bug could have been fixed.

comment:14 by fingolfin, 13 years ago

I am sorry, I got confused by the "It's gone, as far as i can see, thank you" statement.

Anyway, I don't think anybody has actively maintained the MorphOS backend in ages. The last change to abox-fs.cpp by somebody other than me (not
counting copyright header updates) was in 2002-11-20. As such, I am surprised that the file even compiles, but am not surprised it doesn't work
(making updates blindly tends to have this effect).

Since it hasn't been maintained for almost 4 years, IMO we should consider removing it, unless we can quickly find a new maintainer.

comment:15 by SF/fab1, 13 years ago

The morphos fs backend file (aboxfs.cpp) is still used, and is actually updated (otherwise it wouldn't even build). But - and it's wrong i know - it hasn't been committed to your svn, because i have no write access. I'm regularly contacted to build release builds, but i was never given an access to svn. Anyway, please don't remove morphos backend and give me an access instead so that i can commit it. :)

comment:16 by fingolfin, 13 years ago

That's not how it works. You ought to submit a patch via our patch tracker for review, then it can be added to SVN. After that we can talk about write
access.
As it is, releasing MorphOS binaries based on your modifications w/o publishing the modifications (and clearly documenting this, and where to obtain
the extra souces, inside the release) is a violation of the GPL... :-/

comment:17 by SF/fab1, 13 years ago

Well, in the archive i included my E-Mail, so anyone wanted the sources can just ask for them, as it's stated in GPL.
But i agree this way not very practical, and i'll submit a patch to your tracker ASAP.

comment:18 by fingolfin, 13 years ago

A patch by fab1 is now in SVN. Does this patch affect this bug report in any way?

comment:19 by SF/fab1, 13 years ago

Yes, it fixes that issue, that can be closed now.

comment:20 by sev-, 13 years ago

Owner: set to fingolfin
Resolution: fixed
Status: newclosed

comment:21 by sev-, 13 years ago

Ok, closing.

comment:22 by digitall, 12 months ago

Component: Ports
Note: See TracTickets for help on using tickets.