The TypeError: _this.sscanf is not a function crash provides two huge pieces
of information:
The Missing EFUN: sscanf is a fundamental C/LPC function that relies on memory
pointers (pass-by-reference) to populate variables. JavaScript does not have
pointers for primitives (like strings), which means we have to bridge this gap
architecturally.
The Missing File Path: The output GD >>> Config-line[0]: 0 indicates that
read_file("gd.cfg") failed and returned 0. It failed because the file is
actually located at gamelib/gd.cfg, but master.c doesn't know that it's being
executed from a parent folder.
We can solve both of these permanently right now.
The Fix
1. The AST sscanf Interceptor
Instead of trying to pass variables by reference (which JS forbids), we will
instruct the codegen.js AST parser to intercept sscanf(str, fmt, var1, var2)
and dynamically transpile it into an inline Javascript IIFE that unpacks an
array:
(() => { let res = rt.sscanf(str, fmt); var1 = res[0]; var2 = res[1]; return
res.length; })()
This perfectly mimics C-pointer mutation using standard JavaScript!
2. The File System Auto-Resolver
We will upgrade efuns.d/04_fs.js to automatically check the gamelib/ subfolder
if it fails to find a file in the root directory.

==

I also pushed out is_array, is_mapping, and sprintf to 07_types.js and
03_system.js because I noticed they are used heavily during the initialization
sequence of the world.c and simul_efun.c files.
Run node test_runner.js verify first to ensure we didn't break any regressions
with the new sprintf integration. Then fire up node harness.js
gamelib/secure/master.c. It should read the config, trigger the printf boot
sequence, and attempt to start loading the gd.ini file directory tree!