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 2 3 [4] 5 6 ... 31
@Kawa, I got hit by a missing resource (11.snd) and subsequent crash. When installing the new canister, there was also a wrong message "try aiming it at the empty slot" when I'm actually doing so. The canister does end up installed and the game continues, but the message needs fixing.

It sounds (and looks) like you're taking the term 'control line' a bit too literally. Actors have an xStep and yStep property which decides how far an actor moves per game loop. If you use control areas smaller than xStep times yStep, then the actor can step right over them. So either make your control lines thicker, or jiggle your actor positioning until the math works out (you can of course also adjust the step counts with the setStep method, but the right step values really depend on your actor's animation, so you may need to redraw him too if you choose to do that).

SCI Syntax Help / Re: Instance Priorities
« on: February 15, 2019, 11:26:36 AM »
(does Companion support OR-ing constant flags together to make a constant signal initializer?)
As in, can you do (someRandomExampleActor state: (| fixPriOn noTurn)), or have an iconbar button's property list have signal (| icHIDEBAR icRELEASE) instead of $0041? Yes.
I meant in the properties section, as in
Code: [Select]
(instance someRandomExampleActor of Actor
    x blah
    y blah
    priority 9
    signal (| fixPriOn noTurn etc.)

SCI Syntax Help / Re: Instance Priorities
« on: February 15, 2019, 09:52:32 AM »
I'd imagine it still wouldn't set the "fixed priority" bit and get overwritten.
Let's put that in clearer terms. There's a property called signal in views that does a lot of marvelous things (it's a bitfield, so it represents 16 boolean flags). Among those things are whether the priority is determined by the engine as others have described or not. To make it easier to use, there are methods you can call that manipulate the signal property in just the right way (setPri, stopUpd, startUpd, etc.)

You'll notice in decompiled games, that they sometimes set the signal property to magical values in addition to setting a particular priority. That is how you can avoid having to call setPri directly, but I guess it could be said to be an advanced technique (does Companion support OR-ing constant flags together to make a constant signal initializer?).

SCI Syntax Help / Re: Instance Priorities
« on: February 03, 2019, 09:13:15 AM »
I think this will be easier if you post the relevant parts of your code.

The Games and other Sierra Adventure stuff / Re: What are we working on?
« on: February 01, 2019, 01:59:52 PM »
Nice. Perhaps make the color thing an edit instead (or make a color picker too, but that would be a bigger job  8))

AGI Development Tools / Re: C# AGI Interpreter
« on: January 25, 2019, 07:44:55 PM »
Hmmm, how does that even work?

SCI Development Tools / Re: SCI01 Template Game
« on: January 24, 2019, 10:53:09 PM »
Well, I was able to address the issue with the menu glitching up. I moved the restart, quit, and about dialogs to the Main script as procedures. Apparently, Sierra themselves ran into this problem, as this is exactly the way those dialogs are implemented in QFG2.
Also, I've added some fonts from the game demos!  :D
I'd say it's quite unlikely that that is the reason the procedures were in script 0 in QfG2. All you're doing is postponing the problem for someone else to find and scratch their head over.

SCI Development Tools / Re: SCI01 Template Game
« on: January 23, 2019, 04:36:41 AM »
I think you can save multiple games with the same title...
I was referring to the fact that if you press ENTER without changing the title in SSCI, the latest slot will be reused. Quite handy if you need to maneuver ego along a difficult path, for instance. This is somehow different in the SCI01 template, probably indicative of the corruption. Unless it was changed knowingly, as I wrote.

Hmm, trying it again just now, that effect stops after the second save. Curious. And of course ScummVM is no help here, as it handles saving differently.

SCI Development Tools / Re: SCI01 Template Game
« on: January 22, 2019, 03:22:51 AM »
Also, isn't the behavior of saving two games with the same title wrong to begin with? as though something is compiled or decompiled wrongly. I strongly recall being able to reuse the latest savegame slot simply by pressing <F5> <ENTER>. And if nobody changed it knowingly...

SCI Development Tools / Re: SCI01 Template Game
« on: January 21, 2019, 11:18:47 PM »
Yes, the saving code seems to be at fault somehow. After saving the game twice in succession I have this in my template directory:
Code: [Select]
lars@starfish:~$ ls -l ~/SCI01-Template/SCI01SG*
-rw-r--r-- 1 lars lars 7771 jan 22 05:06 /home/lars/SCI01-Template/SCI01SG.000
-rw-r--r-- 1 lars lars 7884 jan 22 05:07 /home/lars/SCI01-Template/SCI01SG.213  <- BAD!
-rw-r--r-- 1 lars lars   14 jan 22 05:07 /home/lars/SCI01-Template/SCI01SG.DIR
The Sierra SCI interpreter only supports 20 games. Apparently memory corruption can occur if you try to save a game with number 213 :) I would guess the actual corruption takes place inside the SaveGame kernel call, which does little in the way of error checking (or else one of the other saving-related kernel functions). So the way forward should be to figure out where that number 213 comes from.

EDIT: Also, it may be a good idea to delete your savegame files frequently while investigating this. The mere presence of a file like the above could be a problem.

AGI Development Tools / Re: C# AGI Interpreter
« on: January 20, 2019, 01:52:02 AM »
The booter version of DDP? The "DOS" version floating around on the internet is actually a hacked version of the booter that crashes at points when you press certain keys like escape.
There is a DOS version according to NewRisingSun here.

SCI Development Tools / Re: SCI32 Source Code
« on: January 12, 2019, 02:19:28 AM »
Some KQ7 rooms set up global state and may not reset that state properly if you teleport out (using the debugger). This causes a crash down the road (so far down the road, in fact, that you wouldn't make the connection between the two events). It only happens if you edit variable 13 directly, not when a script calls the newRoom: method. This, of course, means that the KQ7 debug script works, since it does it the proper way. But that is not so easy to do by hand.

SCI Development Tools / Re: SCI32 Source Code
« on: January 11, 2019, 10:26:10 PM »
Meanwhile, I've been working on a savegame dumper for SCI32 games (where that is actually possible, unlike earlier SCI generations). It uses ScummVM to get data on class layouts and such (and for the compression code). I've already used it to investigate one bug in KQ7.

EDIT: Sierra SCI savegames, of course.

AGI Development Tools / Re: C# AGI Interpreter
« on: January 06, 2019, 05:58:44 PM »
The way the original AGI Interpreter manages and redraws its "stopped" and "updating" objects though is like a ball of spaghetti, so its a matter of extracting the key parts in a cleaner design.
Oh yes, oh yes. That was one of the major sticking points in SCI as well. I suspect much of it was brought over unchanged.

Pages: 1 2 3 [4] 5 6 ... 31

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

Page created in 0.142 seconds with 21 queries.