Messages

1

SCI Syntax Help / Re: Parsing Noun/Qualifying Adjective Words

« on: April 05, 2019, 12:25:48 PM »

Yeah, so it looks like the vocab (which I was wrong, it's 900, not 994) is just a straight up dump of the stuff in grammar.txt. You could (tediously) do that manually, or it looks like if you've got the masm.exe, link.exe and exe2bin.exe Sierra tools that would do the job (using the 1988 GRAMMAR.TXT, which is I guess is just straight up asm?). And also assuming you're familiar with Backus-Naur form, which is I guess kind of what the grammar is written in.

I wonder if the localized versions (what did they do? Spanish? German? French?) had different grammar resources...

2

SCI Syntax Help / Re: Parsing Noun/Qualifying Adjective Words

« on: April 04, 2019, 06:11:16 PM »

Either way, though, if the parser's smart enough to use a noun as an adjective when appropriate, that's more than good enough for sure.

It's really defined in the grammar that's in vocab.994 (I think?). Sierra generated that resource based on a grammar text file that you could potentially edit. But I don't know if anyone has those tools (or the original grammar file)... I looked quickly on omermor's github repos and didn't see anything.

3

SCI Syntax Help / Re: Parsing Noun/Qualifying Adjective Words

« on: April 04, 2019, 05:42:12 PM »

Well, shuttle isn't an adjective in the English language. But nouns can act as adjectives, and the SCI parser understands that.

In other words:
'look/door' will match "look shuttle door". Or in fact any "look [anynoun] door".

If you want to specifically match shuttle door, you can do:
'look/door<shuttle'. This will match "look shuttle door" but not "look door", or "look [anynoun] door".

If you want to match "shuttle door" or "door" but not anything else, you can do:
'look/door[<!*,shuttle]'

So there doesn't seem to be any reason to make it an adjective. Although something like
'look/shuttle' should work just fine (i.e. match "look shuttle") if it's both a noun and adjective. Is that not happening for you?

4

The Games and other Sierra Adventure stuff / Re: What are we working on?

« on: April 03, 2019, 04:28:34 PM »

Yeah, that's crazy... not crazy that ScummVM has it wrong, that's understandable - crazy that no one noticed it until now!

Also, as someone who had to implement their own integer polygon pathfinding for this, it's really f***ing hard.

5

SCI Syntax Help / Re: White Control Line Only Applies When Coming from One Direction

« on: March 28, 2019, 07:00:46 PM »

Aah, nice.  Yep, it's SCI0, and that looks about right. Any ideas off the top of your head why it did work only when I entered the screen from that direction for the one room?  Doesn't really matter, I guess, just curious.

Yes, I think because of this:

• The default yStep is 2
• Its base rect will therefore be 2 pixels high, at the ego's y-1 and y (per the kernel BaseSetter function)
• In your pic image, the white control lines at the bottom are at y=187 and y=188.
• So the ego can't be at y=187 or higher - it will be blocked
• Per the SCI0 code, the ego leaves the room to the south at y=186 or higher
• Since yStep is 2 your ego moves in 2 pixel increments in the y axis.
• If the ego is positioned at an odd y coordinate (as when entering from the south) and walks south, it will go to 181, 183, 185, and no further since it can't be at 187
• If the ego is positioned at an even y coordinate (as in all other directions but south), it will go to 182, 184, 186, and then be kicked into the next room

6

SCI Syntax Help / Re: White Control Line Only Applies When Coming from One Direction

« on: March 26, 2019, 08:04:00 PM »

Ok, assuming this is the SCI0 template, it's probably due to this code:

Code: [Select]

(method (doit)
(super doit:)
(cond
((<= x 3) (= edgeHit EDGE_LEFT))
((<= y (gRoom horizon?)) (= edgeHit EDGE_TOP))
((>= x 316) (= edgeHit EDGE_RIGHT))
((>= y 186) (= edgeHit EDGE_BOTTOM))
(else (= edgeHit EDGE_NONE))
)
)

Basically, when the ego is at y 186 or higher, they go to the room to the south. So they never even reach your single white control line. The solution would be to place the control line at 186 or less...

7

SCI Syntax Help / Re: White Control Line Only Applies When Coming from One Direction

« on: March 26, 2019, 02:51:29 PM »

Hmm, I thought onControl: worked with the base rect of the actor, whose height is sized based on the yStep?

Call it a hunch. We had a bunch of bugs like this in the FreeSCI days.

I don't understand. That's exactly what should happen. The base rect (brLeft, etc...) is calculated based on the yStep. And OnControl uses the base rect and returns bitflags containing all the colors in that base rect. So a single control line should be sufficient.

If it's not, then there's a bug somewhere else in their code that should be fixed. Somehow the base rect is getting out of sync.

8

SCI Syntax Help / Re: White Control Line Only Applies When Coming from One Direction

« on: March 13, 2019, 11:23:10 PM »

Hmm, I thought onControl: worked with the base rect of the actor, whose height is sized based on the yStep? So a single line should definitely trigger. Unless somehow they've gotten out of sync? (You can also pass TRUE to onControl: so that it works on a point and not a rect, but you're not doing that here).

9

SCI Community How To's & Tutorials / Re: (SCI.0) Most of My Views and Pics are Missing!

« on: February 23, 2019, 05:32:09 PM »

Your resource.map and resource.000 probably got out of sync... are there any resource.map.bak or resource.000.bak files in your game folder? SCI Companion saves to those and then deletes the originals and renames the .bak ones. But if the delete fails you might get this issue.

(and remember to always backup or use source control!)

10

SCI Syntax Help / Re: Instance Priorities

« on: February 15, 2019, 04:52:44 PM »

Yes, I added support for most constant expressions to be resolved at compile time, thus allowing for that to work ;-)

Setting priority in the properties block, and including the fixPriOn flag is how I usually deal with fixed priority sprites.

11

SCI Syntax Help / Re: Instance Priorities

« on: February 06, 2019, 05:24:03 PM »

Again, y controls the order which things are drawn in each frame, and priority controls whether or not it obscures what was previously drawn. They are different things.

However, they are related, because by default, sprites have their priority calculated automatically based on their y value. So if you're just setting the priority property directly, it will get overridden by the interpreter based on the sprite's y value and the priority bands in the pic background. To specify a fixed priority, you need to use the setPri: method instead (or set the fixPriOn bit on the signal property, which is what setPri: basically does).

12

SCI Syntax Help / Re: Instance Priorities

« on: February 03, 2019, 12:04:38 AM »

I believe the rules are:

• Views are drawn in order according to their y value.
• A pixel won't be drawn if the pixel previously drawn there (from the background or a view) has a higher priority.

If you need a view drawn on top/behind another view, you can usually achieve this by ensuring their y values are in the order you need, and then adjusting z (or the view cel's placement) so that it's visually positioned correctly relative to the other view.

13

SCI Syntax Help / Re: Unlocking Locales and Regions

« on: January 30, 2019, 04:37:38 PM »

You can debug this more easily in the future by running sciv.exe with the -d command line parameter (for SCI0, anyway). It'll print out a nice message telling you in more detail what's wrong, and you can examine the state of the game.

Unfortunately I don't know how to do this when you start it with DOSBox, other than telling DOSBox not to exit the DOS console when the exe crashes, and then running "sciv.exe -d" right from the DOS prompt. Someone else would probably be able to help more...

Or run it with ScummVM, that will probably provide a more readable debug message.

14

SCI Syntax Help / Re: Unlocking Locales and Regions

« on: January 29, 2019, 08:51:02 PM »

Try adding this in your Lieven script:

Code: [Select]

(public
Lieven 0
)

The locale and/or region objects needs to be exported publicly from the script and given a dispatch number. setLocales: will load the given script, and look for export #0, which needs to be the particular Locale instance.

SCI Studio syntax does this implicitly for anything marked public (they inherit the number based on the order they are declared in a script), but in Sierra syntax you need to do it explicitly (helps avoid issues when adding/removing public procedures or instances from a script).

15

The Games and other Sierra Adventure stuff / Re: What are we working on?

« on: January 26, 2019, 07:27:19 PM »

So today I added control-sampling to my fork. Left and right mouse clicks work as before, but holding control effectively temporarily switches to the eyedropper.

How does that affect ctrl-resize?