Can't pick up the rope or hook after dying (if they are tied together)

[eriktorbjorn]

I haven't tried to diagnose why this happens, but if I've tied the rope and grappling hook together, and then get myself killed and resurrected, the hook and rope are scattered along with the rest of your inventory. But if I find them again, I can't pick them up except with "TAKE ALL":

LOOK

  This is the garden.  Tomato plants are growing neatly in rows. 
  A narrow path goes east and a wider one goes west.

  To one side lies a wooden stake. 

  There is some "HORROR HOTEL" writing paper here. 

  There is a heavy steel grappling hook here.

TAKE HOOK

  I don't see that here.

I haven't checked if any other objects are affected. I'll see if I can figure anything out later.

[eriktorbjorn]

The problem seems to be that the parser expects the rope and hook to be together when they are tied. See main.f:

      IF (OBJECT .EQ. 9 .AND. ROPE .EQ. 3) GOTO 452
      IF (OBJECT .EQ.16 .AND. ROPE .EQ. 3) GOTO 452

Object 9 is the rope, object 16 is the grappling hook, and ROPE is 3 when they are tied together.

  452 CONTINUE
      IF (PREC .AND. ROOM .EQ. 83) GOTO 303
      IF (ITEMS(9).NE.ROOM .OR. ITEMS(16).NE.ROOM) GOTO 201
      ITEMS( 9) = -1
      ITEMS(16) = -1
      NUMB = NUMB + 2
      IF (PREC) PREC=.FALSE.
      GOTO 800

Room 83 is the top of a steep precipice. I don't think I've ever gotten that far (I thought I had to tie them together to get out of the bedroom, but that didn't work... which was how I died and discovered the bug in the first place) so I'm not sure what that's about. But the second line is important, because that means that if either the rope or the grappling hook aren't in the room it will go to 201, which prints "I don't see that here."

I don't see anything in the "DEATH AND REINCARNATION" part of the code that would either split up the objects (by resetting ROPE) or guarantee that they end up in the same room, so I guess this is a bug in the original code? Is fixing those a priority, or should they be preserved and just documented as known bugs?

[Quuxplusone]

My take is:

• This looks like an original bug in the game logic. Your explanation makes perfect sense and matches my own expectation.
• We have seen one example so far (#8) where the code worked fine in 1980, but the meaning of the syntax changed such that the code became buggy when compiled on a newer compiler. If this were a situation like that, then I would patch it in the patches branch, just like we did with #8. But all evidence so far indicates that this is not a situation like that. Someone playing on the RPI time-share system in 1980 would have seen exactly the behavior you report; therefore this is "authentic" Castlequest; therefore I am not going to patch it away in the patches branch.
• I predict that at some point I'll attempt porting the game to C, so that I can run it on the Z-machine á là https://quuxplusone.github.io/Advent/ . If I do, then in the C port I would fix this kind of "original but clearly accidental" bug, as well as fixing "original but accidental" spelling errors in the messages, and so on.

[eriktorbjorn]

Sounds good to me, and I take it that means this kind of bug reports are still worth filing for future reference.

[Quuxplusone]

Well, I don't encourage people to file issues on this repo just for "original bugs"; that isn't useful for my purposes. But I can also see how some original bugs might be interesting for people to hear about. I mean, I'm the guy who blogged https://quuxplusone.github.io/blog/2020/02/06/water-bottle-bug/ and https://quuxplusone.github.io/blog/2019/01/28/mcdo0551-sandbox-game/ 🙂

I just really don't want people opening a bunch of issues like "discren should be discern", you know?

[eriktorbjorn]

I just really don't want people opening a bunch of issues like "discren should be discern", you know?

How about just a single bug report for all known irregularities in the text?

[eriktorbjorn]

Anyway, I promise I'll stick to weird bugs. I think this one qualifies. :-)