SCICompanion Prelease Testing!

[Cloudee1]

I haven't had a chance  to get in there and look around yet 

Unfortunately, not all of my rooms views make it to the scicompanion list (or they didn't before.) But then again, not all of them have the standard instances. I've been thinking on it, and while the obvious solution is just to start making everything instances, I like those one liners for placing background views or props. Would it be possible, to display two lists, one of the actual instances like you have now, but how about if sci companion looked for all the cases of a ... :view(xx) in a script. Then displayed those.

For example, Lets say there are three views to an actor, regular, wading, and swimming. When scicompanion lists the instances it shows just the single character on the list, whereas finding the places where a view is set, would generate a list of all three views used in the room for the actor instead of just the one instance. It would also find those things that don't have Instance names that litter my scripts, which is really what I was shooting for but this example fits a lot more situations.

[troflip]

Yeah, it would be possible, and probably not very difficult.  I'll put it on the todo list for the next version.  I'd like to only make bug fixes from now on for this version, as new features tend to destabilize things.
I could also have it so when you right-click on a view number/define, then it offers the option to go edit that view.

[Eigen]

Here's a couple of things I noticed about the script compiler.

1) In SCI Studio the following line

Code: [Select]

(var var1 var2)
throws a "Out bracket (')') expected" but in SCIComp it compiles fine. Although it doesn't seem to have any difference run-time. In SCI Studio it has to be

Code: [Select]

(var var1, var2)

2) And when the game is still open and I try to compile, I get the "acces denied" notice in the script Output window. That's fine. But when I close the game and try to compile again, the program crashes. Probably because the resource.### is renamed to resource.###.bak so I have to go rename it manually and re-open the game.


-Eigen

[troflip]

2) And when the game is still open and I try to compile, I get the "acces denied" notice in the script Output window. That's fine. But when I close the game and try to compile again, the program crashes. Probably because the resource.### is renamed to resource.###.bak so I have to go rename it manually and re-open the game.

I do this all the time and its never crashed for me.
a) open game
b) do single script compile -> fails because game is open
c) close game
d) do single script compile -> succeeds

You are getting a crash at d?  And you saying the resource.map is gone? How can that be if the game is running and using the file?
Can you get a dump file for me to debug (and make sure you're using version 2.1.03)

[jtyler125]

Will sci somp ever run on Vista?

[troflip]

Will sci somp ever run on Vista?

Of course, it runs on Vista just fine.

It should run fine on Win 98 now too...

[edit]
it appears that sciv.exe doesn't run on Vista though.  That's completely unrelated to SCI Companion of course.  Has anyone got sciv.exe to work on Vista?  Or do we have to run it using DOSBox or FreeSCI?

[Collector]

With the exception of some Install Shield installers, No 16 bit code will run on 64 bit Windows. In fact there is no NTVDM on 64 bit Vista. Even on 32 bit Vista, no DOS game can run full screen with Vista graphics card drivers. Some have gotten around this by forcing the install of XP drivers. The good news is that DOSBox runs fine on both 32 AND 64 bit Vista.

[jtyler125]

Ok what exactly is dos box?  And will sci comp or sci studio compile and then run on vista...I know it works on vista it just won't run...darn that Bill Gates guy...

[Collector]

DOSBox, not a DOS box. It is an open source project that emulates an entire DOS machine. It is what VU shipped the new collections with to make them "XP compatible", though with an older version. There is almost no Sierra DOS game that will not easily run in DOSBox, windowed or full screen. Games can be launched in DOSBox from a single Windows shortcut. It has great sound emulation and can be used with an MT-32. DOSBox has improved so much over the last couple of years that you can now even install Windows 3x in it to play the earlier Sierra Windows only games in it.

[jtyler125]

You say DOSBox, I say tomato...

[Collector]

If you aren't comfortable with using DOSBox, you may want to consider using a frontend like DBGL. It makes setting up games in DOSBox easier.

[Doan Sephim]

Troflip, Thanks for the SCI companion...I was a little bummed because SCI studio wasn't allowing me to change the cursor hotspot, but the companion allowed me to change it.

But in some of the text in your cursor editor it says that SCI0 games only use the (0,0) hotspot...but if that's true, why can I change it?

Edit: OK, I tried it out, and even though the cursor hotspot is (8,8) it works as if it were (0,0). So I think I understand the comment in your cursor editor now. It does not allow for a functioning 8,8 hotspot. But, why not?

[troflip]

Yeah, I added the ability to set the hotspot, because I read in the SCI cursor specs that there was a bit that indicated whether the hotspot is 0,0 or 8,8.  And there is - except the SCI0 interpreters don't look at it, only the SCI1 (and maybe SCI01) ones do.
So I was lazy and just added a comment to that effect. Oops :-)

Anyway, you can achieve the same effect in code, just by adding 8 to the x and y coordinates of the cursor code (Cursor.sc maybe?  I forget).

[Eigen]

Here's another "bug?" I found, it has 2 aspects. Again with the compiler. I attached the Controls.sc file with modifications from Brians tutorial for custom gui so you can try it out yourself.

1) In SCI Companion it gives a bunch of warnings: "[Warning]: '1' has no effect on code. Line:#, col:#" in different places. It compiles but with warnings. In SCI Studio on the other hand, it compiles alright. That's one part of the bug.

2) The other one comes up when running the game with compile-warnings. The game crashes with random "Text 100 not found" and so on. I wouldn't want to remove the lines of code giving the warning because they are needed. So I recompile the script in SCI Studio and the game works fine.

So, I'm not sure if this is a bug or maybe you tried to enhance the compiler, but needing to switch between different tools is not very ptoductive. Hope this helps
And you're doing a fantastic work with your editor!



-Eigen

[troflip]

The "[Warning] '1' has no effect on code" isn't a bug in the compiler, it's a bug in the script, sort of.

Look at what you have... to make it more clear, I'll replace some of pieces with tempN variables:

Code: [Select]

+ (+ nsTop (>> (- h rect[rtBOTTOM]) 1) 1)

Code: [Select]

+ (+ nsTop (>> temp1 1) 1)

Code: [Select]

+ (+ nsTop temp2 1)
But + is a binary operator (in Brian's SCI language at least).  So you have a 1 that isn't being used (this causes the compile warning).  You also have a + that needs another term, and it uses the one from the next parameter to the Display function.  This causes the run time error you see.

The '1' should be moved outside the parenthesis.  It should be:

Code: [Select]

+ (+ nsTop temp2) 1or to expand it out again...

Code: [Select]

+ (+ nsTop (>> (- h rect[rtBOTTOM]) 1)) 1
Make this change, and it will compile w/o warnings, and run without the "text 100 not found" error.

Brian's compiler is kind of sloppy in when it decides to look at parentheses.  It's hard to emulate that in my compiler :-).  So that allowed him to write code that wasn't syntactically consistent, but which happened to compile and do the right thing.
 But I did insert warnings to indicate when my compiler detects some code that has no effect.  This usually indicates that some parentheses are mismatched, which will cause problems with my more strict compiler, but which Brian's compiler happens to do the right thing (presumably).


btw, Eigen, you never answered the questions from the previous bug you reported (further up in this thread - the program crashing)... if you could, that would be great!