#3235 closed defect (fixed)
GR: Actor stuck (Amiga version)
| Reported by: | (none) | Owned by: | SF/buddha_ |
|---|---|---|---|
| Priority: | normal | Component: | Engine: AGI |
| Version: | Keywords: | ||
| Cc: | Game: | Goldrush |
Description
ScummVM 0.11.0svn (Jun 7 2007 07:49:05)
When dropping through the hole in the outhouse down to Jakes mine, Jerrod is "stuck". Movement with cursor keys is extremely flawed as Jerrod only walks one pixel in the direction he is ordered to and turns immediately back, facing right and stops.
Movement with mouse is possible upto the point where he enters the dark cave and stops again (intended, i think, as he can't see anything from this point on). Problem is lighting the lantern is refused also, bringing up the message: "Now is not the time"
Haven't played it for a long time, so i may be mistaken about the lantern.
On a related issue: I wasn't able to read in the bible. Not even when i had to figure out the clue from the tombstone in Sutters Fort. It also triggered the message "Now is not the time"
The game is not completeable i fear
Gold Rush! (1.01 1989-01-13 aka 2.05 1989-03-09/Amiga/English)
gcc version 4.0.2 (AmigaOS build 20051012) AmigaOS 4
Ticket imported from: #1733297. Ticket imported from: bugs/3235.
Attachments (2)
Change History (25)
by , 17 years ago
| Attachment: | goldrush-amiga.022 added |
|---|
comment:1 by , 17 years ago
I've played it at this point, it's hard to use the mouse as the actor's walk path is too narrow, just use the arrows there.
As for the lanterm it works fine here: I just typed "use lantern" and the lantern was lit normally
What did you type to turn the lantern on?
comment:2 by , 17 years ago
light lantern - "Now is not the time!"
use matches with lantern - "What do you mean?" use lantern - "What do you mean?"
read bible - "Now is not the time!" read psalm 23 - "Now os not the time!"
Unfortunately it seems to be a problem of the Amiga version of this game, as i'm still stuck at the mine shaft. Jerrod turns immediately to the right and is always going right and down as if the numpad "3" is stuck (which isn't).
It's even worse, the AGI engine seems to be completely bottomed. I can't do anything, i can't look at things (no graphics shown) only the text "Ya see nothin' unusual".
comment:3 by , 17 years ago
Starnge, I get the same "Now is not the time" when I press F1 to see the help file in my DOS version of Goldrush. So this is not only a problem with the Amiga version, it's also a problem of the DOS version. (Maybe all the other versions suffer from this bug, too.)
comment:4 by , 17 years ago
@adventureguy
Affirmative, happens here too, whereas i can't use the F1 key, it just doesn't trigger anyhing, have to use the menu.
comment:6 by , 17 years ago
| Summary: | AGI: GR - Cursor movement flawed → AGI: GoldRush (Amiga) - Actor stuck |
|---|
comment:7 by , 17 years ago
| Summary: | AGI: GoldRush (Amiga) - Actor stuck → GR: Actor stuck (Amiga version) |
|---|
comment:8 by , 17 years ago
The Amiga version has some weird lines drawn at that scene, which are not present in the PC DOS version, and prevent ego from walking into the tunnel. Could this be an issue with priority lines?
As for the lantern bug, the lantern can be lit with the PC DOS version by typing "use lantern" or "light lantern" (among the many other possible inputs). In the Amiga version, "use lantern" is not understood by the interpreter and "light lantern" always returns "now is not the time", like vampir_raziel said
I can also confirm that help cannot be displayed in either the DOS or the Amiga versions, the message "now is not the time" is shown, either by pressing F1 or by accessing the help option in the menu
comment:9 by , 17 years ago
| Owner: | set to |
|---|
comment:10 by , 17 years ago
Kari, picture routines need to be checked, but first we need to doublecheck it with original in emulator. Perhaps it's matter of bad game data.
comment:11 by , 17 years ago
The picture resource used in the bugging room is picture 147. It has some weird lines in it *also* when running the game through WinUAE so it's probably a case of broken data.
I made ScummVM patch the picture resource in memory as it only differed in 6 bytes from the PC version's picture resource. That fixed the weird lines but the actor's still stuck. Possibly the logic is corrupted too? Or the logic uses some command ScummVM doesn't support?
WinAGI can't show some of the logic files and it gives error messages like this:
Logic001: Unknown test command (019) at position 0x36A Logic003: Unknown test command (019) at position 0x1ED Logic005: Unknown test command (019) at position 0x527 Logic006: Unknown test command (019) at position 0x3BF Logic130: Unknown action command (182) at position 0x00D Logic137: Unknown test command (019) at position 0x095 Logic150: Unknown action command (182) at position 0x1EA Logic192: Unknown test command (019) at position 0x163
I used the legally available Amiga version of Gold Rush from the back2roots.org for testing this. I extracted the files from the adf-files using ADF Opus. I had to rename DIRS to GRDIR and VOL.* to GRVOL.* to get WinAGI to load the files.
comment:12 by , 17 years ago
| Priority: | normal → low |
|---|
comment:13 by , 17 years ago
This is probably a case of corrupted data as the weird lines in picture 147 also appear in the game when running the game through an Amiga emulator. So that's why I'm lowering the bug priority.
Also note that when I patched the picture 147 in memory in ScummVM it also fixed possible priority screen/control line problems (If there even were any to begin with). So it's not a problem with the priority screen/control lines either.
My current guess for this bug is that some of the logic data has been corrupted too.
comment:14 by , 17 years ago
It seems changing the parameter count for adj.ego.move.to.x.y from 0 to 2 fixes the problems with lighting the lantern etc but doesn't fix the walking problems. Here are the script entries using command 182:
In logic 130: adj.ego.move.to.x.y(0, 7) // b6 00 07 adj.ego.move.to.x.y(9, 9) // b6 09 09 adj.ego.move.to.x.y(-9, 9) // b6 f7 09 adj.ego.move.to.x.y(0, 8) // b6 00 08
In logic 150: adj.ego.move.to.x.y(0, 0) // b6 00 00
I don't know what the parameters mean at the moment.
I'll probably look more into this bug later today.
by , 17 years ago
| Attachment: | goldrush-amiga.021 added |
|---|
Savegame before the bug ("Go in hole" and "Yes" to enter room 147 where it bugs)
comment:16 by , 17 years ago
| Owner: | changed from to |
|---|
comment:17 by , 17 years ago
Eugene, could you please take a look at the Amiga version's disassembly of the adj.ego.move.to.x.y-command because I'd venture that by implementing that command correctly we'll get this bug to go away (With all the other changes present in the trunk already, that is).
If you don't have the time I might try to make the Amiga executable run some adj.ego.move.to.x.y -test scripts after I hopefully get a version of WinAGI that supports the 2 parameter version of the command (I've contacted WinAGI's author already about this). In this approach I'd try to reason what the command does from how it makes the ego behave when walking around using the mouse. I'd do it this way because I have no Amiga disassembler, e.g. the freeware IDA doesn't support Amiga executables.
So presently everything else about this bug should already be gone but only the moving around in the mines (Rooms 147-162) still bugs (Although not strictly identically as mentioned in this bug report).
P.S. The already present changes in the trunk that are related to this bug are at least the following:
http://scummvm.svn.sourceforge.net/scummvm/?rev=30136&view=rev http://scummvm.svn.sourceforge.net/scummvm/?rev=30251&view=rev http://scummvm.svn.sourceforge.net/scummvm/?rev=30263&view=rev http://scummvm.svn.sourceforge.net/scummvm/?rev=30375&view=rev http://scummvm.svn.sourceforge.net/scummvm/?rev=30377&view=rev
This isn't directly related to this bug but to Amiga's Gold Rush: http://scummvm.svn.sourceforge.net/scummvm/?rev=30259&view=rev
comment:18 by , 17 years ago
| Owner: | changed from to |
|---|---|
| Priority: | low → normal |
comment:19 by , 17 years ago
It's not corrupted logic data that's causing this but our non-implemented adj.ego.move.to.x.y or at least something related to that command and moving with the mouse so I'm raising the priority back to medium.
comment:20 by , 17 years ago
This should be fixed in the trunk in r30602.
I'll close this after someone's tested this thoroughly (Me, Raziel or anyone :-)).
comment:22 by , 17 years ago
I'm closing this bug now as fixed.
Here's the list of commits related to fixing this bug:
- Revisions 30602, 30377 and 30375: These implement the command 182 i.e. adj.ego.move.to.x.y(x, y) which uses 2 arguments. This fixes the walking in this bug and also the parser bug. The parser bug was caused by incorrectly parsing adj.ego.move.to.x.y as using 0 arguments as it actually used 2 arguments. That just messed up the script parsing and therefore "light lantern" etc didn't work.
- Revision 30263: This fixes the broken background picture in the first mine scene after dropping through the outhouse's hole. AFAIK the broken picture data didn't really matter playwise though, so this is just an aesthetic fix.
- Revision 30136: Fixes help screen and bible passage showing by setting amount of free memory (v8 i.e. vFreePages) to maximum value. This helped because before showing the help screen or any bible passage the scripts checked whether there was enough free memory left to do that (i.e. they checked that v8 was over a certain number).
comment:23 by , 17 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Bug takes place