Nodes - What are they? And Inventory said property mystery

[MusicallyInspired]

In my attempts to unravel the mysterious inventory item 'said' property and why it doesn't work, I've been reading up on all the SCI information I can from the SCI Studio help file. Almost everything is there, but many times it references something called a "node" and the help file doesn't have a specific entry for it. I assume this is a generic programming term but I'm confused as to what it is, does, and how it works in SCI scripting. Anybody know?

[lskovlun]

There are a couple of things that this could refer to. Can you quote a bit for context, please?

[lance.ewing]

Not having ever tried to write SCI code, my guess from a more generic point of view is that it would be nodes in a linked list. I've written code to implement linked lists before and nodes are what I called the things that held the data for a particular item in the list and that also had pointers to the next and previous nodes. I'm guessing I called it that because that is probably what they are usually called. And I think I saw in the list of SCI kernel functions that there were a number of functions that dealt with nodes within kernel managed linked lists, so this sounds like a likely answer then. Under the hood I'm guessing that the inventory is managed by such a kernel list.

For my own curiosity, what is mysterious about the said property that you referred to? Is it something that isn't understood much within the SCI programming community? And when you say it doesn't work, is it that you think the original feature in the Sierra interpreter doesn't work, or that the SCI Studio/SCI Companion compilers don't treat it properly, or that the lack of understanding of how it works means that it is hard to get it to work?

[lskovlun]

@Lance: That's one of the things it could be, yes. On the other hand we could also be talking about parse tree nodes, which would be a somewhat longer story to tell. And I guess Brandon's background is not in computer science...

[MusicallyInspired]

Not having ever tried to write SCI code, my guess from a more generic point of view is that it would be nodes in a linked list. I've written code to implement linked lists before and nodes are what I called the things that held the data for a particular item in the list and that also had pointers to the next and previous nodes. I'm guessing I called it that because that is probably what they are usually called. And I think I saw in the list of SCI kernel functions that there were a number of functions that dealt with nodes within kernel managed linked lists, so this sounds like a likely answer then. Under the hood I'm guessing that the inventory is managed by such a kernel list.

This sounds likely. The Inv class is an extension of the List class. Here's the init method from the InvD class which features node manipulation. The init method of invD is used to display the Inventory list window.

Code: [Select]

(method (init theOwner)
(var temp0, temp1, temp2, temp3, temp4, temp5, temp6)
= temp1 4
= temp0 4
= temp2 4
= temp3 0
= temp5 (send gInv:first())
(while(temp5)
    = temp6 NodeValue(temp5)
    (if(send temp6:ownedBy(theOwner))
    ++temp3
    = temp4 (DText:new())
    (self:add(
    (send temp4:
value(temp6)
text((send temp6:name))
nsLeft(temp0)
nsTop(temp1)
state(3)
font(gDefaultFont)
setSize()
yourself()
)
))

    (if(< temp2 (- (send temp4:nsRight) (send temp4:nsLeft)))
    = temp2 (- (send temp4:nsRight) (send temp4:nsLeft))
)
    = temp1 (+ temp1 (+ (- (send temp4:nsBottom) (send temp4:nsTop)) 1))
    (if(> temp1 140)
    = temp1 4
    = temp0 (+ temp0 (+ temp2 10))
    = temp2 0
)
)
  = temp5 (send gInv:next(temp5))
)
(if(not temp3 )
    (self:dispose())
return(0)
)
= window SysWindow
    (self:setSize())
= btnHandle (DButton:new())
(send btnHandle:
text("OK")
setSize()
moveTo((- nsRight (+ 4 (send btnHandle:nsRight))) nsBottom)
)
    (send btnHandle:
    move(
    (- (send btnHandle:nsLeft) (send btnHandle:nsRight))
    0
    )
    )
(self:
add(btnHandle)
setSize()
center()
)
return(temp3)
)


For my own curiosity, what is mysterious about the said property that you referred to? Is it something that isn't understood much within the SCI programming community? And when you say it doesn't work, is it that you think the original feature in the Sierra interpreter doesn't work, or that the SCI Studio/SCI Companion compilers don't treat it properly, or that the lack of understanding of how it works means that it is hard to get it to work?

It could be either of the last two. I'm sure Sierra's games used the function correctly, or it worked correctly or something. Specifically, every inventory item defined has a "said" property, which is a word (noun) from VOCAB.000 as its identifier. Meaning that when you type "look box" or something else it's supposed to check the list of inventory items to see if that noun is one of the inventory said identifiers. I guess more than likely we're just not using it correctly. Like there's a condition we're supposed to add...or maybe it's missing from the global Said statements or something. This is yet another portion of SCI code syntax that Brian never ever explained, at least to my knowledge.

[lskovlun]

Ah, those are nodes of a linked list indeed, as Lance suggested.  A linked list is a list of objects that makes no commitment to size. So it can grow as large as you have memory, or it can shrink to nothingness when it contains no elements. Furthermore, linked lists make it easy to move back and forth between the elements of a list (to perform some action on each, say) and remove specific elements - the List class has a number of methods to facilitate this (but they are not used in your code excerpt). That is to say, the elements of a linked list are stored in the same order we added them, and so this order must be stored somewhere. However, since we cannot claim any space in the objects that are put in a list (what if one SCI object is a member in many different lists?), this information gets stored somewhere else. And that place is the node.

(There's more to the story, of course, but we can get to that another day)

As you say, the purpose here is to set up the text and buttons of an inventory dialog (but not to show it - that comes elsewhere).

So, to answer a not entirely unrelated question: No, this not the right place to add support for the look idiom. The right place is the global handleEvent method.

In there, say something like (I'm not entirely fluent in Brian's syntax; I hope you can massage this into working code):

Code: [Select]

(if (Said('look >'))
  = lookObject (send gInv:firstTrue(#saidMe))
  (send lookObject:showSelf())
)
Now, let's take that very slowly. I mentioned above that linked lists (List class) have some methods designed to facilitate going through the members of a list in order. In this case, we want the first element in the inventory list whose saidMe method returns TRUE. And when does that happen? When the remaining part of the user input corresponds to that object's said property (this should only happen for one object - otherwise you should perhaps rethink the names of your inventory items). Note that this means you must set the said property correctly! As soon as firstTrue finds an object for which saidMe returns TRUE, it returns a pointer to that object. We can then ask the object directly to show itself (as the inventory dialog already does).

[MusicallyInspired]

Finally an explanation! I wonder why this wasn't added to the template game. It seems like a pretty mandatory parser event. Will this code also check to see whether Ego is the owner of it or not? Or would we have to put this code under some kind of a nested if statement checking it first?

Also, what is lookObject supposed to represent? Where would it be defined?

[lskovlun]

lookObject should declared as a variable, preferably inside the handleEvent method (which is where that code goes).
I guess it's not in the template game because it's not in LSL3. There are a couple of things in the template game that conversely
aren't strictly necessary in an SCI game.
And no, that does not check whether ego owns it. I guess you need to say something like

Code: [Select]

(if (Said('look >'))
  = lookObject (send gInv:firstTrue(#saidMe))
  (if (send lookObject:ownedBy(ego))
    (send lookObject:showSelf())
  )
)


[lskovlun]

and to have some appropriate response in case ego does not have the object (for the record, I don't think it is appropriate to say "You don't have it" since it hints that the object exists in the game).

[MusicallyInspired]

Interesting. So I guess LSL3 just had manual global said statements for looking at each inventory item ego has? Or could you just not do that at all?

I'll try out this code and will report back.

[MusicallyInspired]

It works!!! I used the phrase "You don't see that here anywhere." for if ego does not own the object. If you don't mind, could you throw this in the how-to section? This has been plaguing me for years since I started KQ2SCI back in around 2006. Or I can do it and give proper credit. This could do well to be added to the template game as well.

[MusicallyInspired]

One small problem, whenever the parser catches someone trying to look at something that is a word in VOCAB but not an inventory said property the game crashes with "Not an object" error message and closes.

EDIT: Changing the code to this seems to avoid the error. But now I'm getting a Bad Said Spec error and I'm not sure what's causing it. After the message goes away it displays the appropriate "You've left me responseless." dialogue so I'm not exactly sure what's failing.

Code: [Select]

(if (Said('look>'))
    (if (= lookObject (send gInv:firstTrue(#saidMe)))
        (if (send lookObject:ownedBy(gEgo))
             (send lookObject:showSelf())
        )(else
             Print("You don't see that here anywhere.")
         )
    )
)

EDIT 2: It turns out the problem was that the parser wasn't liking the [<word] additions I was putting in inventory said identifiers. Removing them solved it. But that does make it a little annoying that you can't make optional or OR additions to it.

[lance.ewing]

This is yet another portion of SCI code syntax that Brian never ever explained, at least to my knowledge.

I guess it is possible he didn't fully understand it himself at the time... or perhaps he overlooked it given that to me there seems like so much to explain.

As an aside, whenever I see the SCI Studio/Companion syntax like what you've shown, I'm tempted to go through it and change it to what the original SCI syntax was (after having spent that time a while back trying to discover what the original syntax looked like). Now that we know where the sample code from the PQ SWAT game lives (i.e. Wikipedia), we have a better idea of what the original looked like. I wonder if at some point someone could attempt to add the original syntax as an option to SCI Companion?

[MusicallyInspired]

It's definitely possible. Troflip was working on adding a C++ syntax to Companion way back but he never finished it. The option is still there in the preferences window but it's greyed out. It would seem that Companion is set up already for other syntax's. It's just making them...