#58 - proposed changes #59
Conversation
|
Maybe this is the upstream for "Mainframe"/"MDL" Zork now: https://github.com/PDP-10/its/tree/master/src/lcf CC @eswenson1; also #58 |
|
@larsbrinkhoff |
|
@AlexProudfoot, if it's not too much trouble, yes please! (By the way, no need to make both an issue and a pull request for the ITS repository. The latter is enough by itself.) |
|
@larsbrinkhoff |
|
Re-making from scratch should work. Did you include |
|
Hmmm. Remaking works. My solution to make the windows visible using Confusion doesn't work when using Muddle. I'll need to try something different. |
|
@AlexProudfoot Can you explain how your change to add the window function when one tries to open that window is related to your comment about making windows visible under Muddle? I’m confused! |
|
Sure. I was referring to a previous related change. If you start Zork and go north, you will be at “North of House”. If you then type “look at window”, the answer will be “I don’t see any window here.” Although there is a global object representing windows in the sides of the house and that object is a local-global in NHOUSE. This was fixed by #30. The response becomes “I don’t see anything special about the window.” The window object is now “visible” i.e. in scope. Now you can attempt to open the window and will notice the incorrect response that the window function fixes. |
|
What I meant to say was that #30 doesn’t work when applied to https://github.com/PDP-10/its. |
|
Hmmm. No success yet. I need to shorten the turnaround time on my experimental changes. How do I rebuild Zork from inside the PDP-10 simulation. |
|
To recompile Zork, do: :xxfile tty:_lcf;comp xxfile then do: :xxfile tty:_lcf;zork xxfile |
|
For operating ITS in general, I'll point to this page: https://github.com/larsbrinkhoff/its-manual/wiki/HACTRN-basics |
|
I just added a GOBJECT based on the HOUSEBIT object and that's not visible either. That is, the parser recognises the name but it's not in scope. I don't understand what's going on. Is there a limit to the number of GOBJECTs that can be declared? |
|
Finished now @heasm66. |
|
As you've said, the fix, as outlined here, doesn't work on ITS (MUDDLE) Zork. The reason is that the "NHOUS" room needs to have a " (<GET-OBJ "DWIND">)" in the list of objects for the room. If you add that, as well as the DWIND-FUNCTION and "DWIND", then the fix works on ITS Zork. Here is the complete diff of DUNG: With these changes in place, I get: |
|
Shouldn't the same thing be done for "SHOUS"? I get this: |
|
What happens if you try? |
|
Adding the dwindow object to SHOUS object fixes it there too: Change is: |
|
After making both changes, have you navigated to both rooms and obtained the same result. I ask because I thought GET-OBJ was exclusively used for local objects, not global ones. |
|
Works fine. I can go to north or south of house and get the right behavior on “open window”. I went back and forth several times. Feel free to try it out on ES yourself. |
As far as I know, GET-OBJ is used to get the pointer to any object on the global object list. And in order to have a room “contain” an object that can be referenced from the room, you need to put the object on the list of room objects. That allows the parser to find the object when you refer to that object. |
|
That’s great news. I have to admit to still being confused because the situation with all other RGLOBALs, the house for example, is that if it’s on the RGLOBAL list it’s also in scope and GET-OBJ is not needed. Do you have an explanation for why the global window object is different (currently unique) in this respect? |
|
I always thought that either the object had to be on the "objects in room" slot of the ROOM object (or in your inventory) in order to be used as a direct or indirect object in a command. If an object is neither in the room or in your inventory, you get the "I can't see any XXX there." message. |
|
There also has to be a way of making “backdrop” objects. These are in scope in multiple rooms but are not separately listed in the room descriptions and may not be taken. That’s what the RGLOBAL section is for. |
|
Yes, GOBJECT is a function for defining global objects (not necessarily in a single room or in inventory, and accessible as a direct or indirect object from multiple rooms), and that RGLOBAL was a means for specifying, by adding together bits (e.g. ,DWINDOW, ,HOUSEBIT, etc.) and then adding this bitmask to a ROOM to indicate that you could reference the global object "from this room". But it does seem a little more complicated than that, because you can access some global objects (e.g. "sailor") from any room without having an RGLOBAL reference in each room. However, I think for those kinds of objects, any verb used with them results in a word-specific function being invoked, as opposed to getting a "I don't see xxx here" message when you invoke a command that references the word. If no word-specific function is defined for the GOBJECT, however, you get "Nothing happens" as a default for whatever you try to do with the object. |
|
Another problem is that, despite the naming, HOUSEBIT has nothing to do with bit masks. The item ,HOUSEBIT is the GVAL of the object called HOUSEBIT which evaluates to the address of the object. I can only assume that, in this context, <+ …> constructs a list of object addresses. Have you tried your fixes in the interpreter or just in the compiled version? |
|
Hey @eswenson1, here's an interesting result from trying to load zork into the muddle 5.5 interpreter.
It seems that the declaration of DWINDOW causes an overflow. |
|
You were right @larsbrinkhoff. If I comment out DWINDOW, loading continues but there is not enough memory to finish loading DUNG. |
|
Well, it turns out there is a real limit to the number of GOBJECTs you can define. Each new one increases GLOHI by a factor of 2. So we have: And then the definition of DWINDOW ("window") attempts to multiply that last value by 2 and gets an arithmetic overflow. Simply put: But the fix doesn't add a new GOBJECT -- this overflow already exists (when you load the code interpreted). When you compile it and load compiled, the overflow is not caught. Presumably the value of GLOHI simply overflows without error. Since we didn't add this GOBJECT, and the original code had it and worked, I don't think we should worry about the overflow. |
|
I observe the first set of four walls share a vaule. Then there's
another which has two new values. What's up with that?
|
So, HOUSEBIT really is to do with a bit. Each global object is associated with a power of 2 starting at 1 and ending, in practice, at 35. Calculation of the next power of 2 produces an integer overflow. I guess the problem doesn’t exist in Confusion because the integers have 64 bits as opposed to 40. @heasm66 - Do you know how this problem was avoided in 32-bit Confusion? |
It depends what you mean by “worked”. We are still left with the original problem of not being able to refer to the windows in NHOUSE and SHOUSE. It’s clear that the implementation of global objects will not correctly support this. |
Maybe this is the way to go after all. If it works for me, I can submit a pull request if you like. |
|
Its been a while since I looked at the code and I don't even remember if
Zork runs in 32-bit Confusion. I know there are a couple of places that
uses all 36 bits for flags and such. This could be another case where the
number of global objects are limited by 36 bits and Zork uses every slot
already.
Den lör 18 nov. 2023 11:40Alex Proudfoot ***@***.***> skrev:
… @eswenson1 <https://github.com/eswenson1>
As you've said, the fix, as outlined here, doesn't work on ITS (MUDDLE)
Zork. The reason is that the "NHOUS" room needs to have a " (<GET-OBJ
"DWIND">)" in the list of objects for the room. If you add that, as well as
the DWIND-FUNCTION and "DWIND", then the fix works on ITS Zork.
Maybe this is the way to go after all. If it works for me, I can submit a
pull request if you like.
—
Reply to this email directly, view it on GitHub
<#59 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOJZOMQ2A4WE2T745FU5FGLYFCGAXAVCNFSM6AAAAAA6ZCZTJCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJXGQ3TENJRHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
What I meant was that the fix (augmented with the GET-OBJ calls) works fine on ITS compiled. That we get an integer overflow when interpreted doesn’t affect the normal compiled use case). So we should commit this fix (I can do that). In your original fix, you didn’t add the offending GOBJECT — it was already there. So you didn’t introduce the overflow. We never noticed the issue because we don’t ever run interpreted — we can’t because there isn’t enough memory to load it all interpreted. If you agree, I’ll commit the fix since I updated it and have tested it on ITS and found that it fixes the original problem. Note: the addition of the “DWIND” string ID is required — the fix doesn’t work using the “WINDO” ID. |
|
@eswenson1 - Ok Eric. Please do that. |
…ional windows. Addresses this issue: heasm66/mdlzork#58 And this fix: heasm66/mdlzork#59
|
I've submitted this PR: PDP-10/its#2257 |
…ional windows. Addresses this issue: heasm66/mdlzork#58 And this fix: heasm66/mdlzork#59 Also updated LCF;COMP XXFILE and LCF;ZORK XXFILE in an attempt to make them a little more robust.
…ional windows. Addresses this issue: heasm66/mdlzork#58 And this fix: heasm66/mdlzork#59 Also updated LCF;COMP XXFILE and LCF;ZORK XXFILE in an attempt to make them a little more robust.
…ional windows. Addresses this issue: heasm66/mdlzork#58 And this fix: heasm66/mdlzork#59 Also updated LCF;COMP XXFILE and LCF;ZORK XXFILE in an attempt to make them a little more robust.
I didn’t understand your observation (can’t figure out what you mean). |
How does this work at all on PDP-10s? As far as I know, FIX values are limited to 36 bits. There are 40 GOBJECTS defined and multiplying 1 by 2 40 times should overflow a FIX (WORD) variable. Why does the overflow only occur at the 40th object and not the 36th object? |
…ional windows. Addresses this issue: heasm66/mdlzork#58 And this fix: heasm66/mdlzork#59 Also updated lcf/comp.xxfile so that it doesn't fail during ACT2 build. Seems the occasional failures during zork build can be mitigated by breaking up some of the compiles into separate jobs.
|
Please be patient if I seem a bit dense at any point. Wasn’t the PDP-10 a 36-bit machine so why would FIX values be limited to 32 bits? Also, if you look over your number doubling list, you can see that the numbers don’t double for every object. As @larsbrinkhoff said “What’s up with that?” I believe the numbers double to the point where the result would overflow 36 bits. Why the numbers don’t always double, I don’t know. |
Sorry. I typed 32 when I meant 36. The point I was trying to make -- but perhaps I'm the one who is being dense here -- is that doubling 1 36 times should overflow, and yet we don't see the overflow until the 40th object. However, I didn't realize that the numbers didn't double each time. I thought I saw code that did the equivalent of If they don't double each time, of course, then we wouldn't die at 36 objects. I don't see how we can't be doubling though -- especially since we are trying to compute a bit value for each GOBJECT defined. |
…ional windows. Addresses this issue: heasm66/mdlzork#58 And this fix: heasm66/mdlzork#59 Also updated lcf/comp.xxfile so that it doesn't fail during ACT2 build. Seems the occasional failures during zork build can be mitigated by breaking up some of the compiles into separate jobs. Updated zork.tcl to look for :KILL rather than .VALUE first.
…ional windows. Addresses this issue: heasm66/mdlzork#58 And this fix: heasm66/mdlzork#59 Also updated lcf/comp.xxfile so that it doesn't fail during ACT2 build. Seems the occasional failures during zork build can be mitigated by breaking up some of the compiles into separate jobs. Updated zork.tcl to look for :KILL rather than .VALUE first.
|
I’ll try to more precisely decipher the MDL code today but I do remember seeing conditionals.
I can guess that these ensure that all GOBJECTS with a null name share a GVAL of 1 and all objects that share a non-null name share the GVAL that was established when the name was first declared. |
|
@heasm66 |
|
I havn't studied the GOBJECTS but my guess is that objects with the same number are synonyms, i.e. EAST, WEST, NORTH and SOUTH WALL should all respond in the same way when refered to. |
|
The date is from the newspaper (in the kitchen) that states: |
…ional windows. Addresses this issue: heasm66/mdlzork#58 And this fix: heasm66/mdlzork#59 Also updated lcf/comp.xxfile so that it doesn't fail during ACT2 build. Seems the occasional failures during zork build can be mitigated by breaking up some of the compiles into separate jobs. Updated zork.tcl to no longer use XXFILE to either compile or load/save zork. XXFILE seems too brittle and doesn't function consistently.
Updated Zork to address issue with bad message when opening non-functional windows. Addresses this issue: heasm66/mdlzork#58 And this fix: heasm66/mdlzork#59
Updated Zork to address issue with bad message when opening non-functional windows. Addresses this issue: heasm66/mdlzork#58 And this fix: heasm66/mdlzork#59
Proposed changes for issue #58.