Jump to content

EdwardianDuck

Members
  • Posts

    68
  • Joined

  • Last visited

Profile Information

  • Gender
    Male

Recent Profile Visitors

1,899 profile views

EdwardianDuck's Achievements

Star Raider

Star Raider (3/9)

93

Reputation

  1. In related news, Infocom's source code for some of their interpreters has surfaced here https://github.com/erkyrath/infocom-zcode-terps, including an Atari 8 bit one (not sure which version this is). Off topic, I was able to build the Acorn (BBC Model B) version by converting the source code to CA65 syntax. See https://stardot.org.uk/forums/viewtopic.php?p=408915#p408915. Jeremy
  2. @jindroush Yes, that's better, thank you. Uploaded again with a different name to make it clear that this is a released version. Hopefully this is the last release for a while and I can get back to the sequel. If anyone needs hints or wants to provide feedback, please post here. Jeremy DuckMe-Z3-20230903-Release2.atr
  3. I played through the game again using the latest test.atr without issue. One thing I did notice is that SAVE/RESTORE seems to want a double density disk (also cosmetic display issue). If the aim of this build is to target stock hardware, isn't that going to be an issue for most setups? I don't think this is a real issue, it's fine on emulators which is what I imagine most players would use, I'm just trying to figure out how to describe this to avoid confusion. I don't have real hardware myself. Jeremy
  4. I noticed the odd disk size and did think that it would be a problem on real hardware. @jindroush, is it possible to build this in a standard disk size/format? Unfortunately, I've no idea how you're building the image or whether just padding it out would work. In the short term, the two disk build uses a standard disk size. Jeremy
  5. So that this game has a permanent home, I've uploaded it to the Internet Archive here. This page also has a link to an online interpreter so that you can play the bare .Z3 in a browser. Jeremy
  6. @jindroush Yes, that works, thank you. I've played through the whole game again using the same walkthrough without issue. I've attached the .ATR again with a more descriptive name as this is now the release version. @ZeroPage Homebrew I'm calling this (in conjunction with the "20230828" files attached earlier on in this thread) a finalised release (it's currently shown as a WIP binary in your thread). Atari 8bit users have the choice of 1 or 2 disk builds, but for ease of use I'd suggest using the "jindroush" build here. If anyone finds other issues or wants a hint, please post here. Jeremy DuckMe-Z3-20230902-Release2.atr
  7. Even if you just wander around the game, it crashes after a relatively small number of moves with internal error 12, using the test.atr attached above.
  8. @jindroush Actually, no, but I get a different error much earlier in the game (I'm using the exact same walkthrough each time). This version gives "Internal Error 12" and the problem can be creating using the following moves. wear badge get torch get pillow s s e open packet eat crumpet Previously I was getting internal error #5957 when in game was listing the contents of various containers and supporters, some of which are nested (the jack is on the bucket which is on the crate which is under the desk in the study). OK, that isn't going to mean much unless one has nearly completed the game, but perhaps I'm hitting some sort of complexity limit in the interpreter. Using your build I'm not getting far enough through the game to trigger that issue. Another internal error was triggered when I tried to redirect to <<transfer noun second>> within a <<insert noun second>> action just to avoid a particular message being printed. I've since customised one of the response messages instead, which is a much better approach. I wasn't able to figure out precisely what the bugs were. In practice, I'm not particularly bothered by this, the two disk build works and I think that's good enough.
  9. The game has now been independently testing, although not specifically the Atari build. I'm now going to call this release 2 (release 1 was a disaster) and the files are attached. Please note that I have dropped the single disk build which used the early interpreter version as I have not been able to work around the bugs I appear to have triggered in the more complicated bits of my game. While there are apparently bug fixed versions of the interpreters, they don't seem to be publicly available, so I'm just going to release this as a two disk set. Also attached is the .Z3 file in a .ZIP archive. Just for information, none of the issues I've seen with the Atari interpreters appear when using the Acorn build of Ozmoo or when using a modern interpreter, so I'm reasonably sure the problems are interpreter related. Jeremy DuckMe-Z3-20230828-Release2-Disk1.atr DuckMe-Z3-20230828-Release2-Disk2.atr DuckMe-Z3-20230828-Release2.zip
  10. Is anyone willing to fully test this for me? By that I mean play the game through to the end and try anything that comes to mind while playing it. I'll provide a map and minimal walkthrough so you don't get stuck. I'd like to get a proper release out so I can move on to the sequel. Please PM me if you're interested. Jeremy
  11. Interesting idea, although I think (untested) that it'll break down in cases like ... PUT BUCKET IN CRATE ... in my game because both objects are ofclass ConstrainContent. One would probably have to check second first to cover more cases. I guess that in practice I'd try to design the game to avoid this sort of confusion.
  12. The work round is to replace self with either noun or second as appropriate in the class before routine. That works in my game because for the impacted classes self == second in all cases. If a game has a class where self could be either noun or second, that's more of a problem.
  13. To clarify slightly, "before" is additive. You typically use it to constrain some action. In my case I have a class which uses "before" to constrain what containers can hold, based on some properties. For a particular container you might have a "before" routine to check some other condition which is not expressed by the class properties. What's supposed to happen is the class "before" routine is called first, then the object "before" routine. Without coding round the problem, it appears that self = 0 in the class "before" routing when object also has a "before" routine. Self should be the object number in each case. Probably. Unless I'm not understanding how it all works, which is quite likely. Jeremy
  14. At long last, yet another beta (see top post), .ATR + .Z3 in the Zip as usual. For no particular reason I've included both 1 & 2 disk versions. The only difference is the version of the interpreter used.Fingers crossed it's less buggy now and most of the terrible omissions have been dealt with, but as testing is really just me "marking my own homework", who knows? I have had to make Atari specific code changes to deal with what looks like an interpreter issue. In Inform, if you have a class with a "before" routine and an object which is an instance of this class which also has a "before" routing, things get confused and the interpreter tries to reference object 0 ("nothing") instead of the actual object when referenced as "self". If one removes the "before" routine from either the class or the object, the error goes away (but so does the associated functionality). This doesn't happen using Ozmoo on the BBC Micro or in whatever Spatterlight uses on my Mac, where "self" references the correct object. Same issue with "after" routines as well. It's easy enough to code round in specific cases, but it's not very generic.Jeremy DuckMe-Z3-20230613-Beta19.zipDuckMe-Z3-20230613-Beta19.atrDuckMe-Z3-20230613-Beta19-Disk2.atrDuckMe-Z3-20230613-Beta19-Disk1.atr
  15. Effectively yes. I fiddled about with the A8 script from the Puddle Build tools because they don't seem to work on macOS out of the box (or possibly they do and I don't know how to run them on macOS), but the actual process is the same.
×
×
  • Create New...