Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - lskovlun

Pages: 1 ... 32 33 [34] 35 36 37
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())

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).

SCI Syntax Help / Re: Nodes - What are they?
« on: August 29, 2011, 03:02:03 PM »
@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...

SCI Syntax Help / Re: Nodes - What are they?
« on: August 29, 2011, 02:48:20 PM »
There are a couple of things that this could refer to. Can you quote a bit for context, please?

SCI Community How To's & Tutorials / Re: Using timers
« on: August 29, 2011, 02:42:16 PM »
Does anyone know for sure that timers go away inappropriately? As I wrote below many years ago, that should only happen if their clients become NULL - which they do after signaling the client. If so, that is a matter to be investigated. Otherwise, in summary, the things to watch for are:
  • Make sure the Script you gave to the timer remains valid until timer expiration. That is, place it in a region or globally.
  • Make sure that you use the right kind of timer for the job (as described in the original article)


Is,83.0.html useful, by chance?
I have a few additions to that original how-to, which I am going to post there.

SCI Syntax Help / Re: Original SCI syntax
« on: July 30, 2011, 06:20:23 PM »
Hi Lars. I was trying to track you down a few days ago. I tried emailing but not sure if I got the right email address. Is it still the one on your profile page on this site?
Hmm... *checks* no, it's not... *fixes* done.
Should be good now.

SCI Syntax Help / Re: Original SCI syntax
« on: July 30, 2011, 09:03:12 AM »
I haven't posted it on-line because it is really only for investigative purposes, and it does not belong in the main tree (or as a formal patch).
I imagined we would take care of things on IRC, though I must admit I'm not entirely clear on what the next step is after trying this code.
What it does is it clears the underBits of all cast members during DrawPic... SSCI does not do that, so if this patch helps, that would indicate
a tricky bug somewhere in our graphics system.

SCI Syntax Help / Re: Original SCI syntax
« on: July 30, 2011, 04:37:10 AM »
This is part of script 325 in PQ SWAT (I have been searching in vain for this as well...) - 40 lines out of roughly 4kloc according to the embedded line number info in the script.
So a short piece of code indeed. It seems quite plausible that it is from some kind of paper publication, and scanned in by whoever posted it in the first place - there are typos in the code that look like the errors OCR software would make (setloop instead of setLoop, setcel instead of setCel, etc.)
There are also arguments against that, however: I can see that the code is unfinished in places (compared to the version of the game that I have), indicating that the
game may have been a work in progress at the time this was leaked. This would make it less likely to be an official publication, right?

Thanks Omer, for finding this!
(btw, I came up with a small piece of code to test that sq5 issue of yours - but you haven't been back to the ScummVM forum for a long time)

SCI Syntax Help / Re: Arrays as Object Properties
« on: February 04, 2011, 09:34:11 AM »
There is no way to do what you ask. That's part of the reason why they had to introduce the Memory call in SCI01 (but that's an ugly solution to the problem.
There is a hack that you can use, however. Declare a single locsl variable followed by the arrays you need. Then you can (at least from the point of view of the PMachine, not sure about Brian's compiler) index into the large arrays by addressing the lone local variable and using a bit of arithmetic.

So I'm saying something like
Code: [Select]

(instance Blah of Obj
    arrayPos 1

(instance Blarg of Obj
    arrayPos 11
to use the array you then ask for baseVar[arrayPos+i] where i is the index you want.

Actually, you can probably skip the lone local variable and avoid the potential problem with the compiler altogether. Just use the first of your arrays as an index base. Of course, you then subtract one from the arrayPos values above.

SCI Syntax Help / Re: Vocab.900 - The 'Black Box'
« on: December 22, 2010, 07:31:10 PM »
Quote from: Gumby
What kills me is that all things I hated (and swore would not apply in my future) during my higher education are coming back to haunt me.  Push-down automatons, context-insensitive grammars - I never thought I would ever see them in my professional career.  Of course, I have not.  But in my hobbies?  You bet...   
Since I wrote the "black box" document, I thought I'd reply to this. I wrote the document at a time when I had no formal CS education. But this file contains essentially a context-free grammar for the language understood by the parser. It's complicated a bit by some things that are hard-coded in the parser, so you probably couldn't change the black box file easily (not without being mindful of the limitations of the parser code... which we don't have).

SCI Development Tools / Re: SCI Decompiler?
« on: December 22, 2010, 06:04:48 PM »
there is a generic decompiler architecture in the scummvm codebase now (it was written in a Google Summer of Code project). It should be quite possible to write an SCI decompiler based on that. Doesn't help with compilation, of course.

SCI Community How To's & Tutorials / Re: A generic Keypad class
« on: December 21, 2010, 06:26:02 AM »
Hmmm.... I just noticed a couple of bugs:

  • There is a memory leak in this code - I don't dispose the internal list used by the keypad. Look into the dispose and/or release methods.
  • It is not documented how to remove buttons, which you may want to do if you reuse the keypad object. The methods from the superclass EventHandler can be used for this (delete to remove a number of indicated buttons, release to remove all of them)

This is seriously old code, but I'll see what I can do about this.

SCI Community How To's & Tutorials / Re: A generic Keypad class
« on: December 21, 2010, 06:15:42 AM »
Does anyone have this file?
Here you go...

SCI Development Tools / Re: Source Release of SCI Companion?
« on: November 25, 2010, 06:34:26 PM »
The only reason I even use Studio anymore is to compile my scripts because for some reason whenever Companion compiles ScummVM gets a stack overflow whenever you launch the game in question.
I fixed this a few weeks ago.

Pages: 1 ... 32 33 [34] 35 36 37

SMF 2.0.14 | SMF © 2017, Simple Machines
Simple Audio Video Embedder

Page created in 0.293 seconds with 21 queries.