Author Topic: Methods for building when SCICompanion is not an option  (Read 1843 times)

0 Members and 1 Guest are viewing this topic.

Offline SlimeChow

Methods for building when SCICompanion is not an option
« on: June 14, 2024, 08:29:05 PM »
Long story short, I use Linux so SCICompanion is almost entirely unusable (fair enough really), and I'm trying to work out alternative methods for compiling scripts.

I've tried SC.EXE and have had success when using the SCI system/bootup scripts from an existing game to get the ball rolling. It's a janky method, so on one hand it works, but I'm also open to a more elegant solution. It does seem to require a lot of extra boilerplate (SELECTOR, system.sh, etc)

Is there another standalone script compiler out there?



Offline SlimeChow

Re: Methods for building when SCICompanion is not an option
« Reply #1 on: June 15, 2024, 03:52:32 AM »
On second thought, a better question might be: what is the best way to structure a new SCI0 project, with the intention of using the MS-DOS SCI utilities?

Sorry, I'm kind of new to this and am still feeling my way around. I'm happy enough that I can e.g. crunch scripts with SC and package everything with MAKEVOLS, but my approach is less than streamlined and I'd appreciate any guidance on how to improve that.

Offline Kawa

Re: Methods for building when SCICompanion is not an option
« Reply #2 on: June 15, 2024, 06:34:58 AM »
Having one or two batch scripts to help build the game, or run the interpreter in "no resource.map only loose files" mode is as streamlined as they got at the time.

So I'd say copying the rough structure of LSL2 or 3 might be a reasonable starting point. That is, put each resource type into its own directory for clarity. To play, have a script copy them all to a test directory including an interpreter and run it from there. Another script may be used to compile all .sc files in the src folder to script.# and text.# in the script directory. System scripts (255 and anything 900 or higher) go in the system directory along with things like drivers. interpreters, and any fonts and cursors that aren't specific to the game.

SC can take a @redo file, a straight list of filenames without extensions, and redo.bat in LSL2 and 3 uses that.

They apparently had the whole game on the root of a drive, so lines like copy \system\classdef would work. This happily matches what you'd get if you opened DOSBox and mounted your project folder.

Offline SlimeChow

Re: Methods for building when SCICompanion is not an option
« Reply #3 on: June 15, 2024, 07:22:16 AM »
Thanks for the advice Kawa, that is pretty much what I've been doing using LSL3 as a kind of template. My setup is a little messy, owes a hell of a lot to LSL3's system scripts, and requires a lot of DosBox jiggery-pokery, but if that's as good as it gets then it's still alright. I didn't realise loose files was an option! It feels canniballistic using another game as a base, even if it's just to boot it, but I'm used to my conscience bleeding.

Offline Kawa

Re: Methods for building when SCICompanion is not an option
« Reply #4 on: June 15, 2024, 08:25:27 AM »
... You are aware, of course, that the SCI Studio and Companion template games are cannibalized LSL3 and SQ5, right? Calm your conscience.

(A quick test on my Debian VM shows that Companion's compiler, at least, is broken...)
« Last Edit: June 15, 2024, 08:32:46 AM by Kawa »

Offline SlimeChow

Re: Methods for building when SCICompanion is not an option
« Reply #5 on: June 15, 2024, 08:46:26 AM »
Haha, fantastic, I'm on the right track then!

And the compiler in SCICompanion is just the tip of the iceberg. I have rarely seen WINE have so much trouble with a program, I'm guessing it's the MFC stuff? Anyway it's clearly a WINE issue if it works fine on Windows.

Offline Kawa

Re: Methods for building when SCICompanion is not an option
« Reply #6 on: June 15, 2024, 08:56:48 AM »
It's not just MFC. SCI Companion uses an MFC-like thing named Prof-UIS. Might have something to do with it?

Offline SlimeChow

Re: Methods for building when SCICompanion is not an option
« Reply #7 on: June 15, 2024, 09:15:29 AM »
Either way, WINE has some serious conniptions with SCICompanion. The script mass build gets it stuck into a strange loop. Compiling individual scripts sometimes hangs the program. Importing resources via drag/drop sometimes causes an unreadable error message and the program closes. Sometimes editing a PIC resource will crash it. I'm semi-tempted to run it in a VM but it's not an amazingly efficient solution.

Offline Kawa

Re: Methods for building when SCICompanion is not an option
« Reply #8 on: June 15, 2024, 09:18:17 AM »
Yeah, at that point you might be better off dosboxing the original tools.

Offline lskovlun

Re: Methods for building when SCICompanion is not an option
« Reply #9 on: June 16, 2024, 04:35:19 PM »
It's not just MFC. SCI Companion uses an MFC-like thing named Prof-UIS. Might have something to do with it?
Yeah. I get some odd resize-recalculate-resize loop which locks the program when using the compiler. It's clearly a problem with a visual effect, and I wouldn't be surprised if Prof-UIS was the problem. If only there was some way to turn that off... (or better yet, turn the compiler portion into a stand-alone program. There were visual problems with the decompiler as well, but nothing dealbreaking.


SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.034 seconds with 23 queries.