Messages

1

The Games and other Sierra Adventure stuff / Betrayed Alliance Book 1 v1.3.1 (graphics/music overhaul update)

« on: May 06, 2024, 02:16:22 AM »

This was released a few days ago, but wanted to make sure it was known here if it wasn't already. Ryan/Doan Sephim's Betrayed Alliance Book 1 SCI game has been updated and released featuring new vector artwork by Karl Dupere-Richer (and a few by Ryan) and a newly arranged MIDI soundtrack by me which currently supports Adlib/Sound Blaster, MT-32, and PC Speaker (partially), but which will eventually support pretty much everything Sierra supported (CMS/Game Blaster, Tandy 3v, FB-01/IMFC, Casio MT-540/CT460, Casio CSM-1, etc).

Download:
https://rjslattery.com/betrayed-alliance/

Trailer:

2

SCI Syntax Help / Re: What's going on???? (emLEFT_BUTTON and emRIGHT_BUTTON)

« on: April 29, 2024, 11:53:20 AM »

What about instead of checking explicitly if the the left button is a modifier, check if the right button is NOT a modifier?

That's.....a good idea. I'm so lost in the weeds on this that I didn't think of that. (not (& (pEvent modifiers?) emRIGHT_BUTTON)) does indeed seem to work. And of course, just as weirdly as the previous inverse behaviour, referencing emLEFT_BUTTON in the same code instead of emRIGHT_BUTTON also works.

So you're checking for modifier == 1, which logically means if you're holding shift, or have numlock, scroll lock, or caps lock on, or insert turned on, then the result will NOT be 1. and so the logic check will fail.  I've never checked that in code, if numlock, scroll lock, or caps lock are properly detected or cause havock with right-clicking.

I have checked that a right-click is the same as holding shift and left clicking.  So that's also something that may be messing with your debugging... seemingly random, but maybe you're accidentally pressing caps lock every other time you type or something.

Surely this wouldn't be the case with the additional conditional check for this being specifically a evMOUSEBUTTON/evMOUSERELEASE event, right? The game shouldn't care about the keyboard modifiers even though they use the same bit values. At any rate, Activating/deactivating caps lock/numlock doesn't seem to change any behaviour in-game.

3

SCI Syntax Help / What's going on???? (emLEFT_BUTTON and emRIGHT_BUTTON)

« on: April 28, 2024, 05:55:38 PM »

These aren't working. Or rather, they only seem to work part of the time and I can't figure out why/how.

I've been debugging some code, and as I've been digging into it I have vague memories of having problems with this years ago for KQ2SCI as well. In this code a method checks if there is a mouse event and whether that mouse event is the left button. If both are true, the code executes. There is a similar following block of code checking for mouse release. The problem is this seems to only randomly work some of the time. Randomly as in, sometimes it works all the time and sometimes it doesn't work at all, not that it will randomly work and not work within the same game runtime instance. Here is the code:

Code: [Select]

(if
(and
(== (pEvent type?) evMOUSEBUTTON)
(== (pEvent modifiers?) emLEFT_BUTTON)
) 

And here is the following code to check for mouse release.

Code: [Select]

(if
(and
(== (pEvent type?) evMOUSERELEASE)
(== (pEvent modifiers?) emLEFT_BUTTON)
)

As I said, this seems to work sometimes and not others without any change. Sometimes it will not respond at all and other times it works without a hitch. I've been trying to nail down exactly why and I simply can't. I've also tried this on period hardware and get the same random results (random between game runtime instances) so it's not a DOSBox issue or a Windows issue. This is with the game interpreting the script only. It works without a hitch if I remove the modifiers check and just do any mouse event. But then both buttons will execute the block of code; two separate instances at the same time. I could fix this with some extra conditional statements to isolate the action, but this is just bugging me now when event modifiers should be working. I had wondered if this was an issue with using the "==" operator instead of "&" but in recent attempts with that method I've found that it will work with the right mouse button and explicitly not the left mouse button. Switching to emRIGHT_BUTTON instead in that instead yields exactly the same results. It only works with the right mouse button. I'm at a total loss. Is this a compiler issue? It's just weird that the results are erratic and inconsistent with the *same compiled script* at two different instances at a time of loading DOSBox (or running on period hardware) and I just cannot track down what the missing factor is.

I've also tried changing "modifiers?" to "modifiers:" as I've seen some code use that invocation, but that doesn't work either. Any ideas?

EDIT: As well, I've seen several examples of invoking the left and right mouse buttons. emLEFT_BUTTON and emRIGHT_BUTTON in sci.h are both defined respectively as "1" and "3". But I've seen this invoked as "512" and "515" respectively and also "32" and "35" elsewhere in code examples on these forums and the Mega-Tokyo archives. What are the proper values/bitmasks for the mouse button event modifiers anyway? Doubly annoying is that using emRIGHT_BUTTON for right click look events works fine all the time. It's just this one case that I can't figure out. Can something else break this conditional check for mouse event modifiers that I'm just not aware of?

4

SCI Syntax Help / Re: Trying to sidestep the Restore Menu (SCI0)

« on: April 06, 2024, 12:16:07 PM »

I had a similar issue with another SCI0 project where ScummVM just ignores SAVE/LOAD commands if they aren't coming from the scripts it expects. I never bothered looking at the scummvm source code, but I worked around it in the same way using flags. Just an heads up for anyone else who might encounter this oddity.

Would this still be the case if you enabled the "use original save/load dialogs" checkbox in engine options for the game?

5

SCI Development Tools / Re: Voice acting in Space Quest V - Part 2

« on: April 06, 2024, 12:13:35 PM »

That's what I said...

6

SCI Development Tools / Re: Voice acting in Space Quest V - Part 2

« on: April 06, 2024, 12:09:35 PM »

I'm going to be the odd one out and say that I believe Gary Owens isn't the best choice for narrating SQ5. He does best when narrating Scott's writing (or Josh's). But SQ5 isn't about immense sarcasm. It needs a different flair. I don't know what, but Gary Owens isn't it.

7

AGI Development Tools / Re: Sierra's Debug/Testing Version of AGI

« on: March 06, 2024, 09:17:06 PM »

Yeah, SCI has something similar. The release SCI0 interpreter is called SCIV.EXE (V for volumes).

On a side note, I used to have a list of what the various interpreter naming conventions meant, but I cannot find it. What ones are you aware of?

This is what NewRisingSun posted on VOGONS somewhere. I found it a couple months ago and saved it.

Command-line parameters for 16-bit interpreters: (case-sensitive):

    -a: Do not use "extra memory" even if it was selected via the INSTALL program (i.e. ignore the "memoryDrv=ARM.DRV" setting in RESOURCE.CFG).
    -c [n]: Indicate the change of disks (i.e. changing from RESOURCE.00x to RESOURCE.00y) and the access of "extra memory" by changing the shape and/or position of the mouse cursor. "n" is a decimal representation of a bitfield. The bit values have the following meaning: 1: change cursor shape upon disk change, 2: change cursor position upon disk change, 4: change cursor shape upon "extra memory" access, 8: change cursor shape upon "extra memory" access. If "n" was not specified, value 5 is assumed (change shape but not position on both events).
    -m: The function of the middle mouse button changes from "switch between walk and selected icon" to "open debugger" (same as Shift-Shift-NumMinus)
    -u [filename]: Log use of game resources to filename, default is "resource.use"
    -U [filename]: Log use of far-pointer memory to filename, default is "hunk.use". ("Hunk" is what Sierra calls memory accessed via a far pointer, while "heap" is how Sierra calls memory accessed via a near pointer.)
    -w top left bottom right: Set the dimensions of the game screen. Default is 10 0 200 320, meaning that ten lines at the top are left blank for a status/icon/menu bar. Some games which do not use such must be run with -w 0 0 200 320, otherwise the picture will be drawn ten pixels too low.
    -X Store each handle to a game resource twice in memory so it is noticed when buggy script code overwrites the handle table. (Apparently, that was a problem?)

I have not followed which option was introduced with which interpreter version. The debug-related options will only work as intended, if at all, if the interpreter executable has the debugger included.

Not asked but since I am writing: the meaning of the letters of the interpreter name SCIxxx.EXE:

    V present: Load game data from RESOURCE.0xx/RESOURCE.MAP files, using individual files only as replacements, and use RESOURCE.CFG as a config file.
    V absent: Load game data from individual files only, and use a file named "WHERE" as a config file which, in addition to the usual hardware-config lines, must contain paths for each resource type.
    D present: Pull-down menus not available.
    D absent: Pull-down menus available.
    U present: Debugger not available.
    U absent: Debugger available (Shift-Shift-NumMinus to activate)
    H present: 256 colors
    H absent: 16 colors

SCIV.EXE therefore means 16 colors, with debugger, with pull-down menus, using RESOURCE.00x files. Interestingly, there never seems to have been a letter to indicate the presence or absence of a parser. Obviously, non-V versions were only used internally. Many games rename the interpreter executable to just SIERRA.EXE.

8

SCI Development Tools / Re: SCI Unlocked - Sierra's game engine running on Python3 + Raylib

« on: February 27, 2024, 11:30:51 AM »

Eyyyy I like what I see.

9

AGI Development Tools / CrafterCMS (Online AGI tools)

« on: February 21, 2024, 11:41:26 AM »

Did we know about this?

10

The Games and other Sierra Adventure stuff / Re: The Best AGI fan-made games?

« on: January 17, 2024, 08:03:04 AM »

The Time Quest demo I still think is really great.

11

AGI Development Tools / Re: Introducing Sierra Quest: Power Pack Demo

« on: January 11, 2024, 02:49:14 PM »

I wish I'd seen this earlier. What an awesome endeavour! Can't wait to try it.

EDIT: I beat it. Quite nice! Amazing features. I kind of hoped you had added VGA palette capability that AGI256 had, seeing as you pretty much added all the other AGI patch features that Brian Provinciano and others have made for AGI in years past (AGISB, AGIMIDI, AGIMouse, etc). But palette control itself, even though it's only 16 colours, is fantastic. I was blown away by that intro!

I did run into a couple bugs. If you pick up the 80s mix tape and the floppy disk and put them in the Walkman and floppy drive respectively and go back to where you originally found them you will find brand new items in their place that you can pick up a second time. Getting the floppy disk again didn't cause any issues, but getting the mix tape while it was already in the Walkman crashed the game when I tried to fast forward after trying to use it again.

12

SCI Development Tools / Re: SCICompanion: Is there a way to import the priory and control screens also?

« on: January 11, 2024, 02:02:35 PM »

Unfortunately, no. At least not that I know of.

13

The Games and other Sierra Adventure stuff / Re: Japanese KQ7 Intro on YouTube

« on: November 07, 2023, 09:28:28 AM »

This is so cool. All the music has been rerecorded on a completely different synth than the English original's version for this dub!

14

SCI Syntax Help / Re: How does EcoQuest 1 allow to enter any code and not just the copy protected one?

« on: October 14, 2023, 11:35:42 AM »

Before Companion 3 there were no decompilers. Brian had hand decompiled an SCI game (LSL2?) to make the original fan SCI template game and create his SCI Studio script.

It was LSL3.

15

SCI Community How To's & Tutorials / Re: How to easily convert SCI patches to ScummVM?

« on: October 14, 2023, 11:30:52 AM »

Just because there's a deep and passionate community around DOSBox doesn't mean fluent commits are the same as stable versions.
While they are the same for "insiders", most population doesn't look behind stable versions which is why for example Wikipedia first and foremost mentions the last stable date.

[citation needed]
(speaking of Wikipedia)

Also, it doesn't matter what version or flavour of DOSBox you use (and there are many that are under active development, btw, and always will be), SCI games will work on all of them (old or new).