Version 0.10 of ZILF is here! Highlights include support for vehicles, a new centralized library message system, quasiquoting, better (and easier) abbreviation finding, new sample projects, and six years’ worth of bug fixes.
Get it at the all-new zilf.io, where you can now even try it out in your browser first.
seems that the Linux binary is missing or inaccessible:
<Error>
<Code>NoSuchKey</Code>
<Message>The specified key does not exist.</Message>
<Details>
No such object: zilf-releases/0.10/zilf-0.10.0-linux-x64.zip
</Details>
</Error>
Best regards from Italy,
dott. Piergiorgio.
The link for Linux_x86 should be: https://storage.googleapis.com/zilf-releases/0.10/zilf-0.10.0-linux-x64.tar.gz
You can find it if you click “other downloads”, here.
(I’m pretty sure it will be fixed soon.)
Oops, fixed.
Thanks to both.
As expected, there’s, again, the need to sort out how put these m$hit files in a cooperative behaviour under this Linux box, but isn’t urgent (no zilf WIPs, anyway: I use only when respectfully tinkering with the Venerable Historical Sources)
on my usage of zilf, I reiterate my opinion on version numbering: 0.9 already compiles perfectly every Infocom source (I daresay, the ultimate test suite…), so I remain convinced that zilf ought to be already into 1.x versioning.
of course, after (someday…) putting the binaries into cooperation with Linux, I’ll do the real test suite (compiling everything from Zork I to Journey…), please be very patient…)
Best regards from Italy,
dott. Piergiorgio.
It should be as simple as extracting the tar.gz somewhere and then either adding bin to your path or linking zilf and zapf someplace that’s already in the path.
It’s been a while since I had a Linux desktop. If someone who actually uses Linux (or macOS) in their day-to-day wants to step up and take ownership of the Linux/Mac builds, it’d be appreciated. In the meantime, I suppose I can try to cobble something together with fpm.
Compiling the historical source is an important use case, but not the only one.
Call it perfectionism, perhaps: I don’t think I’ll be ready to call it 1.0 until I’ve cleared the remaining bugs and some big usability issues. For example, expecting authors to copy the entire library and delete the verbs they don’t want to implement was one thing in 1980, but in 2025, I think we can aim closer to “Inform 5” levels of customizability.
(I took a “just hack the library” approach with Guncho, and… that’s why its version of Inform only got upgraded once or twice. What an ordeal that was!)
I thought I would give this a quick go - so I downloaded the win64 version. A while back I converted a version of ‘The Awakening’ by Dennis Matheson to ZIL just as a learning exercise - This compiles okay in 0.9 but fails with this error in 0,10 ?
in INSERT-FILE called at awaken.zil:21
[error MDL0128] C:\zilf\zillib\TEMPLATE.zil:81: SET: arg 3: expected ENVIRONMENT
in HANDLE-DEF called at C:\zilf\zillib\TEMPLATE.zil:46
in MAPF called at C:\zilf\zillib\TEMPLATE.zil:45
in OBJECT-TEMPLATE called at E:\ZIL\Awakening\ZIL_VERSION\start.zil:1307
in INSERT-FILE called at awaken.zil:21
The code defines some OBJECT-TEMPLATES - and this seems to be the point of failure, but I am unsure what this error means? The code to create the template is:-
<OBJECT-TEMPLATE
OUTSIDE = ROOM
(IN ROOMS)
(CANTGO CANT_GO_OUTDOORS)
(UP SORRY NOT_YOUR_TIME)
(DOWN SORRY NOT_YOUR_PLACE)
(FLAGS LIGHTBIT ONBIT OUTSIDEBIT)
(ACTION OUTSIDE-F)
(GLOBAL CHURCH OUTSIDE_STORM RAIN MUDDY_GROUND STEEPLE WINDOWS); "ADD GLOBAL OBJECT HERE">
Oops - it’s very possible that some internal changes in 0.10 broke templates. I’ll look into this.
At least with Debian, I had to install Microsoft’s dotnet-runtime-9.0 package for it to work. On the plus side, I could finally get rid of an obsolete libicu67 package that I only kept around for ZILF 0.9.
Microsoft officially recommends using their install script, I think, but hey–whatever floats your boat. Also, glad to see ZILF is back!
Raspberry Pi 5 problems…
Zilf 0.10b5 (linux-ARM64) runs properly on the Pi 5 but the release version will not.
Error: Requires libstdc++.so.6 ? (Note: tried installing all arm64 dev versions)
I have not been able to find the difference. 0.10 works fine on Win 11.
Thoughts?
Jeff
As I remember I built that version directly from source and made it self-contained (with trimming). This isn’t exactly how the release is published. Self-contained should theoretically remove the need for NET9 Runtime. Maybe this is the difference here for the raspberry?
Can you share the build commands for the source. I haven’t found the right combination yet.
The version (linux-arm64) linked through the Discord Server and Tara’s link below works fine.
Absolutely, but I’m currently at work so it will take a couple of hours. Maybe @vaporware will beat me to it, because it looks like there’s work going on in the project (I see branch pushes on the Discord server).
this is great and there seems to be maybe some critical mass building for zilf. i would humbly suggest that this may be a good time to change the readme from:
“### How do I get set up? ###
Someday we’ll fill in this section with instructions for building the project, configuring it, installing dependencies, running tests, etc.”
to actual helpful instructions on how to get it set up (and not just on windows. i’m having no luck on macos).
Anyone who’s having trouble installing, try downloading one of the self-contained builds from here and let me know how it goes. These should theoretically work without .NET installed.
I have to complement you on the website… i especially liked the about story. I honestly never made the more pubescent connection of the name until you mentioned it…
That did the trick for me.
The linux-arm64 version works on the RPi 5.
Thank you!
Linux-x64 works on Ubuntu 24.04.3 LST.
downloaded the self-contained macos build (the arm-64).
if i run zilf or zapf (i’m literally just inputting ./zilf --help) the process is immediately killed.
i have no idea what this means or what to do about it.