Opened 12 years ago
Closed 9 years ago
#6277 closed defect (fixed)
EOB2: Ending sequence
| Reported by: | SF/brutto1979 | Owned by: | athrxx |
|---|---|---|---|
| Priority: | high | Component: | Engine: Kyra |
| Version: | Keywords: | script | |
| Cc: | Game: | Eye of the Beholder 2 |
Description
Warning, spoiler final boss!
Hi, i just completed eye of The Beholder II using last beta of scummVM 1.6.0git3443-gde883e6 Mar 19 2013 04:30:50
When i found the final boss, there is a sequence of picture and dialugue that are in the wrong order, let me explain. At first there is a picture behind the boss then he turn back then he speaks then he prepare for battle. Now you can play normally, afther several damage taken, there is another sequence: first he is suffering then he transforms himself then you play normally until you kill him and there is the final picture of him dead.
In my experience, the sequences are wrong, and i mean: behind boss turn back he speaks he prepare for battle he suffers he transforms himself THEN YOU START to fight for the first time, and after hitting him, another scene: he suffers he transforms himself AFTER killing him, final picture of him dead.
You can see the right sequence in this video http://www.youtube.com/watch?v=YeA7PmEmc6E&feature=share&list=PL29BAFA0E7022DF9A
I hope this can help, and excuse for my english :)
Ticket imported from: #3611077. Ticket imported from: bugs/6277.
Change History (24)
comment:1 by , 12 years ago
| Owner: | set to |
|---|
comment:2 by , 12 years ago
comment:3 by , 12 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → pending |
comment:4 by , 12 years ago
| Status: | pending → new |
|---|
comment:5 by , 12 years ago
Sorry if i wasn't clear in my explanation.
The correct sequence in the PICTURES is that in the video, so: 1)at first you found the boss turned back 2)he turns only the head 3)he turns completely back facing you 4)he prepares for battle with a smile
Than you combat him in human form, after that
5) he suffers 6)he transforms himself
You combat him in his dragon form
7)you defeat him and he is dead.
7 pictures, correct sequence.
In my experience, this is not the sequence that i saw!
The first thine, i saw all the pictures from 1 to 6. Than there is the fight in human form Than there are pictures 5 and 6 Than u defeat him So i saw picture 7.
In few words, at the beginning of the meeting with final boss, i already know what will be happened after few minutes (the transformation). SCummVM spoiled the final boss..damn!
I hope it's clear now, let me know what are you thinking about this.
Best regards!
PS: I would like to play Eye of The beholder 3...ScummVM will support this game?!
comment:6 by , 12 years ago
| Summary: | Eye of the Beholder II → EOB2: Ending sequence |
|---|
comment:7 by , 12 years ago
So the bug is supposed to be that you get to watch the dragon transformation twice, once before and once after you fight Dran in human form?
I never had anything like that happen to me, so I cannot reproduce this bug. The way the transformation sequence is triggered in the code makes it seem unlikely that it could appear right after the encounter sequence.
Which operation system ((Windows, Linux, etc.) do you use with ScummVM?
comment:9 by , 12 years ago
Other people are suffering this problem. A friend of mine told me that he had the problem with the Eye of Bholder trilogy cd. I don't think it's related to the scummvm, this friend of mine explained me that it's a script bug inside level16.inf. The first time you meet Dran, the man must turn in your direction and then combat you. When you win the combat he change in dragon. With the bug you meet him in human form, he turn in your direction, then (and this is the bug) start the animation of him changing in a dragon, you begin the combat (he's in human form) you win and then for the second time (and now is correct) it start the animation where he change in dragon.
So basically the right sequence of animation is A --->human fight---->B----->dragon fight, but we have A--->B--->human fight----->B----->dragon fight. We suppose that there is a "error" in some line at the ending of the trigger of A. In floppy disk version i remember i didn't had this problem playing.
comment:10 by , 12 years ago
here the level16.inf (sorry but i can't attache the file at my post) http://www.sendspace.com/file/b5nz5c Maybe the bug is there, or maybe the bug is in the exe...
comment:11 by , 12 years ago
I still cannot reproduce this with Windows or Linux. Does this bug occur always when you encounter Dran? Or does this happen only occasionally? Could you attach a save file, please (saved before entering Dran's room)?
comment:12 by , 12 years ago
Okay, I've now actually reproduced this issue which occurs under certain conditions. The issue also appears in DOSBox, sinc e it is a bug in the original code. I'll try to come up with a workaround shortly.
comment:14 by , 12 years ago
| Priority: | normal → high |
|---|---|
| Resolution: | invalid |
comment:15 by , 12 years ago
This bug is nice to get fixed before the release. Raising priority for keeping the track.
comment:16 by , 12 years ago
| Component: | → Engine: Kyra |
|---|---|
| Game: | → Eye of the Beholder 2 |
comment:17 by , 12 years ago
The reported bug should now be fixed. Please test with the latest build.
comment:18 by , 12 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → pending |
comment:19 by , 12 years ago
Sev, athrxx, could you please explain me the conditions that generate the bug? Or could you explain me wich original file is involved by it? I wish to try to fix it even in the original game, thanks.
comment:20 by , 12 years ago
The boss level and the mindflayer level use the same map and monster data. The mind flayer level is sub level 0, the boss level is sub level 1. The bug will occur when you approch Dran if all 30 monster slots are already taken. If you hang around the mind flayers long enough this will be the case (timed script will generate 3 new mind flayers at certain intervals). Now, whenever a monster is killed the code will check whether the current level is 16 and the sub level is 1 and the monster type is 0 and also some flags. When all these are true it will trigger the transformation sequence. The problem is that not only Dran in human form is monster type 0, but the mind flayers are type 0, too. So when the program uses a former mindflayer slot to create Dran this will trigger the transformation sequence right before the start of the regular sequence when you meet Dran. After this sequence the script will remove Dran and create another one. This will trigger the transformation sequence again.
I could work around this issue in ScummVM, but doing this in the orignal binary (hacking the necessary byte code in) wouldn't be that much fun.
comment:22 by , 12 years ago
yep the bug exist and I think is EXE related becouse I talked about that with micartu quite a year ago, but I cannot reproduce this issue
comment:23 by , 12 years ago
@athrxx: my 2 cent, what do you think if I hack the byte that control the number of slots? can I increase that number a bit and see what will be happen? do you have other info about the workaround you choose for scummvm implementation
thanks
comment:24 by , 9 years ago
| Status: | pending → closed |
|---|
If I understand your description correctly the parts in capital letters are supposed to be wrong in ScummVM. I couldn't find any evidence of a bug here, though.
You seem to believe that Dran should "suffer" and "transform" (into what?) before any actual fight. This is not correct. You can check with DosBox, WinUAE etc, Even in your linked video (which is a little misleading, since the author loads new savegames from time to time) you can clearly see that you meet Dran in human form and he has to be defeated in human form before he does his dragon transformation.
I'm afraid I don't understand the second problem ("AFTER killing him...."). Of course, the ending sequence appears after and not before defeating Dran. This is also true for ScummVM.
I just did the boss battle again. Everything seems fine.
At the moment I tend to believe that this bug report is invalid. If you really think that something is off in ScummVM, please try to describe it more accurately.