FOA: Extro playing incorrectly

[Mataniko]

Issue migrated from trac ticket # 285

component: Engine: SCUMM | priority: normal | resolution: fixed

2002-05-20 13:47:03: SF/trinity78 created the issue

---

Game: Indiana Jones 4 - German Floppy
OS: Windows 2000 Adv. Server SP 2
ScummVM: DailyBuild 2002/5/19

Bug:

Two minor bugs.

In the closing scene \(extro\) of indiana jones 4 there 
are to bugs. 
First, the music stops after a short time \(maybe after 
the first theme\) and doesn't go on. Usually \(almost\)
all themes of the game are played until the credits 
are over. This happens with both, adlib emulation and 
midi.
Second the sky does not fade red, so this sunset looks 
a little bit weird with a yellow bright sky.

savegame attached.

Ticket imported from: !#558245. Ticket imported from: bugs/285.

[Mataniko]

2002-05-20 13:47:03: SF/trinity78 uploaded file atlantis.s07 (34.2 KiB)

[Mataniko]

2002-05-21 01:17:12: SF/doomstalk commented

---

I can confirm that this is not a machine specific problem, as I've encountered it too, except under Windows XP Professional \(build 2600\)

[Mataniko]

2002-05-21 21:43:31: commented

---

Logged In: NO 

i found the part which should be responible for the missing 
sunset:

in script\_v1.cpp

case 15:                  
/\* 
palmanip? \*/
a = getVarOrDirectByte\(0x80\);
\_opcode = fetchScriptByte\(\);
b = getVarOrDirectByte\(0x80\);
c = getVarOrDirectByte\(0x40\);
\_opcode = fetchScriptByte\(\);
d = getVarOrDirectByte\(0x80\);
unkRoomFunc4\(b, c, a, d, 1\);
break;

this opcode should actually redden the sky, its called 4 times 
for the 4 different shades of red.

[Mataniko]

2002-05-23 16:00:32: commented

---

Logged In: NO 

i did some work on this and found out that this opcode is 
indeed need for a pal-manipulation \(like a sunset\).

the original script say something about:

\------

\[0000\] \(33\) palManipulate\(32,16,190,Local\[0\]\)\)

\[...\] some code \[...\]

\[0081\] \(33\) palManipulate\(32,16,190,1\)\)

\------

32, 16, 190, 1 are the same values which are also stored in 
a,b,c,d in the script\_v1.cpp at this place \(see post below\).
however, i've been unsuccessful to understand the true 
functioning of the palManipulate\(\) method. my guess is that 
the values represent the rgb-colors, the pals involved and 
maybe a time delay \(used to slowly fade one colour into 
another\).
i keep on working on this, but I'm not sure if i will solve it.

so far, trin

[Mataniko]

2002-05-24 13:40:28: commented

---

Logged In: NO 

after some more reverse engineering, i found out that what the 
values in the original script by lucasarts mean.

palManipulate\(32,16,190,Local\[0\]\)\)

32 = color value
16 = all palettes from 1-16
190 = brightness/darkness \(not sure about that one\)
Local\[0\] = time span for the effect \(180 for the first call and 
800 for the second in the closing scene\)

[Mataniko]

2002-06-02 00:08:46: fingolfin changed title from Indiana Jones extro playing incorrectly to FOA: Extro playing incorrectly

[Mataniko]

2002-06-02 00:08:46: fingolfin commented

---

Thanks for the work, nobody, I am sure it'll be helpful to 
fix this - but of course if you can come up with a proper 
fix, that would be more than welcome, too :-\)

I might look into this, once I have again a save game for 
the end.

[Mataniko]

2002-06-02 00:40:58: SF/trinity78 uploaded file SAVEGAME.003 (32.2 KiB)

orginal savegame for indy4 closing scene

[Mataniko]

2002-06-02 00:42:54: SF/trinity78 commented

---

I've upload a savegame from the original game for the closing 
scene.

btw: nobody = trinity
just to lazy to login.

[Mataniko]

2002-06-03 10:54:19: fingolfin commented

---

hehe OK :-\) Anyway I have my own savegame now, too 
\(I can't use save games that others made, I guess this 
is a en endian issue\).

Anyway, unkRoomFunc4\(\) is also called in script\_v2. It 
would be nice if we collected more than this one space 
where it is used, so that we can get this done right.

[Mataniko]

2002-06-03 12:29:01: fingolfin changed owner from * to fingolfin*

[Mataniko]

2002-06-03 12:29:01: fingolfin commented

---

Oh I just see it's a save game for the original. Well I 
doubt that my mac version of FoA can open it :-\) In any 
case: could you possibly make some screen shots of 
the original game during the extro, then I have some 
visual reference whether I am doing this right so far or 
not.

[Mataniko]

2002-07-13 06:16:19: SF/ender commented

---

Any progress on this?

[Mataniko]

2002-07-13 13:15:07: fingolfin commented

---

Well, I am still waiting for screenshots of the original.
Pretty hard to implement an effect if you don't know what it
is supposed to look like :-\)

I haven't looked into the music issue. Music seems to be
quite problematic currently in general.

[Mataniko]

2002-07-13 16:37:11: SF/trinity78 commented

---

yeah, yeah, in know.

i'm really busy with real life issues at the moment, so i hadn't 
much time looking into it.

the problem is also, i don't how to take screenshots in a dos 
game. the windows print button doesn't work.

but i'll see what i can do, a little more patience please. :\)

[Mataniko]

2002-08-04 03:18:59: fingolfin changed owner from fingolfin to **

[Mataniko]

2002-08-04 03:18:59: fingolfin commented

---

Impossible for me to work on this w/o any way to see the original. 
Sorry :-\(

[Mataniko]

2002-08-06 18:20:07: SF/trinity78 commented

---

well im out of ideas here.
as i said im not able to take screenshot in dos mode \(i'm 
running win2k / win98\),  i tried various screengrabbers 
\(pcxdump, snag it, ... some more\) none worked.
also i'm not sure if screenshots will really help, because a 
sunset is a progress and you need to see the sun move and 
slowly the sky turnig red.

i can't do much more than upload my savegame \(which not 
worked for you\).
so the only solutions is that you finish \(the original\) indy 4 by 
yourself and see the sunset for yourself. don't you have any 
archives where you store savegames?

i could try to program it myself, but since i'm very busy at the 
moment and rather unfamiliar with the code, it chould take 
months, if i do not fail entirely. actually i'm a java 
programmer, with only basic knowledge of c++.

[Mataniko]

2002-08-21 00:27:15: fingolfin commented

---

A screen shot would help me, even if it was taken while 
"in progress", because I coulde us it analyze just how 
the palette is changed \(e.g. is just the red part 
changed, and how, stuff like that\). I am fairly sure that I 
could make a pretty good approximation using 2-3 
screen shots taken at different points.

Finishing the original Indy here is currently not a real 
option, as I have to reboot to Mac OS 9 to play it properly 
\(well I can use it under OS X, but it's extremly bugged 
and forces me to switch to 256 color mode which 
slows down the system a lot\).

Anyway, I think the first two parameters \(16 and 190\) 
specify the first and last color to be changed - the 
colors from 16-190 are exactly the ones used for 
waves/sky/clouds etc. I changed this in CVS 
accordingly and it seems pretty good.

I agree that 180/1/800 mean time - between the first 
and second call, roughly 18 = 180/10 seconds pass. 
So we need to do our work in this period.

I dunno about the other two parameters, though. The 
current change still just fade down the red part, but 
probably not enough. Another reason why a screen 
shot would help: I could see how it is supposed to look, 
roughly. <sigh> :-\)

I do understand

[Mataniko]

2002-08-21 03:22:02: SF/matt_hargett commented

---

Screenshots from DOS version are @
http://www.clock.org/~matt/scummvm . 
I couldn't attach files to an already submitted bug as a non-
admin.

[Mataniko]

2002-08-21 12:15:59: SF/trinity78 commented

---

@matt

thx

@fingolfin

i'm not sure that your meaning about the "16" value is correct. 
my reverse engeneering attempts had different results. 
changes to the "16" value in the original foa 
\(atlantis.000/atlantis.001\) code, actually influence the areas 
where the pal-manipulation takes place. for example if you 
change the value to "8" only the upper half whould be affected 
by the pal-manipulation. so i found out that the screen is 
actually divided into 16 horizontal slices/levels \(however you 
want to call it\). changing the value to "3" whould result that 
only the upper 3 levels are affected by the pal-manip..

im not 100% certain about this \(my test were 3 month ago\), 
but i gonna double check it tonight.

[Mataniko]

2002-08-21 13:39:20: fingolfin commented

---

Thanks, Matt.

Trinity: ah well, you never told us you did that, so how
should I know :-\)

I don't see how it should be possible to only affect the
upper part of the screen by a palette change only - after
all, the palette always affects the whole screen\! But since
the colors are "ramped", of course changing the value from
16 to something else will look as if only part of the screen
is affected.

So I am certain it doesn't directly affect the area of
palette change, simply because techincally it is extremly
unlikely. Doesn't mean my guess at what it measn is right,
either :-\) So if you have some other ideas, speak up.

[Mataniko]

2002-08-22 04:19:39: SF/trinity78 commented

---

well i think i was mistaken, my mind is playing tricks on 
me :\). i tested it again and it was not the same as in my 
memory. so ignore my previous post.

[Mataniko]

2002-08-22 18:25:10: SF/trinity78 commented

---

ok here are the results of my nightly reverse engineering 
session.
i was able to take screenshots the same way matt did, which 
is a very annoying procedure. to take a screenshot, i have to 
switch to window mode, which crashes the game. so 10 
screenshots = 10 crashs, 10 restarts, 10 load savegames. 
but nevertheless, here are the results,  i hope the help you to 
figure out what the certain values are good for.

original lucas script code:

\[0000\] \(33\) palManipulate\(32,16,190,Local\[0\]\)\) //Local\[0\] = 
180 and 800

\[...\] some code \[...\]

\[0081\] \(33\) palManipulate\(32,16,190,1\)\) // this might be just a 
call to be sure that the pal-manip has finished, maybe to 
avoid problems with too slow cpu speeds. just a guess.
\----------------------

chaning the first value \(the 32-value\) to 16 results in this:

http://domfree.de/trin/uploads/indy32to16-0.png
http://domfree.de/trin/uploads/indy32to16-1.png
http://domfree.de/trin/uploads/indy32to16-2.png

changing the second value \(the 16-value\) to 72 result in this:

http://domfree.de/trin/uploads/indy16to72.png

changing the second value \(the 16-value\) to 88 result in this:

http://domfree.de/trin/uploads/indy16to88.png

the last two screenshots show, how i came up with that 
slice/level idea, but now i think you are correct and is just 
coincidence.

i hope this helps you a little bit.

one last question \(like columbo, hehe\). fingolfin why does 
your pal-manipulation function has 5 parameters, while the 
one of lucasarts has only 4 parameters? is there a certain 
reason for this?

[Mataniko]

2002-08-29 07:21:39: SF/jamieson630 commented

---

I encountered the same type of palette manipulation problem 
earlier in FOA, in the inner sanctum of Atlantis, when 
activating the big machine. The room is supposed to take on 
a reddish tint as the machine fires up and lava begins to flow.

In the August 25 daily build for Win32 \(running on Windows 
98 SE\), a single, partial palette shift occurs halfway through 
the time period in which the transition would occur. In 0.2.0, 
even this partial transition does not occur.

Since I cannot submit files on a followup, I have sent them to 
fingolfin for review. Four files: two are before/after shots of the 
room from the original LEC executable, and two are 
before/after shots from the August 25 ScummVM daily build.

Finally, here are the errors produced in the console during 
this event:

WARNING: palManipulate\(32, 65, 46, 20, 1\): not implemented\!
WARNING: unkRoomFunc3\(16,255,500,500,500\): not fully 
implemented\!

Since this is just a single manipulation and not TWO 
manipulations like the end sequence is reported to be, 
perhaps it will be a bit easier to figure out what the palette 
changes are supposed to be like.

Hope this helps....

[Mataniko]

2002-08-29 18:27:45: fingolfin uploaded file FOA1.png (30.9 KiB)

Inner Sanctum - original - before change

[Mataniko]

2002-08-29 18:28:57: fingolfin uploaded file FOA2.png (30.1 KiB)

Inner Sanctum - original - after change

[Mataniko]

2002-08-29 19:03:43: fingolfin commented

---

Very useful information indeed\! Now we have an additional
test case, and more test data.

E.g. it's now obvious that one of my guess \(that 16-190 is a
range\) can't be correct, as here the range would be 65-46,
which doesn't make sense at all.

I attached the two screen shots from the original version.

[Mataniko]

2002-08-29 20:17:26: fingolfin commented

---

Stupid little me, of course the range would be 32-65, which
could be right. Need to verify if it would match the palette.

[Mataniko]

2002-08-29 21:13:45: SF/jamieson630 commented

---

Don't know why people say the Windows PrntScrn button 
doesn't work with FOA. Works fine for me, except that it 
transforms the capture to 640x400 True-Color.

Anyway, I downloaded a capture utility to do native VGA 
captures, so the original 256-color palettes would come 
through. I have uploaded native VGA captures of the inner 
sanctum "Big Machine" scene \(before/after shots\) to fingolfin 
for review.

The palette range that seems to be affected does indeed 
seem to be something coinciding with, or very close to, the 
32-65 range. In addition, I timed the color transition, and it 
takes about 2 seconds to complete \(the 20 in our 
palManipulate call?\).

I'm looking at the exact nature of the palette changes now to 
try to figure out how diverse target colors can be specified 
using a single parameter \(the mysterious 46 in the 
palManipulate call for the "Big Machine" scene\). Or is it 
possible that additional useful information is included in the 
unkRoomFunc3 incident that seems to accompany every 
palManipulate call? I'll ponder that too.

I feel like I'm putting Indy in danger over and over, each time I 
activate that big machine for test purposes.  ;-\)

[Mataniko]

2002-08-29 21:47:46: SF/jamieson630 commented

---

Never mind about unkRoomFunc3 occurring along with 
palManipulate calls. I just played through to the end, and it 
didn't show up at all during the extro. Just 4 calls to 
palManipulate, showing up in the August 25 Daily Build 
console window as such:

Loading room 96 \[extro scene\]
WARNING: palManipulate\(16, 190, 32, 180, 1\): not 
implemented\!
Time since last call: 346559
WARNING: palManipulate\(16, 190, 32, 1, 1\): not implemented\!
Time since last call: 17184
WARNING: palManipulate\(16, 190, 32, 800, 1\): not 
implemented\!
Time since last call: 9983
WARNING: palManipulate\(16, 190, 32, 1, 1\): not implemented\!
Time since last call: 75353
Loading room 68 \[closing LucasArts logo\]

I'm only reporting on what shows up in the console window, 
not opcodes that are recognizable and processed without 
alerts. Are there surrounding opcodes that provide more 
information about the target palette for transitions? 
ScummVM \*does\* change the palette, but they are 
instantaneous changes, and I don't know where the target 
palette is coming from.

[Mataniko]

2002-08-29 22:06:40: fingolfin commented

---

First check out the changes I commited to CVS just now :-\)
In scumm/gfx.cpp, you can find palManipulateInit\(\) which
does the current \(wrong\) effect, just a hack. There is also
palManipulate\(\) which apparently is not having any effect as
the variables that steer it are nowhere inited, nor are the
rtTemp buffers existant.
So I think somebody disassembled those but never hooked them up?

In any case, I also had a look at the original data file
using a data browser, and know what, the CLUT there doesn't
match the "new" nor the "old" palette \(i.e. before/after the
effect\) jamieson sent me.

So my guess is that what actually happens might not be a
purely computed effect, but rather a transition to a
different palette. I'll try to hook up into palette
modifying procs to check what exactly goes on.

[Mataniko]

2002-08-29 22:32:14: fingolfin commented

---

OK, in the Inner Sanctum, the palette is changed by the
script: the colors from 32-65 are changed "manually" by
calls to setPalColor. As a consequence, if I just restore
the "original" room palatte, it looks right \(changing this
to "fade" the palette is the simplest part, let's do that
later\).

However that doesn't work at all for the extro, I couldn't
detect any palette changes there, and the original room
palette is the starting one \(daylight\). And in any case,
here we have to fades, first it reddens as the sub sets,
then it gets night, and the starts comes out.

[Mataniko]

2002-08-30 00:12:51: SF/trinity78 uploaded file reverseeng.zip (185.8 KiB)

the screenshot from the reverse engineering session, see post in this thread to understand their meaning

[Mataniko]

2002-09-10 18:03:49: SF/jamieson630 commented

---

Another point of interest is that in the extro, palManipulate is 
doing its work on colors that themsleves are shifting. The 
water is constantly changing, while at the same time 
following the general lighting fades that palManipulate is 
supposed to be effecting. Whether the water is animated or 
based on a palette cycle, I'm not sure. If the latter is true, it 
would be evidence that palManipulate is based on math 
transformations rather than target palette information.

I'm dumping and de-SCUMMing the scripts right now to start 
really digging into this. Let's see how far I can get with the 
next 5 days off. ;-\)

[Mataniko]

2002-09-10 18:52:28: fingolfin commented

---

palManipulate works by slowly fading a given source palette into a target 
palette. Look at file gfx.cpp, palManipulate and palManipulateInit.

If cycling is active, it is not only being applied to the current palette, but 
also to the target pal - moveMemInPalRes is responsible for that.

That is, that's how it is supposed to work. The only puzzle piece which 
is missing is how to acquire the "target palette data". That's why, if you 
look closely, palManipulate and moveMemInPalRes are not doing 
anything right now. Of course, I could change that to at least to a proper 
fade to the \(currently wrong\) target palette. But the realy "mystery" is: 
how do we generate the target palette? 

I did compare the target and source palettes in the original came. As a 
result, I am fairly convinced that this is not being done by a 
mathematical function, at least not without some big additional lookup 
table \(i.e. static data\). Hence it is much more likely \(as it is simpler\) to 
assume that they somehow use a second different palette as data, 
instead of a math function.

Of course, I can not 100% exclude the possibility of a math function. 
Disassembling the original code would be the "easiest" way to find out 
for sure.

[Mataniko]

2002-09-11 02:53:45: SF/jamieson630 commented

---

Okay, here's the missing puzzle piece. palManipulate gets its 
target palette from STRINGS.

Three strings, specifically. The first string specifies the red 
values, the second string specifies the green values, and the 
third string specifies the blue values. The strings must have 
contiguous ID numbers, e.g. 32 \(red\), 33 \(green\) and 34 
\(blue\). The first ID number is referenced in the palManipulate 
call, and the other two are inferred.

In the Inner Sanctum \(room 23\), the following scripts are 
relevant \(these are script numbers, not resource offsets, 
since I'm working off of SCUMMVM dumped scripts\):

Script 166 is the script that executes when Indy manages to 
turn on the big machine. At the point where the lighting 
changes, Script 171 is called. Script 171 starts off like this:

\[0000\] \(27\) PutCodeInString
\(46, "@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@"\)
;
\[0053\] \(27\) PutCodeInString
\(47, "@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@
@"\);
\[00A7\] \(27\) PutCodeInString
\(48, "@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@"\);
\[0100\] \(27\) SetStringChar\(46,32,243\)
\[0105\] \(27\) SetStringChar\(46,33,251\)
\[010A\] \(27\) SetStringChar\(46,34,251\)
\[010F\] \(27\) SetStringChar\(46,35,251\)
\[0114\] \(27\) SetStringChar\(46,36,251\)
\[0119\] \(27\) SetStringChar\(46,37,251\)
\[011E\] \(27\) SetStringChar\(46,38,251\)
\[0123\] \(27\) SetStringChar\(46,39,243\)
....

Three strings. Initialized to dummy characters so that each 
character can subsequently be replaced with direct numbers 
\(that may or may not be representable by printable 
characters\). The code goes on to initialize string IDs 46, 47 
and 48 with the red, green and blue colors for the reddish 
room \(which, as fingolfin pointed out, corresponds to the intial 
palette of the room anyway\).

The call to palManipulate, at the end of a long sequence of 
string character setups, is as follows:

\[02FF\] \(33\) palManipulate\(46,32,65,20\)\)

The first parameter, the one we haven't been able to identify, 
is in fact the ID of the first of the three strings from which to 
glean the target palette data.

Okay, now let's look at the troublesome extro sequence, 
which is Room 96.

There are TWO palManipulate calls, executed by Room 96 
localized Script 201. Both calls reference the same base 
string ID of 32:

\[0000\] \(33\) palManipulate\(32,16,190,Local\[0\]\)\)
....
\[0081\] \(33\) palManipulate\(32,16,190,1\)\)

However, no strings are set up in this script. In fact, this 
script is being monitored by a parallel script, Room 96 
localized Script 200. Here are the interesting lines for Script 
200:

\[002E\] \(0A\) startScript\(157,\[\]\)
\[0031\] \(80\) breakHere\(\)
\[0032\] \(68\) Var\[0\] = getScriptRunning\(157\)
\[0036\] \(28\) if \(Var\[0\]\) goto 0031;
....
\[006D\] \(2A\) startScript\(201,\[180\]\)
....
\[007C\] \(80\) breakHere\(\)
\[007D\] \(68\) Var\[0\] = getScriptRunning\(201\)
\[0081\] \(28\) if \(Var\[0\]\) goto 007C;
\[0086\] \(0A\) startScript\(158,\[\]\)

This section of script runs global Script 157, makes sure its 
completed its stuff, then runs the Script 201 we just talked 
about. It then waits for a break in 201 before running Script 
158\.

Scripts 157 and 158 each contain -- you guessed it -- string 
intializations\! Both of them initialize strings 32, 33 and 34 
with numeric data. Script 157 sets the strings to our "middle" 
or "twilight" palette, and must get the strings all ready before 
201 starts. Once 201 is in progress, BUT before it gets to the 
second palManipulate, script 158 is called by 200 to set up 
strings 32, 33 and 34 to our "final" or "nighttime" palette. By 
the time 201 gets around to its second palManipulate, the 
strings are ready to rock and roll.

To test that these strings were, in fact, being instantiated with 
the target palettes we've been searching for, I pulled the code 
out and stripped it down to the basic numbers, then plugged 
those directly into the palette area of a PCX image 
representing the start of the extro \(i.e. the "initial" 
or "daytime" palette\). I am sending the resulting 256-color 
images to fingolfin for review.

Note that for the extro, colors for EVERY palette entry are 
entered into the three strings, even though only palette 
entries 16 through 190 are making the transition. Also note 
that the strings CAN be less than 256 characters long if not 
all the colors are to be changed, BUT each string must be at 
least as long as the highest color index that will be 
manipulated. \(In the Inner Sanctum, strings 46, 47 and 48 are 
actually 79, 80 and 85 characters in length, even though only 
characters 32 through 65 are being set to anything. Weird, 
huh?\)

I hope this helps\! Gorgeous Indy sunset, here we come\! ;-\)

[Mataniko]

2002-09-11 03:03:57: SF/jamieson630 commented

---

Slight correction -- Room 96 Script 201 executes 
palManipulate twice for the same palette. The first call is to 
do the transition, the second call is to force the transition to 
happen immediately, if for some reason it hasn't already 
reached its target palette.

Room 96 Script 200, which controls the calls to 157, 158 and 
201, calls 201 twice, once for the "twilight" palette \(transition 
from "daylight" in 180 tenths-of-a-second\) and once for 
the "nighttime" palette \(transition from "twilight" in 800 tenths-
of-a-second\).

\[002E\] \(0A\) startScript\(157,\[\]\)
\[0031\] \(80\) breakHere\(\)
\[0032\] \(68\) Var\[0\] = getScriptRunning\(157\)
\[0036\] \(28\) if \(Var\[0\]\) goto 0031;
....
\[006D\] \(2A\) startScript\(201,\[180\]\)
....
\[007C\] \(80\) breakHere\(\)
\[007D\] \(68\) Var\[0\] = getScriptRunning\(201\)
\[0081\] \(28\) if \(Var\[0\]\) goto 007C;
\[0086\] \(0A\) startScript\(158,\[\]\)
...
\[009C\] \(2A\) startScript\(201,\[800,1\]\)

So the wait for Script 201 is actually to wait for it to 
COMPLETELY end, not to slip a call to 158 into the middle of 
201's execution. Sorry for the mixup; I think I've been staring 
at hex a little too long this evening. ;-\)

[Mataniko]

2002-09-13 13:54:55: fingolfin changed owner from * to fingolfin*

[Mataniko]

2002-09-13 13:54:55: fingolfin changed resolution from * to fixed*

[Mataniko]

2002-09-13 13:54:55: fingolfin changed status from new to closed

[Mataniko]

2002-09-13 13:54:55: fingolfin commented

---

Fixed by patch \#608138, now in CVS.

[Mataniko]

2002-09-13 14:04:52: SF/trinity78 commented

---

well, the music issue still remains, but i can open a new bug 
report for this :\)

finally this bug closed, great job everyone \!