Script patch files

[doomlazer]

I'm having trouble exporting a modified room script as a patch file.

If I start with a fresh copy of a game in SCICompanion and only decompile the room script I need, I can edit the script easy enough. I then compile that single script and rebuild the resources. Finally I try exporting the script number as a patch.

Unfortunately, when I import the new script patch (or put it in a game folder) I'm still getting the original code.

Am I trying to do something that's not possible here? If I want to distribute a mod with changes to just one room, should I instead be distributing the SRC folder with just the .sc and .sco for that room?

This ties into a larger question about distributing mod files for the original games. I believe even modified VIEW patches would technically be a copyright violation as derivative work are prohibited under copyright. I'm trying to decide if, on larger mods with many changes, I'll need to distribute all the VIEW patches and the SCR folder or if it's best to just rebuild resource.001 and distribute that (which seems to work fairly well)?

For a single room mod that requires script changes, distributing a modded RESOURCE.001 seems wasteful, I'd much prefer to use a script patch instead if possible.

Any thoughts? 

[doomlazer]

After some more testing, I believe distributing the src folder wouldn't do much good unless the endusers were compiling and rebuilding for themselves in SCICompanion. I was mistakenly thinking the SCI engine would load the contents of the scr folder like patch files.

Also, I'm starting to think the idea of exporting a single modified script patch to change a room's code is never going to work. Is that because the decompiler is imperfect? I see that a new decompile wont recompile without a lot of work - which is what led me to EO's archive in the first place, now that I think about it.

Maybe distributing a rebuilt RESOURCE.001 is the only real option for any mods that change code?

I'd like to distribute mods in the most law abiding way possible, but end users often struggle to get stuff like this working if it's too complicated. On the other hand, distributing a zip with the full game pre-patched, even if the copy protection was left intact, seems like a really sketchy thing to do.

Speaking of RESOURCE files. Are there any utilities that would allow me to split things up to fit on physical 3.5 disks? If anyone has experience with any companies that print disks and boxes, please let me know.

[MusicallyInspired]

What I've done to create script patch files is backup my RESOURCE files, compile the altered script, extract it in the game directory, and then copy the backed up RESOURCE files back into the game folder. Obviously this doesn't work for everything (like SCRIPT.000 which would break the entire game by doing this method because many scripts require being recompiled together with others to function), but it works for smaller incidental scripts.

Alternatively, you could create an IPS binary differential patch, which is what NRS's SQ4CD patch does.

As for splitting up RESOURCE files, you can do that when you save a resource. It asks you the resource number and then the resource file number to save it in. This is usually left as 0 but you can put any number in there. Each number would be for a different disk. There's no automatic way to handle this unfortunately or track how large the files are becoming like Sierra probably were able to do (outside of just checking it in Explorer) but with a little trial and error it's possible. There's also 7zip and Winrar which can natively split compressed archives into separate smaller files and they even have presets for floppy disks.

[doomlazer]

Thank you, that helped me adjust my workflow enough to get things working. I was doing a few things wrong.

Attached below is the result: KQIV Whale Tongue Accessibility Patch

As for the splitting up the resources files into 3.5 floppies, that points me in the right direction. I'll probably shelve the idea for the time being.

[Kawa]

This ties into a larger question about distributing mod files for the original games. I believe even modified VIEW patches would technically be a copyright violation as derivative work are prohibited under copyright. I'm trying to decide if, on larger mods with many changes, I'll need to distribute all the VIEW patches and the SCR folder or if it's best to just rebuild resource.001 and distribute that (which seems to work fairly well)?

I am not a lawyer... nor am I someone who gives a frick, considering I have patches to turn LSL2's Polyester Patty in Passionate Patti, and play DOS PQ2 with the Japanese sprites and have no qualms putting them in a publicly accessible place.

[Collector]

What I've done to create script patch files is backup my RESOURCE files, compile the altered script, extract it in the game directory, and then copy the backed up RESOURCE files back into the game folder.

I would also think you'd also need to backup the map file.

[doomlazer]

Yes, resource.map should be backed up too. I've been making copies of the folder and they are multiplying like rabbits!

@Kawa, I guess I don't really care about copyright either, but I do see the potential for Activision (or the current license holder) to send out cease and desist letters. Maybe they don't care as long as I'm not disabling the CopyProtect.

[doomlazer]

DOS PQ2 with the Japanese sprites

I'll have to check this out later. Looks cool.

[MusicallyInspired]

Yes, I was lumping the MAP file in mentally with the RESOURCE files I mentioned. Sorry if that wasn't clear.

@Kawa, I guess I don't really care about copyright either, but I do see the potential for Activision (or the current license holder) to send out cease and desist letters. Maybe they don't care as long as I'm not disabling the CopyProtect.

Honestly I'd doubt they'd know you exist. This kind of stuff is just not on their radar.

[doomlazer]

Ok, I won't worry about it then. If they haven't complained about the fan remakes it sounds like a non-issue.

[Kawa]

Honestly I'd doubt they'd know you exist. This kind of stuff is just not on their radar.

I know Al Lowe knew I exist... though I think I might've still gone by my old handle back then.

[MusicallyInspired]

Ok, I won't worry about it then. If they haven't complained about the fan remakes it sounds like a non-issue.

When Vivendi was the sole owners, they contacted AGDI and an official license was negotiated. They also negotiated with The Silver Lining a couple times (after a couple shutdowns) and have permission for that too with a license. When ActiVision bought Vivendi however, they allowed the existing contracts to be honoured (obviously) but explicitly stated they didn't want any more licensed remakes. IA's SQ2VGA and KQ3VGA went ignored however. I think ActiVision is just willing to turn a blind eye as long as it doesn't get too big and would have done the same with AGDI's games had they not already been under contract, but since they were they had to take a stance and address it. IA's games still remain ignored, however. I just really think they're happy to ignore it even if they DO notice it.

[doomlazer]

Ok, another script patch question. This one specifically relates to this thread about SQIV easter eggs.

I thought it was interesting that the two SQIV easter eggs caused a lock up and were removed altogether down the road. Looking at the code, the conflict is fixed with a (curRoom script?) check. Restoring both eggs in the CD version should only require rm397 .src and .view patch files.

I plugged the code from the floppy versions into the SCIDArchive's SQ4CD source and updated the variables where needed. The problem is, while a patch with no egg code works fine, if I try to add a feature to the room I get interpreter error 4 (couldn't find info of these error codes). Even if I try adding a 3rd shelf as a sq4Feature it breaks, so I don't understand what I'm doing wrong. I thought it might be a version stamp check problem, but I can get narrator say: calls to work in the .src patch.

Until today, I've focused on SCI0, so it's probably something stupid, but after reading the relevant documentation and two different SCI1.1 tutorials I don't see why I can't lick the wall.

I've attached the rm397.sc file if anyone would like to take a look at the code. All the egg additions are currently block commented out.

Edit: technically if I got the .src patch working the rm397.view patch is optional. The CD version only erases the middle finger from the cel, so you could restore both easter eggs while keeping things PG.

I've checked to see if this easter egg has already been restored, but I don't see it listed here. Please let me know if this has already been patched.

[Kawa]

Oops #4 means that a given object pointer did not in fact point to an object. It's like a null pointer exception but it doesn't have to be 0. The CD version of Space Quest 4 has separate Heap and Script resources, so if you change a SCR file, depending on the exact changes you will need a matching HEP file. Adding a Feature counts, as these would be defined in the HEP.

SCI0 has only SCR files, containing both the code and data, which is actually a good way to run out of heap space. That's what the split was for.

[doomlazer]

It was that easy? I spent hours stuck on that! At least now I know. Thank you.