Lectrote 1.4.2

Technical Development Interpreters
#1

Current release, up to date on all the VMs and stuff.

Thanks to Dannii for all the emglken VMs. We should have the TADS status window bug squared away too, finally.

Release Lectrote 1.4.2 · erkyrath/lectrote · GitHub

8 Likes
#2

Is there any way to update Lectrote within the app? Or do I have to download it again?

#3

You have to download it again. Sorry.

(I see that auto-update technology exists for this app framework, but I haven’t figured out how to use it.)

1 Like
#4

It probably is just that my current Windows build is hot trash, but

I upgraded because 1.41 was showing an absent/broken image icon where I expected art to be. (or sound in one case)

In windows 11 with 1.42 I seem to be having mixed results with I7 gblorbs, art or no art. This is all stuff that works with parchment, winglulxe. z-code is fine.

They just hang with the “loading” screen with spinning compass. I left three windows open for ~10 minutes, no change.

6 instances
less than 2% CPU
less than 200 MB memory
0 disk activity

Since I own the commercial release of Anchorhead, I went ahead and downloaded 1.28 (that’s what’s there with my copy) and it handles images ok.

fake edit: walking back through the versions, the last release to show cover art for me is 1.3.10

#5

I don’t have Win11 lying around but I can check this on Win10.

When you say “mixed results”, do you mean some games work and some don’t? Which games don’t work?

If you open the dev console (Toggle Developer Tools menu item), is there an error visible in Console?

#6

Less and less mixed at this point. I don’t seem to be able to open gblorbs. I thought I had gotten a few, but I must have gotten confused with various versions DL’d. Just tried Scroll Thief and Counterfeit Monkey. Below is the console from Scroll Thief, though CM doesn’t look different.

node:internal/fs/utils:344 Uncaught Error: ENOENT: no such file or directory, open './emglken/glulxe-core.wasm'
    at Object.openSync (node:fs:585:3)
    at Object.func [as openSync] (node:electron/js2c/asar_bundle:5:1812)
    at Object.readFileSync (node:fs:453:35)
    at Object.e.readFileSync (node:electron/js2c/asar_bundle:5:9160)
    at common_emglken_load (C:\Users\crank\OneDr…pp\formats.js:65:26)
    at Object.load (C:\Users\crank\OneDr…p\formats.js:117:43)
    at load_named_game (C:\Users\crank\OneDr…p\apphooks.js:29:22)
    at sequence (C:\Users\crank\OneDr…p\apphooks.js:372:9)
    at EventEmitter.<anonymous> (C:\Users\crank\OneDr…p\apphooks.js:395:9)
    at EventEmitter.emit (node:events:390:28)
1 Like
#7

It’s a pathing problem. I moved a copy of the folder mentioned in the error up a level, and now it is working.

It loads my image, too. Nice

1 Like
#8

Ugh.

Did the total path length reach 256 characters? Some parts of Windows get real cranky about that.

#9

It isn’t bad so far as things go.

The lectrote folder path is
C:\Users\crank\OneDrive\Documents\general IF\Lectrote-1.4.2
(59)

Edit: though… it appears to need the folder wherever it is “running.” so if I want to double-click on a gblorb, it won’t open unless a copy of that folder is in the same directory as the file.

So whatever directory the app launches out of, it seems the folder has to be present. exe, gblorb, whatever.

1 Like
#10

You mean the Lectrote-1.4.2 folder has to be in the same directory as the game file? That seems strange, but I don’t know a lot about Windows.

Does anybody else see the same problem?

Can you avoid it by using the “Open” menu option inside Lectrote?

#11

no. It’s the folder in the console message so far as I can tell.

Launching the exe and then “open” doesn’t work unless the EMGLKEN folder is in the same place as the executable.

Double-clicking a GBLORB will hang unless a copy of the EMBGLKEN directory is in the same folder. It has to do with the START IN variable, I think. Undefined, apps just look around for resources where they are running.

I’ve just realized that I can partially work around this by making a custom Windows shortcut with a set START IN value (the initial value was the directory where the executable is. I changed it to the folder where the ENGLKEN directory can be found):

That allows the app to be launched and open files as expected. It does not do anything for opening GBLORBS (can’t set a START IN value for documents (AFAIK)

Also, if I move a GBLORB to the location where the default EMGLKEN directory is located, it launches fine.

EDIT: tried it on a win10 laptop and it seems fine. So… dunno if it’s me or Win 11

1 Like
#12

I can confirm the issue (Windows 8.1 here). It also occurs for TADS and Hugo games (for any engine which needs to be loaded from the emglken subdirectory), and only in Lectrote 1.4.2, not Lectrote 1.4.1.

It seems to have to do with what the program considers as the current working directory at the point when fs.readFileSync is called here (in formats.js):

opts.wasmBinary = fs.readFileSync(`./emglken/${file}-core.wasm`)

It probably wants a relative path starting from where Lectrote.exe is located.
Indeed, when I change the line above to this:

opts.wasmBinary = fs.readFileSync(`./resources/app/emglken/${file}-core.wasm`)

… then it works well and loads Glulx, TADS and Hugo games without an error.

3 Likes
#13

Oh, that would make sense. I had tested it just in unpackaged mode, where that’s the correct path. But if the working directory changes when it’s packaged then that would break.

2 Likes
#14

I figured it was the app directory. I was about to start rooting around in the files but of course I’m not a programmer

#15

Testing further, I see that my quick fix above only works when I start Lectrote.exe and use “Open Game” from the menu. Unfortunately, it doesn’t work for the case which you already outlined above, Drew (when we double-click a game file). In a way, that makes sense, of course, because then the working directory is set to the location of that file.
I haven’t looked into the codebase enough, and I don’t know enough about the Electron framework, to suggest a good fix at the moment.

Edited to add:
One way might be to use Node’s built-in __dirname to get the absolute path of the current module, and use that to construct the absolute path to the emglken subdirectory, like this:

var abspath = __dirname + `\\emglken\\${file}-core.wasm`
opts.wasmBinary = fs.readFileSync(abspath)

(works for Windows, would presumably need modification to be cross-platform again for POSIX paths with forward slashes)

Since it uses the module’s location instead of the current working directory, it works both for opening a game via “Open game” from within Lectrote and via double-clicking from an arbitrary location in the Windows file explorer.

3 Likes
#16

As an aside, Windows itself handles paths with forward and backward slashes. It’s only the Command Prompt, for historical reasons, that needs backslashes. So

var abspath = __dirname + `/emglken/${file}-core.wasm`
opts.wasmBinary = fs.readFileSync(abspath)

should work on Windows as well as anything POSIX.

1 Like
#17

Oh, neat!

I thought that I tested doing it that way (appending the POSIX-compliant second half), and I had a situation where that didn’t seem to work, and I then thought the reason for it not working might be that Node’s __dirname contains a Windows-style path on Windows, so the concatenated path will contain a mix of backslashes and forward slashes, like this:

G:\spiele\IF\Lectrote-1.4.2-win32-x64\resources\app/emglken/glulxe-core.wasm

That’s why I went with the all-backslashes in my previous post.

But now that I test it again, the mixed-slashes path works, so I don’t know what was going on in that situation (I must have inadvertently changed something else to make it not work).
Thanks for the advice!

#18

I’ve pushed out 1.4.3 which contains the __dirname fix.

4 Likes
#19

A change that went in recently: the Windows file dialogs (and, I think, Linux) now show both “.glksave” and “.sav” as a valid filetype for save games.

(The save files are the same. It’s only the filename suffix that changes.)

Someone suggested it to allow easier exchange of save files with older interpreters. But I worry that it might be confusing. There are of course lots of .sav formats in the world which have nothing to do with IF interpreters.

What do people think about this change? Worth keeping? Please try to keep the average and beginner IF players in mind, not just people who have been using interpreters for twenty years.

#20

Hey Zarf,

Any thoughts on a Tauri implementation of Lectrote?

Looks like it’s faster and has interesting features.

Dave

1 Like