Opened 14 years ago

Closed 14 years ago

#5687 closed defect (fixed)

GOB: Urban Runner Inventory Item \"Film\" name truncated

Reported by: digitall Owned by: DrMcCoy
Priority: normal Component: Engine: Gob
Version: Keywords: script
Cc: Game: Urban Runner

Description

In Urban Runner, in the Hotel, the inventory contains the Film item, but the name is truncated to \"FI\" This does not occur in the original.

ScummVM 1.4.0git51-ga896125 (May 1 2011 20:06:36) Game is Urban Runner (US English) DOS Platform is Linux x86_32

Ticket imported from: #3295893. Ticket imported from: bugs/5687.

Attachments (2)

FI-Should-Be-Film.jpg (77.4 KB ) - added by digitall 14 years ago.
Screenshot of Bug
ur-savegames.zip (206.8 KB ) - added by digitall 14 years ago.
Savegames For Replication

Download all attachments as: .zip

Change History (11)

by digitall, 14 years ago

Attachment: FI-Should-Be-Film.jpg added

Screenshot of Bug

comment:1 by DrMcCoy, 14 years ago

I can't reproduce this bug on my system / with in my version of the game. :/

Also, you attached the wrong save file; that one's much later, when you have to hide your items from the inspector. I doubt that the save will tell me much, though. The item names are pulled only once, when entering the screen, from the data files into the variable memory, so the save is already "corrupted". You might want to attach a save from one screen earlier ("SQUAT") instead.

by digitall, 14 years ago

Attachment: ur-savegames.zip added

Savegames For Replication

comment:2 by digitall, 14 years ago

I have removed the incorrect savegame and attached a zip files with all the savegames for this run, omitting the last two states to keep this within the SF.net attachment size limit. Save D10 demonstates this bug, which should be slot 9, but your description makes me doubt the alignment between the UR save dialog and the savestate files, so am attaching all.

One further question, The savestate size is about 2000 to 5000 bytes, except for urban.asp which is nearly 128K and the last two savestates s24 and s25 which are 132K+... Could you confirm if this is normal and the purpose of urban.asp? Thanks.

comment:3 by DrMcCoy, 14 years ago

Thanks, I'll look at it tomorrow. :)

The last two savestates are bigger because they include a sprite (the terminal at the end, where you enter the codes). The original game writes those to disk as intro.000 - intro.059 (depending on the slot), and expects them to be in the correct state instead of rebuilding the terminal on load, so that's "normal" (if ugly, but there's nothing I can do against it). urban.asp is the same sprite for the "continue" save state when you die (urban.aut holding the variable memory for that state). I can't quite remember right now why I saved those separately (probably because there was no easy way to check whether a sprite is still coming or not), but since those are only used temporarily, that shouldn't really matter.

comment:4 by DrMcCoy, 14 years ago

Okay, I found out something icky: The saves of your game version are incompatible with my version of the game. They still load (since the variable space size is the same), but they apparently reordered the rooms: When I load one of your saves, I am in one room, but the inventory items I have are incosistent with that. For example, D8 (urban-us.s07) shows me the inventory items for the hotel, but the room I'm actually in is the part of the SQUAT with the electrical cable.

comment:5 by DrMcCoy, 14 years ago

Also, Urban Runner handles inventory item names differently than, for example, gob3. The names are pulled once at the start of the game.

And in your first save, the "FILM" is still correct. In the second save, that's been somehow corrupted to "FI\0M" (i.e. the L has been replaced by a \0). There's no way of retroactively tracing that, I'm afraid. :/

comment:6 by digitall, 14 years ago

I can confirm this. Entering "varString 17580" in the debugger (CTRL+D) gives FILM for the first save (d1) in the basement, but for the second save (d2) after escaping into the cubbyhole room, this gives FI, so the region to trigger this bug is quite small, but am having trouble replicating this and thus determining the root cause.

comment:7 by digitall, 14 years ago

AHA. To replicate: 1. Start New Game (You can skip the intro). 2. Save Game in First Slot (called d1) deleting the default "basement". 3. check varString 17580 in the debugger. It should be the correct FILM. 4. Save Game in Second Slot (called d1) deleting the default "basement" BUT! Hit "no", not "yes" when asked to confirm the save. 5. check varString 17580 in debugger. It should now be the incorrect FI.

comment:8 by DrMcCoy, 14 years ago

Should be fixed in 8e03a20.

comment:9 by DrMcCoy, 14 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.