v1.24 or v1.25 are probably the most common versions in use.a) *DIR ^ - I was initially using FS3 v 0.92, as the first source of FS3 that I came across. *DIR ^ is only supported from v1.24 onwards. That was the main source of my problems with Ozmoo.
Oh. I had issues with greater than 1.25 when I tried using it:b) having found the Stardot Github repository of L3FS, I tried to install 1.33 and discovered that Copyfiles as provided with L3Utils seems to have some problems with copying load and exec addresses - at least, when I changed to Treecopy 1.63a these addresses appeared correctly on my ADFS partition on my FS drive and I was able to start it and redo my user accounts so that home directories supported *DIR ^ - I am not clear on how this is implemented, but it seems that each directory folder entry must have a field denoting the parent directory - so only home folders created in 1.24 or later behave correctly.
viewtopic.php?p=349251#p349251
I understand that issue has now been fixed in v1.31, but I'm not sure about later versions:
viewtopic.php?p=411525#p411525
I've had countless issues with both CopyFiles and TreeCopy:
viewtopic.php?t=23959
viewtopic.php?p=350434#p350434
Some issues were down to PiFS. I now use a patched version of TreeCopy (details in the above link) and always run it from the co-pro.
If you're using the -a modifier to create an ADFS image, then I don't think it's necessary to also include the --nfs-install-only modifier.c) Using a minizork build including the -a and --nfs-install-only modifiers, copied the disc image contents to $.ZORK, added a SAVES directory, sorted permissions and edited !BOOT so that the third line was the absolute address of the user home directory - ie *DIR $.ZORK. Then uttered the magical incantation *OPT4,3
Now *I AM ZORK cleanly starts miniZork. This is achieved with no amendments to LOADER. Which is where I had initially hoped to get to.
I'm assuming that the user ZORK is the owner of the ZORK directory and all it's files. If you want other users to access that directory then make sure you've set the directory and file permissions to WR/R (and WR/WR for the SAVES directory) with the *ACCESS command.The issue on a server is of course that one would like multiple users to be able to use this code, including simultaneously, but these games were all created in a time of single user machines and floppy discs and in many cases, hard wired file/pathnames. So there is the thorny issue of saving game states. Ken's structure of a games directory appeals. What I have also found is that the save command in Zork will accept an NFS pathname. $.ZORK.savename gets an insufficient access error, BUT &.savename succeeded - &.SAVES.savename ditto. I will experiment with this, but I think that if the games are stored in a read-only gamesLib folder, and if the user correctly enters pathnames for saves, this could work. This is therefore the next experiment.
If you are wanting to store the game executables in a common area for multiple users to access, and for each user to have their own 'SAVES' directory in their own home directory, that should be entirely possible. Just make sure you've set the common area permissions appropriately, and if you create a 'SAVES' directory in the root of the user home directory, saves should automatically go into that directory.
Edit: Ah. I see you've discovered most of this!
Statistics: Posted by KenLowe — Thu Jul 18, 2024 10:30 am