Opened 3 years ago

Last modified 2 years ago

#11890 new defect

STARK: listLocations debug command should print actual location numbers, not file paths

Reported by: aquadran Owned by:
Priority: low Component: Engine: Stark
Version: Keywords:
Cc: Game: The Longest Journey


Related to #1456.

Currently listLocations debug command prints a list of relative paths to all .xarc files found inside current game directory. It should print only the pair of the ids (followed by the location name) needed for changeLocation debug command instead. To keep in line with the output from listInventoryItems and listScripts I also suggest using comma instead of dash/hyphen, so instead the 1b/00/00.xarc – Outside Subway Station it should print 1b 00: Outside Subway Station.

Also, because the command lists the .xarc files that are found on the main folder as well, it shows entries such as 1b/1b.xarc – Outside Subway Station along the regular 1b/00/00.xarc – Outside Subway Station, giving a false impression that typing changeLocation 1b 1b would work, while it's not a valid link to a location but a file instead, so it should not be listed.

Because the general .xarc are listed twice (and so is Global/Global.xarc), the list becomes too long to scroll in the non-demo version of the game, so you can't see the earliest locations from the list, but luckily if the command would only list an actual pairs of ids for the location that can be entered, there should be enough spot in the console history.

ust noticed that @DouglasLiuGamer referenced the issue about the buffer being too short in this command in one of the comments of PR #1456. Without listing the non-location .xarc files this hopefully this won't be needed anymore :).

I'm not sure I agree with just removing the non-location entries. The listLocations command is also meant to be used to list input values for the dumpArchive command. Perhaps there should be two commands instead of one. Or perhaps it's good enough as is, with the output buffer of the debug console changed to be bigger.

Oh, I never had an idea that listLocation could be used for the dumpArchive (I actually think it should be called "extractArchive, since it's different from other dump commands – it extracts files to the location instead dumping info to stdout), as nothing suggests it and was quite counter-intuitive to use. (I even wanted to send a PR for but ultimately gave up for now :P).

I actually wanted to suggest adding a new "listArchives" command, so I guess it's a good idea to make two separate ones. The problem will be that the output from the new "listArchives" would be too long anyway, unless someone makes it so it lists multiple files per line, makes it paginated or changes the buffer length in ScummVM.

Change History (1)

comment:1 by aquadran, 2 years ago

Priority: normallow
Note: See TracTickets for help on using tickets.