Community
SCI Programming => SCI Development Tools => Topic started by: troflip on June 02, 2015, 10:52:18 AM
-
Let's use this thread to discussion improvements and major bugs in the alpha release I put out here (http://scicompanion.com/Downloads/SCICompanion.zip). (updated 6/16/2015, 7:27pm GMT)
I'll keep editing this first post to summarize things.
RELEASE NOTES
------------
- Support for creating new SCI 1.1 games. Editing of SCI 1.1 views, pics, palettes, messages, scripts
- Pic Editor: VGA support. New zoom/final pane on the right. The "light up lines" icon is now "transform coords". Click on it and choose (for instance) the line tool, and you can move line vertices around. "Show priority bars" displays pri bars differently and lets you move them around on the right.
- View editor: eye-dropper tool to select color from image (and yes, I know, the working palette is way too tiny). Edit embedded view palettes from view menu.
- Tools->Extract all resources. Functionality to mass extract resources, generate view/pic bitmaps, and disassemble all scripts.
- SCI0 sound editing support.
- Drag wavs into the Audio view to add them
- Version Detection dialog
- Decompiler
- "Find in Files" now searches text and message resources, not just scripts.
- If you turn on "Tools->Preferences->Enable browse info", you can now do "Script->Class hierarchy". You can also jump around in scripts using the combobox at the top of the script editor. (WARNING: this feature has some bad bugs, and if you load another game while the browse info is being generated in the background, SCI Companion will crash)
RELEASE NOTES 6-10-2015
---------------------
- View editor pane has been "revamped". Palette is larger, and there is an edit palette button. The treeview of loops/cels is gone. You can use the arrows, as before, to select cels or loops, or you can use the new panes on the right/bottom. The loop selector pane also lets you reorder loops (and of course you can re-order cels in the cel selector pane).
- Fixed a number of bugs (striked out below)
- SCI1 sound is... functional. You can import a MIDI file, add it to the game, and add cues and loop points. I added the SCI0 death sound to the SCI1 template game, and it sounds pretty bad! So things are still kind of messed up. Other midi files I've tried sound pretty good though.
- you can preview palette cycling in the edit palette dialog (for pics)
- improved the selection rect in the palette editor
- I tried to get gif image sequences to import - it worked fine for most gifs, but for some reason not those exported from SV.exe! The library I'm using to load them loses all palette and indexed/color information for those gifs.
- support for extended char sets in fonts (previously it was locked to 128 characters, like SCI0 requires)
- copy-paste in VGA views was pretty busted, it is now working properly
RELEASE NOTES 6-15-2015
---------------------------
- things update without having to close/reopen the game when global palette is changed
- support import of multi-frame gif images into views, retaining the palette
- support for (and persistence of) midi output device for previewing sounds
- animate dialog shows transparency properly
- show duration in preview pane for sound and audio resources
RELEASE NOTES 6-16-2015
--------------------
- support for original aspect ratio (Tools->Preferences, check button at the bottom). The only place I can think of where I don't honor aspect ratio is in the pane in the font editor where you choose letters.
- some minor bug fixes
RELEASE NOTES 6-18-2015
----------------------
- bug fix: newly added cels don't get focus
- bug fix: deleting last pic command, or cropping commands -> position is lost and goes back to 0
- bug fix: resource deletion problem
- bug fix: can't set -ve y offset for cels
- bug fix: setting a loop that was a mirror to "none", then save. Reopen and it stays a mirror of another loop
- other minor fixes
- I forgot to update the version number (still 3.0.0.4)... oops
- beginning of polygon editor, but I've been busy fixing bugs, so it doesn't really do anything yet.
RELEASE NOTES 6-22-2015 (3.0.0.5)
----------------------
- Fixes for MIDI tempo change bugs (hopefully)
- Polygon editor, seamlessly integrated into the pic editor (full undo support)
- updates to template game (debug handler, plus other minor updates)
- labels for cel/view panes in the view editor
- visual changes to the resource tabs
- view cel paste corruption bug fix
RELEASE NOTES 6-25-2015 (3.0.0.6)
--------------------------
- "debugger" functionality. Run the template game using the red button and DebugPrint calls are routed to SCI Companion
- "Debug room" from the script editor. Script 16 is where you put debug room setup stuff
- added lots of defines to the template game (icon states, scripts, icon indices, etc...). Should make it easier to see dependencies
- text resource wackiness is fixed
- delete resource problem hopefully fixed for good now!
- some views from community members now part of template game
- the views in the game explorer are larger now, and the resource number is shown in the preview
- the polygon editor has an editbox for the points now
- speech bubble view resource (993) added back in from SQ5. SpeakWindow.sc uses it. Maybe someone can play around with that?
RELEASE NOTES 7-1-2015 (3.0.0.7)
----------------------------------------
- named polygons are now supported (so you can create the polygon by itself and do whatever you want with it)
- fake ego has option to observe polygons
- pic editor has a gutter around the top and left sides so you can easily extend polygons to the pic boundary
- cloudee's Adobe wavs can now be imported.
- template game updated to use KQ5 palette
- simple palette remapping functionality for views
- new pics inherit the global palette instead of a hard-coded one
- audio previewer has been updated to show bit/sample rates and describe how to add files
RELEASE NOTES 7-3-2015 (3.0.0.8 )
-----------------------------------
- remove support for old polys
- hopefully fix crash in pic side pane
- fix pics being garbage in SV.exe
- validate polygon winding order so user doesn't have to think about it
- update tutorial link in help menu
- fix painting glitch on right side of pic
- show all letters in font preview
RELEASE NOTES 7-8-2015 (3.0.0.9 )
----------------------------
- ability to adjust hue/lum/sat/tint of palette colors in the editor
- palette changes are now previewed on views/pics instantly
- from palette editor, save palette as a separate resource
- pics can now be previewed with different palettes, just like views
- fix bug with SCI0 having 0 as default package
- message resources can be imported (compatible with SV.exe) and exported from txt files
- "extract all" dialog has option to export messages as txt files
- wav files added as audio resources inherit the filename by default
- fixed issues with not recognizing certain wave files
- >22Khz wav files are automatically downsampled to 22Khz
- stereo wav files can now be imported (SCI Companion uses the left channel)
- background images up to 200px are supported (set the height from the pic menu, then import a new bg).
- sample resources for SCI1.1 are now available
- warning when importing a resource when there is already a resource of this number (instead of silent overwrite)
RELEASE NOTES 7-15-2015 (3.0.0.10)
----------------------------
- template game cleaned up, new fonts with extended char sets from kawa added.
- when importing pic backgrounds, you can specify custom palette ranges to map to
- when importing pic background, you overlay it on the current pic background. This is a powerful feature!
- default font edit color is black now
- you can paste commands from EGA pics into VGA pics, and invalid commands will be removed
- menu option to remove setvisual commands from pics (for EGA->VGA conversion)
- minor improvements to palette editor (shift-click anchoring, and easier visualization of used colors for light colors)
- warning in save resource dialog when you're about to overwrite an existing resource
- support for shifting colors in a view to a new section of the palette, for easy re-coloring of views.
- dithering support for importing image sequences to VGA views, and for pic backgrounds
- output pane (e.g. for debugging support) now keeps scrolled to the bottom as new things come in
- support for exporting loops as gifs
- paste in VGA pic editor now applies a tracing image, as it does in EGA
- insert object dialog re-done, and extensible to support both SCI0 and SCI1.1
- insert object from right click menu in script editor
RELEASE NOTES 8-4-2015 (3.0.0.11)
-------------------------------
- expanded support for importing images into views
- lots of fixes to the image import dialog
- dithering support and alpha dithering support in image import dialog
- undo support for nouns/cases in message editor
- easier way to choose "fake ego"
- more penstyles in view editor
- import image dialog support hue change now
- fixes to compiler for better error messages
- maybe it runs under XP now?
- "insert method" in script right-click menu
- lots of other minor fixes
RELEASE NOTES 10-14-2015 (3.0.0.12)
-------------------------------
- support for message audio
- support for script navigation/tooltips/autocomplete
- auto Lip-syncing
- ability to record audio right in the message editor
RELEASE NOTES 12-7-2015 (3.0.1.0)
-----------------------------------------------
- support for Sierra Script syntax
- updated template game with lots of renames
- ability to open most SCI2 resources, and edit most of them too
- custom syntax highlighting (modify syntaxcolor.ini in the Customize folder)
- built-in help
- support for plugins
- fix some font rendering issues
- game "profiles" for running under DOSBox or ScummVM (or custom)
- lots of other stuff I guess, it's been a while
RELEASE NOTES 12-9-2015 (3.0.1.1)
----------------------------------------
- Fix the compiler bug with SCI0
RELEASE NOTES 12-11-2015 (3.0.1.2)
------------------------------------
- Fix the pic drawing bug reported by cloudee
- Slightly updated help
- syntax highlighting of procedure and class names
RELEASE NOTES 12-23-2015 (3.0.1.3)
------------------------------------------------
(if you downloaded this prior to Dec 24, 05:10 GMT, download it again, small bug fix)
- reduce script size a bit
- many fixes for compiling scripts in interpreter versions other than the two template games:
- Mixed Up Fairy Tales scripts compile properly now
- KQ5 floppy should decompile ok (someone reported that some scripts didn't decompile)
- KQ5-CD, scripts should compile properly now
- SCI0: some games don't like it when you write empty export tables. Fixed.
- fixed bug where deleting a resource could remove everything from resource.map
- fix decompiler bug that caused unpredictable decompiles in some cases (sometimes success sometimes not)
- fix decompiler bug that caused problems in xmas card 1990 demo Game::handleEvent
- improved source code formatting
- fixed some issues when decompiling to Sierra Script
- generate compile error when number literals don't fit in 16 bits.
- template game fixes:
- message case support
- scale signal defines
RELEASE NOTES 1-25-2016 (3.0.1.4)
---------------------------------
- basic digital sound support for SCI1 (just so 1990 Xmas Card demo can have Sfx)
- fix loading of some SCI1 sound resources
- various compiler and decompiler fixes
RELEASE NOTES 1-27-2016 (3.0.1.5)
---------------------------------
- fixes for synonyms compile issues and said string decompile issues with SCI0
- some autocomplete fixes to prevent autocompletion inside strings and such
- resource names weren't applied when doing Save As resource
- Stop the weird o in SQ3 for Joystick
- updates to template game to fix SaveRestoreDialog issues reported in December
- updates to pixel positino of status bar in template game
- LValue tokens not properly cleaned (dungeon# not turned into dungeon_ in all cases during KQ6 decompilation)
RELEASE NOTES 1-28-2016 (3.0.1.6)
--------------------------
- fixed issue with multiple plugins
RELEASE NOTES 1-29-2016 (3.0.1.7)
--------------------------
- fixed issue with drag-to-add resource names being blank until a rebuild
BUGS
-----
- crazy colors when copy-pasting a background in a VGA pic, then corrupted palette when delete image.
- problems deleting script
- editing view palette doesn't save it back to view
- pen (and other?) vector commands need to be disabled for SCI1.1+
- sequence 0 should be disallowed
- issue with control key being "stuck down" when editing messages (no consistent repro)
- Need to enforce the position of gDongle global var (perhaps remove it completely, and handle it automatically?)
- fg/bg colors in palette don't update properly when switching views
- newly added cels don't get focus
- deleting last pic command, or cropping commands -> position is lost and goes back to 0
- message (and other?) resources keep coming back after deleting, but open wrong resource - MI
- can't set -ve y offset for cels
- setting a loop that was a mirror to "none", then save. Reopen and it stays a mirror of another loop
- adding multiple inventory items: they overlap in the inventory window (drawInvWindow bug?)
- pasting from cel to cel gets weird if destination cel is smaller.
- pic resources render badly in SV.exe - kawa
- text editor is messed up
- apparently still have an issue with deleting resources
- AddPolygonsToRoom crashes in ScummVM
- can't read KQ5 CD script resources properly. lofsa absolute, but exports are not wide.
FEATURE REQUESTS
---------------------
- fake ego should obey polygons
- button for deleting messages
- way to visualize polygon paths (lskovlun)
- export palettes (MI)
- import gif sequence (MI)
- paste tracing image in VGA pics
- choose view/pic type when "new pic/view" when no game loaded
- palette cycling preview in pic editor
- highlight foreground/background colors in view editor palette
- 4x3 aspect ratio (for preving/editing)
- show mm:ss in the resource list view for sound/audio resources
- consider hiding pic command pane for VGA pics
- support gif export for views
- upload patches to midi devices for preview.
- when exporting message resources, export headers too - cloudee
- show all font letters in font preview (omer)
- preview pic with different palettes
- tint palettes
- import export messaGes
- extended character issues - kawa
- fix up DosBox config file and options
- Add Wait call to main loop
-
One feature I was thinking might be useful is to be able to import images in layers for the pic editor. The workflow now (and presumably what sierra used), was to import your hand-painted backgrounds ( ;) ) and then carefully draw priority regions that match up with the image. The alternative would be to track external files that get "composed" into a final image in the actual pic resource. For instance, you could have pic_100_0.png, pic_100_4.png, pic_100_15.png that represent images with priority layers 0, 4 and 15 for pic 100. Maybe you could even drag them around a bit to reposition the layers in the editor. Not sure if this would be useful or not - it would be a lot of work, so it depends how hard it is to draw the priority regions manually.
-
I really like that multiple image file layer/priority import function idea!
-
* Pic Editor...
Selecting Copy from the visual screen, and then clicking paste, the image itself is pasted onto the background but all kinds of weird when it is the whole pic image. I am assuming that this is a feature that I need to explore more. However when deleting the image from the left pane, the pallette appears to get screwed up.
In this sense, how hard also would it be to add the ability to load tracing image from clipboard instead of file. Usually when I have imported a bmp to the pic editor, I copy the visual screen in order to use it as a tracing image on the priority and control screens.
* Script listings...
I have rearranged a couple of scripts ex 100 became 800 for consistency. However after deleting 100 and removing the files from the src folder, the room still wanted to be listed on the main scripts page. But it took on the name of one of the scripts surrounding it, and only showed the decompilation. For a workaround, I just re-added a new room 100 script, but delete definitely does some weird stuff.
-
Can we have an option to create resources for specific versions of SCI? Currently when you open the View or Pic editors without opening a game first they default to SCI0. Can we have a selection box to choose which version of the SCI resource we want to create?
-
In this sense, how hard also would it be to add the ability to load tracing image from clipboard instead of file. Usually when I have imported a bmp to the pic editor, I copy the visual screen in order to use it as a tracing image on the priority and control screens.
Hmm, so that's exactly how it works in SCI0. All that happened for VGA pics is that I changed the default behavior of paste to "insert the image" instead of "load a tracing image". How does it feel to use the "zoom" screen (on the right) to draw the pri/control screens? e.g. switch the "zoom" screen to visual, then draw on the pri/control screens on the main image.
Can we have an option to create resources for specific versions of SCI? Currently when you open the View or Pic editors without opening a game first they default to SCI0. Can we have a selection box to choose which version of the SCI resource we want to create?
Is there a reason you're creating new views/pics without a game loaded? I'm trying to figure out if this is an important scenario to handle properly. SCI versions are bit more complicated than just SCI0/SCI1/SCI1.1. The "version" for a game currently consists of 17 different values describing different features!
-
* Script listings...
I have rearranged a couple of scripts ex 100 became 800 for consistency. However after deleting 100 and removing the files from the src folder, the room still wanted to be listed on the main scripts page. But it took on the name of one of the scripts surrounding it, and only showed the decompilation. For a workaround, I just re-added a new room 100 script, but delete definitely does some weird stuff.
I'm not seeing this behavior. Can you describe the steps you took in more detail? Also, did you check the box "remove blahblahblah completely from the game"?
-
Is there a reason you're creating new views/pics without a game loaded? I'm trying to figure out if this is an important scenario to handle properly. SCI versions are bit more complicated than just SCI0/SCI1/SCI1.1. The "version" for a game currently consists of 17 different values describing different features!
From what I've seen and tested all SCI1 Views work in any SCI1 game and the same for SCI1.1 and SCI0. The only exceptions are EGA SCI1 games which just use SCI0 View formats, it seems. They work, anyway. I've loaded the EGA version of SQ1 remake's ego sprites into SQ3 with no problems before. Same with Picture resources.
As for the reason why, well for instance I'm working on a new Ego View for the template game and I don't need the template game loaded. Other scenarios include creating a library of View/Pic/Anything resources for people to use for their own games. It'd just be easier than loading a game with the version of SCI I want just to work on sprites that I don't intend to use for that game (or any game).
-
It's a good idea, but I think I'll consider that a low-priority feature request. I tried as much as possible to make "version" specific to resources, but there are still many places where code uses a global "version" of the currently loaded game. It would be a lot of work to fix properly (in fact, I should probably disable "new ***" when a game is not loaded), and the workaround is just to load a game of the version you need.
-
Alright. :) I agree greying out New **** is a good idea for now.
EDIT: Oh, how about palette colour cycling previewing in the Pic editor?
Some comments. I love those extra small windows on the left hand side of the Pic editor. And the gradient feature is very useful!
EDIT 2: Oh, also for the View editor, I know you said you're aware that the palette box is too small, but is it possible that you can highlight on the palette which colours are selected for foreground/background? I'm thinking of Grafx2's feature where the foreground and background colours, in addition to be displayed in the foreground/background colour boxes, are highlighted on the palette as well (with a broken line border). The reason being it would be nice when using the eyedropper on a colour in the View to know which colour on the palette it is using. During 8-bit image editing using the right palette entry is almost as important as using the right colour, if you get I mean. Grafx2, btw, is an 8-bit image editor inspired by and works almost exactly like the old Amiga/DOS Deluxe Paint program, but made for modern systems.
Actually, this reminds me of setting dithered palette entries in SCI Companion for SCI0 Pictures where an "A" and "B" would appear on the colours selected for creating a dithered colour entry.
EDIT 3: One more thing, there doesn't seem to be an option to edit the palette for a sprite. Another option would be to have a checkbox to toggle whether the View has an embedded palette or not.
-
EDIT 3: One more thing, there doesn't seem to be an option to edit the palette for a sprite. Another option would be to have a checkbox to toggle whether the View has an embedded palette or not.
View -> Edit Palette
As I mentioned in the other thread, I didn't put it in the left-hand pane, because I need to totally re-work that for VGA views.
[edit:] oh, but it doesn't actually save it back to the view, does it? hahaha...
-
* Script listings...
I have rearranged a couple of scripts ex 100 became 800 for consistency. However after deleting 100 and removing the files from the src folder, the room still wanted to be listed on the main scripts page. But it took on the name of one of the scripts surrounding it, and only showed the decompilation. For a workaround, I just re-added a new room 100 script, but delete definitely does some weird stuff.
I'm not seeing this behavior. Can you describe the steps you took in more detail? Also, did you check the box "remove blahblahblah completely from the game"?
Alright, I moved script 255 (Controls) to 997...
First off I go into game.sh and add a new define (define CONTROLS_SCRIPT 997)
Then I go in and create a new room with the number that I am wanting to put it in
Then I cppy and paste the original script into the new room that I just created
I change the script number to reflect the define (script CONTROLS_SCRIPT)
I compile.
Then I went into the main script listing and select the original controls script and delete
The checkbox was checked.
Then I open the physical src folder
find the original controls.sco as it was not deleted and manually delete it
find the rm997.sc and sco files and rename those to controls.sc and sco
In the main script screen, I select rm997 and renamed it to controls.
open game.ini and verify that 255 was removed and 997 was entered.
Everything compiled and rebuilt and scicomp closed and opened a couple of times during this process.
Now except for the anomaly highlighted in screen shot, everything appears to be working correctly. Including the toolbox listing of scripts.
-
Thanks Cloudee, I'll look into this.
Why are you moving scripts around though? I don't see much point, and I think that's only going to cause you grief, as there may be places that refer to these scripts via ScriptId (and via a variable, so it may be hard to search for these).
[edit:] ok, I'm still not able to repro (there was already a script at 997, so I used 979 - not sure what you did with your script 997). Maybe you can send me a zip of your project and I can look into it if you want. That's really weird it would show two different names for the same resource... it may be that resource.map got corrupt somehow? That would scare me. What does SV.exe show?
Also, why use New Room instead of New Empty Script?
-
I am trying to get all of the lower numbered scripts out of the way. I usually (attempt) to use some sort of numbering scheme to my rooms. One project that I've got going is attempting to combine 5 parser based games into 1 point and clicker. I want the lower numbers for my rooms.
As for using new room instead of blank script, just habit I guess. For my point and click template I have my own room script template that I use, so from the start I am overwriting everything that is generated and copy and pasting over it.
I have found a couple of places where a script I have moved has been used by number reference. In those cases, I have just gone ahead and thrown in the game.sh define that I set up. DisposeCode, script 11, is one for instance that I had to track a bit more.
Here is my tester zipped up. I haven't touched the actual template that was packaged up. I'll have to look and see what is going on with 997... I swear it's not currently part of the 1.1 template.
-
Resource map has script 255 and 800:
0027: FF 00 14 2E 02 Script(255, 0) offset: 00045C28
0027: 20 03 6D 2F 02 Script(800, 0) offset: 00045EDA
But the script 255 resource map entry points to a package file entry that is identified as 800 (20 03):
045c28: 82 20 03 A8 02 A8 02 00 00 9C 02 00 00 00 00 01
045eda: 82 20 03 B0 02 B0 02 00 00 A4 02 00 00 00 00 01
I wonder if you compiled script 255, but had put (script TITLE_SCREEN) in it at one point... I'll try to figure out how this can happen. It looks like the heap resources also have this mismatch too.
[edit:] ok, I can repro this if I do a "compile all" with a script that has the wrong script number (or rather, a duplicate script number of another script)
[edit2:] no, there must be more to it than that. I thought I had a repro, but I didn't.
-
Sir, I can not "add after" a cel to a view, add before seems to do the job though. Both add loop before and after appear to work too.
-
Hmm, I'm not able to repro. Which cel do you have selected when you "add after"? How many cels are already in the loop?
-
Just went back in and double checked it just to make sure that I am not losing it.... 4 cels currently in loop. Current loop is loop 0. No matter which cel I have selected, the add after button has no effect.
-
Just went back in and double checked it just to make sure that I am not losing it.... 4 cels currently in loop. Current loop is loop 0. No matter which cel I have selected, the add after button has no effect.
It crashes in Wine - I thought this might be a Wine problem, but I guess not if you're having problems with it too.
-
From your two different reports and my different experience, sounds like I have some uninitialized data somewhere...
-
Speaking of views, I get an error in ScummVM when loading views made with Companion:
WARNING: unsupported flags byte (144) inside sci1.1 view!Actually, it is an error in stock ScummVM (which breaks into the debugger), but it is easy to change it to a warning. Doesn't work out of the box, though.
-
Thanks Lars, I'm able to repro the invalid view issue (looks like it only happens with new views, rather than modified views?). I'll look into it.
I'm not able to repro the Add After problem though, no matter what I do. I've tried both debug and release builds. Cloudee, what OS are you running?
-
Thanks Lars, I'm able to repro the invalid view issue (looks like it only happens with new views, rather than modified views?). I'll look into it.
I'm not able to repro the Add After problem though, no matter what I do. I've tried both debug and release builds. Cloudee, what OS are you running?
Windows 7 Pro
-
Companion seems to crash when opening LB2. Stack trace follows:
=>0 0x0040a75b in scicompanion (+0xa75b) (0x0032eda4)
1 0x0040a2a8 in scicompanion (+0xa2a7) (0x0032eddc)
2 0x00481dc4 in scicompanion (+0x81dc3) (0x0032eea8)
3 0x004b7450 in scicompanion (+0xb744f) (0x0032eee4)
4 0x004b735b in scicompanion (+0xb735a) (0x0032ef50)
5 0x004b6e3b in scicompanion (+0xb6e3a) (0x0032f034)
6 0x004b6be3 in scicompanion (+0xb6be2) (0x0032f060)
7 0x00416802 in scicompanion (+0x16801) (0x0032f07c)
8 0x006f28ac in scicompanion (+0x2f28ab) (0x0032f098)
9 0x004193db in scicompanion (+0x193da) (0x0032f0f4)
10 0x006f17d2 in scicompanion (+0x2f17d1) (0x0032f184)
11 0x00418f8c in scicompanion (+0x18f8b) (0x0032f194)
12 0x006d2858 in scicompanion (+0x2d2857) (0x0032f1c0)
13 0x00708b54 in scicompanion (+0x308b53) (0x0032f500)
14 0x00708981 in scicompanion (+0x308980) (0x0032f510)
15 0x004052ed in scicompanion (+0x52ec) (0x0032f78c)
16 0x007087e2 in scicompanion (+0x3087e1) (0x0032f7b8)
17 0x006ce165 in scicompanion (+0x2ce164) (0x0032f7c8)
18 0x006cdfb1 in scicompanion (+0x2cdfb0) (0x0032f7f8)
19 0x006df198 in scicompanion (+0x2df197) (0x0032f838)
20 0x006e385e in scicompanion (+0x2e385d) (0x0032f878)
21 0x006c9079 in scicompanion (+0x2c9078) (0x0032f8c8)
22 0x006df22c in scicompanion (+0x2df22b) (0x0032f8e4)
23 0x004600ea in scicompanion (+0x600e9) (0x0032f904)
24 0x006c9c91 in scicompanion (+0x2c9c90) (0x0032f9bc)
25 0x006cb4f5 in scicompanion (+0x2cb4f4) (0x0032f9dc)
26 0x00460234 in scicompanion (+0x60233) (0x0032fa08)
27 0x006c6b1b in scicompanion (+0x2c6b1a) (0x0032fa78)
28 0x006c729f in scicompanion (+0x2c729e) (0x0032fa98)
29 0x7eb86d1a WINPROC_wrapper+0x19() in user32 (0x0032fac8)
30 0x7eb87456 in user32 (+0xa7455) (0x0032fb18)
31 0x7eb89d8b CallWindowProcA+0x5a() in user32 (0x0032fb60)
32 0x005fb973 in scicompanion (+0x1fb972) (0x0032fba8)
33 0x005fcb34 in scicompanion (+0x1fcb33) (0x0032fbe8)
34 0x7eb86d1a WINPROC_wrapper+0x19() in user32 (0x0032fc18)
35 0x7eb87456 in user32 (+0xa7455) (0x0032fc68)
36 0x7eb89c23 in user32 (+0xa9c22) (0x0032fcb8)
37 0x7eb4a616 DispatchMessageA+0xb5() in user32 (0x0032fdc8)
38 0x006d4437 in scicompanion (+0x2d4436) (0x0032fe00)
39 0x0082d02a in scicompanion (+0x42d029) (0x0032fe14)
40 0x007fd99d in scicompanion (+0x3fd99c) (0x0032fe60)
...(the remaining frames are Wine code)
This appears to happen consistently. Has anybody else seen this?
EDIT: SCI32 games, too. But that's different.
-
I can open fine LB2 - both the floppy and cd versions.
-
I can open fine LB2 - both the floppy and cd versions.
Hmm, seems to be caused by a patch file in my LB2 dir. If I place the resource volumes in a separate directory, I can open them just fine.
I'll have to look into which file is causing this.
-
Decompiler bug:
there are some scripts that the decompiler fails on, and doesn't even manage to fallback to disassembly. I do manage to manually disassemble them by checking the "Disassemble only" check-box.
Example:
The Castle of Dr. Brain (all versions), 325.SCR.
Decompilation log:
Decompiling script 325
Decompiled 2 of 2 functions successfully (100%).
Overall bytecount success rate: 100%.
It seems like it was succesfull, but it actually wasn't. During decompilation it seemed to spend lots of time doing this:
word::dispatchEvent: Analyzing control flow Switch:0189
Disassembled script:
(version 2)
(include "sci.sh")
(exports
0 word
)
(use "Main")
(use "dummyClient")
(use "PuzzleIcon")
(use "Class_255_0")
(use "n958")
(use "SysWindow")
(use "Sound")
(use "Obj")
(script 325)
(local
local0[10] = (49 10 43 30 40 50 60 52 21 43 )
local10[10] = (1 4 11 14 3 1 5 0 7 11 )
local20[30] = (325 0 325 1 325 2 325 3 325 4 325 5 325 6 325 7 325 8 325 9 325 10 325 11 325 12 325 13 325 14 )
local50[225]
local275
local276
local277
local278[100] = (9 3 0 12 12 14 5 14 3 3 12 12 5 0 13 0 6 10 6 2 3 12 9 12 9 9 14 4 13 14 13 7 7 5 7 9 9 6 9 13 2 12 2 6 1 13 1 6 1 2 1 5 4 6 4 1 13 13 8 13 14 12 14 3 2 2 2 6 10 7 5 12 4 13 4 9 7 3 7 0 9 4 14 4 8 1 3 6 8 5 13 0 13 1 8 1 0 3 0 11 )
local378[44] = (0 14 4 14 6 5 6 2 10 3 13 3 11 2 8 2 12 6 12 11 4 0 0 0 5 11 5 8 11 8 9 10 10 5 13 5 8 3 8 5 1 7 4 7 )
local422
local423[16]
local439[16] = (-1 1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 )
local455
local456 = -1
local457
local458
local459 = -1
local460 = -100
local461 = -100
local462
)
(procedure (localproc_0a0a param1 param2 param3 param4 param5)
(var temp0, temp1, temp2, temp3)
(asm
pushi 9
pushi 11
pushi 22
lsp param3
ldi 9
mul
add
sat temp0
push
pushi 4
lsp param2
ldi 11
mul
add
sat temp2
push
lst temp0
ldi 8
add
sat temp1
push
lst temp2
ldi 10
add
sat temp3
push
pushi 1
lsp param4
pushi 65535
dup
callk Graph, 18
pushi 6
pushi 12
lst temp0
lst temp2
lst temp1
lst temp3
pushi 1
callk Graph, 12
pushi 8
lap param1
lea @local50
push
pushi 100
pushi 5
lsp param2
ldi 11
mul
add
push
pushi 23
lsp param3
ldi 9
mul
add
push
pushi 105
pushi 999
pushi 102
lsp param5
callk Display, 16
ret
)
)
(procedure (localproc_0a78 param1 param2 param3 param4)
(asm
pushi 2
lsp param1
lsp param2
call localproc_0a9e, 4
bnt code_0a9d
pushi 1
lsp param1
call localproc_0c8a, 2
push
lap param3
eq?
bnt code_0a9d
pushi 1
lsp param2
call localproc_0c8a, 2
push
lap param4
eq?
code_0a9d:ret
)
)
(procedure (localproc_0a9e param1 param2)
(asm
lsp param1
ldi 0
eq?
push
lsp param2
ldi 0
eq?
xor
bt code_0abb
pushi 1
lsp param1
callk Abs, 2
push
pushi 1
lsp param2
callk Abs, 2
eq?
code_0abb:ret
)
)
(procedure (localproc_0abc)
(var temp0, temp1)
(asm
ldi 0
sat temp0
code_0ac2:lst temp0
ldi 15
lt?
bnt code_0b0e
ldi 0
sat temp1
code_0ace:lst temp1
ldi 15
lt?
bnt code_0b09
lat temp0
lsli local423
lst temp1
ldi 1
add
lali local439
and
not
bnt code_0b04
pushi 5
lst temp0
ldi 15
mul
push
lat temp1
add
push
lst temp1
lst temp0
ldi 2
lsli local0
ldi 1
lsli local0
call localproc_0a0a, 10
code_0b04:+at temp1
jmp code_0ace
code_0b09:+at temp0
jmp code_0ac2
code_0b0e:ret
)
)
(procedure (localproc_0bc4)
(var temp0[200])
(asm
lsl local422
ldi 1
eq?
bnt code_0be7
pushi 7
pushi 325
pushi 19
pushi 67
pushi 65
pushi 6
pushi 25
pushi 3
calle proc255_0, 14
jmp code_0c26
code_0be7:lsl local422
lal local455
ge?
bnt code_0bfd
pushi 1
lofsa sPlaySounds
push
calle proc5_15, 2
jmp code_0c26
code_0bfd:pushi 5
lea @temp0
push
pushi 325
pushi 20
lsl local422
lsl local455
lal local422
sub
push
callk Format, 10
pushi 4
lea @temp0
push
pushi 67
pushi 65
pushi 6
calle proc255_0, 8
code_0c26:ret
)
)
(procedure (localproc_0c27)
(asm
pushi 2
pushi 325
pushi 21
calle proc5_9, 4
pushi 2
pushi 325
pushi 22
calle proc5_9, 4
pushi 2
pushi 325
pushi 23
calle proc5_9, 4
lsg global114
dup
ldi 0
eq?
bnt code_0c60
pushi 2
pushi 325
pushi 24
calle proc5_9, 4
ldi 18
sal local455
jmp code_0c88
code_0c60:dup
ldi 1
eq?
bnt code_0c79
ldi 22
sal local455
pushi 2
pushi 325
pushi 25
calle proc5_9, 4
jmp code_0c88
code_0c79:ldi 25
sal local455
pushi 2
pushi 325
pushi 26
calle proc5_9, 4
code_0c88:toss
ret
)
)
(procedure (localproc_0c8a param1)
(asm
lsp param1
ldi 0
eq?
bnt code_0c97
ldi 0
jmp code_0ca1
code_0c97:pushi 1
lsp param1
callk Abs, 2
push
lap param1
div
code_0ca1:ret
)
)
(procedure (localproc_0ca2 param1 param2 param3 param4 param5)
(var temp0, temp1, temp2, temp3, temp4[4], temp8, temp9, temp10, temp11[100])
(asm
pushi 0
lap param1
le?
bnt code_0cd9
pprev
ldi 14
le?
bnt code_0cd9
pushi 0
lap param3
le?
bnt code_0cd9
pprev
ldi 14
le?
bnt code_0cd9
pushi 0
lap param2
le?
bnt code_0cd9
pprev
ldi 14
le?
bnt code_0cd9
pushi 0
lap param4
le?
bnt code_0cd9
pprev
ldi 14
le?
code_0cd9:not
bnt code_0ce3
pushi 0
call localproc_0abc, 0
ret
code_0ce3:pushi 1
lsp param3
lap param1
sub
push
call localproc_0c8a, 2
sat temp0
pushi 1
lsp param4
lap param2
sub
push
call localproc_0c8a, 2
sat temp1
lat temp0
bnt code_0d46
lat temp1
bnt code_0d46
pushi 2
pushi 1
lsp param3
lap param1
sub
push
callk Abs, 2
push
pushi 1
lsp param4
lap param2
sub
push
callk Abs, 2
push
calle proc999_3, 4
sat temp10
lsp param3
lsp param1
push
lat temp0
mul
add
ne?
bt code_0d3e
lsp param4
lsp param2
lst temp10
lat temp1
mul
add
ne?
code_0d3e:bnt code_0d46
pushi 0
call localproc_0abc, 0
code_0d46:lap param1
sat temp2
lap param2
sat temp3
lsp param5
dup
ldi 1
eq?
bnt code_0d5e
ldi 6
lali local0
jmp code_0d77
code_0d5e:dup
ldi 0
eq?
bnt code_0d6c
ldi 2
lali local0
jmp code_0d77
code_0d6c:dup
ldi 2
eq?
bnt code_0d77
ldi 8
lali local0
code_0d77:toss
sat temp8
lsp param5
dup
ldi 1
eq?
bnt code_0d8a
ldi 5
lali local0
jmp code_0da3
code_0d8a:dup
ldi 0
eq?
bnt code_0d98
ldi 1
lali local0
jmp code_0da3
code_0d98:dup
ldi 2
eq?
bnt code_0da3
ldi 7
lali local0
code_0da3:toss
sat temp9
code_0da6:lsp param5
ldi 2
eq?
bnt code_0ddd
lat temp3
lsli local423
lst temp2
ldi 1
add
lali local439
or
push
lat temp3
sali local423
pushi 5
lst temp3
ldi 15
mul
push
lat temp2
add
push
lst temp2
lst temp3
lst temp8
lst temp9
call localproc_0a0a, 10
jmp code_0e48
code_0ddd:lsp param5
ldi 0
eq?
bnt code_0e30
lat temp3
lsli local423
lst temp2
ldi 1
add
lali local439
and
bnt code_0e15
pushi 5
lst temp3
ldi 15
mul
push
lat temp2
add
push
lst temp2
lst temp3
ldi 8
lsli local0
ldi 7
lsli local0
call localproc_0a0a, 10
jmp code_0e48
code_0e15:pushi 5
lst temp3
ldi 15
mul
push
lat temp2
add
push
lst temp2
lst temp3
lst temp8
lst temp9
call localproc_0a0a, 10
jmp code_0e48
code_0e30:pushi 5
lst temp3
ldi 15
mul
push
lat temp2
add
push
lst temp2
lst temp3
lst temp8
lst temp9
call localproc_0a0a, 10
code_0e48:lst temp2
lap param3
eq?
bnt code_0e55
lst temp3
lap param4
eq?
code_0e55:bt code_0e69
lst temp2
lat temp0
add
sat temp2
lst temp3
lat temp1
add
sat temp3
jmp code_0da6
code_0e69:ret
)
)
(procedure (localproc_0e6a param1 param2 param3 param4)
(var temp0, temp1)
(asm
ldi 0
sat temp0
code_0e70:lst temp0
ldi 25
lt?
bnt code_0f9a
pushi 4
lat temp0
mul
sat temp1
lsp param1
lap param3
eq?
bnt code_0e95
lsp param2
lap param4
eq?
bnt code_0e95
ldi 65535
ret
jmp code_0f95
code_0e95:lsp param2
lat temp1
lali local278
eq?
bnt code_0f16
lsp param1
lst temp1
ldi 1
add
lali local278
eq?
bnt code_0f16
lsp param4
lst temp1
ldi 2
add
lali local278
eq?
bnt code_0f16
lsp param3
lst temp1
ldi 3
add
lali local278
eq?
bnt code_0f16
pushi 0
lat temp1
lali local278
sub
push
lat temp1
sali local278
pushi 0
lst temp1
ldi 1
add
lali local278
sub
push
lst temp1
ldi 1
add
sali local278
pushi 0
lst temp1
ldi 2
add
lali local278
sub
push
lst temp1
ldi 2
add
sali local278
pushi 0
lst temp1
ldi 3
add
lali local278
sub
push
lst temp1
ldi 3
add
sali local278
ldi 1
ret
jmp code_0f95
code_0f16:pushi 0
lap param2
sub
push
lat temp1
lali local278
eq?
bnt code_0f5d
pushi 0
lap param1
sub
push
lst temp1
ldi 1
add
lali local278
eq?
bnt code_0f5d
pushi 0
lap param4
sub
push
lst temp1
ldi 2
add
lali local278
eq?
bnt code_0f5d
pushi 0
lap param3
sub
push
lst temp1
ldi 3
add
lali local278
eq?
bnt code_0f5d
ldi 2
ret
jmp code_0f95
code_0f5d:lsp param2
lat temp1
lali local378
eq?
bnt code_0f95
lsp param1
lst temp1
ldi 1
add
lali local378
eq?
bnt code_0f95
lsp param4
lst temp1
ldi 2
add
lali local378
eq?
bnt code_0f95
lsp param3
lst temp1
ldi 3
add
lali local378
eq?
bnt code_0f95
ldi 3
ret
code_0f95:+at temp0
jmp code_0e70
code_0f9a:ldi 0
ret
)
)
(procedure (localproc_0f9d param1)
(var temp0, temp1)
(asm
pushi #x
pushi 0
lap param1
send 4
sat temp0
pushi #y
pushi 0
lap param1
send 4
sat temp1
lal local457
not
bnt code_0fb9
ret
code_0fb9:pushi #message
pushi 0
lap param1
send 4
push
dup
ldi 1
eq?
bnt code_0fdf
pushi 187
pushi #x
lsg gCursorNumber
pushi 1
lst temp0
lst temp1
ldi 9
sub
push
lag gGame
send 12
jmp code_1171
code_0fdf:dup
ldi 8
eq?
bnt code_1012
lst temp0
ldi 9
eq?
bt code_0ff3
lst temp1
ldi 26
eq?
code_0ff3:not
bnt code_1171
pushi 187
pushi 4
lsg gCursorNumber
pushi 1
lst temp0
ldi 11
sub
push
lst temp1
ldi 9
sub
push
lag gGame
send 12
jmp code_1171
code_1012:dup
ldi 2
eq?
bnt code_1046
lst temp0
ldi 163
eq?
bt code_1027
lst temp1
ldi 26
eq?
code_1027:not
bnt code_1171
pushi 187
pushi 4
lsg gCursorNumber
pushi 1
lst temp0
ldi 11
add
push
lst temp1
ldi 9
sub
push
lag gGame
send 12
jmp code_1171
code_1046:dup
ldi 5
eq?
bnt code_106d
lst temp1
ldi 152
ne?
bnt code_1171
pushi 187
pushi #x
lsg gCursorNumber
pushi 1
lst temp0
lst temp1
ldi 9
add
push
lag gGame
send 12
jmp code_1171
code_106d:dup
ldi 4
eq?
bnt code_10a2
lst temp0
ldi 163
eq?
bt code_1083
lst temp1
ldi 152
eq?
code_1083:not
bnt code_1171
pushi 187
pushi 4
lsg gCursorNumber
pushi 1
lst temp0
ldi 11
add
push
lst temp1
ldi 9
add
push
lag gGame
send 12
jmp code_1171
code_10a2:dup
ldi 6
eq?
bnt code_10d6
lst temp0
ldi 9
eq?
bt code_10b7
lst temp1
ldi 152
eq?
code_10b7:not
bnt code_1171
pushi 187
pushi 4
lsg gCursorNumber
pushi 1
lst temp0
ldi 11
sub
push
lst temp1
ldi 9
add
push
lag gGame
send 12
jmp code_1171
code_10d6:dup
ldi 7
eq?
bnt code_1124
lst temp0
ldi 9
eq?
bnt code_1105
lst temp1
ldi 26
ne?
bnt code_1105
pushi 187
pushi #x
lsg gCursorNumber
pushi 1
pushi 163
lst temp1
ldi 9
sub
push
lag gGame
send 12
jmp code_1171
code_1105:lst temp0
ldi 9
ne?
bnt code_1171
pushi 187
pushi #x
lsg gCursorNumber
pushi 1
lst temp0
ldi 11
sub
push
lst temp1
lag gGame
send 12
jmp code_1171
code_1124:dup
ldi 3
eq?
bnt code_1171
lst temp1
ldi 152
ne?
bnt code_1154
lst temp0
ldi 163
eq?
bnt code_1154
pushi 187
pushi #x
lsg gCursorNumber
pushi 1
pushi 9
lst temp1
ldi 9
add
push
lag gGame
send 12
jmp code_1171
code_1154:lst temp0
ldi 163
ne?
bnt code_1171
pushi 187
pushi #x
lsg gCursorNumber
pushi 1
lst temp0
ldi 11
add
push
lst temp1
lag gGame
send 12
code_1171:toss
ret
)
)
(procedure (localproc_1173 param1)
(var temp0, temp1)
(asm
pushi #x
pushi 0
lap param1
send 4
sat temp0
pushi #y
pushi 0
lap param1
send 4
sat temp1
lst temp0
ldi 0
gt?
bnt code_11a6
lst temp1
ldi 20
gt?
bnt code_11a6
lst temp0
ldi 168
lt?
bnt code_11a6
lst temp1
ldi 161
lt?
code_11a6:ret
)
)
(instance public word of PuzzleBar
(properties
puzzleHeight 169
bottomHeight 0
solvedFlag 10
)
(method (init param1)
(var temp0)
(asm
pushi 1
pushi 0
calle proc5_5, 2
not
bnt code_0031
ldi 0
sat temp0
code_001e: lst temp0
ldi 10
lt?
bnt code_0031
lat temp0
lsli local10
sali local0
+at temp0
jmp code_001e
code_0031: lofsa wordWindow
aTop window
pushi #back
pushi 1
ldi 9
lsli local0
lofsa wordWindow
send 6
pushi 7
pushi 132
pushi 50
pushi 51
pushi 54
pushi 56
pushi 104
pushi 967
calle proc958_0, 14
pushi #init
pushi 0
&rest param1
super PuzzleBar, 4
pushi #show
pushi 0
self 4
lag global114
sal local459
ret
)
)
(method (show param1)
(asm
pushi #show
pushi 0
&rest param1
super PuzzleBar, 4
pushi 1
pushi 10
calle proc5_5, 2
bnt code_008e
pushi #init
pushi 0
pushi 2
pushi 377
pushi 1
callk ScriptID, 4
send 4
code_008e: ret
)
)
(method (dispatchEvent pEvent)
(var temp0, temp1[2], temp3, temp4, temp5, temp6, temp7, temp8, temp9, temp10, temp11, temp12, temp13, temp14, temp15, temp16, temp17, temp18, temp19, temp20, temp21, temp22, temp23, temp24, temp25[24], temp49, temp50)
(asm
pushi #type
pushi 0
lap pEvent
send 4
sat temp0
pushi #x
pushi 0
lap pEvent
send 4
sat temp4
pushi #y
pushi 0
lap pEvent
send 4
sat temp5
pushi 1
lsp pEvent
call localproc_1173, 2
not
bnt code_0181
ldi 0
sal local457
code_0181: lst temp0
ldi 64
and
bnt code_01cc
pushi #message
pushi 0
lap pEvent
send 4
push
dup
ldi 5
eq?
bnt code_01b7
lal local457
not
bnt code_01cb
ldi 1
sal local457
pushi #setCursor
pushi 4
lsg gCursorNumber
pushi 1
pushi 9
pushi 26
lag gGame
send 12
jmp code_01cb
code_01b7: dup
ldi 1
eq?
bnt code_01cb
lst temp5
ldi 26
lt?
bnt code_01cb
ldi 0
sal local457
code_01cb: toss
code_01cc: lal local457
not
bnt code_01df
pushi #firstTrue
pushi 2
pushi 196
lsp pEvent
self 8
sat temp3
code_01df: ldi 1
sat temp20
lst temp4
ldi 5
sub
push
ldi 11
div
sat temp6
lst temp5
ldi 23
sub
push
ldi 9
div
sat temp7
pushi 0
lat temp6
le?
bnt code_065a
pprev
ldi 14
le?
bnt code_065a
pushi 0
lat temp7
le?
bnt code_065a
pprev
ldi 14
le?
bnt code_065a
lst temp7
ldi 15
mul
push
lat temp6
add
sat temp8
lst temp0
ldi 4
and
bt code_022d
lst temp0
ldi 64
and
code_022d: bnt code_02a6
lal local457
not
bnt code_0244
lst temp5
ldi 26
ge?
bnt code_0244
ldi 1
sal local457
code_0244: lst temp4
ldi 9
sub
push
ldi 11
mod
not
bnt code_025b
lst temp5
ldi 26
sub
push
ldi 9
mod
not
code_025b: not
bnt code_0264
ldi 1
sal local462
code_0264: lal local462
bnt code_029f
pushi 187
pushi 4
lsg gCursorNumber
pushi 1
pushi #nsTop
lst temp6
ldi 11
mul
add
sat temp49
push
pushi 26
lst temp7
ldi 9
mul
add
sat temp50
push
lag gGame
send 12
ldi 0
sal local462
pushi #x
pushi 1
lst temp49
pushi 3
pushi 1
lst temp50
lap pEvent
send 12
code_029f: pushi 1
lsp pEvent
call localproc_0f9d, 2
code_02a6: pushi #message
pushi 0
lap pEvent
send 4
push
ldi 13
eq?
bnt code_02b8
ldi 1
sat temp0
code_02b8: lst temp0
dup
ldi 0
eq?
bnt code_0334
lst temp8
lal local275
ne?
bnt code_0322
pushi 5
lst temp8
lst temp6
lst temp7
ldi 4
lsli local0
ldi 3
lsli local0
call localproc_0a0a, 10
lal local277
lsli local423
lsl local276
ldi 1
add
lali local439
and
bnt code_030b
pushi 5
lsl local275
lsl local276
lsl local277
ldi 8
lsli local0
ldi 7
lsli local0
call localproc_0a0a, 10
jmp code_0322
code_030b: pushi 5
lsl local275
lsl local276
lsl local277
ldi 2
lsli local0
ldi 1
lsli local0
call localproc_0a0a, 10
code_0322: lat temp8
sal local275
lat temp6
sal local276
lat temp7
sal local277
jmp code_0656
code_0334: dup
ldi 1
eq?
bnt code_0656
lst temp4
ldi 5
sub
push
ldi 11
div
sat temp12
lst temp5
ldi 23
sub
push
ldi 9
div
sat temp13
lat temp12
sat temp16
lat temp13
sat temp17
pushi 5
lst temp13
ldi 15
mul
push
lat temp12
add
push
lst temp12
lst temp13
ldi 6
lsli local0
ldi 5
lsli local0
call localproc_0a0a, 10
ldi 0
sat temp19
sat temp18
code_037b: pushi #type
pushi 0
pushi #new
pushi 0
class Event
send 4
sat temp9
send 4
push
ldi 2
ne?
bnt code_0586
pushi #type
pushi 0
lat temp9
send 4
push
ldi 256
ne?
bnt code_0586
pushi #message
pushi 0
lat temp9
send 4
push
ldi 13
ne?
bnt code_0586
pushi #localize
pushi 0
lat temp9
send 4
pushi 1
lst temp9
callk MapKeyToDir, 2
lal local457
bnt code_03ce
pushi 1
lst temp9
callk MapKeyToDir, 2
pushi 1
lst temp9
call localproc_0f9d, 2
code_03ce: pushi #x
pushi 0
lat temp9
send 4
sat temp10
pushi #y
pushi 0
lat temp9
send 4
sat temp11
lst temp10
ldi 5
sub
push
ldi 11
div
sat temp14
lst temp11
ldi 23
sub
push
ldi 9
div
sat temp15
lst temp20
ldi 1
eq?
bnt code_043f
lst temp14
lat temp12
ne?
bt code_040b
lst temp15
lat temp13
ne?
code_040b: bnt code_043f
pushi 2
lst temp14
lat temp12
sub
push
lst temp15
lat temp13
sub
push
call localproc_0a9e, 4
bnt code_043f
ldi 0
sat temp20
lst temp14
lat temp12
sub
sat temp18
lst temp15
lat temp13
sub
sat temp19
lat temp14
sat temp16
lat temp15
sat temp17
jmp code_057c
code_043f: pushi 0
lat temp14
le?
bnt code_0458
pprev
ldi 14
le?
bnt code_0458
pushi 0
lat temp15
le?
bnt code_0458
pprev
ldi 14
le?
code_0458: not
bnt code_0461
ldi 0
jmp code_057c
code_0461: pushi 4
lst temp14
lat temp16
sub
push
lst temp15
lat temp17
sub
push
lst temp18
lst temp19
call localproc_0a78, 8
bnt code_04a6
lst temp14
lat temp16
eq?
bnt code_0487
lst temp15
lat temp17
eq?
code_0487: not
bnt code_04a6
pushi 6
lst temp16
lst temp17
lst temp14
lst temp15
pushi 1
pushi 1
call localproc_0ca2, 12
lat temp14
sat temp16
lat temp15
sat temp17
jmp code_057c
code_04a6: pushi 4
lst temp16
lat temp14
sub
push
lst temp17
lat temp15
sub
push
lst temp18
lst temp19
call localproc_0a78, 8
bnt code_0507
lst temp14
lat temp16
eq?
bnt code_04cc
lst temp15
lat temp17
eq?
code_04cc: not
bnt code_0507
lst temp14
lat temp12
eq?
bnt code_04e4
lst temp15
lat temp13
eq?
bnt code_04e4
ldi 1
sat temp20
code_04e4: pushi 6
lst temp14
lat temp18
add
push
lst temp15
lat temp19
add
push
lst temp16
lst temp17
pushi 0
pushi 2
call localproc_0ca2, 12
lat temp14
sat temp16
lat temp15
sat temp17
jmp code_057c
code_0507: lst temp20
ldi 0
eq?
bnt code_057c
lst temp14
lat temp16
eq?
bnt code_051c
lst temp15
lat temp17
eq?
code_051c: not
bnt code_057c
pushi 2
lst temp14
lat temp12
sub
sat temp21
push
lst temp15
lat temp13
sub
sat temp22
push
call localproc_0a9e, 4
bnt code_057c
pushi 1
lst temp21
call localproc_0c8a, 2
sat temp23
pushi 1
lst temp22
call localproc_0c8a, 2
sat temp24
pushi 6
lst temp12
lst temp13
lst temp16
lst temp17
pushi 0
pushi 3
call localproc_0ca2, 12
pushi 6
lst temp12
lst temp13
lst temp14
lst temp15
pushi 1
pushi 4
call localproc_0ca2, 12
lat temp23
sat temp18
lat temp24
sat temp19
lat temp14
sat temp16
lat temp15
sat temp17
code_057c: pushi #dispose
pushi 0
lat temp9
send 4
jmp code_037b
code_0586: pushi #dispose
pushi 0
lat temp9
send 4
pushi 4
lst temp12
lst temp13
lst temp14
lst temp15
call localproc_0e6a, 8
push
dup
ldi 1
eq?
bnt code_05c7
pushi #play
pushi 0
lofsa rightSound
send 4
+al local422
pushi 0
call localproc_0bc4, 0
pushi 6
lst temp12
lst temp13
lst temp16
lst temp17
pushi 2
pushi 5
call localproc_0ca2, 12
jmp code_0655
code_05c7: dup
ldi 2
eq?
bnt code_05f4
pushi #play
pushi 0
lofsa oldSound
send 4
pushi 2
pushi 325
pushi 15
calle proc5_9, 4
pushi 6
lst temp12
lst temp13
lst temp16
lst temp17
pushi 2
pushi 5
call localproc_0ca2, 12
jmp code_0655
code_05f4: dup
ldi 3
eq?
bnt code_0626
pushi #play
pushi 0
lofsa squawkSound
send 4
pushi 6
lst temp12
lst temp13
lst temp16
lst temp17
pushi 0
pushi 6
call localproc_0ca2, 12
pushi 2
pushi 325
pushi 16
calle proc5_9, 4
pushi 0
call localproc_0abc, 0
jmp code_0655
code_0626: dup
ldi 0
eq?
bnt code_0655
pushi #play
pushi 0
lofsa wrongSound
send 4
pushi 6
lst temp12
lst temp13
lst temp16
lst temp17
pushi 0
pushi 6
call localproc_0ca2, 12
pushi 2
pushi 325
pushi 17
calle proc5_9, 4
pushi 0
call localproc_0abc, 0
code_0655: toss
code_0656: toss
jmp code_068f
code_065a: lsl local276
lal local460
ne?
bt code_066b
lsl local277
lal local461
ne?
code_066b: bnt code_068f
pushi 6
lsl local276
lsl local277
lsl local276
lsl local277
pushi 0
pushi 7
call localproc_0ca2, 12
lal local276
sal local460
lal local277
sal local461
code_068f: pushi #claimed
pushi 1
pushi 0
lap pEvent
send 6
lal local457
not
bnt code_06b6
pushi #dispatchEvent
pushi 1
lsp pEvent
super PuzzleBar, 6
bnt code_06b0
ldi 1
ret
jmp code_06c0
code_06b0: ldi 0
ret
jmp code_06c0
code_06b6: pushi #dispose
pushi 0
lap pEvent
send 4
ldi 0
ret
code_06c0: ret
)
)
(method (buyClue)
(var temp0, temp1)
(asm
pushi #buyClue
pushi 0
super PuzzleBar, 4
bnt code_012d
ldi 0
sat temp0
code_009f: lst temp0
ldi 25
lt?
bnt code_012d
pushi 4
lat temp0
mul
sat temp1
lsli local278
ldi 0
ge?
bnt code_0128
pushi 6
lst temp1
ldi 1
add
lsli local278
lat temp1
lsli local278
push
ldi 3
add
lsli local278
lst temp1
ldi 2
add
lsli local278
pushi 1
pushi 8
call localproc_0ca2, 12
pushi 1
pushi 0
callk Wait, 2
pushi 1
pushi 60
callk Wait, 2
pushi 6
lst temp1
ldi 1
add
lsli local278
lat temp1
lsli local278
push
ldi 3
add
lsli local278
lst temp1
ldi 2
add
lsli local278
pushi 2
pushi 8
call localproc_0ca2, 12
pushi 1
pushi 60
callk Wait, 2
+al local422
pushi 0
call localproc_0bc4, 0
pushi 0
lat temp1
lali local278
sub
push
lat temp1
sali local278
ret
code_0128: +at temp0
jmp code_009f
code_012d: ret
)
)
(method (showHelp)
(asm
pushi 0
call localproc_0c27, 0
pushi 0
call localproc_0bc4, 0
ret
)
)
(method (animateOnce)
(asm
pushi 2
pushi #elements
pushi 0
lag gCast
send 4
push
pushi 1
callk Animate, 4
lag gTheNewDialog
bnt code_0151
pushi #check
pushi 0
send 4
code_0151: ldi 1
ret
)
)
)
(instance rightSound of Sound
(properties
flags $0001
number 50
)
)
(instance wrongSound of Sound
(properties
flags $0001
number 56
)
)
(instance oldSound of Sound
(properties
flags $0001
number 54
)
)
(instance squawkSound of Sound
(properties
flags $0001
number 104
)
)
(instance rewardSound of Sound
(properties
flags $0001
number 51
)
)
(instance wordWindow of SysWindow
(properties
top 19
left 79
bottom 180
right 247
)
(method (open param1)
(var temp0, temp1, temp2[15], temp17, temp18, temp19, temp20)
(asm
pushi #open
pushi 0
super SysWindow, 4
ldi 5
sat temp18
ldi 23
sat temp19
ldi 0
sat temp20
ldi 0
sat temp0
code_0855: lst temp0
ldi 30
lt?
bnt code_099e
pushi 3
lea @temp2
push
lat temp0
lsli local20
push
ldi 1
add
lsli local20
&rest param1
callk Format, 6
ldi 0
sat temp1
code_0876: lst temp1
ldi 15
lt?
bnt code_0945
pushi 2
lea @temp2
push
lst temp1
callk StrAt, 4
push
pushi 15
lst temp0
ldi 2
div
mul
push
lat temp1
add
sali local50
sat temp17
pushi 10
lea @temp17
push
pushi 100
lst temp18
lst temp19
pushi 105
pushi 999
pushi 102
ldi 1
lsli local0
pushi 103
ldi 2
lsli local0
callk Display, 20
lst temp0
ldi 2
div
lsli local423
lst temp1
ldi 1
add
lali local439
and
bnt code_08f1
pushi 5
lst temp0
ldi 2
div
push
ldi 15
mul
push
lat temp1
add
push
lst temp1
lst temp0
ldi 2
div
push
ldi 8
lsli local0
ldi 7
lsli local0
call localproc_0a0a, 10
code_08f1: lst temp18
ldi 11
add
sat temp18
lst temp20
ldi 0
eq?
bnt code_0940
lst temp1
ldi 14
ne?
bnt code_0940
pushi 8
pushi 4
pushi 22
lst temp18
ldi 2
sub
push
pushi 156
lst temp18
ldi 2
sub
push
ldi 0
lsli local0
pushi 65535
dup
callk Graph, 16
pushi 6
pushi 12
pushi 23
lst temp18
ldi 3
sub
push
pushi 156
lst temp18
ldi 1
sub
push
pushi 1
callk Graph, 12
code_0940: +at temp1
jmp code_0876
code_0945: ldi 1
sat temp20
ldi 5
sat temp18
lst temp19
ldi 9
add
sat temp19
lst temp0
ldi 28
ne?
bnt code_0994
pushi 8
pushi 4
lst temp19
ldi 2
sub
push
pushi 4
lst temp19
ldi 2
sub
push
pushi 168
ldi 0
lsli local0
pushi 65535
dup
callk Graph, 16
pushi 6
pushi 12
lst temp19
ldi 3
sub
push
pushi 5
lst temp19
ldi 1
sub
push
pushi 168
pushi 1
callk Graph, 12
code_0994: lst temp0
ldi 2
add
sat temp0
jmp code_0855
code_099e: lal local458
not
bt code_09ab
lsl local459
lag global114
ne?
code_09ab: bnt code_09b8
pushi 0
call localproc_0c27, 0
ldi 1
sal local458
code_09b8: pushi 0
call localproc_0bc4, 0
pushi #setCursor
pushi 4
lsg gCursorNumber
pushi 1
pushi 9
pushi 26
lag gGame
send 12
ret
)
)
)
(instance sPlaySounds of Script
(properties)
(method (changeState newState)
(asm
lap newState
aTop state
push
dup
ldi 0
eq?
bnt code_0b27
pushi #play
pushi 1
pushSelf
lofsa rewardSound
send 6
jmp code_0b87
code_0b27: dup
ldi 1
eq?
bnt code_0b43
pushi 3
pushi 325
pushi 18
lsl local422
calle proc5_14, 6
ldi 1
aTop cycles
jmp code_0b87
code_0b43: dup
ldi 2
eq?
bnt code_0b6a
pushi #number
pushi 1
pushi 967
pushi 102
pushi 1
pushi 1
pushi 162
pushi 1
pushi 1
pushi 161
pushi 1
pushi 127
pushi 42
pushi 1
pushSelf
lag gCMusic2
send 30
jmp code_0b87
code_0b6a: dup
ldi 3
eq?
bnt code_0b87
pushi #solvePuzzle
pushi 0
pushi 539
pushi 0
lofsa word
send 8
ldi 0
aTop client
pushi #dispose
pushi 0
self 4
code_0b87: toss
ret
)
)
)
-
Another example:
Hoyle's volume 3, 301.SCR.
Decompilation log:
Decompiling script 301
Restructured branches in BGPlayer_generateBoards
WARNING: BGPlayer::handleEvent: Analyzing control flow: Unable to insert if node. Exit needs to predecessors.: 1 at 05d2
Falling back to disassembly for handleEvent
WARNING: BGPlayer::dieMove: Analyzing control flow: Unable to insert if node. Exit needs to predecessors.: 1 at 079b
Falling back to disassembly for dieMove
Decompiled 25 of 27 functions successfully (92%).
Overall bytecount success rate: 90%.
Fell back to assembly for the remaining functions.
-
Lars, can you send me a zip file with the patch files? Should be easy to tell what the issue is. Even if it's a corrupt/bogus patch file, I'd like to handle it gracefully.
I found the issue with the decompilation. Well, basically at some point I decided I had done enough work on the decompiler, and any "sticky situations" it got into, I would just say "ok, bail, and fall back to disassembly". But I missed some of the sticky situations, so it's just a matter of identifying them properly. It was the same issue for both Dr Brain and Hoyle (btw, most of the resources in Hoyle 3 don't load properly - I may look at it eventually, but Hoyle isn't high on the list of games to have working).
-
I see.
Thanks for addressing this so quickly!
-
As for Hoyle 3, you can use the Game -> Version Detection dialog to open things properly (set view and pic to EGA, and click reload).
My version detection stuff trips up, because I detect a VGA palette resource, so I assume views and pics are VGA, but they're not. (Why does Hoyle 3 have a palette????).
[edit:] Or maybe there are VGA versions of Hoyle 3 too?
-
Hoyle 3 is a VGA game by default with a Tandy compatible EGA version just like SQ4, SQ1Remake, LSL1Remake, LSL5, PQ3, etc.
-
Ah, ok, the version I have is the EGA one. It definitely looks converted from VGA, given they left the palette resource in, and the EGA pics are all EGA bitmaps instead of vector commands.
-
Do you need any files from the Hoyle 3 VGA?
-
Ah, ok, the version I have is the EGA one. It definitely looks converted from VGA, given they left the palette resource in, and the EGA pics are all EGA bitmaps instead of vector commands.
Hmm, the one I had was too lol. Try it again. I have now replaced the EGA version with a VGA one.
-
How about the option to delete messages. I was attempting to sort out the business of having the room look statement change depending on a local variable and in the end I now have a message statement that I no longer want right now.
Also, I haven't been able to isolate it quite yet, but currently when typing in the message, it almost seems to act like I have the control key held down. I noticed it at first when I couldn't type in a "c" but just now when typing out a word with a v in it, it pasted some code that I had just copied to the clipboard. I am not sure if this is all the time or a random issue yet. For the most part I have been copying and pasting most of my messages.
-
How about the option to delete messages. I was attempting to sort out the business of having the room look statement change depending on a local variable and in the end I now have a message statement that I no longer want right now.
Also, I haven't been able to isolate it quite yet, but currently when typing in the message, it almost seems to act like I have the control key held down. I noticed it at first when I couldn't type in a "c" but just now when typing out a word with a v in it, it pasted some code that I had just copied to the clipboard. I am not sure if this is all the time or a random issue yet. For the most part I have been copying and pasting most of my messages.
Speaking of message files, it also seems that sequence number 0 should be disallowed. I was working on a polygon tool (with a different purpose than the standard one) with an auxiliary message and view resource, and I wanted to have the standard polygon type number = a cel number in the view = a sequence number in the message resource. It didn't work; and that took me some time to track down.
-
How about the option to delete messages. I was attempting to sort out the business of having the room look statement change depending on a local variable and in the end I now have a message statement that I no longer want right now.
Click on the message and hit the delete key. (I agree, there needs to be a toolbar button or something too).
Also, I haven't been able to isolate it quite yet, but currently when typing in the message, it almost seems to act like I have the control key held down. I noticed it at first when I couldn't type in a "c" but just now when typing out a word with a v in it, it pasted some code that I had just copied to the clipboard. I am not sure if this is all the time or a random issue yet. For the most part I have been copying and pasting most of my messages.
I've noticed that too, but I haven't been able to come up with a consistent repro.
Speaking of message files, it also seems that sequence number 0 should be disallowed. I was working on a polygon tool (with a different purpose than the standard one) with an auxiliary message and view resource, and I wanted to have the standard polygon type number = a cel number in the view = a sequence number in the message resource. It didn't work; and that took me some time to track down.
I'm not sure I understand your scenario, but yeah, it looks like a sequence # of zero isn't allowed? What happens, does SCI just fail to get the message?
-
I'm not sure I understand your scenario, but yeah, it looks like a sequence # of zero isn't allowed? What happens, does SCI just fail to get the message?
It gives you the message for sequence number 1 instead.
-
When doing something to all cels of a view, it does not update the changes in the panel on the right. Not even in the cel with focus.
-
Thanks. Found the problem. I'll release a new build when I get SCI1 sound working. Well, it's working, but cues and loop points still cause the Sierra interpreter to lockup.
-
I've released another update to SCICompanion. Same link as before, see the first post in this thread.
RELEASE NOTES 6-10-2015
---------------------
- View editor pane has been "revamped". Palette is larger, and there is an edit palette button. The treeview of loops/cels is gone. You can use the arrows, as before, to select cels or loops, or you can use the new panes on the right/bottom. The loop selector pane also lets you reorder loops (and of course you can re-order cels in the cel selector pane).
- Fixed a number of bugs (striked out below)
- SCI1 sound is... functional. You can import a MIDI file, add it to the game, and add cues and loop points. I added the SCI0 death sound to the SCI1 template game, and it sounds pretty bad! So things are still kind of messed up. Other midi files I've tried sound pretty good though.
- you can preview palette cycling in the edit palette dialog (for pics)
- improved the selection rect in the palette editor
- I tried to get gif image sequences to import - it worked fine for most gifs, but for some reason not those exported from SV.exe! The library I'm using to load them loses all palette and indexed/color information for those gifs.
- support for extended char sets in fonts (previously it was locked to 128 characters, like SCI0 requires)
- copy-paste in VGA views was pretty busted, it is now working properly
-
Editing Pallette 999...
I added a row of colors to pallette 999, basically I needed the tealish colors from sci0. I added the colors to the pallette. Marked each one as used and fixed. However, neither an existing view or new view displays the new colors added to the pallette until scicomp has been closed and reopened again.
Not that this is a huge deal, as the colors do show up at that point. It was just a bit unexpected that the pallette wasn't reloaded at the time that the view was opened for editing.
However, when using a view with the new color. The color does not come out right.... The Navy colored floor under ego, is supposed to be the solid cyan view.
Using the add after cel button, results in the program crashing. View 0, cel 0 selected. Currently using windows 8.1
-
Can you try the latest version? That looks like the first v3 version I put out.
(Although I don't think any of those bugs have been fixed. )
Regarding the color not coming out right in the interpreter - does the view have an embedded palette? What does the palette for the pic look like?
And wow, things look bad in high DPI... :'(
-
I thought I was in the newest one... re-downloaded 3.0.0.2 and confirmed. The same issues as listed, except this time instead of Navy the in game color was one of the grays.
There is not an embedded palette, just pal.999 with the cyan color added to it via the palette editor.
-
I was asking about the pic palette. If the pic has a palette, the colors will override those in the global palette. Can you show the background, and its palette?
Here's how I was able to get this to work:
Also, if you need to copy your cyan extension to other palettes in the game, you can use the "export range" feature of the palette editor, and then "import".
-
Ahh, I see. So here is the pic palette.
So what is happening then is that the view isn't really looking at the color that is saved in the views palette, but moreso the position. Since that position is actually gray in the pic palette then it is placing that color there instead of the color in the views palette.
* and with that bit of info in mind, the view now appears as I would expect. Thanks for the info.
-
Finally home from touring now, playing around with the template game. I was wondering if there could be another option for the preview cels in the Picture editor on the right (or possibly the editor window itself). Is it possible to preview a 4:3 version of the picture? I ask because of the 4:3 nature of the 320x200 resolution. All of Sierra's games at the time used that aspect ratio with rectangular pixels instead of square. Not a big deal, just a request. I can work around it for now but it'd make for quicker and easier work.
Actually, an option to import images with a checkbox to convert (stretch) to a 4:3 ratio would be nice as well. It'd lose data, but would be more accurate to the way the engine treats that resolution. Or maybe make it a radio selection between Scale Image to Fit (4:3) and Scale Image to Fit (16:9).
Speaking of which, if we're going to be using custom artwork for sprites and such, do we want to create 4:3-friendly (rectangular pixel) sprites/backgrounds/cursors or modern monitor-friendly 16:9 (square pixel) assets? It'd be easier to treat it all as square pixels, but we'd have to really recreate the assets from scratch instead of basing them off of Sierra game assets as none of them were created with 16:9 in mind.
-
I can see how that would be useful for editing old Sierra games, but for new stuff it seems to make more sense to use square pixels (even Scumm and DosBOX use square pixels by default, right?). And honestly, I'm so used to playing/seeing the Sierra games "squished" that they look weird when they're not squished.
-
Fair enough. I'm probably alone in this, but if anyone is curious as to how to transform your backgrounds to be compatible with a 4:3 resolution, open it up in an image editor and enlarge the canvas size (not resize) to 320x227 THEN resize down to 320x190 (make sure maintain aspect ratio is not selected). This actually gives you more "room" in your background, but less pixels if that makes sense. You can do it with sprites, too. The difference is about a 120% increase in height.
On the other hand, having a widescreen resolution in an SCI game is kind of an awesome fluke due to the way DOS games used to treat pixels. :D
-
Am I incorrect in remembering some functions in the Picture editor command list where you can not only copy and paste commands and move them around the drawing area, but also mirror/flip and stretch/resize them? I know you can rotate but I seem to distinctly remember at least mirroring commands...
-
It seems that the MIDI device selection doesn't persist after clicking OK in the Preferences menu. There are four MIDI devices on my list and when I try to select one other than the first on the list it just resets after opening Preferences again. I can't listen to any Sounds properly as a result.
Also, I have two other MIDI devices that aren't being listed in SCI Companion for some reason...However, in other programs they sometimes give odd names with Chinese characters. Maybe that's why? Never mind, figured this part out. Choosing alternate MIDI devices still doesn't persist after selecting, though.
-
I apologize for all the back to back posts, I have another feature request. Is it possible that you can add the Length in time (MM:SS) for sound resources in the resource detail list browser?
-
Am I incorrect in remembering some functions in the Picture editor command list where you can not only copy and paste commands and move them around the drawing area, but also mirror/flip and stretch/resize them? I know you can rotate but I seem to distinctly remember at least mirroring commands...
You can stretch them with the arrow keys and rotate/flip them with the numpad (I had to look at the code to remember this).
-
I apologize for all the back to back posts, I have another feature request. Is it possible that you can add the Length in time (MM:SS) for sound resources in the resource detail list browser?
So, that would require actually opening/decoding the resource. Which is a relatively slow operation, which means I'd need to spawn a background thread to do that (like I do for view and pic resources). How important is this? Is showing it in the preview pane sufficient, or are you needing to sort by this in the view or something?
-
You can stretch them with the arrow keys and rotate/flip them with the numpad (I had to look at the code to remember this).
Right! Thank you!!
So, that would require actually opening/decoding the resource. Which is a relatively slow operation, which means I'd need to spawn a background thread to do that (like I do for view and pic resources). How important is this? Is showing it in the preview pane sufficient, or are you needing to sort by this in the view or something?
Ah I see. That makes sense. Yeah, I was thinking of sorting through the list, but that's no big deal. If it slows the operation then don't worry about it. Preview pane will suffice. :) There's still the size field which is fairly close to the same thing anyway.
-
One little glitch which is not really a breaker in any way, but might be confusing for some. In the View editor on the bottom left where it lists what Loop you're viewing it adds one to the total number of loops (probably because it's not taking into account that it starts at 0). For instance, in the template game for view 995 (which is the control panel view buttons and such) it says "Loop 0/10", which is sort of corrent. There are 10 loops, but it starts from 0 so when you go to the last loop in the view it displays "Loop 9/10".
-
One little glitch which is not really a breaker in any way, but might be confusing for some. In the View editor on the bottom left where it lists what Loop you're viewing it adds one to the total number of loops (probably because it's not taking into account that it starts at 0). For instance, in the template game for view 995 (which is the control panel view buttons and such) it says "Loop 0/10", which is sort of corrent. There are 10 loops, but it starts from 0 so when you go to the last loop in the view it displays "Loop 9/10".
I agree, that's weird. What should it say? I want to convey which loop you're looking at, but also how many loops there are. I don't want to start counting from 1, because in code you refer to them starting at 0.
I should put out a new build later today with some of these fixes (including setting the midi device, which is basically just unimplemented). I just need to track down a painting bug where sometimes switching between the different screens of a pic doesn't update the view.
-
Just let it count by zero. I think people will understand the context. At least, we do, and if somebody doesn't and is going to be programming their own game they should get into the habit of becoming familiar with programming conventions like counting from zero. My two cents.
-
I've updated the SCI Companion at the download link (http://icefallgames.com/Downloads/SCICompanion.zip). Should be version 3.0.0.3 now. Release notes in the first post of this thread.
The download is much bigger because it includes debug symbols. If someone has a debugger and can repro the "Add AFter" cel crash and give me a stack trace, that would be much appreciate!!
-
I can see how that would be useful for editing old Sierra games, but for new stuff it seems to make more sense to use square pixels (even Scumm and DosBOX use square pixels by default, right?). And honestly, I'm so used to playing/seeing the Sierra games "squished" that they look weird when they're not squished.
It is not that DOSBox purposely uses square pixels. With render set to 2x or 3x it is only doubling or tripling the exact same number of X and Y pixels of the original display. This gives it its unnaturally swished aspect over what it was intended to have. It is the sole reason that both DOSBox and ScummVM have the aspect correction option, to give it the same aspect for which the original artists created their graphics.
As noted, it may not make that much difference for new game development, but it is a real obstacle when working with original resources. Just for display having DOSBox set to use aspect correction is enough, but it would be great if the drawing canvases and any polygon tools had a switchable view. I don't know how difficult this would be to implement.
-
I've updated the SCI Companion at the download link (http://icefallgames.com/Downloads/SCICompanion.zip). Should be version 3.0.0.3 now. Release notes in the first post of this thread.
The download is much bigger because it includes debug symbols. If someone has a debugger and can repro the "Add AFter" cel crash and give me a stack trace, that would be much appreciate!!
One problem with that is that simply switching to the Debug configuration in MSVC swaps some parts of the standard library (e.g. STL) to more fault-tolerant versions, so things that crash in the Release configuration do not necessarily do so in the Debug configuration. It should be possible to configure this, but I couldn't tell you how; I don't use MSVC myself.
-
I've updated the SCI Companion at the download link (http://icefallgames.com/Downloads/SCICompanion.zip). Should be version 3.0.0.3 now. Release notes in the first post of this thread.
The download is much bigger because it includes debug symbols. If someone has a debugger and can repro the "Add AFter" cel crash and give me a stack trace, that would be much appreciate!!
For me, the add after crash disappeared with 3.0.0.2. I was still using .1 when I mistakenly reported it a few posts ago. I struck it out once I was using the current version and it was gone as well as unattached the image of the error message I got. Is anyone else still seeing this behavior?
-
One problem with that is that simply switching to the Debug configuration in MSVC swaps some parts of the standard library (e.g. STL) to more fault-tolerant versions, so things that crash in the Release configuration do not necessarily do so in the Debug configuration. It should be possible to configure this, but I couldn't tell you how; I don't use MSVC myself.
Oh, it's a still a "release build", it just has symbol information for debugging. So it should be possible to get a stack trace with function names (assuming they haven't been inlined).
-
It is not that DOSBox purposely uses square pixels. With render set to 2x or 3x it is only doubling or tripling the exact same number of X and Y pixels of the original display. This gives it its unnaturally swished aspect over what it was intended to have. It is the sole reason that both DOSBox and ScummVM have the aspect correction option, to give it the same aspect for which the original artists created their graphics.
As noted, it may not make that much difference for new game development, but it is a real obstacle when working with original resources. Just for display having DOSBox set to use aspect correction is enough, but it would be great if the drawing canvases and any polygon tools had a switchable view. I don't know how difficult this would be to implement.
I agree it would be nice. I know DOSBox/Scumm isn't "purposely" using a 1x1 aspect ratio. If you correct for aspect ratio, things look blurry (in Scumm, at least - which is expected when you're scaling hard-edged "pixel perfect" graphics by fractional amounts. Presumably that's why it's not the default setting?). I can look into it for SCI Companion, but I don't think it would be a trivial change. The code is currently setup for integer zoom levels, changing it to floating point might be a bit destabilizing (i.e. a lot of bugs could come out of it).
[edit:] Ok, I looked into it. No promises, but it looked easier than I had anticipated. In the pic editor, at least, it was pretty trivial to implement.
-
The pic editor would be the main thing to have aspect correction. It will be great if you can do it, but I would have thought that it wound not be trivial. What about the polygon tools?
-
What "polygon tools" are you talking about?
-
I haven't had a chance to play much with the pic editor yet, but looking closer at it I guess you only have an ellipse tool and since I don't see a way to constrained to a circle I guess it is a moot point. A lot of Graphics programs will force their ellipse tool to a circle when the control key is held and a rectangle tool to a square, etc. Such tools might be less useful for raster than vector.
Which brings to mind, you still have the list showing each step in drawing the pic. How useful is this for a raster based pic? Would a simple undo stack make more sense? Obviously you would want it for SCI0 vector pics. Perhaps hiding it based on the resource version?
-
I haven't had a chance to play much with the pic editor yet, but looking closer at it I guess you only have an ellipse tool and since I don't see a way to constrained to a circle I guess it is a moot point. A lot of Graphics programs will force their ellipse tool to a circle when the control key is held and a rectangle tool to a square, etc. Such tools might be less useful for raster than vector.
Which brings to mind, you still have the list showing each step in drawing the pic. How useful is this for a raster based pic? Would a simple undo stack make more sense? Obviously you would want it for SCI0 vector pics. Perhaps hiding it based on the resource version?
Holding shift down snaps the ellipse to a circle in the pic editor. I see your point, you'd want it still to look like circle despite the aspect ratio, right?
The VGA pics aren't completely raster-based. They still support lines and fills for all three screens. The vector tools are rarely used for the visual screen, but are necessary for the priority and control screens. But I agree having the vector commands as the "focus" of the pic editor could be confusing to someone starting out. It might be a reasonable idea to hide the command pane (well, it would be replaced with the path-finding polygon list), and maybe the position slider at the bottom of the pic. There is already an undo stack (all resources support that).
-
Perhaps hold CTRL as well as SHIFT to make the ellipse tool constrain to a perfect circle in a 4:3 aspect rectangular pixel resolution?
EDIT: Another small request: the ability to zoom in and out with the scrollwheel when editing Views and Pictures.
-
EDIT: Another small request: the ability to zoom in and out with the scrollwheel when editing Views and Pictures.
That functionality already exists. Hold down the ctrl-key while using the scrollwheel.
-
Oh! Sorry! Thanks.
Is there some kind of a list somewhere (or can there be) of the updated kernel functions in SCI1.1 and what they do? I'm trying to do a screen transition and it's not working with DrawPic and the new SCI1.1 transitions. Never mind, but a runthrough of some kernel functions would still be welcome.
-
You can glean some insight from the ScummVM code or by looking at usage. But yes, this is kind of documentation is work that needs to be done!
I think screen transitions in SCI1.1 are usually done by setting the style property on the Rm instance.
(define dpOPEN_HCENTER 0) // horizontally open from center
(define dpOPEN_VCENTER 1) // vertically open from center
(define dpOPEN_RIGHT 2) // open from right
(define dpOPEN_LEFT 3) // open from left
(define dpOPEN_BOTTOM 4) // open from bottom
(define dpOPEN_TOP 5) // open from top
(define dpOPEN_EDGECENTER 6) // open from edges to center
(define dpOPEN_CENTEREDGE 7) // open from center to edges
(define dpOPEN_CHECKBOARD 8) // open random checkboard
(define dpOPEN_PIXELATION 9)
(define dpOPEN_FADEPALETTE 10)
(define dpOPEN_SCROLL_RIGHT 11)
(define dpOPEN_SCROLL_LEFT 12)
(define dpOPEN_SCROLL_UP 13)
(define dpOPEN_SCROLL_DOWN 14)
(define dpOPEN_NO_TRANSITION 100)
(define dpANIMATION_BLACKOUT $8000)
-
Feature Request:
Click on a point on the view screen of a pic resource, and it highlight the color and position of the color in the picture's displayed palette.
-
Feature Request:
Click on a point on the view screen of a pic resource, and it highlight the color and position of the color in the picture's displayed palette.
This info is in the status bar when you hover over a pixel. Is that sufficient? What's the scenario where this is useful?
-
That was enough to get me there. I hadn't noticed that in the status bar area.
But the scenario, is that importing agi/sci0, the pic palette is generated. Copy and pasting the view images, the palette comes as close as is defined in 999 without embedding the pic palette instead which I don't really want to do if I don't have to. The blues used in 999 aren't blues used in sci0. I needed to add the blues to the 999 palette, but I wasn't sure which blue and in which position I was looking at in the picture resource. The status bar tells me though, position and rgb. I needed to match up the positions so that the pic resource didn't default the colors to something unexpected.
-
Small bug report. When working with multiple views in their own view editors and switching back and forth, the highlighted selected colours (for left and right click) in the palette of one View editor stays highlighted when switching to other View editors even if those aren't the selected colours in the other editors. The colours that persist follow the last colours that were clicked in a palette. It shows the proper selected colours in the boxes beneath the palette, just not the right highlighted colours in the palette.
-
New version of SCI Companion uploaded (http://icefallgames.com/Downloads/SCICompanion.zip) (3.0.0.4) with support for aspect ratio. Today's release notes in the first post of this thread.
But the scenario, is that importing agi/sci0, the pic palette is generated. Copy and pasting the view images, the palette comes as close as is defined in 999 without embedding the pic palette instead which I don't really want to do if I don't
Can you just set your global palette to have the 16 EGA colors (instead of the 64 colors) and be done with it? Although I guess that might cause some problems with the rest of the template game where text and UI are displayed.
Small bug report. When working with multiple views in their own view editors and switching back and forth, the highlighted selected colours (for left and right click) in the palette of one View editor stays highlighted when switching to other View editors even if those aren't the selected colours in the other editors.
Now fixed in the new version.
-
When adding new loop or cel, the newly added loop or cel does not get focus. It used to in the original scicompanion and apparently I am set in my ways :P
-
I could see being able to click on a point on the pic and having the color at that point be the selected color to apply elsewhere in the pic would be handy, but that is a standard feature in most graphics programs. What you already have should be sufficient if all you need is to know the value.
-
Can you just set your global palette to have the 16 EGA colors (instead of the 64 colors) and be done with it? Although I guess that might cause some problems with the rest of the template game where text and UI are displayed.
I have gone ahead and added the 16 colors to the 999 palette. It will take a bit of work to re-import the pics and the views, but it seems like a better idea at this point to go ahead and get that taken care of going forward. I don't know if anyone else wants it but I have attached the pal file here. If you are planning to convert any of your current projects over, this may come in very handy.
-
Also, in order for UI to show up correctly, you can probably adjust the values in the globalpalettes.sc file (it may very well already be fine)
In fact, it looks like almost all of them are unused. I think only global151, gLowLightColor and global159 are used in the template game. I'll remove the rest from the template game. And I'll rename the file/procedure SetGlobalColors or SetFixedColors or something, to more accurately represent what I think this is.
-
Also, on a similar note to cels and loops not getting focus. When deleting or cropping in the pic editor, companion loses the position that it was at.
-
Don't forget to add the poly variables to the sci.sh file.
//*************************************
// Polygon Types
//*************************************
(define POLY_TOTAL_ACCESS 0)
(define POLY_NEAREST_ACCESS 1)
(define POLY_BARRED_ACCESS 2)
(define POLY_CONTAINED_ACCESS 3)
//************************************
-
The polygon def'ns have been in the header for a few iterations of SCI Companion now...
// Polygon types
(define PTotalAccess 0)
(define PNearestAccess 1)
(define PBarredAccess 2)
(define PContainedAccess 3)
-
Ah, I used the defines that I listed. No wonder it would fail every new iteration ;)
*Edit
Ok, my scripts are all squared away and we are on the same page now.
-
I've discovered that it's not just deleting scripts that's a problem but other resources as well. I tried deleting an extraneous MSG and it keeps popping back, even though it's not there, and points to the next resource instead when you try to open it.
-
I've discovered that it's not just deleting scripts that's a problem but other resources as well. I tried deleting an extraneous MSG and it keeps popping back, even though it's not there, and points to the next resource instead when you try to open it.
I'm not able to reproduce this issue. If you create a new game, create a new message resource, save some stuff into it, then delete it, does it happen?
-
And rebuild resources. I had to recreate it to get the numbers to point to the proper resources again.
-
I'm still not seeing this. Can you provide clear repro steps from creating a new game? (including which resource number you're using, etc..)
Also, when it's in this state, can you dump the resource map and attach it here? (The files that appear when you do Game->Version detector->View resource map)
-
All I have to do is delete any resource and the rebuild resources and the deleted resource pops back up but points to the next highest resource number. For example, I've just tried this with palettes. I have two palettes. 998 and 999. 998 is the SQ5 palette and 999 is the KQ5 palette. I kept the SQ5 one just in case. I decided that I didn't need it anymore and deleted it. After rebuilding resources 998 popped back but its number is set to 999 (as opposed to its name) and when opening either palette it opens palette 999 for editing. If I delete 998 again and rebuild resources nothing exists because I deleted 999 so it deleted both entries.
This brings up another bug that I've also run into before. When I try to create a new palette and attempt to save it to the game I can set any number I want, but the package number is set to 63 and can't be changed (it's greyed out). Attempting to save to a resource number fails because it complains that it can't find resource package 64. I have to actually edit an existing palette (or any resource) and then save as a new number to create new resources from scratch. Creating new blank resources doesn't allow saving.
Here's a resource map dump from a brand new game just after I've added and deleted a 998.pal resource and then rebuilt resources (which brings 998 back in name, but its number is set to 999 in the list):
Resource map for New Game
Type: 80 Offset: 002b
Type: 81 Offset: 0080
Type: 82 Offset: 0099
Type: 83 Offset: 0265
Type: 84 Offset: 0283
Type: 86 Offset: 0292
Type: 87 Offset: 02a6
Type: 89 Offset: 02bf
Type: 8b Offset: 02d3
Type: 8f Offset: 02dd
Type: 90 Offset: 0305
Type: 91 Offset: 030a
Type: ff Offset: 04e0
0027: 00 00 00 00 00 View(0, 0) offset: 00000000
0027: 0D 00 25 1E 00 View(13, 0) offset: 00003C4A
0027: 84 03 1D 3D 00 View(900, 0) offset: 00007A3A
0027: D4 03 8C 3E 00 View(980, 0) offset: 00007D18
0027: D5 03 93 42 00 View(981, 0) offset: 00008526
0027: D6 03 DA 42 00 View(982, 0) offset: 000085B4
0027: D7 03 24 43 00 View(983, 0) offset: 00008648
0027: D8 03 F0 43 00 View(984, 0) offset: 000087E0
0027: DD 03 C0 44 00 View(989, 0) offset: 00008980
0027: DE 03 14 45 00 View(990, 0) offset: 00008A28
0027: DF 03 9F 4B 00 View(991, 0) offset: 0000973E
0027: E3 03 B3 4F 00 View(995, 0) offset: 00009F66
0027: E4 03 3B 65 00 View(996, 0) offset: 0000CA76
0027: E5 03 7D 65 00 View(997, 0) offset: 0000CAFA
0027: E7 03 0B 66 00 View(999, 0) offset: 0000CC16
0027: D0 07 59 66 00 View(2000, 0) offset: 0000CCB2
0027: 33 08 A0 6E 00 View(2099, 0) offset: 0000DD40
0027: 00 00 A0 74 00 Pic(0, 0) offset: 0000E940
0027: 1F 00 D2 74 00 Pic(31, 0) offset: 0000E9A4
0027: 6E 00 50 EB 00 Pic(110, 0) offset: 0001D6A0
0027: C8 00 F5 64 01 Pic(200, 0) offset: 0002C9EA
0027: 2C 01 9F 6B 01 Pic(300, 0) offset: 0002D73E
0027: 00 00 D2 8C 01 Script(0, 0) offset: 000319A4
0027: 0B 00 67 97 01 Script(11, 0) offset: 00032ECE
0027: 0C 00 BB 97 01 Script(12, 0) offset: 00032F76
0027: 0D 00 0E 98 01 Script(13, 0) offset: 0003301C
0027: 0E 00 26 98 01 Script(14, 0) offset: 0003304C
0027: 0F 00 9C 98 01 Script(15, 0) offset: 00033138
0027: 10 00 21 9A 01 Script(16, 0) offset: 00033442
0027: 11 00 44 9B 01 Script(17, 0) offset: 00033688
0027: 12 00 B9 9D 01 Script(18, 0) offset: 00033B72
0027: 13 00 A7 9F 01 Script(19, 0) offset: 00033F4E
0027: 14 00 78 A1 01 Script(20, 0) offset: 000342F0
0027: 15 00 6F A2 01 Script(21, 0) offset: 000344DE
0027: 16 00 B7 A2 01 Script(22, 0) offset: 0003456E
0027: 18 00 B3 A4 01 Script(24, 0) offset: 00034966
0027: 19 00 AF A7 01 Script(25, 0) offset: 00034F5E
0027: 1A 00 75 A9 01 Script(26, 0) offset: 000352EA
0027: 1B 00 09 AD 01 Script(27, 0) offset: 00035A12
0027: 1E 00 3E AE 01 Script(30, 0) offset: 00035C7C
0027: 20 00 42 B3 01 Script(32, 0) offset: 00036684
0027: 64 00 1D B4 01 Script(100, 0) offset: 0003683A
0027: 69 00 76 B5 01 Script(105, 0) offset: 00036AEC
0027: 6E 00 AF B5 01 Script(110, 0) offset: 00036B5E
0027: CD 00 04 B6 01 Script(205, 0) offset: 00036C08
0027: FF 00 D0 B6 01 Script(255, 0) offset: 00036DA0
0027: 6D 03 86 BC 01 Script(877, 0) offset: 0003790C
0027: 99 03 AB BE 01 Script(921, 0) offset: 00037D56
0027: 9A 03 B4 C3 01 Script(922, 0) offset: 00038768
0027: 9B 03 0B C6 01 Script(923, 0) offset: 00038C16
0027: 9C 03 9D C8 01 Script(924, 0) offset: 0003913A
0027: 9D 03 73 CA 01 Script(925, 0) offset: 000394E6
0027: 9E 03 86 CC 01 Script(926, 0) offset: 0003990C
0027: 9F 03 69 CD 01 Script(927, 0) offset: 00039AD2
0027: A0 03 D0 CF 01 Script(928, 0) offset: 00039FA0
0027: A1 03 43 D6 01 Script(929, 0) offset: 0003AC86
0027: A2 03 AF D7 01 Script(930, 0) offset: 0003AF5E
0027: A4 03 7B D8 01 Script(932, 0) offset: 0003B0F6
0027: A5 03 3B D9 01 Script(933, 0) offset: 0003B276
0027: A6 03 05 DA 01 Script(934, 0) offset: 0003B40A
0027: A7 03 D2 DB 01 Script(935, 0) offset: 0003B7A4
0027: A8 03 3F DC 01 Script(936, 0) offset: 0003B87E
0027: A9 03 DB DD 01 Script(937, 0) offset: 0003BBB6
0027: AA 03 83 E6 01 Script(938, 0) offset: 0003CD06
0027: AB 03 FE E6 01 Script(939, 0) offset: 0003CDFC
0027: AD 03 5C E7 01 Script(941, 0) offset: 0003CEB8
0027: AE 03 08 E8 01 Script(942, 0) offset: 0003D010
0027: AF 03 BA E8 01 Script(943, 0) offset: 0003D174
0027: B0 03 C4 F5 01 Script(944, 0) offset: 0003EB88
0027: B1 03 AB F6 01 Script(945, 0) offset: 0003ED56
0027: B2 03 A5 F7 01 Script(946, 0) offset: 0003EF4A
0027: B3 03 E3 F7 01 Script(947, 0) offset: 0003EFC6
0027: B4 03 CA 0A 02 Script(948, 0) offset: 00041594
0027: B5 03 5E 11 02 Script(949, 0) offset: 000422BC
0027: B6 03 BE 11 02 Script(950, 0) offset: 0004237C
0027: B7 03 5D 14 02 Script(951, 0) offset: 000428BA
0027: B9 03 B0 14 02 Script(953, 0) offset: 00042960
0027: BA 03 2A 15 02 Script(954, 0) offset: 00042A54
0027: BB 03 90 17 02 Script(955, 0) offset: 00042F20
0027: BC 03 0F 18 02 Script(956, 0) offset: 0004301E
0027: BE 03 49 18 02 Script(958, 0) offset: 00043092
0027: C1 03 71 18 02 Script(961, 0) offset: 000430E2
0027: C3 03 28 19 02 Script(963, 0) offset: 00043250
0027: C4 03 67 19 02 Script(964, 0) offset: 000432CE
0027: C7 03 FF 19 02 Script(967, 0) offset: 000433FE
0027: C8 03 4F 1A 02 Script(968, 0) offset: 0004349E
0027: C9 03 03 1C 02 Script(969, 0) offset: 00043806
0027: CA 03 3A 1C 02 Script(970, 0) offset: 00043874
0027: CB 03 A3 1C 02 Script(971, 0) offset: 00043946
0027: CC 03 63 1D 02 Script(972, 0) offset: 00043AC6
0027: CD 03 ED 1D 02 Script(973, 0) offset: 00043BDA
0027: CF 03 3B 1F 02 Script(975, 0) offset: 00043E76
0027: D0 03 EC 1F 02 Script(976, 0) offset: 00043FD8
0027: D1 03 9B 21 02 Script(977, 0) offset: 00044336
0027: D2 03 75 23 02 Script(978, 0) offset: 000446EA
0027: D4 03 7B 25 02 Script(980, 0) offset: 00044AF6
0027: D5 03 C7 25 02 Script(981, 0) offset: 00044B8E
0027: D6 03 E1 26 02 Script(982, 0) offset: 00044DC2
0027: D7 03 7F 27 02 Script(983, 0) offset: 00044EFE
0027: D8 03 48 28 02 Script(984, 0) offset: 00045090
0027: D9 03 DB 29 02 Script(985, 0) offset: 000453B6
0027: DA 03 8D 2A 02 Script(986, 0) offset: 0004551A
0027: DB 03 30 2B 02 Script(987, 0) offset: 00045660
0027: DC 03 E7 2C 02 Script(988, 0) offset: 000459CE
0027: DD 03 5F 2E 02 Script(989, 0) offset: 00045CBE
0027: DE 03 E0 2F 02 Script(990, 0) offset: 00045FC0
0027: DF 03 95 35 02 Script(991, 0) offset: 00046B2A
0027: E0 03 59 37 02 Script(992, 0) offset: 00046EB2
0027: E1 03 C9 39 02 Script(993, 0) offset: 00047392
0027: E2 03 A3 3A 02 Script(994, 0) offset: 00047546
0027: E3 03 F6 42 02 Script(995, 0) offset: 000485EC
0027: E4 03 34 4A 02 Script(996, 0) offset: 00049468
0027: E6 03 46 4C 02 Script(998, 0) offset: 0004988C
0027: E7 03 95 53 02 Script(999, 0) offset: 0004A72A
0027: 0A 00 60 58 02 Text(10, 0) offset: 0004B0C0
0027: C9 00 BE 58 02 Text(201, 0) offset: 0004B17C
0027: CC 01 C7 58 02 Text(460, 0) offset: 0004B18E
0027: AF 03 D0 58 02 Text(943, 0) offset: 0004B1A0
0027: B8 03 1C 59 02 Text(952, 0) offset: 0004B238
0027: E7 03 52 59 02 Text(999, 0) offset: 0004B2A4
0027: 2D 00 6E 59 02 Sound(45, 0) offset: 0004B2DC
0027: E8 03 E2 5B 02 Sound(1000, 0) offset: 0004B7C4
0027: E9 03 14 5C 02 Sound(1001, 0) offset: 0004B828
0027: E2 03 7C 61 02 Vocab(994, 0) offset: 0004C2F8
0027: E4 03 B8 61 02 Vocab(996, 0) offset: 0004C370
0027: E5 03 DF 62 02 Vocab(997, 0) offset: 0004C5BE
0027: E6 03 DB 80 02 Vocab(998, 0) offset: 000501B6
0027: 00 00 55 82 02 Font(0, 0) offset: 000504AA
0027: 04 00 C4 85 02 Font(4, 0) offset: 00050B88
0027: E7 03 4D 88 02 Font(999, 0) offset: 0005109A
0027: 45 06 B3 8A 02 Font(1605, 0) offset: 00051566
0027: 3A 08 92 8D 02 Font(2106, 0) offset: 00051B24
0027: 01 00 01 91 02 Patch(1, 0) offset: 00052202
0027: 03 00 38 B7 02 Patch(3, 0) offset: 00056E70
0027: 04 00 C0 C1 02 Patch(4, 0) offset: 00058380
0027: 65 00 54 C4 02 Patch(101, 0) offset: 000588A8
0027: E6 03 6E C5 02 Palette(998, 0) offset: 00058ADC
0027: E7 03 03 C6 02 Palette(999, 0) offset: 00058C06
0027: 00 00 98 C6 02 Message(0, 0) offset: 00058D30
0027: 0D 00 31 CD 02 Message(13, 0) offset: 00059A62
0027: 0F 00 63 CD 02 Message(15, 0) offset: 00059AC6
0027: 14 00 89 CE 02 Message(20, 0) offset: 00059D12
0027: 69 00 A1 CE 02 Message(105, 0) offset: 00059D42
0027: 6E 00 BF CE 02 Message(110, 0) offset: 00059D7E
0027: DE 03 10 CF 02 Message(990, 0) offset: 00059E20
0027: E2 03 8E D0 02 Message(994, 0) offset: 0005A11C
0027: FF FF 57 D1 02 Map(65535, 0) offset: 0005A2AE
0027: 00 00 61 D1 02 Heap(0, 0) offset: 0005A2C2
0027: 0B 00 31 D5 02 Heap(11, 0) offset: 0005AA62
0027: 0C 00 4A D5 02 Heap(12, 0) offset: 0005AA94
0027: 0D 00 53 D5 02 Heap(13, 0) offset: 0005AAA6
0027: 0E 00 6B D5 02 Heap(14, 0) offset: 0005AAD6
0027: 0F 00 93 D5 02 Heap(15, 0) offset: 0005AB26
0027: 10 00 4B D7 02 Heap(16, 0) offset: 0005AE96
0027: 11 00 79 D7 02 Heap(17, 0) offset: 0005AEF2
0027: 12 00 AF D7 02 Heap(18, 0) offset: 0005AF5E
0027: 13 00 25 D8 02 Heap(19, 0) offset: 0005B04A
0027: 14 00 83 D8 02 Heap(20, 0) offset: 0005B106
0027: 15 00 6C DA 02 Heap(21, 0) offset: 0005B4D8
0027: 16 00 8C DA 02 Heap(22, 0) offset: 0005B518
0027: 18 00 E9 DA 02 Heap(24, 0) offset: 0005B5D2
0027: 19 00 1A DD 02 Heap(25, 0) offset: 0005BA34
0027: 1A 00 4C DD 02 Heap(26, 0) offset: 0005BA98
0027: 1B 00 9A DD 02 Heap(27, 0) offset: 0005BB34
0027: 1E 00 DC DD 02 Heap(30, 0) offset: 0005BBB8
0027: 20 00 C3 DE 02 Heap(32, 0) offset: 0005BD86
0027: 64 00 EF DE 02 Heap(100, 0) offset: 0005BDDE
0027: 69 00 54 DF 02 Heap(105, 0) offset: 0005BEA8
0027: 6E 00 9C DF 02 Heap(110, 0) offset: 0005BF38
0027: CD 00 1F E0 02 Heap(205, 0) offset: 0005C03E
0027: FF 00 4C E0 02 Heap(255, 0) offset: 0005C098
0027: 6D 03 B9 E0 02 Heap(877, 0) offset: 0005C172
0027: 99 03 F2 E0 02 Heap(921, 0) offset: 0005C1E4
0027: 9A 03 1F E1 02 Heap(922, 0) offset: 0005C23E
0027: 9B 03 A5 E1 02 Heap(923, 0) offset: 0005C34A
0027: 9C 03 24 E2 02 Heap(924, 0) offset: 0005C448
0027: 9D 03 9B E2 02 Heap(925, 0) offset: 0005C536
0027: 9E 03 FD E2 02 Heap(926, 0) offset: 0005C5FA
0027: 9F 03 25 E3 02 Heap(927, 0) offset: 0005C64A
0027: A0 03 49 E3 02 Heap(928, 0) offset: 0005C692
0027: A1 03 03 E4 02 Heap(929, 0) offset: 0005C806
0027: A2 03 42 E4 02 Heap(930, 0) offset: 0005C884
0027: A4 03 71 E4 02 Heap(932, 0) offset: 0005C8E2
0027: A5 03 A0 E4 02 Heap(933, 0) offset: 0005C940
0027: A6 03 BE E4 02 Heap(934, 0) offset: 0005C97C
0027: A7 03 F8 E4 02 Heap(935, 0) offset: 0005C9F0
0027: A8 03 2B E5 02 Heap(936, 0) offset: 0005CA56
0027: A9 03 94 E5 02 Heap(937, 0) offset: 0005CB28
0027: AA 03 DF E5 02 Heap(938, 0) offset: 0005CBBE
0027: AB 03 FD E5 02 Heap(939, 0) offset: 0005CBFA
0027: AD 03 18 E6 02 Heap(941, 0) offset: 0005CC30
0027: AE 03 4E E6 02 Heap(942, 0) offset: 0005CC9C
0027: AF 03 6C E6 02 Heap(943, 0) offset: 0005CCD8
0027: B0 03 49 EA 02 Heap(944, 0) offset: 0005D492
0027: B1 03 79 EA 02 Heap(945, 0) offset: 0005D4F2
0027: B2 03 A5 EA 02 Heap(946, 0) offset: 0005D54A
0027: B3 03 C0 EA 02 Heap(947, 0) offset: 0005D580
0027: B4 03 F6 F3 02 Heap(948, 0) offset: 0005E7EC
0027: B5 03 B0 F8 02 Heap(949, 0) offset: 0005F160
0027: B6 03 DA F8 02 Heap(950, 0) offset: 0005F1B4
0027: B7 03 3C F9 02 Heap(951, 0) offset: 0005F278
0027: B8 03 67 F9 02 Heap(952, 0) offset: 0005F2CE
0027: B9 03 2C FB 02 Heap(953, 0) offset: 0005F658
0027: BA 03 55 FB 02 Heap(954, 0) offset: 0005F6AA
0027: BB 03 C7 FB 02 Heap(955, 0) offset: 0005F78E
0027: BC 03 F0 FB 02 Heap(956, 0) offset: 0005F7E0
0027: BE 03 11 FC 02 Heap(958, 0) offset: 0005F822
0027: C1 03 1A FC 02 Heap(961, 0) offset: 0005F834
0027: C3 03 39 FC 02 Heap(963, 0) offset: 0005F872
0027: C4 03 62 FC 02 Heap(964, 0) offset: 0005F8C4
0027: C7 03 89 FC 02 Heap(967, 0) offset: 0005F912
0027: C8 03 AF FC 02 Heap(968, 0) offset: 0005F95E
0027: C9 03 D3 FC 02 Heap(969, 0) offset: 0005F9A6
0027: CA 03 ED FC 02 Heap(970, 0) offset: 0005F9DA
0027: CB 03 14 FD 02 Heap(971, 0) offset: 0005FA28
0027: CC 03 3C FD 02 Heap(972, 0) offset: 0005FA78
0027: CD 03 63 FD 02 Heap(973, 0) offset: 0005FAC6
0027: CE 03 8B FD 02 Heap(974, 0) offset: 0005FB16
0027: CF 03 9F FD 02 Heap(975, 0) offset: 0005FB3E
0027: D0 03 C4 FD 02 Heap(976, 0) offset: 0005FB88
0027: D1 03 1C FE 02 Heap(977, 0) offset: 0005FC38
0027: D2 03 5C FE 02 Heap(978, 0) offset: 0005FCB8
0027: D4 03 B0 FE 02 Heap(980, 0) offset: 0005FD60
0027: D5 03 D8 FE 02 Heap(981, 0) offset: 0005FDB0
0027: D6 03 25 FF 02 Heap(982, 0) offset: 0005FE4A
0027: D7 03 2E FF 02 Heap(983, 0) offset: 0005FE5C
0027: D8 03 81 FF 02 Heap(984, 0) offset: 0005FF02
0027: D9 03 CC FF 02 Heap(985, 0) offset: 0005FF98
0027: DA 03 E4 FF 02 Heap(986, 0) offset: 0005FFC8
0027: DB 03 10 00 03 Heap(987, 0) offset: 00060020
0027: DC 03 B6 00 03 Heap(988, 0) offset: 0006016C
0027: DD 03 04 01 03 Heap(989, 0) offset: 00060208
0027: DE 03 29 01 03 Heap(990, 0) offset: 00060252
0027: DF 03 5E 03 03 Heap(991, 0) offset: 000606BC
0027: E0 03 AF 03 03 Heap(992, 0) offset: 0006075E
0027: E1 03 71 04 03 Heap(993, 0) offset: 000608E2
0027: E2 03 8C 04 03 Heap(994, 0) offset: 00060918
0027: E3 03 20 06 03 Heap(995, 0) offset: 00060C40
0027: E4 03 85 06 03 Heap(996, 0) offset: 00060D0A
0027: E6 03 D7 06 03 Heap(998, 0) offset: 00060DAE
0027: E7 03 A4 07 03 Heap(999, 0) offset: 00060F48
-
This brings up another bug that I've also run into before. When I try to create a new palette and attempt to save it to the game I can set any number I want, but the package number is set to 63 and can't be changed (it's greyed out). Attempting to save to a resource number fails because it complains that it can't find resource package 64. I have to actually edit an existing palette (or any resource) and then save as a new number to create new resources from scratch. Creating new blank resources doesn't allow saving.
Yeah, that's a bad bug. I've found the problem, it should be fixed in the next version (this is *only* a problem with new palettes, right? I can't repro this for any other resources).
Here's a resource map dump from a brand new game just after I've added and deleted a 998.pal resource and then rebuilt resources (which brings 998 back in name, but its number is set to 999 in the list):
Unfortunately I'm still not able to repro this :(. Is anyone else other than MusicallyInspired?
I'd like to narrow down if the problem happens after deleting the item or after rebuilding resources. I know the bad item only re-appears after rebuilding resources, but that's just because we reload the resource view. I want to know if the resource.map file is corrupt earlier. Can you attach the resource.map.text thing for just after you delete the 998 resource?
-
Here it is after deleting but before rebuilding. It is showing two entries still for Palettes, but this time at the same offset:
Resource map for New Game2
Type: 80 Offset: 002b
Type: 81 Offset: 0080
Type: 82 Offset: 0099
Type: 83 Offset: 0265
Type: 84 Offset: 0283
Type: 86 Offset: 0292
Type: 87 Offset: 02a6
Type: 89 Offset: 02bf
Type: 8b Offset: 02d3
Type: 8f Offset: 02dd
Type: 90 Offset: 0305
Type: 91 Offset: 030a
Type: ff Offset: 04e0
0027: 00 00 00 00 00 View(0, 0) offset: 00000000
0027: 0D 00 25 1E 00 View(13, 0) offset: 00003C4A
0027: 84 03 1D 3D 00 View(900, 0) offset: 00007A3A
0027: D4 03 8C 3E 00 View(980, 0) offset: 00007D18
0027: D5 03 93 42 00 View(981, 0) offset: 00008526
0027: D6 03 DA 42 00 View(982, 0) offset: 000085B4
0027: D7 03 24 43 00 View(983, 0) offset: 00008648
0027: D8 03 F0 43 00 View(984, 0) offset: 000087E0
0027: DD 03 C0 44 00 View(989, 0) offset: 00008980
0027: DE 03 14 45 00 View(990, 0) offset: 00008A28
0027: DF 03 9F 4B 00 View(991, 0) offset: 0000973E
0027: E3 03 B3 4F 00 View(995, 0) offset: 00009F66
0027: E4 03 3B 65 00 View(996, 0) offset: 0000CA76
0027: E5 03 7D 65 00 View(997, 0) offset: 0000CAFA
0027: E7 03 0B 66 00 View(999, 0) offset: 0000CC16
0027: D0 07 59 66 00 View(2000, 0) offset: 0000CCB2
0027: 33 08 A0 6E 00 View(2099, 0) offset: 0000DD40
0027: 00 00 A0 74 00 Pic(0, 0) offset: 0000E940
0027: 1F 00 D2 74 00 Pic(31, 0) offset: 0000E9A4
0027: 6E 00 50 EB 00 Pic(110, 0) offset: 0001D6A0
0027: C8 00 F5 64 01 Pic(200, 0) offset: 0002C9EA
0027: 2C 01 9F 6B 01 Pic(300, 0) offset: 0002D73E
0027: 00 00 D2 8C 01 Script(0, 0) offset: 000319A4
0027: 0B 00 67 97 01 Script(11, 0) offset: 00032ECE
0027: 0C 00 BB 97 01 Script(12, 0) offset: 00032F76
0027: 0D 00 0E 98 01 Script(13, 0) offset: 0003301C
0027: 0E 00 26 98 01 Script(14, 0) offset: 0003304C
0027: 0F 00 9C 98 01 Script(15, 0) offset: 00033138
0027: 10 00 21 9A 01 Script(16, 0) offset: 00033442
0027: 11 00 44 9B 01 Script(17, 0) offset: 00033688
0027: 12 00 B9 9D 01 Script(18, 0) offset: 00033B72
0027: 13 00 A7 9F 01 Script(19, 0) offset: 00033F4E
0027: 14 00 78 A1 01 Script(20, 0) offset: 000342F0
0027: 15 00 6F A2 01 Script(21, 0) offset: 000344DE
0027: 16 00 B7 A2 01 Script(22, 0) offset: 0003456E
0027: 18 00 B3 A4 01 Script(24, 0) offset: 00034966
0027: 19 00 AF A7 01 Script(25, 0) offset: 00034F5E
0027: 1A 00 75 A9 01 Script(26, 0) offset: 000352EA
0027: 1B 00 09 AD 01 Script(27, 0) offset: 00035A12
0027: 1E 00 3E AE 01 Script(30, 0) offset: 00035C7C
0027: 20 00 42 B3 01 Script(32, 0) offset: 00036684
0027: 64 00 1D B4 01 Script(100, 0) offset: 0003683A
0027: 69 00 76 B5 01 Script(105, 0) offset: 00036AEC
0027: 6E 00 AF B5 01 Script(110, 0) offset: 00036B5E
0027: CD 00 04 B6 01 Script(205, 0) offset: 00036C08
0027: FF 00 D0 B6 01 Script(255, 0) offset: 00036DA0
0027: 6D 03 86 BC 01 Script(877, 0) offset: 0003790C
0027: 99 03 AB BE 01 Script(921, 0) offset: 00037D56
0027: 9A 03 B4 C3 01 Script(922, 0) offset: 00038768
0027: 9B 03 0B C6 01 Script(923, 0) offset: 00038C16
0027: 9C 03 9D C8 01 Script(924, 0) offset: 0003913A
0027: 9D 03 73 CA 01 Script(925, 0) offset: 000394E6
0027: 9E 03 86 CC 01 Script(926, 0) offset: 0003990C
0027: 9F 03 69 CD 01 Script(927, 0) offset: 00039AD2
0027: A0 03 D0 CF 01 Script(928, 0) offset: 00039FA0
0027: A1 03 43 D6 01 Script(929, 0) offset: 0003AC86
0027: A2 03 AF D7 01 Script(930, 0) offset: 0003AF5E
0027: A4 03 7B D8 01 Script(932, 0) offset: 0003B0F6
0027: A5 03 3B D9 01 Script(933, 0) offset: 0003B276
0027: A6 03 05 DA 01 Script(934, 0) offset: 0003B40A
0027: A7 03 D2 DB 01 Script(935, 0) offset: 0003B7A4
0027: A8 03 3F DC 01 Script(936, 0) offset: 0003B87E
0027: A9 03 DB DD 01 Script(937, 0) offset: 0003BBB6
0027: AA 03 83 E6 01 Script(938, 0) offset: 0003CD06
0027: AB 03 FE E6 01 Script(939, 0) offset: 0003CDFC
0027: AD 03 5C E7 01 Script(941, 0) offset: 0003CEB8
0027: AE 03 08 E8 01 Script(942, 0) offset: 0003D010
0027: AF 03 BA E8 01 Script(943, 0) offset: 0003D174
0027: B0 03 C4 F5 01 Script(944, 0) offset: 0003EB88
0027: B1 03 AB F6 01 Script(945, 0) offset: 0003ED56
0027: B2 03 A5 F7 01 Script(946, 0) offset: 0003EF4A
0027: B3 03 E3 F7 01 Script(947, 0) offset: 0003EFC6
0027: B4 03 CA 0A 02 Script(948, 0) offset: 00041594
0027: B5 03 5E 11 02 Script(949, 0) offset: 000422BC
0027: B6 03 BE 11 02 Script(950, 0) offset: 0004237C
0027: B7 03 5D 14 02 Script(951, 0) offset: 000428BA
0027: B9 03 B0 14 02 Script(953, 0) offset: 00042960
0027: BA 03 2A 15 02 Script(954, 0) offset: 00042A54
0027: BB 03 90 17 02 Script(955, 0) offset: 00042F20
0027: BC 03 0F 18 02 Script(956, 0) offset: 0004301E
0027: BE 03 49 18 02 Script(958, 0) offset: 00043092
0027: C1 03 71 18 02 Script(961, 0) offset: 000430E2
0027: C3 03 28 19 02 Script(963, 0) offset: 00043250
0027: C4 03 67 19 02 Script(964, 0) offset: 000432CE
0027: C7 03 FF 19 02 Script(967, 0) offset: 000433FE
0027: C8 03 4F 1A 02 Script(968, 0) offset: 0004349E
0027: C9 03 03 1C 02 Script(969, 0) offset: 00043806
0027: CA 03 3A 1C 02 Script(970, 0) offset: 00043874
0027: CB 03 A3 1C 02 Script(971, 0) offset: 00043946
0027: CC 03 63 1D 02 Script(972, 0) offset: 00043AC6
0027: CD 03 ED 1D 02 Script(973, 0) offset: 00043BDA
0027: CF 03 3B 1F 02 Script(975, 0) offset: 00043E76
0027: D0 03 EC 1F 02 Script(976, 0) offset: 00043FD8
0027: D1 03 9B 21 02 Script(977, 0) offset: 00044336
0027: D2 03 75 23 02 Script(978, 0) offset: 000446EA
0027: D4 03 7B 25 02 Script(980, 0) offset: 00044AF6
0027: D5 03 C7 25 02 Script(981, 0) offset: 00044B8E
0027: D6 03 E1 26 02 Script(982, 0) offset: 00044DC2
0027: D7 03 7F 27 02 Script(983, 0) offset: 00044EFE
0027: D8 03 48 28 02 Script(984, 0) offset: 00045090
0027: D9 03 DB 29 02 Script(985, 0) offset: 000453B6
0027: DA 03 8D 2A 02 Script(986, 0) offset: 0004551A
0027: DB 03 30 2B 02 Script(987, 0) offset: 00045660
0027: DC 03 E7 2C 02 Script(988, 0) offset: 000459CE
0027: DD 03 5F 2E 02 Script(989, 0) offset: 00045CBE
0027: DE 03 E0 2F 02 Script(990, 0) offset: 00045FC0
0027: DF 03 95 35 02 Script(991, 0) offset: 00046B2A
0027: E0 03 59 37 02 Script(992, 0) offset: 00046EB2
0027: E1 03 C9 39 02 Script(993, 0) offset: 00047392
0027: E2 03 A3 3A 02 Script(994, 0) offset: 00047546
0027: E3 03 F6 42 02 Script(995, 0) offset: 000485EC
0027: E4 03 34 4A 02 Script(996, 0) offset: 00049468
0027: E6 03 46 4C 02 Script(998, 0) offset: 0004988C
0027: E7 03 95 53 02 Script(999, 0) offset: 0004A72A
0027: 0A 00 60 58 02 Text(10, 0) offset: 0004B0C0
0027: C9 00 BE 58 02 Text(201, 0) offset: 0004B17C
0027: CC 01 C7 58 02 Text(460, 0) offset: 0004B18E
0027: AF 03 D0 58 02 Text(943, 0) offset: 0004B1A0
0027: B8 03 1C 59 02 Text(952, 0) offset: 0004B238
0027: E7 03 52 59 02 Text(999, 0) offset: 0004B2A4
0027: 2D 00 6E 59 02 Sound(45, 0) offset: 0004B2DC
0027: E8 03 E2 5B 02 Sound(1000, 0) offset: 0004B7C4
0027: E9 03 14 5C 02 Sound(1001, 0) offset: 0004B828
0027: E2 03 7C 61 02 Vocab(994, 0) offset: 0004C2F8
0027: E4 03 B8 61 02 Vocab(996, 0) offset: 0004C370
0027: E5 03 DF 62 02 Vocab(997, 0) offset: 0004C5BE
0027: E6 03 DB 80 02 Vocab(998, 0) offset: 000501B6
0027: 00 00 55 82 02 Font(0, 0) offset: 000504AA
0027: 04 00 C4 85 02 Font(4, 0) offset: 00050B88
0027: E7 03 4D 88 02 Font(999, 0) offset: 0005109A
0027: 45 06 B3 8A 02 Font(1605, 0) offset: 00051566
0027: 3A 08 92 8D 02 Font(2106, 0) offset: 00051B24
0027: 01 00 01 91 02 Patch(1, 0) offset: 00052202
0027: 03 00 38 B7 02 Patch(3, 0) offset: 00056E70
0027: 04 00 C0 C1 02 Patch(4, 0) offset: 00058380
0027: 65 00 54 C4 02 Patch(101, 0) offset: 000588A8
0027: E6 03 6E C5 02 Palette(998, 0) offset: 00058ADC
0027: E7 03 6E C5 02 Palette(999, 0) offset: 00058ADC
0027: 00 00 03 C6 02 Message(0, 0) offset: 00058C06
0027: 0D 00 9C CC 02 Message(13, 0) offset: 00059938
0027: 0F 00 CE CC 02 Message(15, 0) offset: 0005999C
0027: 14 00 F4 CD 02 Message(20, 0) offset: 00059BE8
0027: 69 00 0C CE 02 Message(105, 0) offset: 00059C18
0027: 6E 00 2A CE 02 Message(110, 0) offset: 00059C54
0027: DE 03 7B CE 02 Message(990, 0) offset: 00059CF6
0027: E2 03 F9 CF 02 Message(994, 0) offset: 00059FF2
0027: FF FF C2 D0 02 Map(65535, 0) offset: 0005A184
0027: 00 00 CC D0 02 Heap(0, 0) offset: 0005A198
0027: 0B 00 9C D4 02 Heap(11, 0) offset: 0005A938
0027: 0C 00 B5 D4 02 Heap(12, 0) offset: 0005A96A
0027: 0D 00 BE D4 02 Heap(13, 0) offset: 0005A97C
0027: 0E 00 D6 D4 02 Heap(14, 0) offset: 0005A9AC
0027: 0F 00 FE D4 02 Heap(15, 0) offset: 0005A9FC
0027: 10 00 B6 D6 02 Heap(16, 0) offset: 0005AD6C
0027: 11 00 E4 D6 02 Heap(17, 0) offset: 0005ADC8
0027: 12 00 1A D7 02 Heap(18, 0) offset: 0005AE34
0027: 13 00 90 D7 02 Heap(19, 0) offset: 0005AF20
0027: 14 00 EE D7 02 Heap(20, 0) offset: 0005AFDC
0027: 15 00 D7 D9 02 Heap(21, 0) offset: 0005B3AE
0027: 16 00 F7 D9 02 Heap(22, 0) offset: 0005B3EE
0027: 18 00 54 DA 02 Heap(24, 0) offset: 0005B4A8
0027: 19 00 85 DC 02 Heap(25, 0) offset: 0005B90A
0027: 1A 00 B7 DC 02 Heap(26, 0) offset: 0005B96E
0027: 1B 00 05 DD 02 Heap(27, 0) offset: 0005BA0A
0027: 1E 00 47 DD 02 Heap(30, 0) offset: 0005BA8E
0027: 20 00 2E DE 02 Heap(32, 0) offset: 0005BC5C
0027: 64 00 5A DE 02 Heap(100, 0) offset: 0005BCB4
0027: 69 00 BF DE 02 Heap(105, 0) offset: 0005BD7E
0027: 6E 00 07 DF 02 Heap(110, 0) offset: 0005BE0E
0027: CD 00 8A DF 02 Heap(205, 0) offset: 0005BF14
0027: FF 00 B7 DF 02 Heap(255, 0) offset: 0005BF6E
0027: 6D 03 24 E0 02 Heap(877, 0) offset: 0005C048
0027: 99 03 5D E0 02 Heap(921, 0) offset: 0005C0BA
0027: 9A 03 8A E0 02 Heap(922, 0) offset: 0005C114
0027: 9B 03 10 E1 02 Heap(923, 0) offset: 0005C220
0027: 9C 03 8F E1 02 Heap(924, 0) offset: 0005C31E
0027: 9D 03 06 E2 02 Heap(925, 0) offset: 0005C40C
0027: 9E 03 68 E2 02 Heap(926, 0) offset: 0005C4D0
0027: 9F 03 90 E2 02 Heap(927, 0) offset: 0005C520
0027: A0 03 B4 E2 02 Heap(928, 0) offset: 0005C568
0027: A1 03 6E E3 02 Heap(929, 0) offset: 0005C6DC
0027: A2 03 AD E3 02 Heap(930, 0) offset: 0005C75A
0027: A4 03 DC E3 02 Heap(932, 0) offset: 0005C7B8
0027: A5 03 0B E4 02 Heap(933, 0) offset: 0005C816
0027: A6 03 29 E4 02 Heap(934, 0) offset: 0005C852
0027: A7 03 63 E4 02 Heap(935, 0) offset: 0005C8C6
0027: A8 03 96 E4 02 Heap(936, 0) offset: 0005C92C
0027: A9 03 FF E4 02 Heap(937, 0) offset: 0005C9FE
0027: AA 03 4A E5 02 Heap(938, 0) offset: 0005CA94
0027: AB 03 68 E5 02 Heap(939, 0) offset: 0005CAD0
0027: AD 03 83 E5 02 Heap(941, 0) offset: 0005CB06
0027: AE 03 B9 E5 02 Heap(942, 0) offset: 0005CB72
0027: AF 03 D7 E5 02 Heap(943, 0) offset: 0005CBAE
0027: B0 03 B4 E9 02 Heap(944, 0) offset: 0005D368
0027: B1 03 E4 E9 02 Heap(945, 0) offset: 0005D3C8
0027: B2 03 10 EA 02 Heap(946, 0) offset: 0005D420
0027: B3 03 2B EA 02 Heap(947, 0) offset: 0005D456
0027: B4 03 61 F3 02 Heap(948, 0) offset: 0005E6C2
0027: B5 03 1B F8 02 Heap(949, 0) offset: 0005F036
0027: B6 03 45 F8 02 Heap(950, 0) offset: 0005F08A
0027: B7 03 A7 F8 02 Heap(951, 0) offset: 0005F14E
0027: B8 03 D2 F8 02 Heap(952, 0) offset: 0005F1A4
0027: B9 03 97 FA 02 Heap(953, 0) offset: 0005F52E
0027: BA 03 C0 FA 02 Heap(954, 0) offset: 0005F580
0027: BB 03 32 FB 02 Heap(955, 0) offset: 0005F664
0027: BC 03 5B FB 02 Heap(956, 0) offset: 0005F6B6
0027: BE 03 7C FB 02 Heap(958, 0) offset: 0005F6F8
0027: C1 03 85 FB 02 Heap(961, 0) offset: 0005F70A
0027: C3 03 A4 FB 02 Heap(963, 0) offset: 0005F748
0027: C4 03 CD FB 02 Heap(964, 0) offset: 0005F79A
0027: C7 03 F4 FB 02 Heap(967, 0) offset: 0005F7E8
0027: C8 03 1A FC 02 Heap(968, 0) offset: 0005F834
0027: C9 03 3E FC 02 Heap(969, 0) offset: 0005F87C
0027: CA 03 58 FC 02 Heap(970, 0) offset: 0005F8B0
0027: CB 03 7F FC 02 Heap(971, 0) offset: 0005F8FE
0027: CC 03 A7 FC 02 Heap(972, 0) offset: 0005F94E
0027: CD 03 CE FC 02 Heap(973, 0) offset: 0005F99C
0027: CE 03 F6 FC 02 Heap(974, 0) offset: 0005F9EC
0027: CF 03 0A FD 02 Heap(975, 0) offset: 0005FA14
0027: D0 03 2F FD 02 Heap(976, 0) offset: 0005FA5E
0027: D1 03 87 FD 02 Heap(977, 0) offset: 0005FB0E
0027: D2 03 C7 FD 02 Heap(978, 0) offset: 0005FB8E
0027: D4 03 1B FE 02 Heap(980, 0) offset: 0005FC36
0027: D5 03 43 FE 02 Heap(981, 0) offset: 0005FC86
0027: D6 03 90 FE 02 Heap(982, 0) offset: 0005FD20
0027: D7 03 99 FE 02 Heap(983, 0) offset: 0005FD32
0027: D8 03 EC FE 02 Heap(984, 0) offset: 0005FDD8
0027: D9 03 37 FF 02 Heap(985, 0) offset: 0005FE6E
0027: DA 03 4F FF 02 Heap(986, 0) offset: 0005FE9E
0027: DB 03 7B FF 02 Heap(987, 0) offset: 0005FEF6
0027: DC 03 21 00 03 Heap(988, 0) offset: 00060042
0027: DD 03 6F 00 03 Heap(989, 0) offset: 000600DE
0027: DE 03 94 00 03 Heap(990, 0) offset: 00060128
0027: DF 03 C9 02 03 Heap(991, 0) offset: 00060592
0027: E0 03 1A 03 03 Heap(992, 0) offset: 00060634
0027: E1 03 DC 03 03 Heap(993, 0) offset: 000607B8
0027: E2 03 F7 03 03 Heap(994, 0) offset: 000607EE
0027: E3 03 8B 05 03 Heap(995, 0) offset: 00060B16
0027: E4 03 F0 05 03 Heap(996, 0) offset: 00060BE0
0027: E6 03 42 06 03 Heap(998, 0) offset: 00060C84
0027: E7 03 0F 07 03 Heap(999, 0) offset: 00060E1E
-
Thank you. I think I've found the problem.
-
FYI, proc0_11() in the main script hides the status bar. Renaming mine to HideStatus().
It took me a while to figure it out, but ever since I changed my titlescreen to script 800, the status bar has been drawn during the intro
Finally, I spotted this in the startRoom method of the public sq5 game
(if (IsOneOf(param1 100))
proc0_11()
)
With that hard coded 100 replaced to the game.sh definition TITLEROOM_SCRIPT that I added, my status bar no longer shows up... or gets drawn black instead from what it looks like.
-
Sounds good, I'll make those changes in the template game. It looks like there's another IsOnOf call in main.sc that passes the title room number, if GameIsRestarting. (Looks like flag 22 is for when you're a fly... BTest(22). I'll remove all code around that too)
-
I saw that, but it doesn't seem to work like it reads. If you go to the second room of the template game, rm105 and hit restart, the status bar is not present when the game restarts. But 105 is not in the isOneOf array variables which means that as the method reads, the status bar should be drawn. Regardless, here's what I did there
(if (GameIsRestarting())
//(if (IsOneOf(gModNum TITLEROOM_SCRIPT 104 110 106 107))
HideStatus()
//)(else
// (sq5StatusLineCode:doit())
//)
= gColorDepth Graph(grGET_COLOURS)
(if (== gColorDepth 256)
Bset(0)
)
)
I figure since restarting is always dumping us back at the splash screen, then I would never want the status bar drawn. So I commented out most of it.
-
Just wanted to say that the aspect ratio option works great! Thank you for that!
-
There seem to be some glitches with the View editor.
1) To create new loops in the same view with the same amount of cels as the previous loop I'll "Add After" a loop and then make it a mirror of the previous loop. Then I'll make it a mirror of "none" immediately. This keeps all the number of cels around the same size as the previous loop and I can edit them separately without affecting the last loop. However, if I save, close, and then reopen the view I've edited in this way it still thinks all those loops that I had temporarily made as mirrors are still mirrors so I lose all my work.
Update: None of the loops are actually set as mirrors of anything (even though the contents are clearly mirrored cels) and a few of the cels even have the option to mirror greyed out for some reason.
2) I also ran into an glitch with the offset values. Sierra used many Views with offsets that are out of bounds of the actual cel dimensions for moving animation without a mover class (like the Sierra logo sparkles). I can edit the X offset value to any value I like, but I can't seem to change the Y offset value to something out of bounds.
EDIT: 3) There doesn't seem to be a way to export loop animations as GIFs anymore.
-
Update: None of the loops are actually set as mirrors of anything (even though the contents are clearly mirrored cels) and a few of the cels even have the option to mirror greyed out for some reason.
If other loops are already a mirror of a particular loop, that particular loop will have "mirror of" greyed out.
EDIT: 3) There doesn't seem to be a way to export loop animations as GIFs anymore.
I don't think that ever existed? Maybe you're thinking about SV.exe?
-
Oh. I could have sworn you said you had that functionality as well. My bad.
-
Oh. I could have sworn you said you had that functionality as well. My bad.
I added gif import support for image sequences (I believe you requested it?).
-
Yeah, I know that. I thought you had said when I initially requested it that you had export ability already. I must be mis-remembering. No big deal. Can you support GIF exporting?
-
Yeah, it's possible. I'll consider it a low pri request though, since SV.exe can already do it.
-
Uploaded a new version of SCI Companion with a bunch of bug fixes for the recently reported issues. Ignore the tabs in the pic editor side pane, they don't do anything yet (for the upcoming polygon editor)
-
Thanks for the update!
I have another feature request. How hard would it be to have something similar to SV's feature where you can "upload" a patch resource to a MIDI device. This really only works with the MT-32 patch bank which sends system exclusive MIDI messages to the MIDI device, but it would help. Currently we can preview sounds but for MT-32 games it doesn't really work because we can't open the patch bank. Now SV does support this so you might ask "why is it important", well besides the fact that it aides in sound creation for MT-32 songs, I'm also thinking about the MUNT WDM driver. With a real MT-32 you can upload the patch bank and as long as the MT-32 is still on it retains it all the custom patches. But in the WDM driver it doesn't. I believe SCI Viewer also had this issue: when you'd upload a Patch to the WDM driver, after it was done it would close the device and so the information would be lost. The creator programmed it so that as long as SCI Viewer was open it was always "using" the MIDI device. This would have to happen as well for Companion (if it was to be feature) for Patch bank uploads to have any purpose whatsoever when using the MUNT WDM driver. For now, it's not possible to use SV in conjunction with Companion for previewing patch banks and sounds because SV reserves the MIDI device and anything sent to the WDM driver would be lost as soon as SV closes and wouldn't persist when using Companion. Not a problem with a real MT-32, but definitely a problem with MUNT, which is what most people will be using if they want to do any MT-32 work or previewing.
EDIT: Ok so I was wrong. Apparently SV doesn't reserve the MIDI device. But it does have an upload checkbox when previewing a song which works well. Actually, SV's SCI1.1 sound previewing seems pretty flawed as incorrect instruments, missing, and hung notes are present throughout. Oh well.
-
I'll add it to the feature request list.
I don't know anything about any of this though. So I have no idea how difficult it might be to accomplish. SV.exe is able to read patch resources? Is the format spec'd somewhere?
-
Where is Ravi Iyengar when you need him:)
-
Or NewRisingSun.
I don't know if there are specs for the patch formats or not. At least not SCI1.1. How effective would reading up on the ScummVM source be? I might look at it myself, even though I have even less of an idea of what I'm doing.
-
Hello. I'm just dropping in to say that I am very happy to see this all being a thing that is happening, and to show this little thing (http://i.imgur.com/WeT8yPv.png). Keep it up! :D
-
Ooooh care to share that in the tutorial section? :D
-
Ooooh care to share that in the tutorial section? :D
Change addColoredButton to addButton? You may have to change some of the parameters... experiment a little.
-
Ooooh care to share that in the tutorial section? :D
Change addColoredButton to addButton? You may have to change some of the parameters... experiment a little.
That's exactly what I did. Among other things.
-
Geez where were you guys when I initially asked this question? lol
-
Geez where were you guys when I initially asked this question? lol
I can speak only for myself -- I wasn't here, thinking SCI dev dead.
-
Great to see someone else join in!
-
Great to see someone else join in!
Happy to be here. If you need template graphics, preferably UI stuff, hit me up.
-
We could use all the help we can get!
-
I should have a new build of SCI Companion sometime tomorrow with fixes for the MIDI issues (hopefully) and a first stab at the polygon editor (and probably some updates to the template game too).
-
Were you ever able to reproduce the resource delete issue... Try deleting pic 31 and then hitting rebuild.
-
Yeah, pretty sure it's fixed. Or at least the problem that gets you into that state is fixed.
-
This is what I've been playing around with since the release.
https://www.youtube.com/watch?v=uSiWCU03S9I
-
Hey, that looks great! So those are graphics resources from a fan-made KQ1 done in another engine, right? And you're re-making it in SCI 1.1?
The palette cycling looks pretty slick.
Looks like you'll need some polygons soon :P
-
Yeah, they're borrowed from AGDI's remake made in AGS. Not as easy as you'd think. Screenshotting animation frames is a paaaaaaain. Won't be finishing this. Just for the experience to work out some of the advanced features in SCI1.1. If I ever did do this I'd want to finish KQ2SCI first. I did the logo image in Deluxe Paint and Grafx 2 (a modern spiritual successor to Deluxe Paint). It was fun to create I liked how it turned out.
-
Y'gotta love those button borders. ;)
-
MI, isn't there any utility that can extract graphics from an AGS game?
-
Or better yet: you've worked with AGDI. Won't they give you access to their graphic resources?
-
MI, isn't there any utility that can extract graphics from an AGS game?
I had thought that Chris Jones specifically designed AGS so that nobody could decompile or rip assets from it.
Or better yet: you've worked with AGDI. Won't they give you access to their graphic resources?
That's a lot of content. With us still working hard to finish up Mage's I doubt they'd have the time. Especially when I'm still finishing up music! Chris Warren (AGD2) liked the logo though lol.
-
I had thought that Chris Jones specifically designed AGS so that nobody could decompile or rip assets from it.
You know that's impossible. Difficult maybe, but theoretically it can be done.
-
Copy and paste from one cel in a loop to another cel in the same loop, causes all kinds of bad things.
In the screen shot, cel 1 was copied to cel 2.
-
arghh... (also, you mean loops/views, not cels/loops). Yeah, I broke this when I "fixed" things so that copying among view cels with the same palette just did a direct copy (instead of re-interpreting RGB colors).
Well, you can work around it in the meantime by making the bottom cel the same size of the one you're copying from, then adjusting (and wouldn't you need to do that anyway? If you're trying to make a small version of the plunger, you'd want to copy the old one into a same size cel, and then re-size it by SHIFT-dragging a border).
-
Yeah, that is just what I was going to add, that it only happens when the second cel is smaller.
When I did it, I didn't think about the cels being different sizes, I was just copy and pasting without a care in the world
and yeah I did mean cels of different loops... I'm not used to the right pane showing loops and the bottom pane showing cels yet. But it also breaks with cels in the same loop if the second one is smaller
-
I've run into this. I saw that it was a size issue and just worked around it. I do like the idea that when a cel is smaller the pasted graphic will be resized. However, sometimes I'm working so fast I might not notice that it's smaller (take walk animations for instance) and I'll end up with skewed animation cels. This isn't a feature request but a request for feedback on a potential feature. Does anyone think it would be too bothersome and time wasting to add a pop up window warning that the image being pasted is larger than the size of the cel it's being pasted in and asking for confirmation before proceeding?
Y'gotta love those button borders. ;)
If you're talking about the ones on the title screen, those are actually Views. lol
-
If you're talking about the ones on the title screen, those are actually Views. lol
I know they are. I was joking about the lowlightColor thing. ;)
-
:)
Actually, if you'll notice, the insetWindow for the Inventory GUI still uses grey colours. I have to find that and fix it. My first attempt proved fruitless. It's probably a global variable thing, which makes finding the point at which the colours are set difficult because you don't know what to search for right away.
-
Version 3.0.0.5 is out! List of changes in the first post of this thread, as usual.
The two main changes of interest are the polygon editor, and the script-based debug helper (from SQ5).
Polygon Editor
-------------
Polygon is now "seamlessly" integrated into the pic editor (including full undo/redo support). It reads/writes from a [picnum].shp header file in the "poly" folder. The header file consists of a SetUpPolys_[picnum] procedure which can be called from your room's init method. The "new room" command sets this up automatically. The SetUpPolys_[picnum] procedure adds all the polygons to the current room. If you're adding to an existing room, you'll need to add this call, the include of the .shp file, and the "use" of the Polygon script.
The editing functionality is still a bit unpolished (i.e. the workflow doesn't feel super smooth to me). There is a polygon tool to the right of the standard pic drawing tools. Clicking on this will make the polygons show up. You can just left-click anywhere to start drawing a polygon. Right-click ends it (and closes the loop), or you can left-click on the first point you made. Once a polygon has been made, you can drag the points around, delete the points (right-click popup menu), or split the edges (right-click popup menu). You can also delete the selected polygon with the delete key. To hide the polygons, uncheck the "show polygons" box in the left-hand pane. You'll note the polygon list takes the place of the regular pic commands list for VGA pics. You can switch back and forth between them with the buttons above the list.
Once "gotcha" is that you need to recompile the script in order for the new polygons to take effect, of course. It's possible I could do this automatically.
For the next step, I think I'd like to have functionality for "named" polygons, so they can be added (or removed) by name at a different time (say when a particular object appears, or whatever), instead of just once at room init. So it would be a separate set of polygons, and the calling code would look something like:
(= temp0 CreateNewPolygon(MY_FANCY_POLYGON))
// store it off in temp0 in case maybe later you want to remove it
(send gRoom:addObstacle(temp0))
But of course I'd like to hear feedback on what you all think is best.
debug handler
---------------
I added the debug script from SQ5 back into the template game, and made a few changes. You can invoke it simply by pressing Alt-d at any point in the game. The Question mark key will then show you the menu of choices (press alt in combination with the letters shown). You can set variables and flags, show the cast, switch screens, show the current palette, get inventory items, move the ego around, invoke the feature writer or in-game polygon editor, and view the obstacles (I added that).
(oops, and I just realized alt-d conflicts with one of the debug handler features).
(oops, and I just realized I left in a bunch of print statements for alt-y, the view obstacles functionality)
-
Er isn't it 3.0.0.6? I already have a 3.0.0.5 lol. Oh wait no I don't! Wait...then what did I name 3.0.0.4?...
Ok, I have two copies of 3.0.0.4. I named one 3.0.0.5. Was one merely a hotfix for 3.0.0.4 and I presumptuously named it 3.0.0.5?
-
I just forgot to update the version number after 3.0.0.4. I did mention it (see release notes for 6-18-2015). Didn't realize anyone was paying attention/cared, so I just went with 3.0.0.5 for this iteration. :P
-
That's fine. My archived copy will now be called 3.0.0.4b. :)
I also agree with your ideas for naming polygons and calling them when needed. I must say I really love the system you've put together. It's very easy to work with. The resizing, deleting, splitting, etc all work wonderfully and really speed up progress. One request, could you add polygons as one of the options that the fake ego View can observe?
-
Yeah, I put it on the list. It's a little bit less straightforward, because it's not simply "can be here" or not. But I guess I can just make the fake ego not allowed in barred access polygons, and only allowed in contained access polygons (if there is one).
-
Hey Phil, with the polygon editor. Is there anyway that we could be able to right click on a completed entry and copy the point coordinates to the clipboard. For views and movable items, or removable items. It would be handy to be able to handle those points via a local variable array.
-
Yeah, I was going to have a little edit box below the polygons where it would show the points for the current poly, and you could paste/copy/edit that.
But ideally you'll be able to used name polygons for your scenario... assuming I understand what your scenario is...
-
So the debug polygon tool that is built into the debug script... That is actually pretty damn cool.
It was especially nice that the .pol file it generated was readable too.
; Polygon Editor 1.11
; Dynamic Obstacles : Picture 110
(curRoom addObstacle:
((Polygon new:)
type: PBarredAccess,
init: 220 76 259 81 274 91 268 108 230 100 212 91,
yourself:
)
((Polygon new:)
type: PBarredAccess,
init: 0 63 45 67 47 87 22 96 0 97,
yourself:
)
((Polygon new:)
type: PBarredAccess,
init: 93 96 91 107 111 111 119 94 109 90 100 92,
yourself:
)
)
(altPolyList add:
)
-
There's some seriously gnarly shit going down with the pic resources here, when you look at them in SV. Oddly, they clearly render just fine at runtime, both the template scene and what's supposed to be one of those close-up portraits.
-
Hah, yeah I'd noticed that before, but thought I fixed it (or maybe I only fixed it for views, or maybe I missed a case or something). I'll add it to the list of things to fix.
Comes back to the view/pic resources having a lot of redundant offsets and sizes and such. SCI Companion and Sierra (and Scumm) read the files one way, SV.exe reads them slightly differently.
-
So the debug polygon tool that is built into the debug script... That is actually pretty damn cool.
Yeah, lots of cool things in there. The feature writer is in there too. There's also a dialog editor script in the game too, but I haven't linked it into there. Alt-I also brings up UI that lets you add inventory items to the ego (although the buttons appear off the edge of the dialog).
-
SCI Companion and Sierra (and Scumm) read the files one way, SV.exe reads them slightly differently.
SCI Studio reads them right too, just for the record.
-
Adding text resources is a little fishy. I just entered my text and hit enter and two new lines popped up.
When I create a new text resource, there is a spot for noun and verb. But after it has been closed and opened then the noun verb areas are gone. Which I am guessing they shouldn't have been there from the start.
-
Oh yeah, it's messed up. The text and message editors were originally the same when I was just getting things up and running with SCI1.1. I then split them when I implemented full message functionality. Looks like I left the text editor in a bad state. Oops.
(Is this for a SCI0 game? Shouldn't really need to use text resources for SCI 1.1).
-
I'm still getting an issue when deleting resources, but instead of the same resource popping back, the next one on the list doubles and takes its place and number. I tried deleting WD-40's View (13) and the next view in my list (15) took its place, but it still points to 15, even though it's named 13. I tried the same thing to a Pic resource. I deleted 301 but 000 took its place, even though 312 was the next in the list. I fixed it and tried deleting another Pic number and 000 replaced it again.
After deleting 301 before rebuilding:
Resource map for Test
Type: 80 Offset: 002b
Type: 81 Offset: 0099
Type: 82 Offset: 00da
Type: 83 Offset: 02b5
Type: 84 Offset: 02d3
Type: 86 Offset: 02ec
Type: 87 Offset: 0300
Type: 89 Offset: 0323
Type: 8b Offset: 0337
Type: 8f Offset: 0341
Type: 90 Offset: 037d
Type: 91 Offset: 0382
Type: ff Offset: 0567
0027: 00 00 00 00 00 View(0, 0) offset: 00000000
0027: 01 00 DC 1C 00 View(1, 0) offset: 000039B8
0027: 0D 00 AD 29 00 View(13, 0) offset: 0000535A
0027: 0F 00 22 62 00 View(15, 0) offset: 0000C444
0027: 64 00 FC 69 00 View(100, 0) offset: 0000D3F8
0027: 84 03 A1 77 00 View(900, 0) offset: 0000EF42
0027: B0 03 0D 79 00 View(944, 0) offset: 0000F21A
0027: D4 03 0B 7A 00 View(980, 0) offset: 0000F416
0027: D5 03 FD 7D 00 View(981, 0) offset: 0000FBFA
0027: D6 03 7D 7E 00 View(982, 0) offset: 0000FCFA
0027: D7 03 1A 7F 00 View(983, 0) offset: 0000FE34
0027: D8 03 12 82 00 View(984, 0) offset: 00010424
0027: DD 03 8E 84 00 View(989, 0) offset: 0001091C
0027: DE 03 25 85 00 View(990, 0) offset: 00010A4A
0027: DF 03 02 A3 00 View(991, 0) offset: 00014604
0027: E3 03 54 B2 00 View(995, 0) offset: 000164A8
0027: E4 03 A8 C8 00 View(996, 0) offset: 00019150
0027: E5 03 EA C8 00 View(997, 0) offset: 000191D4
0027: E7 03 77 C9 00 View(999, 0) offset: 000192EE
0027: D0 07 EB C9 00 View(2000, 0) offset: 000193D6
0027: 33 08 32 D2 00 View(2099, 0) offset: 0001A464
0027: B9 0B 51 D9 00 View(3001, 0) offset: 0001B2A2
0027: 00 00 3A E1 00 Pic(0, 0) offset: 0001C274
0027: 1F 00 6C E1 00 Pic(31, 0) offset: 0001C2D8
0027: 65 00 EA 57 01 Pic(101, 0) offset: 0002AFD4
0027: 66 00 5E CC 01 Pic(102, 0) offset: 000398BC
0027: 6E 00 46 3C 02 Pic(110, 0) offset: 0004788C
0027: 6F 00 EB B5 02 Pic(111, 0) offset: 00056BD6
0027: B7 00 A2 2F 03 Pic(183, 0) offset: 00065F44
0027: C8 00 30 9F 03 Pic(200, 0) offset: 00073E60
0027: 2C 01 8D A6 03 Pic(300, 0) offset: 00074D1A
0027: 2D 01 C0 C7 03 Pic(301, 0) offset: 00078F80
0027: 38 01 C0 C7 03 Pic(312, 0) offset: 00078F80
0027: F4 01 FF 3C 04 Pic(500, 0) offset: 000879FE
0027: F5 01 3F 54 04 Pic(501, 0) offset: 0008A87E
0027: 00 00 ED C6 04 Script(0, 0) offset: 00098DDA
0027: 0B 00 5A D1 04 Script(11, 0) offset: 0009A2B4
0027: 0C 00 AE D1 04 Script(12, 0) offset: 0009A35C
0027: 0D 00 01 D2 04 Script(13, 0) offset: 0009A402
0027: 0E 00 19 D2 04 Script(14, 0) offset: 0009A432
0027: 0F 00 8F D2 04 Script(15, 0) offset: 0009A51E
0027: 10 00 14 D4 04 Script(16, 0) offset: 0009A828
0027: 11 00 37 D5 04 Script(17, 0) offset: 0009AA6E
0027: 12 00 AC D7 04 Script(18, 0) offset: 0009AF58
0027: 13 00 9A D9 04 Script(19, 0) offset: 0009B334
0027: 14 00 6B DB 04 Script(20, 0) offset: 0009B6D6
0027: 15 00 61 DC 04 Script(21, 0) offset: 0009B8C2
0027: 16 00 A9 DC 04 Script(22, 0) offset: 0009B952
0027: 18 00 A5 DE 04 Script(24, 0) offset: 0009BD4A
0027: 19 00 12 E1 04 Script(25, 0) offset: 0009C224
0027: 1A 00 D8 E2 04 Script(26, 0) offset: 0009C5B0
0027: 1B 00 6C E6 04 Script(27, 0) offset: 0009CCD8
0027: 1E 00 A2 E7 04 Script(30, 0) offset: 0009CF44
0027: 20 00 A6 EC 04 Script(32, 0) offset: 0009D94C
0027: 64 00 81 ED 04 Script(100, 0) offset: 0009DB02
0027: 65 00 89 F0 04 Script(101, 0) offset: 0009E112
0027: 66 00 AE F1 04 Script(102, 0) offset: 0009E35C
0027: 69 00 F2 F1 04 Script(105, 0) offset: 0009E3E4
0027: 6E 00 2B F2 04 Script(110, 0) offset: 0009E456
0027: B7 00 80 F2 04 Script(183, 0) offset: 0009E500
0027: CD 00 C4 F2 04 Script(205, 0) offset: 0009E588
0027: FF 00 90 F3 04 Script(255, 0) offset: 0009E720
0027: 6D 03 46 F9 04 Script(877, 0) offset: 0009F28C
0027: 99 03 6B FB 04 Script(921, 0) offset: 0009F6D6
0027: 9A 03 74 00 05 Script(922, 0) offset: 000A00E8
0027: 9B 03 CB 02 05 Script(923, 0) offset: 000A0596
0027: 9C 03 5D 05 05 Script(924, 0) offset: 000A0ABA
0027: 9D 03 33 07 05 Script(925, 0) offset: 000A0E66
0027: 9E 03 46 09 05 Script(926, 0) offset: 000A128C
0027: 9F 03 29 0A 05 Script(927, 0) offset: 000A1452
0027: A0 03 90 0C 05 Script(928, 0) offset: 000A1920
0027: A1 03 03 13 05 Script(929, 0) offset: 000A2606
0027: A2 03 6F 14 05 Script(930, 0) offset: 000A28DE
0027: A4 03 3B 15 05 Script(932, 0) offset: 000A2A76
0027: A5 03 FB 15 05 Script(933, 0) offset: 000A2BF6
0027: A6 03 C5 16 05 Script(934, 0) offset: 000A2D8A
0027: A7 03 92 18 05 Script(935, 0) offset: 000A3124
0027: A8 03 FF 18 05 Script(936, 0) offset: 000A31FE
0027: A9 03 F1 1B 05 Script(937, 0) offset: 000A37E2
0027: AA 03 99 24 05 Script(938, 0) offset: 000A4932
0027: AB 03 14 25 05 Script(939, 0) offset: 000A4A28
0027: AD 03 72 25 05 Script(941, 0) offset: 000A4AE4
0027: AE 03 1E 26 05 Script(942, 0) offset: 000A4C3C
0027: AF 03 D0 26 05 Script(943, 0) offset: 000A4DA0
0027: B0 03 DA 33 05 Script(944, 0) offset: 000A67B4
0027: B1 03 C1 34 05 Script(945, 0) offset: 000A6982
0027: B2 03 BB 35 05 Script(946, 0) offset: 000A6B76
0027: B3 03 F9 35 05 Script(947, 0) offset: 000A6BF2
0027: B4 03 E0 48 05 Script(948, 0) offset: 000A91C0
0027: B5 03 74 4F 05 Script(949, 0) offset: 000A9EE8
0027: B6 03 D4 4F 05 Script(950, 0) offset: 000A9FA8
0027: B7 03 73 52 05 Script(951, 0) offset: 000AA4E6
0027: B9 03 C6 52 05 Script(953, 0) offset: 000AA58C
0027: BA 03 40 53 05 Script(954, 0) offset: 000AA680
0027: BB 03 A6 55 05 Script(955, 0) offset: 000AAB4C
0027: BC 03 25 56 05 Script(956, 0) offset: 000AAC4A
0027: BE 03 5F 56 05 Script(958, 0) offset: 000AACBE
0027: C1 03 87 56 05 Script(961, 0) offset: 000AAD0E
0027: C3 03 C7 56 05 Script(963, 0) offset: 000AAD8E
0027: C4 03 06 57 05 Script(964, 0) offset: 000AAE0C
0027: C7 03 9E 57 05 Script(967, 0) offset: 000AAF3C
0027: C8 03 EE 57 05 Script(968, 0) offset: 000AAFDC
0027: C9 03 A2 59 05 Script(969, 0) offset: 000AB344
0027: CA 03 D9 59 05 Script(970, 0) offset: 000AB3B2
0027: CB 03 42 5A 05 Script(971, 0) offset: 000AB484
0027: CC 03 02 5B 05 Script(972, 0) offset: 000AB604
0027: CD 03 8C 5B 05 Script(973, 0) offset: 000AB718
0027: CF 03 DA 5C 05 Script(975, 0) offset: 000AB9B4
0027: D0 03 8B 5D 05 Script(976, 0) offset: 000ABB16
0027: D1 03 3A 5F 05 Script(977, 0) offset: 000ABE74
0027: D2 03 14 61 05 Script(978, 0) offset: 000AC228
0027: D4 03 1A 63 05 Script(980, 0) offset: 000AC634
0027: D5 03 66 63 05 Script(981, 0) offset: 000AC6CC
0027: D6 03 80 64 05 Script(982, 0) offset: 000AC900
0027: D7 03 1E 65 05 Script(983, 0) offset: 000ACA3C
0027: D8 03 E7 65 05 Script(984, 0) offset: 000ACBCE
0027: D9 03 7A 67 05 Script(985, 0) offset: 000ACEF4
0027: DA 03 2C 68 05 Script(986, 0) offset: 000AD058
0027: DB 03 CF 68 05 Script(987, 0) offset: 000AD19E
0027: DC 03 86 6A 05 Script(988, 0) offset: 000AD50C
0027: DD 03 FE 6B 05 Script(989, 0) offset: 000AD7FC
0027: DE 03 7F 6D 05 Script(990, 0) offset: 000ADAFE
0027: DF 03 34 73 05 Script(991, 0) offset: 000AE668
0027: E0 03 F8 74 05 Script(992, 0) offset: 000AE9F0
0027: E1 03 68 77 05 Script(993, 0) offset: 000AEED0
0027: E2 03 42 78 05 Script(994, 0) offset: 000AF084
0027: E3 03 95 80 05 Script(995, 0) offset: 000B012A
0027: E4 03 D3 87 05 Script(996, 0) offset: 000B0FA6
0027: E6 03 E5 89 05 Script(998, 0) offset: 000B13CA
0027: E7 03 34 91 05 Script(999, 0) offset: 000B2268
0027: 0A 00 FF 95 05 Text(10, 0) offset: 000B2BFE
0027: C9 00 5D 96 05 Text(201, 0) offset: 000B2CBA
0027: CC 01 66 96 05 Text(460, 0) offset: 000B2CCC
0027: AF 03 6F 96 05 Text(943, 0) offset: 000B2CDE
0027: B8 03 BB 96 05 Text(952, 0) offset: 000B2D76
0027: E7 03 F1 96 05 Text(999, 0) offset: 000B2DE2
0027: 2D 00 0D 97 05 Sound(45, 0) offset: 000B2E1A
0027: E8 03 81 99 05 Sound(1000, 0) offset: 000B3302
0027: E9 03 B3 99 05 Sound(1001, 0) offset: 000B3366
0027: EA 03 F0 9B 05 Sound(1002, 0) offset: 000B37E0
0027: EB 03 57 A6 05 Sound(1003, 0) offset: 000B4CAE
0027: E2 03 3A AF 05 Vocab(994, 0) offset: 000B5E74
0027: E4 03 76 AF 05 Vocab(996, 0) offset: 000B5EEC
0027: E5 03 9D B0 05 Vocab(997, 0) offset: 000B613A
0027: E6 03 9E CE 05 Vocab(998, 0) offset: 000B9D3C
0027: 00 00 18 D0 05 Font(0, 0) offset: 000BA030
0027: 01 00 87 D3 05 Font(1, 0) offset: 000BA70E
0027: 04 00 D1 D6 05 Font(4, 0) offset: 000BADA2
0027: 45 00 5A D9 05 Font(69, 0) offset: 000BB2B4
0027: E7 03 CA DC 05 Font(999, 0) offset: 000BB994
0027: 45 06 30 DF 05 Font(1605, 0) offset: 000BBE60
0027: 3A 08 0F E2 05 Font(2106, 0) offset: 000BC41E
0027: 01 00 7E E5 05 Patch(1, 0) offset: 000BCAFC
0027: 03 00 B5 0B 06 Patch(3, 0) offset: 000C176A
0027: 04 00 3D 16 06 Patch(4, 0) offset: 000C2C7A
0027: 65 00 D1 18 06 Patch(101, 0) offset: 000C31A2
0027: E6 03 EB 19 06 Palette(998, 0) offset: 000C33D6
0027: E7 03 02 1C 06 Palette(999, 0) offset: 000C3804
0027: 00 00 19 1E 06 Message(0, 0) offset: 000C3C32
0027: 0D 00 60 24 06 Message(13, 0) offset: 000C48C0
0027: 0F 00 92 24 06 Message(15, 0) offset: 000C4924
0027: 14 00 B8 25 06 Message(20, 0) offset: 000C4B70
0027: 64 00 D0 25 06 Message(100, 0) offset: 000C4BA0
0027: 65 00 E0 25 06 Message(101, 0) offset: 000C4BC0
0027: 66 00 FE 25 06 Message(102, 0) offset: 000C4BFC
0027: 69 00 1C 26 06 Message(105, 0) offset: 000C4C38
0027: 6E 00 3A 26 06 Message(110, 0) offset: 000C4C74
0027: B7 00 8B 26 06 Message(183, 0) offset: 000C4D16
0027: DE 03 A9 26 06 Message(990, 0) offset: 000C4D52
0027: E2 03 27 28 06 Message(994, 0) offset: 000C504E
0027: FF FF F0 28 06 Map(65535, 0) offset: 000C51E0
0027: 00 00 FC 28 06 Heap(0, 0) offset: 000C51F8
0027: 0B 00 D0 2C 06 Heap(11, 0) offset: 000C59A0
0027: 0C 00 E9 2C 06 Heap(12, 0) offset: 000C59D2
0027: 0D 00 F2 2C 06 Heap(13, 0) offset: 000C59E4
0027: 0E 00 0A 2D 06 Heap(14, 0) offset: 000C5A14
0027: 0F 00 32 2D 06 Heap(15, 0) offset: 000C5A64
0027: 10 00 EB 2E 06 Heap(16, 0) offset: 000C5DD6
0027: 11 00 19 2F 06 Heap(17, 0) offset: 000C5E32
0027: 12 00 4F 2F 06 Heap(18, 0) offset: 000C5E9E
0027: 13 00 C5 2F 06 Heap(19, 0) offset: 000C5F8A
0027: 14 00 23 30 06 Heap(20, 0) offset: 000C6046
0027: 15 00 0C 32 06 Heap(21, 0) offset: 000C6418
0027: 16 00 2C 32 06 Heap(22, 0) offset: 000C6458
0027: 18 00 89 32 06 Heap(24, 0) offset: 000C6512
0027: 19 00 BD 34 06 Heap(25, 0) offset: 000C697A
0027: 1A 00 EF 34 06 Heap(26, 0) offset: 000C69DE
0027: 1B 00 3D 35 06 Heap(27, 0) offset: 000C6A7A
0027: 1E 00 80 35 06 Heap(30, 0) offset: 000C6B00
0027: 20 00 67 36 06 Heap(32, 0) offset: 000C6CCE
0027: 64 00 93 36 06 Heap(100, 0) offset: 000C6D26
0027: 65 00 9C 38 06 Heap(101, 0) offset: 000C7138
0027: 66 00 83 39 06 Heap(102, 0) offset: 000C7306
0027: 69 00 CB 39 06 Heap(105, 0) offset: 000C7396
0027: 6E 00 13 3A 06 Heap(110, 0) offset: 000C7426
0027: B7 00 96 3A 06 Heap(183, 0) offset: 000C752C
0027: CD 00 DE 3A 06 Heap(205, 0) offset: 000C75BC
0027: FF 00 0B 3B 06 Heap(255, 0) offset: 000C7616
0027: 6D 03 78 3B 06 Heap(877, 0) offset: 000C76F0
0027: 99 03 B1 3B 06 Heap(921, 0) offset: 000C7762
0027: 9A 03 DE 3B 06 Heap(922, 0) offset: 000C77BC
0027: 9B 03 64 3C 06 Heap(923, 0) offset: 000C78C8
0027: 9C 03 E3 3C 06 Heap(924, 0) offset: 000C79C6
0027: 9D 03 5A 3D 06 Heap(925, 0) offset: 000C7AB4
0027: 9E 03 BC 3D 06 Heap(926, 0) offset: 000C7B78
0027: 9F 03 E4 3D 06 Heap(927, 0) offset: 000C7BC8
0027: A0 03 08 3E 06 Heap(928, 0) offset: 000C7C10
0027: A1 03 C2 3E 06 Heap(929, 0) offset: 000C7D84
0027: A2 03 01 3F 06 Heap(930, 0) offset: 000C7E02
0027: A4 03 30 3F 06 Heap(932, 0) offset: 000C7E60
0027: A5 03 5F 3F 06 Heap(933, 0) offset: 000C7EBE
0027: A6 03 7D 3F 06 Heap(934, 0) offset: 000C7EFA
0027: A7 03 B7 3F 06 Heap(935, 0) offset: 000C7F6E
0027: A8 03 EA 3F 06 Heap(936, 0) offset: 000C7FD4
0027: A9 03 55 40 06 Heap(937, 0) offset: 000C80AA
0027: AA 03 A0 40 06 Heap(938, 0) offset: 000C8140
0027: AB 03 BE 40 06 Heap(939, 0) offset: 000C817C
0027: AD 03 D9 40 06 Heap(941, 0) offset: 000C81B2
0027: AE 03 0F 41 06 Heap(942, 0) offset: 000C821E
0027: AF 03 2D 41 06 Heap(943, 0) offset: 000C825A
0027: B0 03 0A 45 06 Heap(944, 0) offset: 000C8A14
0027: B1 03 3A 45 06 Heap(945, 0) offset: 000C8A74
0027: B2 03 66 45 06 Heap(946, 0) offset: 000C8ACC
0027: B3 03 81 45 06 Heap(947, 0) offset: 000C8B02
0027: B4 03 B7 4E 06 Heap(948, 0) offset: 000C9D6E
0027: B5 03 71 53 06 Heap(949, 0) offset: 000CA6E2
0027: B6 03 9B 53 06 Heap(950, 0) offset: 000CA736
0027: B7 03 FD 53 06 Heap(951, 0) offset: 000CA7FA
0027: B8 03 28 54 06 Heap(952, 0) offset: 000CA850
0027: B9 03 ED 55 06 Heap(953, 0) offset: 000CABDA
0027: BA 03 16 56 06 Heap(954, 0) offset: 000CAC2C
0027: BB 03 88 56 06 Heap(955, 0) offset: 000CAD10
0027: BC 03 B1 56 06 Heap(956, 0) offset: 000CAD62
0027: BE 03 D2 56 06 Heap(958, 0) offset: 000CADA4
0027: C1 03 DB 56 06 Heap(961, 0) offset: 000CADB6
0027: C3 03 FA 56 06 Heap(963, 0) offset: 000CADF4
0027: C4 03 23 57 06 Heap(964, 0) offset: 000CAE46
0027: C7 03 4A 57 06 Heap(967, 0) offset: 000CAE94
0027: C8 03 70 57 06 Heap(968, 0) offset: 000CAEE0
0027: C9 03 94 57 06 Heap(969, 0) offset: 000CAF28
0027: CA 03 AE 57 06 Heap(970, 0) offset: 000CAF5C
0027: CB 03 D5 57 06 Heap(971, 0) offset: 000CAFAA
0027: CC 03 FD 57 06 Heap(972, 0) offset: 000CAFFA
0027: CD 03 24 58 06 Heap(973, 0) offset: 000CB048
0027: CE 03 4C 58 06 Heap(974, 0) offset: 000CB098
0027: CF 03 60 58 06 Heap(975, 0) offset: 000CB0C0
0027: D0 03 85 58 06 Heap(976, 0) offset: 000CB10A
0027: D1 03 DD 58 06 Heap(977, 0) offset: 000CB1BA
0027: D2 03 1D 59 06 Heap(978, 0) offset: 000CB23A
0027: D4 03 71 59 06 Heap(980, 0) offset: 000CB2E2
0027: D5 03 99 59 06 Heap(981, 0) offset: 000CB332
0027: D6 03 E6 59 06 Heap(982, 0) offset: 000CB3CC
0027: D7 03 EF 59 06 Heap(983, 0) offset: 000CB3DE
0027: D8 03 42 5A 06 Heap(984, 0) offset: 000CB484
0027: D9 03 8D 5A 06 Heap(985, 0) offset: 000CB51A
0027: DA 03 A5 5A 06 Heap(986, 0) offset: 000CB54A
0027: DB 03 D1 5A 06 Heap(987, 0) offset: 000CB5A2
0027: DC 03 77 5B 06 Heap(988, 0) offset: 000CB6EE
0027: DD 03 C5 5B 06 Heap(989, 0) offset: 000CB78A
0027: DE 03 EA 5B 06 Heap(990, 0) offset: 000CB7D4
0027: DF 03 1F 5E 06 Heap(991, 0) offset: 000CBC3E
0027: E0 03 70 5E 06 Heap(992, 0) offset: 000CBCE0
0027: E1 03 32 5F 06 Heap(993, 0) offset: 000CBE64
0027: E2 03 4D 5F 06 Heap(994, 0) offset: 000CBE9A
0027: E3 03 E1 60 06 Heap(995, 0) offset: 000CC1C2
0027: E4 03 46 61 06 Heap(996, 0) offset: 000CC28C
0027: E6 03 98 61 06 Heap(998, 0) offset: 000CC330
0027: E7 03 65 62 06 Heap(999, 0) offset: 000CC4CA
After rebuilding:
Resource map for Test
Type: 80 Offset: 002b
Type: 81 Offset: 0099
Type: 82 Offset: 00da
Type: 83 Offset: 02b5
Type: 84 Offset: 02d3
Type: 86 Offset: 02ec
Type: 87 Offset: 0300
Type: 89 Offset: 0323
Type: 8b Offset: 0337
Type: 8f Offset: 0341
Type: 90 Offset: 037d
Type: 91 Offset: 0382
Type: ff Offset: 0567
0027: 00 00 00 00 00 View(0, 0) offset: 00000000
0027: 01 00 DC 1C 00 View(1, 0) offset: 000039B8
0027: 0D 00 AD 29 00 View(13, 0) offset: 0000535A
0027: 0F 00 22 62 00 View(15, 0) offset: 0000C444
0027: 64 00 FC 69 00 View(100, 0) offset: 0000D3F8
0027: 84 03 A1 77 00 View(900, 0) offset: 0000EF42
0027: B0 03 0D 79 00 View(944, 0) offset: 0000F21A
0027: D4 03 0B 7A 00 View(980, 0) offset: 0000F416
0027: D5 03 FD 7D 00 View(981, 0) offset: 0000FBFA
0027: D6 03 7D 7E 00 View(982, 0) offset: 0000FCFA
0027: D7 03 1A 7F 00 View(983, 0) offset: 0000FE34
0027: D8 03 12 82 00 View(984, 0) offset: 00010424
0027: DD 03 8E 84 00 View(989, 0) offset: 0001091C
0027: DE 03 25 85 00 View(990, 0) offset: 00010A4A
0027: DF 03 02 A3 00 View(991, 0) offset: 00014604
0027: E3 03 54 B2 00 View(995, 0) offset: 000164A8
0027: E4 03 A8 C8 00 View(996, 0) offset: 00019150
0027: E5 03 EA C8 00 View(997, 0) offset: 000191D4
0027: E7 03 77 C9 00 View(999, 0) offset: 000192EE
0027: D0 07 EB C9 00 View(2000, 0) offset: 000193D6
0027: 33 08 32 D2 00 View(2099, 0) offset: 0001A464
0027: B9 0B 51 D9 00 View(3001, 0) offset: 0001B2A2
0027: 00 00 3A E1 00 Pic(0, 0) offset: 0001C274
0027: 1F 00 6C E1 00 Pic(31, 0) offset: 0001C2D8
0027: 65 00 EA 57 01 Pic(101, 0) offset: 0002AFD4
0027: 66 00 5E CC 01 Pic(102, 0) offset: 000398BC
0027: 6E 00 46 3C 02 Pic(110, 0) offset: 0004788C
0027: 6F 00 EB B5 02 Pic(111, 0) offset: 00056BD6
0027: B7 00 A2 2F 03 Pic(183, 0) offset: 00065F44
0027: C8 00 30 9F 03 Pic(200, 0) offset: 00073E60
0027: 2C 01 8D A6 03 Pic(300, 0) offset: 00074D1A
0027: 2D 01 C0 C7 03 Pic(301, 0) offset: 00078F80
0027: 38 01 FF 3C 04 Pic(312, 0) offset: 000879FE
0027: F4 01 3E B2 04 Pic(500, 0) offset: 0009647C
0027: F5 01 7E C9 04 Pic(501, 0) offset: 000992FC
0027: 00 00 2C 3C 05 Script(0, 0) offset: 000A7858
0027: 0B 00 99 46 05 Script(11, 0) offset: 000A8D32
0027: 0C 00 ED 46 05 Script(12, 0) offset: 000A8DDA
0027: 0D 00 40 47 05 Script(13, 0) offset: 000A8E80
0027: 0E 00 58 47 05 Script(14, 0) offset: 000A8EB0
0027: 0F 00 CE 47 05 Script(15, 0) offset: 000A8F9C
0027: 10 00 53 49 05 Script(16, 0) offset: 000A92A6
0027: 11 00 76 4A 05 Script(17, 0) offset: 000A94EC
0027: 12 00 EB 4C 05 Script(18, 0) offset: 000A99D6
0027: 13 00 D9 4E 05 Script(19, 0) offset: 000A9DB2
0027: 14 00 AA 50 05 Script(20, 0) offset: 000AA154
0027: 15 00 A0 51 05 Script(21, 0) offset: 000AA340
0027: 16 00 E8 51 05 Script(22, 0) offset: 000AA3D0
0027: 18 00 E4 53 05 Script(24, 0) offset: 000AA7C8
0027: 19 00 51 56 05 Script(25, 0) offset: 000AACA2
0027: 1A 00 17 58 05 Script(26, 0) offset: 000AB02E
0027: 1B 00 AB 5B 05 Script(27, 0) offset: 000AB756
0027: 1E 00 E1 5C 05 Script(30, 0) offset: 000AB9C2
0027: 20 00 E5 61 05 Script(32, 0) offset: 000AC3CA
0027: 64 00 C0 62 05 Script(100, 0) offset: 000AC580
0027: 65 00 C8 65 05 Script(101, 0) offset: 000ACB90
0027: 66 00 ED 66 05 Script(102, 0) offset: 000ACDDA
0027: 69 00 31 67 05 Script(105, 0) offset: 000ACE62
0027: 6E 00 6A 67 05 Script(110, 0) offset: 000ACED4
0027: B7 00 BF 67 05 Script(183, 0) offset: 000ACF7E
0027: CD 00 03 68 05 Script(205, 0) offset: 000AD006
0027: FF 00 CF 68 05 Script(255, 0) offset: 000AD19E
0027: 6D 03 85 6E 05 Script(877, 0) offset: 000ADD0A
0027: 99 03 AA 70 05 Script(921, 0) offset: 000AE154
0027: 9A 03 B3 75 05 Script(922, 0) offset: 000AEB66
0027: 9B 03 0A 78 05 Script(923, 0) offset: 000AF014
0027: 9C 03 9C 7A 05 Script(924, 0) offset: 000AF538
0027: 9D 03 72 7C 05 Script(925, 0) offset: 000AF8E4
0027: 9E 03 85 7E 05 Script(926, 0) offset: 000AFD0A
0027: 9F 03 68 7F 05 Script(927, 0) offset: 000AFED0
0027: A0 03 CF 81 05 Script(928, 0) offset: 000B039E
0027: A1 03 42 88 05 Script(929, 0) offset: 000B1084
0027: A2 03 AE 89 05 Script(930, 0) offset: 000B135C
0027: A4 03 7A 8A 05 Script(932, 0) offset: 000B14F4
0027: A5 03 3A 8B 05 Script(933, 0) offset: 000B1674
0027: A6 03 04 8C 05 Script(934, 0) offset: 000B1808
0027: A7 03 D1 8D 05 Script(935, 0) offset: 000B1BA2
0027: A8 03 3E 8E 05 Script(936, 0) offset: 000B1C7C
0027: A9 03 30 91 05 Script(937, 0) offset: 000B2260
0027: AA 03 D8 99 05 Script(938, 0) offset: 000B33B0
0027: AB 03 53 9A 05 Script(939, 0) offset: 000B34A6
0027: AD 03 B1 9A 05 Script(941, 0) offset: 000B3562
0027: AE 03 5D 9B 05 Script(942, 0) offset: 000B36BA
0027: AF 03 0F 9C 05 Script(943, 0) offset: 000B381E
0027: B0 03 19 A9 05 Script(944, 0) offset: 000B5232
0027: B1 03 00 AA 05 Script(945, 0) offset: 000B5400
0027: B2 03 FA AA 05 Script(946, 0) offset: 000B55F4
0027: B3 03 38 AB 05 Script(947, 0) offset: 000B5670
0027: B4 03 1F BE 05 Script(948, 0) offset: 000B7C3E
0027: B5 03 B3 C4 05 Script(949, 0) offset: 000B8966
0027: B6 03 13 C5 05 Script(950, 0) offset: 000B8A26
0027: B7 03 B2 C7 05 Script(951, 0) offset: 000B8F64
0027: B9 03 05 C8 05 Script(953, 0) offset: 000B900A
0027: BA 03 7F C8 05 Script(954, 0) offset: 000B90FE
0027: BB 03 E5 CA 05 Script(955, 0) offset: 000B95CA
0027: BC 03 64 CB 05 Script(956, 0) offset: 000B96C8
0027: BE 03 9E CB 05 Script(958, 0) offset: 000B973C
0027: C1 03 C6 CB 05 Script(961, 0) offset: 000B978C
0027: C3 03 06 CC 05 Script(963, 0) offset: 000B980C
0027: C4 03 45 CC 05 Script(964, 0) offset: 000B988A
0027: C7 03 DD CC 05 Script(967, 0) offset: 000B99BA
0027: C8 03 2D CD 05 Script(968, 0) offset: 000B9A5A
0027: C9 03 E1 CE 05 Script(969, 0) offset: 000B9DC2
0027: CA 03 18 CF 05 Script(970, 0) offset: 000B9E30
0027: CB 03 81 CF 05 Script(971, 0) offset: 000B9F02
0027: CC 03 41 D0 05 Script(972, 0) offset: 000BA082
0027: CD 03 CB D0 05 Script(973, 0) offset: 000BA196
0027: CF 03 19 D2 05 Script(975, 0) offset: 000BA432
0027: D0 03 CA D2 05 Script(976, 0) offset: 000BA594
0027: D1 03 79 D4 05 Script(977, 0) offset: 000BA8F2
0027: D2 03 53 D6 05 Script(978, 0) offset: 000BACA6
0027: D4 03 59 D8 05 Script(980, 0) offset: 000BB0B2
0027: D5 03 A5 D8 05 Script(981, 0) offset: 000BB14A
0027: D6 03 BF D9 05 Script(982, 0) offset: 000BB37E
0027: D7 03 5D DA 05 Script(983, 0) offset: 000BB4BA
0027: D8 03 26 DB 05 Script(984, 0) offset: 000BB64C
0027: D9 03 B9 DC 05 Script(985, 0) offset: 000BB972
0027: DA 03 6B DD 05 Script(986, 0) offset: 000BBAD6
0027: DB 03 0E DE 05 Script(987, 0) offset: 000BBC1C
0027: DC 03 C5 DF 05 Script(988, 0) offset: 000BBF8A
0027: DD 03 3D E1 05 Script(989, 0) offset: 000BC27A
0027: DE 03 BE E2 05 Script(990, 0) offset: 000BC57C
0027: DF 03 73 E8 05 Script(991, 0) offset: 000BD0E6
0027: E0 03 37 EA 05 Script(992, 0) offset: 000BD46E
0027: E1 03 A7 EC 05 Script(993, 0) offset: 000BD94E
0027: E2 03 81 ED 05 Script(994, 0) offset: 000BDB02
0027: E3 03 D4 F5 05 Script(995, 0) offset: 000BEBA8
0027: E4 03 12 FD 05 Script(996, 0) offset: 000BFA24
0027: E6 03 24 FF 05 Script(998, 0) offset: 000BFE48
0027: E7 03 73 06 06 Script(999, 0) offset: 000C0CE6
0027: 0A 00 3E 0B 06 Text(10, 0) offset: 000C167C
0027: C9 00 9C 0B 06 Text(201, 0) offset: 000C1738
0027: CC 01 A5 0B 06 Text(460, 0) offset: 000C174A
0027: AF 03 AE 0B 06 Text(943, 0) offset: 000C175C
0027: B8 03 FA 0B 06 Text(952, 0) offset: 000C17F4
0027: E7 03 30 0C 06 Text(999, 0) offset: 000C1860
0027: 2D 00 4C 0C 06 Sound(45, 0) offset: 000C1898
0027: E8 03 C0 0E 06 Sound(1000, 0) offset: 000C1D80
0027: E9 03 F2 0E 06 Sound(1001, 0) offset: 000C1DE4
0027: EA 03 2F 11 06 Sound(1002, 0) offset: 000C225E
0027: EB 03 96 1B 06 Sound(1003, 0) offset: 000C372C
0027: E2 03 79 24 06 Vocab(994, 0) offset: 000C48F2
0027: E4 03 B5 24 06 Vocab(996, 0) offset: 000C496A
0027: E5 03 DC 25 06 Vocab(997, 0) offset: 000C4BB8
0027: E6 03 DD 43 06 Vocab(998, 0) offset: 000C87BA
0027: 00 00 57 45 06 Font(0, 0) offset: 000C8AAE
0027: 01 00 C6 48 06 Font(1, 0) offset: 000C918C
0027: 04 00 10 4C 06 Font(4, 0) offset: 000C9820
0027: 45 00 99 4E 06 Font(69, 0) offset: 000C9D32
0027: E7 03 09 52 06 Font(999, 0) offset: 000CA412
0027: 45 06 6F 54 06 Font(1605, 0) offset: 000CA8DE
0027: 3A 08 4E 57 06 Font(2106, 0) offset: 000CAE9C
0027: 01 00 BD 5A 06 Patch(1, 0) offset: 000CB57A
0027: 03 00 F4 80 06 Patch(3, 0) offset: 000D01E8
0027: 04 00 7C 8B 06 Patch(4, 0) offset: 000D16F8
0027: 65 00 10 8E 06 Patch(101, 0) offset: 000D1C20
0027: E6 03 2A 8F 06 Palette(998, 0) offset: 000D1E54
0027: E7 03 41 91 06 Palette(999, 0) offset: 000D2282
0027: 00 00 58 93 06 Message(0, 0) offset: 000D26B0
0027: 0D 00 9F 99 06 Message(13, 0) offset: 000D333E
0027: 0F 00 D1 99 06 Message(15, 0) offset: 000D33A2
0027: 14 00 F7 9A 06 Message(20, 0) offset: 000D35EE
0027: 64 00 0F 9B 06 Message(100, 0) offset: 000D361E
0027: 65 00 1F 9B 06 Message(101, 0) offset: 000D363E
0027: 66 00 3D 9B 06 Message(102, 0) offset: 000D367A
0027: 69 00 5B 9B 06 Message(105, 0) offset: 000D36B6
0027: 6E 00 79 9B 06 Message(110, 0) offset: 000D36F2
0027: B7 00 CA 9B 06 Message(183, 0) offset: 000D3794
0027: DE 03 E8 9B 06 Message(990, 0) offset: 000D37D0
0027: E2 03 66 9D 06 Message(994, 0) offset: 000D3ACC
0027: FF FF 2F 9E 06 Map(65535, 0) offset: 000D3C5E
0027: 00 00 3B 9E 06 Heap(0, 0) offset: 000D3C76
0027: 0B 00 0F A2 06 Heap(11, 0) offset: 000D441E
0027: 0C 00 28 A2 06 Heap(12, 0) offset: 000D4450
0027: 0D 00 31 A2 06 Heap(13, 0) offset: 000D4462
0027: 0E 00 49 A2 06 Heap(14, 0) offset: 000D4492
0027: 0F 00 71 A2 06 Heap(15, 0) offset: 000D44E2
0027: 10 00 2A A4 06 Heap(16, 0) offset: 000D4854
0027: 11 00 58 A4 06 Heap(17, 0) offset: 000D48B0
0027: 12 00 8E A4 06 Heap(18, 0) offset: 000D491C
0027: 13 00 04 A5 06 Heap(19, 0) offset: 000D4A08
0027: 14 00 62 A5 06 Heap(20, 0) offset: 000D4AC4
0027: 15 00 4B A7 06 Heap(21, 0) offset: 000D4E96
0027: 16 00 6B A7 06 Heap(22, 0) offset: 000D4ED6
0027: 18 00 C8 A7 06 Heap(24, 0) offset: 000D4F90
0027: 19 00 FC A9 06 Heap(25, 0) offset: 000D53F8
0027: 1A 00 2E AA 06 Heap(26, 0) offset: 000D545C
0027: 1B 00 7C AA 06 Heap(27, 0) offset: 000D54F8
0027: 1E 00 BF AA 06 Heap(30, 0) offset: 000D557E
0027: 20 00 A6 AB 06 Heap(32, 0) offset: 000D574C
0027: 64 00 D2 AB 06 Heap(100, 0) offset: 000D57A4
0027: 65 00 DB AD 06 Heap(101, 0) offset: 000D5BB6
0027: 66 00 C2 AE 06 Heap(102, 0) offset: 000D5D84
0027: 69 00 0A AF 06 Heap(105, 0) offset: 000D5E14
0027: 6E 00 52 AF 06 Heap(110, 0) offset: 000D5EA4
0027: B7 00 D5 AF 06 Heap(183, 0) offset: 000D5FAA
0027: CD 00 1D B0 06 Heap(205, 0) offset: 000D603A
0027: FF 00 4A B0 06 Heap(255, 0) offset: 000D6094
0027: 6D 03 B7 B0 06 Heap(877, 0) offset: 000D616E
0027: 99 03 F0 B0 06 Heap(921, 0) offset: 000D61E0
0027: 9A 03 1D B1 06 Heap(922, 0) offset: 000D623A
0027: 9B 03 A3 B1 06 Heap(923, 0) offset: 000D6346
0027: 9C 03 22 B2 06 Heap(924, 0) offset: 000D6444
0027: 9D 03 99 B2 06 Heap(925, 0) offset: 000D6532
0027: 9E 03 FB B2 06 Heap(926, 0) offset: 000D65F6
0027: 9F 03 23 B3 06 Heap(927, 0) offset: 000D6646
0027: A0 03 47 B3 06 Heap(928, 0) offset: 000D668E
0027: A1 03 01 B4 06 Heap(929, 0) offset: 000D6802
0027: A2 03 40 B4 06 Heap(930, 0) offset: 000D6880
0027: A4 03 6F B4 06 Heap(932, 0) offset: 000D68DE
0027: A5 03 9E B4 06 Heap(933, 0) offset: 000D693C
0027: A6 03 BC B4 06 Heap(934, 0) offset: 000D6978
0027: A7 03 F6 B4 06 Heap(935, 0) offset: 000D69EC
0027: A8 03 29 B5 06 Heap(936, 0) offset: 000D6A52
0027: A9 03 94 B5 06 Heap(937, 0) offset: 000D6B28
0027: AA 03 DF B5 06 Heap(938, 0) offset: 000D6BBE
0027: AB 03 FD B5 06 Heap(939, 0) offset: 000D6BFA
0027: AD 03 18 B6 06 Heap(941, 0) offset: 000D6C30
0027: AE 03 4E B6 06 Heap(942, 0) offset: 000D6C9C
0027: AF 03 6C B6 06 Heap(943, 0) offset: 000D6CD8
0027: B0 03 49 BA 06 Heap(944, 0) offset: 000D7492
0027: B1 03 79 BA 06 Heap(945, 0) offset: 000D74F2
0027: B2 03 A5 BA 06 Heap(946, 0) offset: 000D754A
0027: B3 03 C0 BA 06 Heap(947, 0) offset: 000D7580
0027: B4 03 F6 C3 06 Heap(948, 0) offset: 000D87EC
0027: B5 03 B0 C8 06 Heap(949, 0) offset: 000D9160
0027: B6 03 DA C8 06 Heap(950, 0) offset: 000D91B4
0027: B7 03 3C C9 06 Heap(951, 0) offset: 000D9278
0027: B8 03 67 C9 06 Heap(952, 0) offset: 000D92CE
0027: B9 03 2C CB 06 Heap(953, 0) offset: 000D9658
0027: BA 03 55 CB 06 Heap(954, 0) offset: 000D96AA
0027: BB 03 C7 CB 06 Heap(955, 0) offset: 000D978E
0027: BC 03 F0 CB 06 Heap(956, 0) offset: 000D97E0
0027: BE 03 11 CC 06 Heap(958, 0) offset: 000D9822
0027: C1 03 1A CC 06 Heap(961, 0) offset: 000D9834
0027: C3 03 39 CC 06 Heap(963, 0) offset: 000D9872
0027: C4 03 62 CC 06 Heap(964, 0) offset: 000D98C4
0027: C7 03 89 CC 06 Heap(967, 0) offset: 000D9912
0027: C8 03 AF CC 06 Heap(968, 0) offset: 000D995E
0027: C9 03 D3 CC 06 Heap(969, 0) offset: 000D99A6
0027: CA 03 ED CC 06 Heap(970, 0) offset: 000D99DA
0027: CB 03 14 CD 06 Heap(971, 0) offset: 000D9A28
0027: CC 03 3C CD 06 Heap(972, 0) offset: 000D9A78
0027: CD 03 63 CD 06 Heap(973, 0) offset: 000D9AC6
0027: CE 03 8B CD 06 Heap(974, 0) offset: 000D9B16
0027: CF 03 9F CD 06 Heap(975, 0) offset: 000D9B3E
0027: D0 03 C4 CD 06 Heap(976, 0) offset: 000D9B88
0027: D1 03 1C CE 06 Heap(977, 0) offset: 000D9C38
0027: D2 03 5C CE 06 Heap(978, 0) offset: 000D9CB8
0027: D4 03 B0 CE 06 Heap(980, 0) offset: 000D9D60
0027: D5 03 D8 CE 06 Heap(981, 0) offset: 000D9DB0
0027: D6 03 25 CF 06 Heap(982, 0) offset: 000D9E4A
0027: D7 03 2E CF 06 Heap(983, 0) offset: 000D9E5C
0027: D8 03 81 CF 06 Heap(984, 0) offset: 000D9F02
0027: D9 03 CC CF 06 Heap(985, 0) offset: 000D9F98
0027: DA 03 E4 CF 06 Heap(986, 0) offset: 000D9FC8
0027: DB 03 10 D0 06 Heap(987, 0) offset: 000DA020
0027: DC 03 B6 D0 06 Heap(988, 0) offset: 000DA16C
0027: DD 03 04 D1 06 Heap(989, 0) offset: 000DA208
0027: DE 03 29 D1 06 Heap(990, 0) offset: 000DA252
0027: DF 03 5E D3 06 Heap(991, 0) offset: 000DA6BC
0027: E0 03 AF D3 06 Heap(992, 0) offset: 000DA75E
0027: E1 03 71 D4 06 Heap(993, 0) offset: 000DA8E2
0027: E2 03 8C D4 06 Heap(994, 0) offset: 000DA918
0027: E3 03 20 D6 06 Heap(995, 0) offset: 000DAC40
0027: E4 03 85 D6 06 Heap(996, 0) offset: 000DAD0A
0027: E6 03 D7 D6 06 Heap(998, 0) offset: 000DADAE
0027: E7 03 A4 D7 06 Heap(999, 0) offset: 000DAF48
-
yup, it's still broken. I'll make sure to test it properly this time ;-)
-
(Is this for a SCI0 game? Shouldn't really need to use text resources for SCI 1.1).
What are the *.TEX resources?
-
They're the text resources, same as in SCI0. But in SCI1.1 games they tend to only be used for debugging purposes. Everything a regular player sees comes from the message resources.
-
Version 3.0.0.6 has been released. "Debugging" support, bug fixes, updates to the template game, polygon point edit box, and more! See the release notes in this threads first post for more details.
-
Yay!
In other news: why yes, yes indeed this is the bastard love-child of Gabriel Knight and Larry 6 why do you ask?
-
Looking good!
-
I'd like to note that the feature builder is also great.
-
Exporting messages... should it also export the include file if it exists?
During development the file would exist, but not after release...
Also, on that note. I am going forward with development. Test it like you use it right? Anyway it has become a pretty tedious task to convert the work I have completed over to a new template each time. Could you please log any template changes going forward so that I can just make those changes and not have to do this copy and pasting again.
As well, is there a way to change the default global palette. So that I don't have to import the palette that I am using with every new pic?
-
Also, on that note. I am going forward with development. Test it like you use it right? Anyway it has become a pretty tedious task to convert the work I have completed over to a new template each time. Could you please log any template changes going forward so that I can just make those changes and not have to do this copy and pasting again.
I can try to do a better job of listing the changes. Are you using a diffing tool, like windiff or something? That would make it easy to see all the changes. (fyi, I'm thinking of changing SetUpPolys_n to SetUpDefaultPolys_n, to emphasize that named polygons won't be included).
I'd love to find a way to avoid having to specify the room number in the SetUpPolys procedure name. But I want to support a room importing two different pic's polygon headers (in case a room switches pics, which is definitely a scenario).
As well, is there a way to change the default global palette. So that I don't have to import the palette that I am using with every new pic?
Hmm, not sure where that default palette is coming from whne you create a new pic... I'll check that out. But anyway, when you import a background, by default it grabs palette 999. So I'm not sure why you're needing to import a palette separately?
-
I'd like to note that the feature builder is also great.
The Sierra feature builder built into the script-based debugging thing?
-
The Sierra feature builder built into the script-based debugging thing?
Crash-prone, but great.
-
As well, is there a way to change the default global palette. So that I don't have to import the palette that I am using with every new pic?
Hmm, not sure where that default palette is coming from whne you create a new pic... I'll check that out. But anyway, when you import a background, by default it grabs palette 999. So I'm not sure why you're needing to import a palette separately?
Yeah, when you create a new Picture from scratch it takes the SQ5 palette from somewhere, but when you import it uses 999 as a base so it's no big deal.
-
Earlier today I wrangled Talkers into a passable state. Just now, I put 'em in a permanent fixture.
It's all very LSL6/GK1-like...
-
Sorry for the doublepost but here's something I've been working on just now, for practice, that I think you guys might like.
-
I like.
-
That looks great! Definitely would like that in the template game!
-
<Screwtape> Don't take this the wrong way, dude, but.. uh, I think you need to vaccum the carpet. And maybe clean the walls.
Y'know what? Looking at existing art, I think Screwy's right. Walls were funky.
-
Do you have a .v56 file for this, or are you still fine-tuning it? I think it looks great - the only slightly weird thing is the shadow on the left. Kind of like this is a movie set and someone just turned on the lights. On the other hand, it gives it some depth.
Also, I think the icons you generated for the template game look a little bit... "disabled" in their regular state. I can try to fix them, but if you have some updated ones on hand that would be great (although it looks like you're using much smaller icons in your current project).
-
Do you have a .v56 file for this, or are you still fine-tuning it? I think it looks great - the only slightly weird thing is the shadow on the left. Kind of like this is a movie set and someone just turned on the lights. On the other hand, it gives it some depth.
Yeah, still got a bit of finetuning to do. Also the table and lamp, y'know? But the shadow is on its own layer and easily removed or altered, so either hand works.
Also, I think the icons you generated for the template game look a little bit... "disabled" in their regular state. I can try to fix them, but if you have some updated ones on hand that would be great (although it looks like you're using much smaller icons in your current project).
I think I get your meaning -- that the dark gray oughta be black, stuff like that. And you know what? I agree.
...Now that you mention my project's icon bar, I'm having some issues with the "ten pixels down" thing so maybe I'll do a combination; keep it about this size, but not permanently visible.
Edit: now with black icons.
Edit?: an inventory is added.
-
Inventory Screen... There is quite a bit of padding that gets added to the end of the item "columns".
The first screen is out of the box, the second is with the code below altered. That should help to show it better than I can explain it.
In the drawInvWindow of the ScrollableInventory class in script 26.
// = temp10 Max((+ 4 theTheTheTheTheTheCurPos_2_2) (* numCols (+ 4 theTheTheTheCurPos)))
= temp10 (+ Max((+ 1 theTheTheTheTheTheCurPos_2_2) (* numCols (+ 1 theTheTheTheCurPos))) 4)
I also changed these values in script 15, the sq5Inv instance of ScrollableInventory
numCols(7) // 5
scrollAmount(7) // 5
dispAmount(14) // 10
-
You must have changed something else (what happened to your up/down arrow icons?). The template game's inventory dialog is thinner.
Also, what was the palette that we had semi-consensus using? Which game was it from?
-
Template uses SQ5 right now, alternative was KQ5/LSL5/many others.
-
The up and down arrows are there... they are just masked right now, I'm assuming cause I haven't reached row three yet. When I replace the mask with a transparent cel, the arrow is visible.
The palette I am using I think is from Hero's Quest, but if I remember, Brandon I think mentioned KQ's palette as a suggestion.
And it is thinner, because in script 15, the number of columns bit. Default is currently 5 and I changed it to show 7 items instead.
... the overall point though, is that the line in the scrollable inventory script, seems to be adding 4 pixels of padding for each item in a row... but the padding seems to be getting added to the end and not between the items like I would expect it to. Also, that would also probably be the cause of the highlight outline overlapping the items beside it. I didn't fix the padding between them, but my edit does remove all of the extra padding for each item and just adds 4 to it once to balance it out.
-
Can anyone find the thread where we discussed this? I can't seem to.
[edit:] found it: http://sciprogramming.com/community/index.php?topic=1442.0
-
Can anyone find the thread where we discussed this? I can't seem to.
[edit:] found it: http://sciprogramming.com/community/index.php?topic=1442.0
Damned smartphone and sleep deprivation slowing me down :D
-
Let me see if I can whip up a little palette conversion tool for view resources to make this easier....
-
... the overall point though, is that the line in the scrollable inventory script, seems to be adding 4 pixels of padding for each item in a row... but the padding seems to be getting added to the end and not between the items like I would expect it to. Also, that would also probably be the cause of the highlight outline overlapping the items beside it. I didn't fix the padding between them, but my edit does remove all of the extra padding for each item and just adds 4 to it once to balance it out.
Before I make an official fix to the template game, I'd need to understand the real underlying issue. i.e. find out why the highlight is overlapping, instead of just adjusting the padding so it looks good in one situation.
-
Version 3.0.0.7 has been released.
Main points:
- cloudee's wav issue hopefully fixed
- named polygons supported. Create these by name from code, and do with them as you please. This should be the final piece of polygon editor functionality. Just bug fixes from here on out. See the template game thread for updates needed.
- fake ego can observe polygons
I think SCI Companion 3 is essentially feature complete at this point. I can't think of any big pieces of critical functionality that are missing. It should be mainly bug fixes and polish from here on, and also finalizing the template game.
My next order of business might be to make a little "explore SCI1.1 features" game, which could help flesh out the documentation for the various kernel and template game functionality.
-
There's some seriously gnarly shit going down with the pic resources here, when you look at them in SV. Oddly, they clearly render just fine at runtime, both the template scene and what's supposed to be one of those close-up portraits.
Incidentally, this appears to be a bug in SV.exe. The pic/view image data compression can encode series of raw bytes in chunks of up to 63, or up to 127 via a different encoding marker. SV.exe doesn't appear to handle the >63 case, and I actually can't find any Sierra games that use it.
So I'm not sure how anyone figured out that the interpreter actually supported that (I forget where I got the specs from... if they were documented, or I looked at scummvm or something).
Oh, ok... there must be some game that uses it somewhere. In the ScummVM code, it makes a reference to fixing bug #3135872. But I can't seem to find that in any bug database, so I don't know what games it involved.
Anyway, I can fix SCI Companion so it only uses the <= 63 marker.
-
It seems to be this: http://sourceforge.net/p/scummvm/bugs/5551/ (http://sourceforge.net/p/scummvm/bugs/5551/)
I had to dig a little to find it, the Git log incorrectly says that this was in the Spanish version, but it's actually the Polish fan version. The bad view is attached to the bug for testing purposes.
-
Speaking of polish, you can use this link for the tutorials.
http://sciprogramming.com/tutorial.php?entry=6693
I know they aren't anywhere near complete yet, but this is where the tutorial index for sci 1.1 and shouldn't change between now and then.
-
Just found out while making some polygons for the sample room, that there's a hall of mirrors in the right-hand gutter of the picture editor.
-
Haha, yup. It's just a painting issue luckily. Sorry about that. Already fixed for the next update!
-
Here ya go, as promised. Polygons on the floor, table, and lamp, priorities on the table and lamp, and controls on the doorway, set up like in the SCI0 version.
-
Great. I've incorporated it into the template game (had to add a priority fill to the back wall though). I guess I'll add a second empty room that you go to after entering the doorway.
-
For the record, here's what it looks like when you put a whole bunch of items in an inventory window that has had no changes other than its iconbar.
-
SCI Companion now crashes when opening any editor under Wine. Used to work.
Backtrace:
=>0 0x0053ed64 in scicompanion (+0x13ed64) (0x0032ca70)
1 0x0053ed0a in scicompanion (+0x13ed09) (0x0032ca8c)
2 0x0053f040 in scicompanion (+0x13f03f) (0x0032caf4)
3 0x004669c2 in scicompanion (+0x669c1) (0x0032cb18)
4 0x004c77b1 in scicompanion (+0xc77b0) (0x0032cb2c)
5 0x006df7d8 in scicompanion (+0x2df7d7) (0x0032cbe8)
6 0x006e0a5b in scicompanion (+0x2e0a5a) (0x0032cc08)
7 0x006dc17d in scicompanion (+0x2dc17c) (0x0032cc78)
8 0x006dc901 in scicompanion (+0x2dc900) (0x0032cc98)
9 0x7eb86d1a WINPROC_wrapper+0x19() in user32 (0x0032ccc8)
10 0x7eb87456 in user32 (+0xa7455) (0x0032cd18)
11 0x7eb89d8b CallWindowProcA+0x5a() in user32 (0x0032cd60)
12 0x00610e23 in scicompanion (+0x210e22) (0x0032cda8)
13 0x00611de4 in scicompanion (+0x211de3) (0x0032cde8)
14 0x7eb86d1a WINPROC_wrapper+0x19() in user32 (0x0032ce18)
15 0x7eb87456 in user32 (+0xa7455) (0x0032ce68)
16 0x7eb87999 in user32 (+0xa7998) (0x0032d338)
17 0x7eb89cc6 in user32 (+0xa9cc5) (0x0032d388)
18 0x7eb4864d in user32 (+0x6864c) (0x0032d3e8)
19 0x7eb4feb6 in user32 (+0x6feb5) (0x0032d458)
20 0x7eb50149 SendMessageW+0x58() in user32 (0x0032d4a8)
21 0x7eb3808b in user32 (+0x5808a) (0x0032d4f8)
22 0x7eb3907b DefMDIChildProcW+0x3fa() in user32 (0x0032d568)
23 0x7eb394fa DefMDIChildProcA+0x159() in user32 (0x0032d5d8)
24 0x006f895f in scicompanion (+0x2f895e) (0x0032d5fc)
25 0x006e0a72 in scicompanion (+0x2e0a71) (0x0032d618)
26 0x006dc17d in scicompanion (+0x2dc17c) (0x0032d688)
27 0x006dc901 in scicompanion (+0x2dc900) (0x0032d6a8)
28 0x7eb86d1a WINPROC_wrapper+0x19() in user32 (0x0032d6d8)
29 0x7eb87456 in user32 (+0xa7455) (0x0032d728)
30 0x7eb87999 in user32 (+0xa7998) (0x0032dbf8)
31 0x7eb89cc6 in user32 (+0xa9cc5) (0x0032dc48)
32 0x7eb4864d in user32 (+0x6864c) (0x0032dca8)
33 0x7eb4feb6 in user32 (+0x6feb5) (0x0032dd18)
34 0x7eb50149 SendMessageW+0x58() in user32 (0x0032dd68)
35 0x7eb851e0 in user32 (+0xa51df) (0x0032de98)
36 0x7eb821d7 SetWindowPos+0xc6() in user32 (0x0032df28)
37 0x7eb7e92f in user32 (+0x9e92e) (0x0032e0f8)
38 0x7eb76bcf CreateWindowExA+0x18e() in user32 (0x0032e388)
39 0x7eb3ab85 in user32 (+0x5ab84) (0x0032e438)
40 0x7eb86fee in user32 (+0xa6fed) (0x0032e468)
41 0x7eb86d1a WINPROC_wrapper+0x19() in user32 (0x0032e498)
42 0x7eb87456 in user32 (+0xa7455) (0x0032e4e8)
43 0x7eb89d8b CallWindowProcA+0x5a() in user32 (0x0032e530)
44 0x00610e23 in scicompanion (+0x210e22) (0x0032e578)
45 0x00611de4 in scicompanion (+0x211de3) (0x0032e5b8)
46 0x7eb86d1a WINPROC_wrapper+0x19() in user32 (0x0032e5e8)
47 0x7eb87456 in user32 (+0xa7455) (0x0032e638)
48 0x7eb89c23 in user32 (+0xa9c22) (0x0032e688)
49 0x7eb4864d in user32 (+0x6864c) (0x0032e6e8)
50 0x7eb4feb6 in user32 (+0x6feb5) (0x0032e758)
51 0x7eb525a1 SendMessageA+0x60() in user32 (0x0032e7a8)
52 0x006f8842 in scicompanion (+0x2f8841) (0x0032e820)
53 0x006f8bc9 in scicompanion (+0x2f8bc8) (0x0032e864)
54 0x00704be2 in scicompanion (+0x304be1) (0x0032e898)
55 0x006e7cd6 in scicompanion (+0x2e7cd5) (0x0032e8c8)
56 0x006e7c8e in scicompanion (+0x2e7c8d) (0x0032e8dc)
57 0x00415c04 in scicompanion (+0x15c03) (0x0032e91c)
58 0x004c1942 in scicompanion (+0xc1941) (0x0032e928)
59 0x004c1992 in scicompanion (+0xc1991) (0x0032e938)
60 0x006e36fc in scicompanion (+0x2e36fb) (0x0032e950)
61 0x006e3515 in scicompanion (+0x2e3514) (0x0032e980)
62 0x006dfdfd in scicompanion (+0x2dfdfc) (0x0032e9a8)
63 0x006e048b in scicompanion (+0x2e048a) (0x0032e9c4)
64 0x006dff38 in scicompanion (+0x2dff37) (0x0032ea60)
65 0x006def37 in scicompanion (+0x2def36) (0x0032ea8c)
66 0x006df347 in scicompanion (+0x2df346) (0x0032eb48)
67 0x006e0a5b in scicompanion (+0x2e0a5a) (0x0032eb68)
68 0x006dc17d in scicompanion (+0x2dc17c) (0x0032ebd8)
69 0x006dc901 in scicompanion (+0x2dc900) (0x0032ebf8)
70 0x7eb86d1a WINPROC_wrapper+0x19() in user32 (0x0032ec28)
71 0x7eb87456 in user32 (+0xa7455) (0x0032ec78)
72 0x7eb87999 in user32 (+0xa7998) (0x0032f148)
73 0x7eb89cc6 in user32 (+0xa9cc5) (0x0032f198)
74 0x7eb4864d in user32 (+0x6864c) (0x0032f1f8)
75 0x7eb4feb6 in user32 (+0x6feb5) (0x0032f268)
76 0x7eb50149 SendMessageW+0x58() in user32 (0x0032f2b8)
77 0x7e593f14 in comctl32 (+0x33f13) (0x0032f2f8)
78 0x7e59a40c in comctl32 (+0x3a40b) (0x0032f3b8)
79 0x7e5a61cb in comctl32 (+0x461ca) (0x0032f498)
80 0x7e5acf86 in comctl32 (+0x4cf85) (0x0032f588)
81 0x7eb86d1a WINPROC_wrapper+0x19() in user32 (0x0032f5c8)
82 0x7eb87456 in user32 (+0xa7455) (0x0032f618)
83 0x7eb88d96 in user32 (+0xa8d95) (0x0032fad8)
84 0x7eb89df8 CallWindowProcA+0xc7() in user32 (0x0032fb1c)
85 0x006dd744 in scicompanion (+0x2dd743) (0x0032fb3c)
86 0x006e0a72 in scicompanion (+0x2e0a71) (0x0032fb58)
87 0x006dc17d in scicompanion (+0x2dc17c) (0x0032fbc8)
88 0x006dc901 in scicompanion (+0x2dc900) (0x0032fbe8)
89 0x7eb86d1a WINPROC_wrapper+0x19() in user32 (0x0032fc18)
90 0x7eb87456 in user32 (+0xa7455) (0x0032fc68)
91 0x7eb89c23 in user32 (+0xa9c22) (0x0032fcb8)
92 0x7eb4a616 DispatchMessageA+0xb5() in user32 (0x0032fdc8)
93 0x006ecddc in scicompanion (+0x2ecddb) (0x0032fe00)
94 0x0084640a in scicompanion (+0x446409) (0x0032fe14)
95 0x00812cf2 in scicompanion (+0x412cf1) (0x0032fe6
-
Any editor at all? I know I introduced a bad (read) buffer overrun bug in the pic editor (luckily no one else seems to be hitting it!). I can supply a binary with a fix, but if this is happening in any editor, it's probably something different.
-
Does it repro with the version at this link (http://icefallgames.com/Downloads/SCICompanion-Temp.zip)?
(symbols are included here too)
-
Right, so the backtrace with symbols looks like this:
=>0 0x0053ece1 PicCommandSidePane::_SyncPolyChoice+0x51() in scicompanion (0x0032ca70)
1 0x0053ec73 PicCommandSidePane::UpdateNonView+0x162(pObject=0x32cac0) in scicompanion (0x0032ca8c)
2 0x0053ef80 PicCommandSidePane::SetDocument+0x4f(pDoc=(nil)) in scicompanion (0x0032caf4)
3 0x00466a4f CMainFrame::_RefreshToolboxPanelOnDeactivate+0x6e(pWnd=0x196c9c0) in scicompanion (0x0032cb18)
...
Unfortunately, Winedbg does not understand the line number info, so I used IDA Pro to locate the faulting instruction instead (see image). PicCommandSidePane... and this happens in all the editors. :o
Looks like it should be skipping this code under normal circumstances? Is there a stale INI file or registry setting I need to get rid of somewhere?
-
Ok, I think I found the problem. I won't have time to build a fix until tomorrow though. This is bad, but it's just a first-chance exception and should be caught and handled... at least it is under Windows (so that's why others aren't hitting it). Not sure why that isn't happening under Wine?
-
Feature request:
In the palette editor, the ability to tint an entire palette a certain colour value with a variable degree of intensity (0% to 100% selectable). Actually three different methods of this action would be welcome:
1) Tint the entire palette (all 255 colours, exempting the last colour as it's never used(?))
2) Tint all the colours after the first default colours (64 to 254)
3) Select a custom range of colours to tint a certain colour, much like the current gradient creation function
...actually those last two could even just be the same thing. If one wants to convert all the colours from 64-254, they'd need only select them.
Purpose:
Making alternate tinted palettes of a regular background is useful for changing the atmosphere of an area. For instance, if you had alternate palettes tinted yellow, red, and blue, you could implement a visual day/night cycle system much like QFG1VGA. During daytime the palette would be normal. As the game timer approaches "dusk" it can slowly fade into the yellow tinted palette for a sunset-like aesthetic, and then eventually fade into a dark blue tinted palette for nighttime. Another example would be the cryofreeze machine on the Eureka in SQ5 where Roger much freeze Beatrice to slow the mutation process to buy him time to save her life. He can freeze her which show Beatrice changing from her normal palette into a blue-tinted palette or "cook" her which shifts her into a red-tinted palette. There are other examples all through SQ5 of palette shifting occurring between different tints like the introduction sequence when Roger's getting out of the bridge simulator and the shot of Roger's shuttle taking him to the Eureka for the first time (the screen flashes red and fades back to normal for an instant as the shuttle, with its engines facing the camera, comes from the camera and flies towards the ship. These are not palette cycling effects but palette transitioning effects. I'd love to work on a day/night cycle type system example if this functionality could be added. There's nothing like this that can be easily done with conventional image editors, even ones that use 8-bit palettes as a base like Deluxe Paint. At least I haven't figured out how. This would be just an easy quick thing you could in Companion without ever leaving it to quickly make alternate palettes.
EDIT: Actually, upon experimentation it's actually quite easy to do this in both Deluxe Paint and Grafx2. I could even do it in PSP, but it only works on the entire palette. Either way, it would still be nice to be able to do this quickly in Companion as it's a fairly simple step for something fairly necessary for some advanced palette usage to have to jump out into a third party program to accomplish.
Another feature that might be beneficial for playing with something like this is the ability to preview a Picture with other palettes (either from a selection of PAL resources, embedded palettes from other PICTURE resources, or importing a new palette). SCI Viewer can already do this natively, minus the imported palette option. I see that Companion can already preview in the editor with other palettes.
-
So I got in contact with NRS about making Patch tools for SCI1 and SCI1.1. According to him (and my tests) it turns out that SCI0-SCI1.1 Patch resources are all the same format! So the current tools we have work for SCI1.1! I can't believe I never bothered to try this before. I just figured they were different. The only problem it seems is that SCI1.1 games no longer support text messages on the MT-32's LCD screen. :( Not sure why Sierra dropped that, but that's sad indeed. NRS did say that he would look into support for General MIDI native games (I assume he's talking about post-SCI1.1).
-
Regarding all the extra "demo" content for the template game, I think we should keep the template game as cut down as possible. Even remove the current screens and keep it as simple as SCI0's template game; a blank slate. Black title screen and an all white empty first room with basic interactions. Any feature/tutorial content we can rename the current template game into Demo Game, like Brian did for SCI0. But a starter game should always be a blank slate. Just a thought.
-
Regarding all the extra "demo" content for the template game, I think we should keep the template game as cut down as possible. Even remove the current screens and keep it as simple as SCI0's template game; a blank slate. Black title screen and an all white empty first room with basic interactions. Any feature/tutorial content we can rename the current template game into Demo Game, like Brian did for SCI0. But a starter game should always be a blank slate. Just a thought.
Cat.sc, all these unused .sco files like Flo and Droole...
-
Another feature that might be beneficial for playing with something like this is the ability to preview a Picture with other palettes (either from a selection of PAL resources, embedded palettes from other PICTURE resources, or importing a new palette). SCI Viewer can already do this natively, minus the imported palette option. I see that Companion can already preview in the editor with other palettes.
Can you describe in a little more detail? What I can see doing is to have the same functionality in the pic editor as there is in the view editor, where you can choose the palette to display the picture in. The list consists of the embedded palette, and all the pal resources in the game. Would that suffice?
Extracting palettes from other pics is probably not something I can do in UI-time (so I'd need to do this in the background or something), so having those in the list would be more difficult.
Regarding all the extra "demo" content for the template game, I think we should keep the template game as cut down as possible. Even remove the current screens and keep it as simple as SCI0's template game; a blank slate. Black title screen and an all white empty first room with basic interactions. Any feature/tutorial content we can rename the current template game into Demo Game, like Brian did for SCI0. But a starter game should always be a blank slate. Just a thought.
I agree with this. Once the template game is "finalized", I can make a final version with all the cruft removed.
-
Cat.sc, all these unused .sco files like Flo and Droole...
I'm pretty sure I removed all extraneous sco/sc files from the template game a while ago. (Flo and such are gone).
Cat.sc I left in, as I don't know it's purpose. It seems like a general purpose Actor class, but I'm not sure what it does.
-
Cat.sc I left in, as I don't know it's purpose. It seems like a general purpose Actor class, but I'm not sure what it does.
Searching for: [^o]cat[^i]
Cat.sc(9): (class Cat of Actor
ClickMenu.sc(103): StrCat(@temp8 ": ")
ClickMenu.sc(105): StrCat(@temp8 " ")
ClickMenu.sc(106): StrCat(text @temp8)
Obj.sc(234): (if (not (self:isDuplicate(param1[temp1])))
Obj.sc(336): (method (isDuplicate)
Obj.sc(385): (if (not (self:isDuplicate(param1[temp0])))
Obj.sc(402): (if (not (self:isDuplicate(param1[temp0])))
Obj.sc(419): (if (not (self:isDuplicate(param2[temp0])))
Obj.sc(456): (method (isDuplicate param1)
rm1000.sc(107): (catwalk:
rm1000.sc(799): (instance catwalk of Feature
rm1001.sc(64): (catwalk:
rm1001.sc(438): (instance catwalk of Feature
Sq5InvItem.sc(119): add(Buckazoids {Floor Scrubber} {Safety Cones} {Distributor Cap} {Transporter Fuse} Antacid {Ship Opener} {Cutting Torch} Spike {Oxygen Tank} Communicator {Hole Punch} {Cloaking Device} {Space Monkeys Package} {Business Card} {Genetix Canister} {Liquid Nitro Tank} {Kiz Branch} {Kiz Fruit} frock {WD40 Head} {Oxygen Mask} Paper)
Sq5InvItem.sc(370): (instance Communicator of Sq5InvItem
sysLogger.sc(54): StrCat(@temp0 "
Found 17 occurrence(s) in 7 file(s)Searching for: of Cat
ice\src\controlPanel.sc(452): (instance wheel of Cat
ice\src\controlPanel.sc(1128): (instance diveLever of Cat
ice\src\controlPanel.sc(1192): (instance engineLever of Cat
qfg1v\src\Rock.sc(352): (instance lasso of Cat
Found 4 occurrence(s) in 2 file(s)It doesn't seem to be used much at all.
-
Can anyone who played those games guess how it might have been used? It appears to be an animated object that you can click and drag.
-
Version 3.0.0.8 released a fix for the crash and a number of other improvements.
-
If previewing palettes in the Pic editor like you've already got done in the View editor is the easiest thing to do then that will suffice, yes.
-
Can anyone who played those games guess how it might have been used? It appears to be an animated object that you can click and drag.
Might be why it was called Cat then, i.e. because it interacts with the "mouse" in a certain way. Does it "catch" the mouse in some manner? I haven't yet looked at the source, so just thinking about what the name might mean.
-
Yeah, haha, that makes sense. It looks like it is just a view that follows the mouse when you drag on it. Not terribly useful, it can probably be removed.
-
Maybe not for games as such. It could be useful for toolmaking though.
-
SQ5 must have used it in that scene where you're rummaging through the tool box. That's pretty useful. Think puzzle minigames.
-
SQ5 must have used it in that scene where you're rummaging through the tool box. That's pretty useful. Think puzzle minigames.
False.Searching for: of Cat
Searching for: Cat
Cat.sc(9): (class Cat of Actor
ClickMenu.sc(103): StrCat(@temp8 ": ")
ClickMenu.sc(105): StrCat(@temp8 " ")
ClickMenu.sc(106): StrCat(text @temp8)
sysLogger.sc(54): StrCat(@temp0 "
Found 5 occurrence(s) in 3 file(s)
The relevant script seems to be Tool.sc, actually rm226.
-
Ah! It was only a guess.
-
Here's something that I really felt I missed while working on my Larry-style question list: importing and exporting message tables in plaintext. Preferrably in the format used by SV, which is basically tab-delimited.
-
Would you want the nouns etc in number form or N_* form? Or both?
-
My personal preference would go towards numerical, but I supposes a switch would be good.
Interesting detail on newlines in messages as SV exports them:1 0 0 2 98 This is the first line.
This is the second.
1 0 0 3 98 This is another message.If a line starts with five tabs, it's part of the last message that didn't. So no "This is the first line.\nThis is the second."
-
Interesting. Yeah, seems like that's necessary, as text can contain tabs too. Without the 5 "empty" tabs there would be some ambiguity.
-
The template game is set to Disney Sound Source by default. This seems to mess up one's audio bigtime. Mᴀᴋᴇs ᴇᴠᴇʀʏᴛʜɪɴɢ sᴏᴜɴᴅ ʟᴏᴡᴇʀ.
For my main project, I have removed all drivers but General MIDI and Sound Blaster for music and audio respectively, but this really threw off my research.
-
Are you running in DOSBox or on windows directly?
I switched it to the disney audio driver by default, since we found the audio didn't work with the soundblaster (I think it was that one?). Switching to disney made it work. So this is definitely different than what you're experiencing.
-
DOSBox. 11k or 22k, both played slow on Disney, fine on SB.
-
The SQ5 SB driver does work.
-
The SQ5 SB driver does work.
Ah, indeed, it appears to.
And now I'm able to repro the "too low" problem with the DISNY driver. It looks like it only happens with 22Khz sounds though. I tried 11Khz (both 8 and 16 bit) and they sounded ok.
In all instances, the SQ5 audblast sounds better, though there was some static with 22Khz sounds.
So should we standardize on the audblast from, SQ5?
For both drivers, there were looping glitches for the 16 bit sounds. Take a sound that has a clean beginning or end and tell me if when you loop it it gets choppy.
-
I vote for AUDBLAST if it works. Again, I selfishly need these babies functioning on a 486.
-
I vote for AUDBLAST, too. Compatibility on old hardware is a legitimate consideration. Many do keep old dinos around for gaming. It is also why no drivers should be removed from the template game. While DOSBox does not emulate all hardware that Sierra provided hardware for, at the very least drivers for what it does emulate should be included. We could even include one of the aftermarket GUS drivers Sierra released. This one works with SQ5.
-
guys i think i broke my status line
(http://i.imgur.com/miBf7XE.png)
-
SCI Companion doesn't support 320x200 pics, which some SCI1.1 games have. Is that something people are interested in?
-
The more options the better, as long as it is not too much trouble.
-
SCI Companion doesn't support 320x200 pics, which some SCI1.1 games have. Is that something people are interested in?
Considering I just faked it, I'd say at least one people is interested :D
-
Interesting. Which games have 320x200 pics? Does the current template interpreter support it?
-
In LSL6: pic 100, 410, 570, 580 and more (so yes, currently template interpreter must support it)
In SQ5: pic 49, 56, 82, 100 and more.
They're actually fairly common, I guess typically used in scenes where there is no status bar. I doesn't appear to be supported in SCI1.0 (at least, I don't see any pics that big).
I don't think there's a "size" flag anywhere, it just depends on the size of the bitmap image included in the pic I guess. I never supported it for SCI Companion, because I wasn't sure of the specs.
The crappy thing is that I've hard-coded the size in so many places, when I really didn't need to!
-
What about scrolling screens like in SQ1. I have never looked at it close enough to see if it was done with two pics side by side or one double wide pic.
While I would like to see support for working with SCI1 games I do not see much point in adding anything that you might want for creating a new SCI1 game unless it also applies to SCI1.1.
-
What about scrolling screens like in SQ1. I have never looked at it close enough to see if it was done with two pics side by side or one double wide pic.
I did, and I checked it just now. It's two regular-sized pics side-by-side with a dpOPEN_SCROLL_something transition. King's Quest 7 on the other hand...
-
Of course KQ7 is an SCI2.1 game.
-
Of course KQ7 is an SCI2.1 game.
That was the joke ;)
-
Yeah those are reg screens. SCI01 has them too. I've been trying to recreate it in my project but it hasn't been working for some reason.
-
Using dpOPEN_SCROLL_RIGHT (or one of the other three) for the room style doesn't work?
Also note that the two screens will need to have the same palette, or it'll look bad.
-
Interesting. Which games have 320x200 pics? Does the current template interpreter support it?
SQ5 pic 128 is actually 201 pixels high! Not sure why...
-
What I'd like to know is how to show 'em at their full height.
-
Hmm, yeah... it displays them 10 pixel down from the top, doesn't it? Even if you hide the status bar.
-
The kernel call you need is called SetPort. There is a long form and a short form, and for this you need the long form. Something like:
SetPort(0 0 200 320 0 0)
and
SetPort(0 0 190 320 10 0)
to reset it afterwards (which you absolutely must do). The short form is used to draw things like dialog box borders (the reason being that they are logically outside the extent of the dialog box) and custom menu bars.
Both of these only affect future draw commands. So you'd typically sandwich a super:init() or a drawPic between two SetPort calls.
-
Sure enough, that works! (Originally, I poked around in the SQ5 code for one of the rooms that use a 320x200 pic, but didn't see any SetPort calls, so I assumed it was something else that was needed).
(attached image of template game with a 320x200 pic from SQ5 (left palette cycling in, obviously)).
-
Cool!
Using dpOPEN_SCROLL_RIGHT (or one of the other three) for the room style doesn't work?
Also note that the two screens will need to have the same palette, or it'll look bad.
No, but if you recall the other thread I made, it was something to do with setting the style property before calling the superclass. I just haven't gone back to it yet.
-
Turns out SCI 1.0 supports 200 pixel high bitmaps too.
-
Got my 320x200 pics ready and rendering... as 320x190 with a white bar on the bottom, because I can't import them right yet ;D
-
Lol, good, because an update is forthcoming to support 200px high images. ;)
-
Lol, good, because an update is forthcoming to support 200px high images. ;)
But John came fifth and won a toaster.
Good night!
-
Wow this is really cool. We could get rid of the status bar altogether if we wanted to. Make an Full Throttle-type game that uses the full screen.
-
I was thinking of a 24-style split screen display. I don't know if that's even doable, though I suspect not.
-
Could something like that be feigned by making a selection of Picture resources that only take up a portion of the whole image area and draw a new Picture with its contents in a different area on top (like you can in SCI0)? If you use the transparent colour in the palette (255) in an image, can you make part of an image transparent with that colour so that another Picture can show beneath it? If so, ports wouldn't be necessary. Of course that method would be limited. You wouldn't be able to impose the same picture in say a portion on the top half of the screen and also on the bottom half without two separate Picture resources, not that file size is a problem.
-
Could something like that be feigned by making a selection of Picture resources that only take up a portion of the whole image area and draw a new Picture with its contents in a different area on top (like you can in SCI0)?
That's basically what I did with a view for the top part when this subtopic started.
-
Okay so here's an observation.
Windows Western: ??????????????????????????? ?????????????? etc.
DOS US: ??????????????????????????ܢ??₧??????Ѫ??⌐?????? etc.
SCI: the same, until ???????????????????? and then finally a '?' where WinWestern would have '?'.
Now, the font editor labels each character as in Windows, so for example '?' is labelled "? (165)". Similarly, code, text, and message editors don't show the actual accented characters:"We've got to do this\nfast! Shield your eyes!"#G"Wir m?ssen es schnell\nmachen! Sch?tze Deine Augen!"
This is of course rendered in-game as "Wir m?ssen es schnell machen! Sch?tze Deine Augen!". Similar trouble occurs for the various roman numerals in the same game, but those are a lost cause, being numbered lower than 32.
Therefore, I have a few suggestions.
- Have the decompiler use hexcodes for <32 characters: StrCat(@temp1 ($1E " - Latex Babes of Estros"))
- Have the font editor not label characters in Windows Western
- Or have the fonts in the template game adjusted to Windows Western order, or otherwise have such fonts available. I'm willing to provide.
That last option would allow, I think, the most intuitive writing of lines with accented characters such as the example from the German SQ4. And considering what the TTF importer does...
-
There are no fonts with extended characters in the template game. Where are you getting your fonts from?
I agree that having fonts in the template game that match the windows order makes the most sense. It's the least work for me, because it already works (See attached, using a font imported from win32).
If you're willing to provide a set of replacement fonts in the right order, that would be awesome (note that you can re-order characters by dragging on them)! But let's hear others' opinions first.
(Note that this means messages from existing international versions of Sierra games won't display properly in the message editor, but that is already the case).
Another option is to have a mapping table that converts between the text you type and the message resource data (and vice verse for displaying them in the message editor). But I think that brings more problems, since I assume some characters aren't available in one set or the other. And then I'd also need to do something special when importing a windows font.
[edit:] Well ok, it might actually be pretty easy to convert between character sets. Do all Sierra games use the "DOS US" character set? Are there any letters that are needed that aren't there?
-
Do all Sierra games use the "DOS US" character set?
I only have Space Quest 4 to compare against, but besides the missing characters in its fonts (all but ? and ? are missing once you pass ?), codepage 437 as it's properly called simply isn't as exhaustive. You don't need box-drawing characters when you can simply draw a box any which way you want, nor do you need dithering or half-width blocks.
-
Version 2.0.0.9 has been released with some exciting changes! Details in the first post of this thread as usual.
Summary:
- importing wavs is much more flexible (no longer need to downsample or convert to mono in another app)
- message import/export to text files
- support for 200px high pics
- support for palette tinting/HSL adjustment, and previewing palettes for pics
-
:D :D :D
I absolutely love the palette tint/adjust feature. It works wonderfully! Thank you!
-
I think you might've meant to call that one palette sample "King 6" :D
Edit: half of Sierra System and all of Sierra Debug left to expand/convert to Win-1252. ? and ? are in there twice, once for compatibility and once to actually type (what, you can't type a ?? you poor unfortunate soul), and the tab character is a wide spacer, in lieu of actual tab stops.
-
Lol, you're right about King 6.
Only one of those fonts matches that in the template game, right? (Sierra Small A, which matches 004). I guess I can add others as "font samples", but I'd like to keep the same fonts in the template game because of sizing issues.... or.... maybe I can play around and see which ones we can substitute? Any recommendations?
-
fyi, here are codepage 437 versions of the other SQ5 extended charset fonts in the template game. If you have time to apply your magic to them.... ;-)
-
I'm sure I'll have plenty time between figuring out the latest horseplop (http://sciprogramming.com/community/index.php?topic=1466) thrown my way.
Edit: okay, now that that horse is back in the stable, here's a thing. The mass resource export function is great, but... what's a curosr? :D
-
but... what's a curosr? :D
A finger spoonerism.
-
And here's Sierra Debug 1252.
Related: the default colors in the font editor are left-white, right-black. I feel this really ought to be inverted.
-
And here's Sierra Debug 1252.
Related: the default colors in the font editor are left-white, right-black. I feel this really ought to be inverted.
Thank you. In return for your work, the next version of SCI Companion will feature inverted initial edit colors for fonts.
-
Thank you. In return for your work, the next version of SCI Companion will feature inverted initial edit colors for fonts.
Oh yeeeaaah~
-
I'm adding support for a few things that will make it a lot easier if you are "importing" pics from an EGA game to the SCI 1.1 template.
You should be able to just paste the commands from an EGA pic into a VGA pic. Invalid commands will then be removed (i.e. the EGA palette commands, and the pen commands).
Then, there will be an option to remove all setvisual commands (since you will have pasted the visual screen as the pic background image).
This should get you *most* of the way there. The main remaining problem are the fill bounaries for the pri and control screens. Pen commands have been removed, and the visual lines/etc... have been removed. This means some boundaries have been lost, so you'll need to go back through the vector commands and touch things up here and there.
I'm using this functionality for part of the "explore SCI1.1" sample I'm making, and it only takes a minute or two to import a pic from EGA now.
-
I've almost implemented a "color shifter" dialog. You can select ranges of colors in the image's palette and move them to different parts of the palette (it changes the image data, not the palette). Given the nice way the default palettes are organized, this makes it easy to change the colors of clothing or icons, or increase/decrease their brightness.
Attached image of Roger going from red/grey to purple/blue.
-
Brilliant!! I love palette features...they're so fun! This also works out the problem of supplying a ton of separate sample VIEW resources just for different colours wonderfully.
-
So how good is your image creation Phil. Not that it really matters but for the sake of showing off work, it might be nice to be able to export a loop as an animated gif file. Not for reimporting, but just for sharing.
-
I asked for that before, it's on the list but not a high priority as SV can do it easily enough for now.
-
As people start using SCI Companion a little more, it might become useful. We'll see what I can do.
-
Small update on the small fonts (3 and 4, 999), fixed the . ? and 1.
-
Ok, updated the template game and samples folders with those. Thanks!
Will you have time to do 1605 and 2106? If not, let me know, and I'll try to do them.
-
Hi sorry my local internets is being a fickle bitch and I can't access this server for arbitrary, random spans of time. So here I am posting from my webserver, through a KiTTY session~
I have plenty time to do 1605 and 2106, don't worry. I can still SFTP them up to my stash.
-
#1605 Wilco Smallcaps is done and available from my signature, including some weight loss on # & al. #2106 seems to just be Sierra System with an extra pixel line height, so I think I'd rather just finish 0 instead.
Edit: #0 Sierra System now also available below.
-
#1605 Wilco Smallcaps is done and available from my signature, including some weight loss on # & al. #2106 seems to just be Sierra System with an extra pixel line height, so I think I'd rather just finish 0 instead.
Edit: #0 Sierra System now also available below.
Thanks! Now part of the template game and in the samples folder...
2106 is actually identical to 0 (at least in SQ5, the game where the originals came from). So I'll probably just delete 2106 from the template game?
-
2106 is actually identical to 0 (at least in SQ5, the game where the originals came from). So I'll probably just delete 2106 from the template game?
Guess so?
Any requests?
-
Request: finishing off the default ego view ;-)
I'm cleaning out the template game and reducing it to bare bones right now.
-
One set of diagonals and a good thinking on even/odd widths coming up! ;D
-
SCI Companion version 3.0.0.10 has been released! Full details in the first post of this thread as usual.
A few of the big items:
- gif export!
- support for color shifting (View->Shift Colors) in views, for remapping to different hues/brightness levels.
- the pic background importer has some important new functionality
- you can overlay images on the existing background
- you can explicitly specify which palette entries the imported image is mapped to
This makes it easy, for instance, to have palette cycling applied to a certain region of your image, since you can assign different palette ranges as you add the layers one by one.
-
Oh nice!! Will have fun playing with that new Pic feature!
-
In my stash right now, there are a slight upd0rt on 999.fon (the ? was too low) and a functionally identical but slightly more readable print.sc that replaces things like theTheTheGModNum_3 with the somewhat clearer seq. I haven't done this to addColorButton and addEdit yet, but it certainly cleans up.
-
In my stash right now, there are a slight upd0rt on 999.fon (the ? was too low) and a functionally identical but slightly more readable print.sc that replaces things like theTheTheGModNum_3 with the somewhat clearer seq. I haven't done this to addColorButton and addEdit yet, but it certainly cleans up.
I don't see those there, but I can make those changes too. Yeah, print.sc is kind of a mess still!
-
I must've neglected to actually upload them. Doing so now.
edit: boom (http://helmet.kafuka.org/sci/print.sc)
-
Got it. I can finish off addColorButton and the others.
-
Awesome. I was thinking of going through all these files and renaming paramN and tempN throughout to increase readability. Incidentally, I really feel like blink.sc should be talker.sc, though I understand why it's been given that name.
-
Awesome. I was thinking of going through all these files and renaming paramN and tempN throughout to increase readability. Incidentally, I really feel like blink.sc should be talker.sc, though I understand why it's been given that name.
I agree. I'll make that change.
Talkers are the next thing I'm going to play around with in my "explore SCI1.1" game...
-
Talkers are the next thing I'm going to play around with in my "explore SCI1.1" game...
I'm looking forward to that already.
-
I think I'm misunderstanding how to use the overlay feature in the picture importer. I can't get the overlay to work without wiping out what was already there. I assume it allows you to import pieces of backgrounds in layers, correct? And then assign those "layers" to a different area of the palette?
Here's a request. Can you allow moving around for placing somehow of the imported picture inside the screen if the imported image is smaller than 320x190? Can you also make it transparent-aware? That is, if the shape of the imported image is not a perfect square/rectangle and has transparency applied either by palette or by alpha, when it's imported it appears on top of the original image? Kind of like a "magic wand" select in an image editor. Am I making sense?
-
Your image needs to have alpha transparency for the overlay feature to work. Png format works well. I haven't been able to get the "from clipboard" functionality to work with transparency, I can try taking another look at it.
-
Ahh perfect. That would be why. I was doing all clipboard. So it already works the way I was wanting for the most part. Thanks!
-
What app are you using to make your images? I'm using Photoshop (an old version though - CS2), and it looks like the bitmap format it places on the clipboard (for other apps to use) doesn't support alpha anyway, so I wouldn't be able to retain transparency.
The work flow I've been using has been to work with a 320x190 or 640x380 image in photoshop, and just save the layers individually as needed as png to import into SCI Companion.
-
Hmmm I'm using PSP5. It also doesn't support alpha. PSP7 does, though. I should try that one. I have it as well.
-
A pretty minor thing, but I just noticed the dosbox.conf file. It looks like it came from an ancient version, probably 0.62 (over 10 years old!). The conf has changed over time. It has a number of things that are no longer used and is missing newer sections. While the depreciated settings will be ignored and the missing settings will revert to defaults, it would be good to have one based on official 0.74. Additionally you have the captures folder set to "f:\capture", which I assume is a folder on your development machine.
One thing that I do with my installers is to only include a few settings that can be changed with my config tool and a couple of things that I include so that the user can manually set if they really need to, such as output for PCs that don't like "overlay". DOSBox will simply use its defaults for everything else.
Here is a good generalized conf for SCI games. Cloudee will of course want to change aspect to false. The EXE would need to be changed to for the SCI1.1 template. I have machine included to make it easy to set it to Tandy for AGI games, but could simply be removed for Companion so it will just default to svga_s3.
SCI1-SCI1.1 is the era of the infamous timer bugs, which means for the affected games you would want normal core and cycles from about 8000 to 10000. It might be good to keep this at dynamic core with max cycles so any potential speed bugs in the developer's game might surface during development.
This conf has the captures folder set to the game's path. The default path is the local %AppData%\DOSBox\capture, but if the game under development needs write permissions there should be no problems with using it for the captures.
The cmd only needs:
"< path to your DOSBox >\dosbox.exe" -conf dosbox.conf
if it is run from the same folder. The exit command is issued from the [autoexec] section of the conf. No path needs to be set for the conf file if it is in the same directory as the cmd. You could include the additional -noconsole command to suppress the console window. You would of course not want to do this if you are using a debug build of DOSBox.
The way we are handling DOSBox from Developer is that it writes the conf file based on the settings the user can select from the options dialog. This can be done on a project specific basis. It has more options than my config tool that I include with my installers. A debug build of DOSBox is included in the "Tools" sub directory under Developer's main folder. This eliminates the need to take its path into account for running the game. It uses no cmd or bat file to start the game.
-
Timer bugs are a direct result of not having been able to test on faster machines. Whatever development environment we're developing in it's going to be much easier and a lot more natural to avoid running into timer bugs without even knowing it. It's not something that's inherent to SCI1.1, it's the way you script your game.
-
It's not something that's inherent to SCI1.1, it's the way you script your game.
Not true. Earlier SCI games used to call Wait in the main loop. This synchronizes the game loop against the system clock while still keeping the speed adjustable.
Later SCI games omit this statement, letting games run as fast as they can and putting a strong burden on the programmer that he wouldn't need to bear otherwise. It's a deliberate decision on the part of the system programmers, and it's bad design. I'd say it's inherent.
In fact, I've just noticed that the NRS patches for at least one game add a Wait statement in the main loop (although not where Sierra used to have it).
-
Timer bugs are a direct result of not having been able to test on faster machines. Whatever development environment we're developing in it's going to be much easier and a lot more natural to avoid running into timer bugs without even knowing it. It's not something that's inherent to SCI1.1, it's the way you script your game.
Oh I understand that it was scripting errors, but my point was just that if DOSBox is set to dynamic core with max cycles any such scripting errors will become readily apparent.
Anyway, the reason for my post was that the dosbox.conf in the template games needs to be replaced.
-
It's not something that's inherent to SCI1.1, it's the way you script your game.
Not true. Earlier SCI games used to call Wait in the main loop. This synchronizes the game loop against the system clock while still keeping the speed adjustable.
Later SCI games omit this statement, letting games run as fast as they can and putting a strong burden on the programmer that he wouldn't need to bear otherwise. It's a deliberate decision on the part of the system programmers, and it's bad design. I'd say it's inherent.
In fact, I've just noticed that the NRS patches for at least one game add a Wait statement in the main loop (although not where Sierra used to have it).
I have not looked at the scripts in the new template game, yet. Has this been taken into account?
-
My bad! Still, 'the way you script your game' is still valid. We don't have to script our games that way.
-
I have not looked at the scripts in the new template game, yet. Has this been taken into account?
It has not, but it sounds like it should? Looking at old games, I see a Wait(gGameSpeed) in the loops in the play and replay methods. I assume that's what we're talking about. It's not obvious what I'd use for game speed in this case though. I guess the equivalent in the template game is gGEgoMoveSpeed.
-
Looks like there's a bug in the picture export function to 8-bit BMP. It produces this result with a strange palette that I didn't have anywhere in my game.
This also brings up another feature that might be useful; importing a picture but using the palette entries already loaded (or the default palette if it's a brand new picture), but without remapping colours. My guess is that I'd get the proper colours here if I was able to import without taking the palette with it or remapping the colours?
-
Looks like there's a bug in the picture export function to 8-bit BMP. It produces this result with a strange palette that I didn't have anywhere in my game.
Ha wow, that's a pretty ugly bug. Looks like that functionality hasn't been updated for VGA, maybe. Should be an easy fix [edit: fix submitted].
This also brings up another feature that might be useful; importing a picture but using the palette entries already loaded (or the default palette if it's a brand new picture), but without remapping colours. My guess is that I'd get the proper colours here if I was able to import without taking the palette with it or remapping the colours?
You can already do that in a roundabout way:
- Export the current picture's palette as a .pal file
- Import your corrupted background image, and set to use imported palette
- Edit the palette and import the .pal file
-
Hmm it must mess up the entries as well. This is what I get in that instance (this is not an 8-bit BMP, I couldn't export from Companion without it screwing the palette up further, so I just copied and pasted it into PSP and saved it as a hi-color BMP).
-
Did you uncheck "use only nnn free palette entries" in the import background dialog?
-
This is what you get when you export a view to bitmap. Also not "updated for VGA"?
-
The pic problem had nothing to do with VGA, actually.
Are you using "export view as encoded bitmap"? That definitely only works in EGA, since it encodes the view resource within the unused nibble of each byte. I'll remove that menu item for VGA.
Or are you using the generate bitmaps thing in the extract dialog? That should work. And I should probably add that feature to the view menu or something.
-
Twas indeed "encoded bitmap", and it would be nice to have a way to dump just the one resource to a bitmap, encoded or otherwise.
-
Did you uncheck "use only nnn free palette entries" in the import background dialog?
That must have been it. All colours are normal now. Good to know.
-
Whether or not you "generate palette", "map to current palette", or "use imported palette", you can always control which of the pic's palette indices are involved.
By default the "unused" entries from the global palette are selected. If you uncheck the box, all of them get selected. And then of course you can manually select ranges and hit the update button, for maximum flexibility.
-
Yeah, I'm aware of that I must have just glossed over that step. It was late last night. lol
-
It's been a while, so I've uploaded a new version (3.0.0.11) of SCI Companion. Info in the first post of this thread, as usual.
Major points:
- tracing images work again with copy/paste in the pic editor
- the "import background" dialog is now also used with "import image sequence" for views. So all the same fancy dithering/palette options are now available when importing images into views
- it might run under XP now :P
- fake ego is easier to use
-
Fact: if you say "fake ego" ten times fast, you'll be handed a bottle of soda by the nearest weird clown guy.
-
Yey new version! :)
-
Couple mad bugs here.
I notice that when going to game settings and clicking browse for the launch command it puts the whole path to the file (in my case "run.cmd") in the field provided, however when the game is actually run from SCI Companion it's already looking in the game's directory so it says that "G:\games\adventures\mine\blahblah\g:\games\adventures\mine\blahblah\run.cmd doesn't exist".
Next problem, I'm trying to open an external Pic image and save it as a resource number. However, the resource package field is greyed out to "1" and can't be changed and the program complains that resource.001 doesn't exist. Which it shouldn't, I only have a resource.000 included. I'm using 3.0.0.11.
-
Next problem, I'm trying to open an external Pic image and save it as a resource number. However, the resource package field is greyed out to "1" and can't be changed and the program complains that resource.001 doesn't exist. Which it shouldn't, I only have a resource.000 included. I'm using 3.0.0.11.
Using v 3...11, I am not seeing this... I exported pic 0... 0.p56
When I drag the resource back into the game, I get a message that tells me that 0 already exists, use a different resource number.
If I click no, then the pic is brought in. If I click yes, then the prompt comes up allowing me to assign a resource number. I gave it a number of 2 and it came right in.
Are you sure your pic resource is from an sci1.1 game?
-
Thanks for the bug reports. This open happens if you use "open resource" from the file menu. cloudee's method of dragging the file in is a good workaround for now.
-
Yeah, the run needs some work yet. Troflip did have the DOSBox location hard wired in the CMD file, but this would be an easy fix. I would add a setting in the preferences that allows setting the DOSBox path. It should copy everything from the template folder to your new development folder when you create a new game. I just noticed that the SCI1.1 folder is the only one with the run.cmd file. Without looking at the source I do not know if the program can also create it or only copies it. Also the SCI0 template is in base of the TemplateGame folder and TemplateGame\SCI0.
-
How hard would it be to get the wav file back out of the aud resource?
There are a few that I need to mix down to either a different Hz or bit now that I have changed the sound driver. Unfortunately I did not save the originals.
-
How hard would it be to get the wav file back out of the aud resource?
There are a few that I need to mix down to either a different Hz or bit now that I have changed the sound driver. Unfortunately I did not save the originals.
I think SV.exe can do that.
At this point, I think this version of SCI Companion is pretty much feature complete. I'll try to fix up any remaining bugs (like those mentioned in the past few posts) and put out an official Beta.
-
Ah, drag and drop. Thanks! Never tried that. That doesn't come intuitively to me like it apparently does to everyone else lol.
Yeah, the run needs some work yet. Troflip did have the DOSBox location hard wired in the CMD file, but this would be an easy fix. I would add a setting in the preferences that allows setting the DOSBox path. It should copy everything from the template folder to your new development folder when you create a new game. I just noticed that the SCI1.1 folder is the only one with the run.cmd file. Without looking at the source I do not know if the program can also create it or only copies it. Also the SCI0 template is in base of the TemplateGame folder and TemplateGame\SCI0.
No, I'm not talking about the file itself, but the browse button. It's just that when browsing for another file to run by (or even run.cmd itself) it puts the entire path into the field. But when you go to launch the game from Companion (with the Green Arrow button) it looks inside the current game's folder for whatever is in the field. So it searches the file pathway twice: "g:\games\adventures\mine\game\g:\games\adventures\mine\game\run.cmd". So really all you need to do is put "run.cmd" into the field and it'll search in the game's directory "g:\games\adventures\mine\game\run.cmd". It's just an issue with how the launch game button and the launch GUI is programmed. It probably shouldn't be predisposed to look inside the game folder but from whatever pathway is in the launch game field. Either that or tie the browse function to look inside the game folder only or something.
EDIT: Errr...I can't drag and drop a picture into Companion...what am I missing?
EDIT 2: Ok, never mind. The file name must have a number. Any way we can allow importing of named filenames too? As long as they end in P56? Also, I'm still having a problem with after deleting and importing a background there are two entries for the background (500). One is blank. Still can't seem to delete any resources without this annoying bug cropping up. Deleting resources is a legitimate exercise and should have no hiccups.
EDIT 3: Ok, never mind again. I deleted the copy and it went away without issue and didn't come back after rebuilding resources. Deleting other unused backgrounds and rebuilding didn't generate copies. Just the one time. Strange, but it all works. I'm not sure what will happen when I import backgrounds at those same numbers, but for now it's ok...
-
I have another question, how do you get a 320x200 background to fill the screen without the 10-pixel black bar along the top? I want my title screen to fill the page, but it starts drawing it underneath this black bar.
-
No, I'm not talking about the file itself, but the browse button. It's just that when browsing for another file to run by (or even run.cmd itself) it puts the entire path into the field. But when you go to launch the game from Companion (with the Green Arrow button) it looks inside the current game's folder for whatever is in the field. So it searches the file pathway twice: "g:\games\adventures\mine\game\g:\games\adventures\mine\game\run.cmd". So really all you need to do is put "run.cmd" into the field and it'll search in the game's directory "g:\games\adventures\mine\game\run.cmd". It's just an issue with how the launch game button and the launch GUI is programmed. It probably shouldn't be predisposed to look inside the game folder but from whatever pathway is in the launch game field. Either that or tie the browse function to look inside the game folder only or something.
I see what you did. You added the path to the executable listed in the game properties. The default is just "run.cmd" rather than a path. Defaulting to the game's folder probably makes the most sense since you do not have to list a path to the conf file. This makes it much more portable. You can move the project's folder and not break the run. Perhaps the browse button should be removed from the game properties and just leave the field for the name of the executable if someone really wants to change it.
-
Agreed.
-
I have another question, how do you get a 320x200 background to fill the screen without the 10-pixel black bar along the top? I want my title screen to fill the page, but it starts drawing it underneath this black bar.
http://sciprogramming.com/community/index.php?topic=1420.msg6965#msg6965
-
I have another question, how do you get a 320x200 background to fill the screen without the 10-pixel black bar along the top? I want my title screen to fill the page, but it starts drawing it underneath this black bar.
http://sciprogramming.com/community/index.php?topic=1420.msg6965#msg6965
Thanks. I knew it was explained but couldn't remember or locate where.
-
I know that troflip is pretty well set on the feature set that the new beta will have, but as per http://sciprogramming.com/community/index.php?topic=1485.0 I was wondering how difficult would it be to have a standard video format (such as AVI) to SEQ import capability. If not within Companion what about an external AVI to SEQ converter? Or for that matter an SEQ editor. Understandable if this get shelved, but would be great for creating cut scenes.
-
I wonder if before you call this "feature complete" if you could readd the enhanced script IDE functions back. Like, the "Find declaration of..." on rightclick of a script object or variable and being able to view the Pic from a currently viewed script (which is now greyed out in the left bar) and viewing the script number of the current Pic you're editing (also on the left bar), etc. I realize that the script number doesn't always match the picture number anymore in SCI1.1, but it's still a handy feature for when it does. All these extra features from 2.1.0.5 seem to be absent (disabled temporarily perhaps?) in 3.0.0.x.
-
It's good to know someone was actually using those features!
Those features require that SCI Companion always be compiling the scripts in the background, and there were some issues with that functionality which made me temporarily disable it. But I can look into re-enabling it.
-
Absolutely! It was crucial to my first understanding how SCI scripting worked in the beginning and was just plain handy after the fact!
-
Picture importing seems to be bugged in 3.0.0.11, where palettes are concerned.
1) I'm trying to import a picture and "use imported image palette", but when I select that option it creates a brand new palette that is definitely not from the image I'm importing (I'm importing a GIF not from the clipboard or anything). Seems like a default VGA palette of sorts and it remaps the entire image to this palette (closest match).
2) It also ignores "Only use 191 free palette entries" unless I deselect and select it again, when using "use imported image palette".
3) Also, the Brightness, Contrast, and Saturation sliders are greyed out when using "Use imported image palette", is that on purpose? Yes it is. However, the Hue slider is not greyed out, but has no effect on the image.
These issues aren't present in 3.0.0.10.
-
Sigh... looks like that happened when I added code to clone the bitmap that gets imported. I did this because the library I'm using keeps the bitmap file open (so it can't be deleted). But it looks like when I clone, the palette gets lost.
Thanks for finding this bug.
-
Regarding the old Cat.sc conversation:
- An instance of Cat that doesn't overload (method posn(x y)) can be dragged anywhere with the mouse.
- Such a Cat will erase any Views it is dragged over. They redraw when you release the Cat.
- You must add the Cat to gOldMH to allow it to be dragged like that.
Attached is a test room script and resource.000/map files that include a simple draggable Cat and the wheel from Codename Iceman.
-
One thing that really gets me...
SCI Companion has all these UI themes, but no retention. It resets to Office 2007 Luna-Blue every time you start it.
-
Not sure why I never fixed it. But I just did, should be in the next release.
-
Not sure why I never fixed it. But I just did, should be in the next release.
yeeey ;D
-
Have I or have I not mentioned by the way how I'm consistently incapable of opening Larry 1 VGA? I either get no resources at all, or (more commonly) SCI Companion outright crashes when I try.
-
I don't think so. I never tried it because I have no LSL games installed on my system. Interesting problem.
-
I can confirm this with 2.0 (EGA int 1.000575 & VGA int 1.000.510) and 2.1 int 1.000.577. The demo (int 1.000.084) does open.
-
I can confirm too. (There are bound to be issues with loading some games, since I don't have all the sierra games).
It may be mis-identifying the resource map format or something...
-
Let me know if you need any files to investigate. Would it be a good idea to check with other SCI1 games?
-
Fix has been submitted for the LSL1 VGA problem, should be in the next release. If there are any other games that have issues opening, please let me know.
-
Out of the games I have, I cannot open Jones in the Fast Lane CD version.
Other than that, the only issues I have are getting garbled graphics when opening EGA SCI1 games:
- 1990 Xmas Card EGA
- Hoyle 3 EGA
- Mixed Up Fairy Tales EGA
- Police Quest 3 EGA
- Conquests of the Longbow EGA
- Jones in the Fast Lane EGA
- Space Quest I VGA
- Space Quest IV EGA
I don't have the LSL games handy to test.
Castle of Dr Brain EGA and KQ5EGA (0.000.055 and 0.000.062) open fine, however.
-
I just tested all and uploaded copies of everything that does not open and one SCI1 EGA game for troflip so he has something to work with.
-
Out of the games I have, I cannot open Jones in the Fast Lane CD version.
Other than that, the only issues I have are getting garbled graphics when opening EGA SCI1 games:
Can you screenshot me what you get when loading SQ1 VGA? I've found an issue, but it only happens when browse info is turned on, which is not the default in the version of SCI Companion you're using.
-
No problem with Jones CD v1.0 with the build I have, regardless of views or settings.
-
Other than that, the only issues I have are getting garbled graphics when opening EGA SCI1 games:
- 1990 Xmas Card EGA
- Hoyle 3 EGA
- Mixed Up Fairy Tales EGA
- Police Quest 3 EGA
- Conquests of the Longbow EGA
- Jones in the Fast Lane EGA
- Space Quest I VGA
- Space Quest IV EGA
If you use the Game->Version detection dialog, and switch the view and pic types to "EGA", then click "reload game", does it work?
I think SCI Companion is incorrectly assuming these games are VGA because they contain a palette resource (presumably just left over).
-
Ah thank you, troflip, that does work for every game. Interestingly, though, the first 12 Picture resources in Conquests of the Longbow are blank (30, 35, 40, 45, 50, 55, 60, 65, 70, 75, 80, 85). However, their priority and control screens work fine. I believe they are the screens for the hedge maze in the game. Even more interestingly, they don't show up in Companion for the VGA version either. As a final thought of abounding interest, neither versions of these screens are viewable in SCI Viewer.
No problem with Jones CD v1.0 with the build I have, regardless of views or settings.
I have 1.0 as well. I get an error message, won't even open up:
Unable to open resource map: Opening
g:\games\adventures\sierra\jonescd\resource.004 failed with error 2:
The system cannot find the file specified
There is no resource.004, incidentally, just resource.001.
-
I have 1.0 as well. I get an error message, won't even open up:
Unable to open resource map: Opening
g:\games\adventures\sierra\jonescd\resource.004 failed with error 2:
The system cannot find the file specified
There is no resource.004, incidentally, just resource.001.
The issue with the Jones CD version is the same as the issue with the LSL1 VGA. It should be fixed in the next release of SCI Companion (Collector is probably using the private build I have him that has the fix).
-
I just found more pictures that won't load in Companion or Viewer. 301 and 699 from Space Quest IV. All versions. I wonder what the differences are in these images and if they have some special purpose.
-
What do you mean "won't load"? They load fine, they just have nothing in the visual screen. Probably used as overlays.
-
Even the hedge maze screens? Are they just comprised of sprites over a single background? Actually, that wouldn't surprise me considering some of the random forest screens are much of the same.
-
Even the hedge maze screens? Are they just comprised of sprites over a single background? Actually, that wouldn't surprise me considering some of the random forest screens are much of the same.
I haven't played the game, but looking at screenshots, and view 500 and pic 490, suggest that this is indeed the case.
-
So I was wondering earlier today, why is SCI Studio 3 only 2.68 MB and SCI Companion 3 a whopping 19.7 MB? I know it's just an alpha build but... I dunno how else to put it, but the poor thing is downright obese. Why is there even a timezone map in there? Why even two? Version 2 is an impressive five point something, with only the one theme.
So I'm thinking... why are the themes even there to begin with? It can't be individualism, considering they're all imitations of Office and Visual Studio. SCI Studio had no themes at all, yet still had this thing where you could tell "Brian made this". Now, because of the nature of what it was made in, all of SCI Studio's window layouts and such are stored in plain text, and almost all of the UI images like toolbar icons and the like are raw hex strings, including the large banners, yet it's a fraction of Comp 2's size.
Not meant as an attack or anything, just something that came to mind and baffled me all the way through lunch.
-
It's not really that baffling. The UI framework I'm using has "themes" built in (a feature which you are clearly using, since you posted about them not persisting), so I thought it would be nice to offer as an option, since it was minimal work to support.
A 20MB binary seems like a strange thing to complain about - that's pretty small these days (SCI Studio was made 8 years ago). IMO, it's really only an issue if the size noticeably interferes with startup time and performance. Does it?
The bulk of the 20MB are the theme resources. I'm not sure why the timezone map is in there. I can look at excluding features of the UI library to try to bring this down.
About 5MB is code. SCI Companion does a ton more stuff than SCI Studio!
-
Everything in that reply makes sense, and no it does not perform badly. Thank you for your consideration.
-
fyi, I was able to remove some of the unneeded resources and trim about 4MB off the binary. Thanks for bringing the timezone map stuff to my attention.
-
Also, fyi, I'm getting closer to putting out another release. This will bring back the navigation/tooltip functionality (in more robust form) that has been disabled by default. You'll be able to right click on something and "goto" where its define. You'll be able to quickly navigate around a script using that combobox at the top of the script view. When you hover the mouse over a symbol, it will show you the parameters it takes (in case of a function call), the value it has (in case of a define, say). And finally, there will be autocomplete as you type (e.g. "intellisense"). This should make it a lot easier to write scripts.
The second big piece of feature creep I'm working on (which will hopefully pan out) is to support audio resources for the messages (e.g. the base36 audio and sync resources). I'm trying to make it as easy as possible. Basically you'll be able to select a message the message view and import a .wav file for it; or, to make it even easier, press a record button and speak into your computer's microphone, and have that saved as an audio resource for that message entry. The issues I'm trying to workout revolve around how the resource management happens. These audio resource volumes (resouce.aud) can be large (~300MB) and that doesn't play well with how I do things now.
The LSL6 interpreter included in the SCI1.1 template game does actually support "talkies". I've verified this by putting in .map and "audio36" patch files. With no extra coding (except for changing a global flag), the corresponding message resource is now "spoken" in game. One caveat is that the talkers in the game are either all text or all spoken. With the template game code as is, if an audio resource is missing there is no fallback to text. It shouldn't be too hard to write code to handle this differently.
I'm not sure what to do about sync resource (this is lipsync data). To me, it seems really difficult and tedious to generate this data (it's basically a list of "tick count"/cel pairs - the cels being the various shapes of the mouth of the talker), and I'm not sure how to expose it in an editor. At the very least, I can let people enter this data manually. That's tedious, but I think trying to match up audio with a particular view cel is tedious anyway. I doubt many people would do this. Certainly it would be possible to try to analyze the waveform and map it to mouth shapes. If someone wants to write a tool that does this... lol
And finally, I need to get documentation done. I'm hoping to produce this automatically off "doc comments" in the scripts. This will be just a basic API reference, I guess. Hopefully I can rely on the community to produce proper tutorials (as some of you have already done).
-
I knew it was a good idea to save my reaction for later.
(http://i.imgur.com/HDY3CD3.png)
-
I forget, was there ever a tool used to import masks for priority/control screens? That would be handy if one was working with images made in layer editors like PSP or Photoshop or even GraFX 2 and exporting certain layers as solid colours for priority or control colours.
-
I forget, was there ever a tool used to import masks for priority/control screens? That would be handy if one was working with images made in layer editors like PSP or Photoshop or even GraFX 2 and exporting certain layers as solid colours for priority or control colours.
Import as visual, replace "set vis color" commands with "set pri/ctl color"?
-
That wouldn't work with SCI1.1, though. Importing a picture would default to the VGA import version not visual draw commands.
-
I never implemented that functionality, no. I've found that it really isn't too much trouble to draw the pri/control screens manually. At least in my experience, having done about 15 SCI 1.1 screens.
-
Me neither. I've found the biggest trouble to be drawing the visual screen, EGA or VGA.
-
I suppose I could always do an import for SCI0 visual, change them to priority/control commands, and then copy those commands into an SCI1.1 game.
-
I'm not sure what to do about sync resource (this is lipsync data). To me, it seems really difficult and tedious to generate this data (it's basically a list of "tick count"/cel pairs - the cels being the various shapes of the mouth of the talker), and I'm not sure how to expose it in an editor. At the very least, I can let people enter this data manually. That's tedious, but I think trying to match up audio with a particular view cel is tedious anyway. I doubt many people would do this. Certainly it would be possible to try to analyze the waveform and map it to mouth shapes. If someone wants to write a tool that does this... lol
Well, regarding that last sentence, it turns out I found a nice little wrapper around Microsoft's speech recognition software that gives me a list of speech phonemes from a wav file. With the help of a settings file that maps the phonemes to a mouth view's cels, it makes it very easy to generate the sync resource. And it works pretty well, though I haven't tried it in game yet.
The only thing the programmer would have to do is:
- provide information that links a talker number to a view and loop.
- for each mouth view/loop, provide a mapping of 39 phonemes to cels in that loop
Once this is done, it is just the click of a button to generate the lipsync data for a piece of speech for a particular talker.
-
Well, regarding that last sentence, it turns out I found a nice little wrapper around Microsoft's speech recognition software that gives me a list of speech phonemes from a wav file.
That's evil.
I approve.
-
I don't care that Microsoft is required, that's awesome.
-
Shouldn't be any additional dependencies anyway, it uses SAPI 5.1, which I think is included with Win XP and up.
-
And then it was no longer XD
-
Fantastic!
-
And just because I'm shit like that, I made a meddle-survey (http://goo.gl/forms/bCK8GRHCc7).
-
Fun stuff...
-
:D :D
-
Fantastic!
-
I've got it working well enough that I was able to replace spoken dialog in Eco Quest (including generating new lip sync data). Also looks like EcoQuest has the option of showing both text and speech. Something that should probably be ported into the SCI 1.1 template game.
Attached is a capture from DOSBox (not sure if it needs a special codec to open or not... DOSBox comes with a video codec you can install).
I didn't have time to be funny, but you can imagine the potential of modding old games by dubbing a new audio track :-)
-
Ooooooo....or adding SPEECH TO SPACE QUEST 5. :O :O
-
I didn't have time to be funny, but you can imagine the potential of modding old games by dubbing a new audio track :-)
It's October, not you lie.
-
Modding games is the very thing that Brian was afraid of people doing.
-
Modding games is the very thing that Brian was afraid of people doing.
Not only that, but Phil forgot to edit one line!
Edit: https://youtu.be/n5XkjGYloow
-
Modding games is the very thing that Brian was afraid of people doing.
Lol, why is that?
-
I think it was mainly because he was afraid that people would do inappropriate or lewd mods and sully the Sierra brand. I think that it was why he never released his decompiler. It is just something that I remember that he had posted on the old MT board.
-
I think it was mainly because he was afraid that people would do inappropriate or lewd mods and sully the Sierra brand.
I suppose you don't need a decompiler to do what troflip just pulled. Oops?
-
That seems rather silly. Adventure fans are some of the most respectable gamers around (that's probably genreist, but it's still probably true). Meanwhile, shooter, RPG, strategy, etc gamers of all kinds get to mod their games up the yin yang, and as un-respectable as some of them are, they didn't do anything to "sully" those brands. In fact, those games became more popular. I admit the mod scene for shooters and other games is different from adventures, but still. The ability to play around is attractive.
Anyway, it doesn't matter now.
-
One MLG Larry comin' up. Not.
-
Of course when Brian expressed concern that some would take liberties with the games was when the MT forums were still around. Many of the Sierra fans were much younger then with more juvenile senses of humor. Some of the fan AGI games were examples of his concerns. You could make the case that he had placed the Sierra games on an unreasonably high pedestal. I love the games too, but they are not objects of worship.
-
Another point is that you could always mess around with Sierra's AGI games with no problem (other than obfuscation, I guess). Yet no one did. However, they did make some fan patches. Like Roger's hair etc.
-
True. I think that Brian's concern was was a bit too much ado about nothing. I am with you on the SQ5 mod. It was one of the first things that occurred to me as well, though I expect that it would be a bigger project to add speech to a game with none over just changing the audio track of a game that already has speech. And sadly in the case of SQ5 no Gary Owens.
-
Ok, this is a big release. I'll fix any issues with this and then hopefully release an official beta.
Download link as usual (http://icefallgames.com/Downloads/SCICompanion.zip)
There are two main changes:
1) autocomplete/tooltips/"goto definition" for the script editor
2) audio support for messages
Autocomplete
---------
This is on by default, but it might be off if you already had SCI Companion on your machine (as I'm sure you do). In that case, go to Tools->Preferences, and check "Enable browse info"
Now you should have autocomplete (e.g. "intellisense") as you type. You can also hover the mouse cursor over variables/functions to get more info. Or right-click on them and "goto definition". You can also quickly navigate through the script using the combo box at the top of the script editor.
Hopefully this is all reliable and fast now :-)
It does take a few seconds when you open a game for the "browse info" to be built (status should be on bottom left)
Message audio (speech)
--------------
- If you have a microphone attached to your computer, you can now just click on a message entry and press the record button to record audio for that message. Or you can load a wav file.
- If you record your own audio in SCI Companion, I keep around the original recording as a wav file. That way you can re-process it with different settings (using the little button with a waveform icon). The original recording is 16-bit audio, but the default for message audio is 8-bit, which is fairly noisy - no way to get around it. You can play around with different compression settings, or noise gates, etc..
- Since the resource.aud file can get really huge (typically around 400MB for Sierra games), I don't rebuild it every time you save a message (with audio) resource. Instead, the audio resources are kept as individual files in the audiocache folder. Whenever you run the game, it checks to see if anything has been changed, and it will automatically repackage everything into resource.aud. It should be mostly transparent, i.e. you shouldn't need to think about it. You can also force things to be repackaged using the icon that looks like a compact disk (in case you're not using SCI Companion to run/test your game).
- You can automatically generate lip-sync data for a message entry with audio. "Quick Lip Sync", or more options in the Advanced dialog. The lip-syncing can be a bit hit or miss. Obviously the more clear you speak the better. If you've used SCI Companion to record the audio, I feed it the post-processed 16-bit audio (even if you've specified the actual audio resource to be 8-bit). I'm not too familiar with the wrapper library I'm using (which uses Microsoft SAPI underneath), but it seems to be hard-coded to US English. It probably wouldn't be too much effort to have this configurable for different accents and languages, but I'm not sure (I suspect the lipsync results will still be somewhat reasonable for other languages anyway).
- You have the option of using the message text to aid in the lip-syncing. Sometimes this makes it worse (it gets the right mouth shapes, but they don't line up with the audio - whereas just using the audio, you get things lined up nicely, but maybe they are the wrong mouth shapes). If you get bad results with one option, try the other.
- You can use the "sample" mouth to check how good/bad the lip-syncing is. But to actually get it working in the game for an actual mouth view, you need two things:
- you need to say which view/loop is the mouth for a given talker number (this should be whatever your Talker instance uses)
- you need to come up with a mapping of the phonemes to particular cels in that mouth view/loop
Let me know if there are any questions! Hopefully it's not too hard to figure things out.
I'll release my "explore SCI1.1" game soon, with full speech and lip-syncing in it.
-
Yey!
-
Sounds good. I hope I can find time this weekend to kick the tires.
-
Well, everything seems to work... except for Rebuild Resources. After adding speech support to my game, it keeps saying "corrupted resource!" and my resource.000 file is ballooning. On the other hand, things seem to still load and such...
Also, possibly related, I get a Zero Hunk Allocation Request in-game when it actually tries to play a line.
-
Is this by "converting" an existing game, or creating a new game?
Can you take a screenshot of the Game -> Version detection dialog?
-
This reminds me of the old problem of a corrupted resource file if you attempted compile or rebuild while the game was running form COMMAND.COM or NTVDM. This is not an issue when using DOSBox, whether because of file locking or whatever reason. Is is possible that using ScummVM allows that old problem to resurface?
-
Is this by "converting" an existing game, or creating a new game?
Can you take a screenshot of the Game -> Version detection dialog?
The new game I've been working on for a bit now, so... both? I followed your guide, then got hit by the zero hunk alloc thing and found that Rebuild Resources didn't work anymore.
So I tried to reverse it, as seen in the attached screenshot.
-
(By "creating a new game", I mean with the new version of SCI Companion)
"Audio volume name" and "Audio36 format" are incorrect. Did you not change those?
If "supports message audio" won't go away, it means there is an audio map for a message resource in your resource.000. That's fine, except since your "Audio volume name" is incorrect, it probably means that audio resource is in your resource.sfx (it should be in a resource.aud). SCI Companion will be reading it using the wrong format (hence corrupt resource), and the game will be looking for it in resource.aud (hence the in-game error)
Here's what it should have looked like. Just start again from a backup of your game (hopefully you saved a backup before doing the conversion!).
-
Yeah see it used to look like it's supposed to, but then it didn't work in practice -- the zero hunk thing -- and I tried to revert it again. But I'm working through fixing it all now.
-
Yeah see it used to look like it's supposed to, but then it didn't work in practice -- the zero hunk thing -- and I tried to revert it again. But I'm working through fixing it all now.
Remember, after adding the message audio resource when converting, it's necessary to save that, and repackage audio files. If you don't do that, then when you re-open the game, it won't detect resource.aud, and you'll get the result you're seeing.
In fact, you might be able to fix it by making a resource.aud consisting solely of 11 0xff values.
-
I've nearly rebuilt my game as it was before, but I can't restore the digital sound effects -- importing an exported aud file from an earlier copy is "not supported", nor is importing a wav file, same result.
The only other problem right now is that even MIDI sound is busted. SSCI remains silent, and ScummVM speaks of an "unsupported resource version 32" the moment the first song is played.
-
I've nearly rebuilt my game as it was before, but I can't restore the digital sound effects -- importing an exported aud file from an earlier copy is "not supported", nor is importing a wav file, same result.
The only other problem right now is that even MIDI sound is busted. SSCI remains silent, and ScummVM speaks of an "unsupported resource version 32" the moment the first song is played.
Oh yeah, importing aud resources is broken. I broke that when I switched to the new system of storing audio resources. Should be an easy fix. Not sure why wav wouldn't work though. What happens when you try to import a wav file?
You can probably re-construct the audio file cache structure like this, which will cause SCI Companion to pick them up and allow repacking into the game:
audiocache\
audiocache\65535.map
audiocache\65535\0.aud
audiocache\65535\10.aud
audiocache\65535\15.aud
etc....
However, you'd need the 65535.map resource, not just the individual .aud resources.
Not sure why MIDI sound isn't working.
-
I managed to fix everything about my game through judicious abuse of older copies. As for "what happens when you try to import a wav file"...
*makes a new backup copy before answering*
*drags semi-random wav into view, picks #42, no name*
"not implemented"
Note: talking about regular Audio sound effects that fall back to and replace MIDI sounds, not Audio36 speech. Baby's tears, not the narrator talking about baby's tears.
-
Hmm, the only reference to such a message I can find in ScummVM is with message resources. Can you check whether your message files are readable in Companion? The version check in SSCI (one of the few places that have one) looks like it's flexible enough to let a broken resource through in your case.
-
My messages are perfectly readable, both in my "broken but new" and "actually working" forks. I'm not even touching messages here. In fact, taking an earlier project -- one where I implemented message-compatible speech bubbles that point at character's walkaround views -- and dropping a wav file... "not implemented".
-
and dropping a wav file... "not implemented".
Ah ok, thanks for finding that bug. You can use the Browse button in the audio preview pane to work around it for now.
-
I didn't think that would work, but it did.
-
As it turns out, the Native theme has a drawing bug in it that affects panel captions: there is no background drawn for them, only the text, leaving ghost trails.
Also minor one: in the color shift dialog, there's a typo on "Cel only, Enire loop, Entire view".
-
Thanks! Fixed for next release...
-
Template game cleanup! In SQEgo::doverb, this whole case can probably be removed, as it references SQ5-specific rooms and such:
(case 32
(if ((send gRoom:script))
(super:doVerb(theVerb rest param2))
)(else
(if (IsOneOf(gModNum 730 740 760 790 620 640 400 410 420))
(send gRoom:setScript(ScriptID(gModNum 20)))
)(else
(super:doVerb(theVerb rest param2))
)
)
)
-
Ha, yep. Looks like verb 32 was for beaming up!
-
Feature Request:
I'm trying to change an existing script in a Sierra game. Would it be possible for me to build a PATCH file from my changed (decompiled) script?
-
Feature Request:
I'm trying to change an existing script in a Sierra game. Would it be possible for me to build a PATCH file from my changed (decompiled) script?
Yes. You can compile the change, then export the SCR file (and possibly the matching HEP) for distribution. Select it, right-click, "export to file".
-
Thanks! Exactly what I was looking for.
Unfortunately I'm too lame in SCI to make the script do my biddings :o.
I'll open another thread, inviting other people to help.
-
So... I deleted the files of a game I had in SCICompanion after I'd closed it. Now, when I try to open SCICompanion, it does nothing and my cursor just spins... It doesn't even load. How could I fix this? I've tried deleting my SCICompanion files and reinstalling fresh from here.
-
Is the entire game deleted or just some files? It might be trying to open the incomplete game. Off hand I am not sure where Phil put the settings, whether in the Registry or an XML in the AppData folder.
-
Is the entire game deleted or just some files? It might be trying to open the incomplete game. Off hand I am not sure where Phil put the settings, whether in the Registry or an XML in the AppData folder.
The entire game (INN) is deleted, there is nothing there for it to load, thus I thinking that it's encountering an error trying to load something which isn't there.
-
I'll see if I can repro. In the meantime, you should be able to hold SHIFT down while starting SCI Companion, and that should reset all settings to default.
First, can you take a screenshot though? It *should* throw up an error message that the game is missing (see attached), then let you continue. Maybe the error dialog ends up behind SCI Companion or something?
-
I'll see if I can repro. In the meantime, you should be able to hold SHIFT down while starting SCI Companion, and that should reset all settings to default.
First, can you take a screenshot though? It *should* throw up an error message that the game is missing, then let you continue. Maybe the error dialog ends up behind SCI Companion or something?
Still nothing... Ugh, it was fine earlier. But now it just locks up the Explorer Window and the mouse icon spins.
-
(https://i.gyazo.com/22a7ba41aeb0a5ea9bf4a931c03be6e3.png)
Now, SCI Companion ISN'T apparently running... BUT now when I try and delete the SCICompanion.exe, I get that (after trying to run the exe).
-
Yup, you've got invisible leftovers. Check Task Manager.
-
Yup, you've got invisible leftovers. Check Task Manager.
SCICompanion.exe isn't listed in the Task Manager though. I'm confused.
-
Well, easiest way out then would be to simply shut down the computer and restart it.
-
Well, easiest way out then would be to simply shut down the computer and restart it.
Okay, I've restarted. How do I get rid of "invisible leftovers"?
-
Okay, I've restarted. How do I get rid of "invisible leftovers"?
You just did. No SCI Companion, with visible windows or otherwise, should be running now, allowing you to clean up.
-
Okay, I've restarted. How do I get rid of "invisible leftovers"?
You just did. No SCI Companion, with visible windows or otherwise, should be running now, allowing you to clean up.
(https://i.gyazo.com/eb8c286ea3d33f62975c44ab94960eb5.png)
But yet, then I delete the .zip I used, and the copy of SCI Companion I had, and emptied my recycle bin, re-downloaded SCI Companion, and tried to run it, and it did the spinny cursor again, and now... Now, as you can see. I can't delete it again, because it's apparently "in use".
-
Open regedit.exe, then go to
Computer\HKEY_CURRENT_USER\Software\mtnPhilms\SCICompanion
Then right click on the SCICompanion and choose Export. Send the resulting .reg file to me so I can see if there is anything strange.
Then delete the SCICompanion reg key altogether.
("re-installing" SCI Companion won't do anything, as there is no install).
fyi, if something is open in "System", that's pretty low level. You don't have any anti-virus software or something that might be interfering with things?
-
Open regedit.exe, then go to
Computer\HKEY_CURRENT_USER\Software\mtnPhilms\SCICompanion
Then right click on the SCICompanion and choose Export. Send the resulting .reg file to me so I can see if there is anything strange.
Then delete the SCICompanion reg key altogether.
("re-installing" SCI Companion won't do anything, as there is no install).
fyi, if something is open in "System", that's pretty low level. You don't have any anti-virus software or something that might be interfering with things?
I don't think so. I can't even SEE SCICompanion.exe in my Task Manager. I have to go into command prompt and do "taskkill /F /T /IM SCICompanion.exe" to get rid of it, or restart.
-
What about in the processes tab?
-
What about in the processes tab?
Wasn't there. Apparently AVAST is giving SCICompanion a false positive result. I sent a message to Phil telling him how he can sent a report to the AVAST Labs, about the false positive result.
-
So once again Avast messes up regular use of a perfectly safe and legitimate application. Nothing new here, carry on.
Edit: interestingly, VirusTotal's copy of Avast doesn't agree (https://www.virustotal.com/en/file/2623a7bd2eb18b020f601c7d8d543b738a849736f3aa0bd998befb29e5b44aff/analysis/).
-
So once again Avast messes up regular use of a perfectly safe and legitimate application. Nothing new here, carry on.
Edit: interestingly, VirusTotal's copy of Avast doesn't agree (https://www.virustotal.com/en/file/2623a7bd2eb18b020f601c7d8d543b738a849736f3aa0bd998befb29e5b44aff/analysis/).
When I first downloaded it, it gave me warnings and locked up the program whilst I'd did an AVAST SmartScreen? Scan of the exe. Now, it won't even load unless I disable it's shields, it just does the spinny mouse cursor thing and says it's running if I do otherwise.
-
So once again Avast messes up regular use of a perfectly safe and legitimate application. Nothing new here, carry on.
Edit: interestingly, VirusTotal's copy of Avast doesn't agree (https://www.virustotal.com/en/file/2623a7bd2eb18b020f601c7d8d543b738a849736f3aa0bd998befb29e5b44aff/analysis/).
Either way THAT (https://www.virustotal.com/en/file/2623a7bd2eb18b020f601c7d8d543b738a849736f3aa0bd998befb29e5b44aff/analysis/) does highlight slight problems, like the fact that ClamAV thinks that SCICompanion.exe is "Win.Adware.Browsefox-14038", and the fact that AVAST still thinks that SCICompanion.exe is suspicious enough to stop it from loading by doing a SmartScreen Scan on it (and now not allow it to load at all).
-
Seriously though? The last ten times at least that I've heard about Avast, it involved overly-aggressive responses to false positives.
-
Seriously though? The last ten times at least that I've heard about Avast, it involved overly-aggressive responses to false positives.
Either way, I've got to exercise caution when using SCICompanion, because it is for some reason locking up the program and allowing it to load, but somehow suspending it before it can be shown on the screen... This means I have to disable my Virus Protection (AVAST) Shield whilst working on my SCI1.1 Game.
-
I may have been too subtle. The implied message was that Avast is shit and should be removed, replaced for something better.
-
I may have been too subtle. The implied message was that Avast is shit and should be removed, replaced for something better.
Which free antivirus would you suggest?
-
I've never adopted the use of anti-virus software and I've never regretted it. Still no viruses here. I can count the amount of times I've had spyware issues on one hand in ten years. And those cases were easily dealt with small free programs rather than large antivirus software that takes up resources and has to always be running. Screw that.
-
I use MSE, and it very rarely triggers. Those few times it did, I expected it to, from downloading arguable material on purpose.
The best protection your system can have is a smart user, like Mu.
-
Phil, you should probably be advised that the template game's view 995 still has the SQ5 palette embedded in it.
-
Yeah, I am only using MSE myself, but have had fewer than a half dozen incidences (all minor) to deal with. Most security issues are PEBKAC errors.
-
Phil, you should probably be advised that the template game's view 995 still has the SQ5 palette embedded in it.
That's probably intentional (so the settings pane always shows the correct colors), but it does make things more difficult for people if they want to use a different global palette. So yeah, I'll remove it.
(And I just use Windows Defender. Last time I had a virus or any kind of spyware was on XP like 8 years ago or something).
-
In the Message editor, I added a 9th verb however it does not show up on the drop down list for entering the message.
Using version .12
* After closing and starting companion back up, all the verbs now appear... I'll keep an eye out on this one to see if it happens again. May just have been a network issue... working on my game stored on a nas drive. Moved it to the local machine between closing and reopening companion.
-
Strange, that shouldn't happen. We don't reload Verbs.sh until you open a new message editor. Otherwise, it should just use the one in memory (which will have your new verb), and it should repopulate the combobox immediately.
Let me know if it happens again.
-
Strange, that shouldn't happen.
-
lol... well at least I went straight to stage 3!
-
Hey Phil, have you added anything to call the publisher from Companion, yet? The latest build should do everything automatically just from using the project' path as an argument.
-
Not yet, I'll def give it a shot before I release the Companion beta though...
-
Grab the last build before you try it.
-
There seems to be a script 19 that is popping up in the template game.
The source file isn't there, but the room can be decompiled. Looks like it contains a FakeView of Obj class and a public procedure which looks like it displays a message reporting the brTop and brBottom
Is this something which should still be hanging around?
-
I don't see this in the current version of the template game, so I must have cleaned it up at some point. There were definitely some turds left over.
-
That's what I had expected, just making sure.
I am turning it into my own little cursor hot spot testing room.
-
Lol. Great minds think alike.
-
Hey Phil, have you added anything to call the publisher from Companion, yet? The latest build should do everything automatically just from using the project' path as an argument.
Done. I posted my experience in the sierra help forums. Looks great!
-
Looks good. Is there a link to the latest template game so I cam make a few tweaks to the app?
-
Latest is here:
https://github.com/icefallgames/SCICompanion/tree/master/SCICompanion/Files/TemplateGame
Those are still in Studio language though. The Sierra syntax will have the version string in {} (not "") most likely. But you probably need to handle both. Or just grab it from the first line of the version file? (which is what the SCI 1.1 tempalte game does).
Not sure how I'm going to handle choosing the scripting language yet. Conversion takes a while, so I either need to checkin the converted template games (which means I need to manually convert each time I make a change), or have them converted as part of the build process (which may take effort).
Attached is the Sierra Script version of Main.sc.
The parens will definitely be there. I may change the converter to use quotes instead of braces, not sure. Both are valid.
-
As I said I could also just do a RegEx to get just alphanumeric characters and periods. I have thought about this some when designing parts of SCI Developer. Many of the SCI0 fan games never have the name or version set in the scripts. It is not uncommon for fan games to use 'TEMPLATE' for the save file name. Add to it a VERSION file and it is one more thing that many developers will miss. My solution for Developer was to set it from the IDE's game property dialog, though I should add a check to see if the Main.sc script is open with unsaved changes before applying name/version changes.
Anyway, I will probably have multiple methods as a failsafe. It can try another way to get the info if the value returned is null.
-
It's just in the version file because that's the way SQ5 did it. I haven't given much thought to game name or version number. I'm open to changing it as long as the interpreter doesn't care if version is mission.
Where is the save game name set?
-
Where is the save game name set?
I just got up so I may have misread your intent here, but... the savee game name is set in a few places in srdialog.sc for starters, also game.sc where the actual saving/restoring takes place.
Since half the stuff is ASM, here's save.sc:
line 90: (= numGames (GetSaveFiles (theGame name?) names nums))
line 229: (= fd (FileIO fileOpen (Format @str {%ssg.dir} (theGame name?))))
line 272: (= numGames (GetSaveFiles (theGame name?) @names @nums))
line 348: ((= fd (File new:)) name: (DeviceInfo MakeSaveDirName @str (theGame name?)), open: fTrunc)
And since "TEMPLATE" is too long (eight characters), the "SG" part that the engine adds is cut off, which is why we have "KQ6SG.010" but "TEMPLATE.002".
-
This is based on SCI0 games, but setting the '(instance public Template of Game' in the main script to the game name should be enough, but if the title contains spaces it will retain the previous name (i.e. 'TEMPLATE'). Enclosing the title in this line in curly brackets fixes this. In fact I would say that the line in the SCI0 template game should be changed to '(instance public {Template} of Game' . But again, it just trims it down to 8 characters so there is no room for the 'SG' as Kawa mentions. It would be nice if it auto-trimmed it to six characters to leave room for the SG. I have not looked into how it is set in the SCI1.1 template.
-
The SCI11 template game, being class SQ5 of Game, uses SQ5SG.*.
-
The Game class (which is part of the System classes) is derived by a game specific class (e.g. Kq6), usually in main.sc.
The game is started by the kernel issuing the play: message to the object whose ID is in entry 0 of script.000.
The play method sets the global variable theGame to that instance.
The compiler will use the symbol for an instance or class as its name unless name is explicitly set.
The save/restore classes will use the theGame's name property for the filename.
game.sh
=======
(define ROOM_ZERO 000)
...
main.sc
=======
(script# ROOM_ZERO)
(public
FooQuest 0
...
)
(instance FooQuest of Game
(method (init ...)
(= name "FQ")
...
)
...
)
game.sc
=======
(class Game kindof Object
(method (play)
;
; Invoked from the kernel, this starts the game going, then goes into the
; main game loop of doit: then wait for the next animation cycle
(= theGame self)
...
)
...
)
-
(instance FooQuest of Game
(method (init ...)
(= name "FQ")
...
)
...
)
Oooooh you rascal.
-
[edit: Ninja'd by Omer]
Sounds like it's set in the same way in both template games then. It's just the name of the main Game instance.
Note that the brace syntax doesn't exist in the Sierra syntax as it does in Studio syntax (in Studio it's for creating syntax tokens with spaces and other illegal characters, in Sierra it's used for internal strings). If your object name needs spaces, it can be set with the name property. So it should be as simple as adding a name property to the Game instance.
(class Template of Game
(properties
name "KQ11"
script 0
printLang 1
_detailLevel 3
panelObj 0
panelSelector 0
handsOffCode 0
handsOnCode 0
)
So Collector, in your properties page, when you set the save game name, is it going in and editing the Main.sc script? Wouldn't it then need to recompile for that to "take"?
-
Rather SQ5SG.
-
Rather SQ5SG.
Shit, yes. You fix one error only to leave the other. Kill me now.
-
So Collector, in your properties page, when you set the save game name, is it going in and editing the Main.sc script? Wouldn't it then need to recompile for that to "take"?
Yes, of course, but the automatic part of that in Developer was during setting up a new game. You can use the game properties dialog to change the name of an existing game and it will change the main script and it would still need to be recompiled just like any script changes. Compiling is a bit of a moot point as Gumby never wrote his compiler. That was the biggest thing left to do on his end.
-
Rather SQ5SG.
Shit, yes. You fix one error only to leave the other. Kill me now.
You grabbed the 'DIR' from the catalog file 'SQ5SG.DIR'.
-
Close enough. I was considering how to write "SQ5SG.DIR and SQ5SG.xxx" in a concise manner, came up with the * thing, and fucked up removing the earlier idea.
Just now nearly wrote "SQ5DIR.xxx" in fact.
-
Oh, you know though... for SCI1.1 the game name has to be a known one in order for it to run in ScummVM (that's why it is SQ5 in the template game). So if someone customizes it, they can't run their game in ScummVM.
-
Is that some kind of secondary check? Most games are ID by ScummVM by the MD5 of the first 5000 bytes of a given file. In the case of SCI that is usually the map file. It is how it can determine between different versions of the same game. In any case, the template game could be submitted to ScummVM to have it IDed as a template game instead of SQ5.
-
We'd need to agree on some new mechanism for the check though. The MD5 hash obviously won't work. Maybe some sentinel value in a global variable or something. Or a file whose presence indicates a either the known SCI0 or SCI 1.1 template game.
Hmm... there's a ScummId named value in the game.ini. Where did that come from? I don't recall putting that in, but I don't know who else would.
[edit:] Oh yeah, I did add it, and it's passed as a cmd line parameter to ScummVM, but it still doesn't work if the Game class name isn't a known game.
-
At one time it would load generic AGI fan game, even if it did not recognize the game. This would need to be done on their end, but if it could just simply ID any unrecognized game as generic. I am sure that this would be harder with SCI than it was with AGI, given how much more interpreter version specific they are. If ScummVM checked the interpreter version of a game it did not recognize then it might be able to load a game generically. We would really need to talk with them after the template is finished.
-
ScummVM has the capability to recognize SCI fangames, but it's cased out or something. I built my own version of ScummVM that adds it in. I have no idea why it doesn't detect by default. It's a simple case change. Either adding or removing a couple lines of code. Like it was disabled on purpose. And in all the time progress has been made, fangame forums opened on the ScummVM forums, and SCI fangames have been created it hasn't been enabled. I don't know what their reasoning is.
-
What I know from my studies is that whatever specific game it's detected as unlocks certain game-specific features. Like how SCI11 RemapColors is only available in QfG4 Demo. Of course, if you're gonna detect SCI fangames, and especially SCI0/Studio or SCI11/Companion fangames, you could do things like throw in RemapColors for the latter, maybe.
-
Random question about opening Sierra SCI games. I'm trying to open KQ5 CD version and it's having trouble understanding sound resources with embedded digital audio. It just says Resource load failed next to each digitally embedded resource. They won't even play. Is there a specific setting I can change in the version detection window to get them to load?
-
Random question about opening Sierra SCI games. I'm trying to open KQ5 CD version and it's having trouble understanding sound resources with embedded digital audio. It just says Resource load failed next to each digitally embedded resource. They won't even play. Is there a specific setting I can change in the version detection window to get them to load?
I don't think I ever implemented that, actually. All the pieces are there, probably, so I doubt it's very difficult. I don't have KQ5 CD in my library... is there another game that this repros with?
-
So far no settings I try are working. It's also not listing the voice acting audio list at all. I think KQ5CD used a transitional version of SCI that used elements from standard SCI1 but with a few advanced features not found in SCI1. It was the first CD/Talkie Sierra made, I think.
If you want to grab it (and any other Sierra games you might not have), they're currently on sale DRM and launcher client-free at GOG right now for $1.99 for each game pack in a bundle (KQ1-2-3, KQ4-5-6, KQ7-8, QFG1-5, and QFI, a newer title). Or $3.99 for one pack. KQ5CD is included in the KQ4-5-6 pack.
http://www.gog.com/promo/winter_sale_bundle_quest_061215
-
Random question about opening Sierra SCI games. I'm trying to open KQ5 CD version and it's having trouble understanding sound resources with embedded digital audio. It just says Resource load failed next to each digitally embedded resource. They won't even play. Is there a specific setting I can change in the version detection window to get them to load?
I don't think I ever implemented that, actually. All the pieces are there, probably, so I doubt it's very difficult. I don't have KQ5 CD in my library... is there another game that this repros with?
I setup an FTP account for you. Check your PM on SHP.
-
It's ok, I got them off gog, that's a steal of a deal!
-
Even though I was going to wait until official beta, the whole Sierra Script thing kind of derailed that a bit. So I decided to release an interim version (details in the first post of this thread, again).
To convert a game from the existing syntax, open the game properties and select "Sierra Script" for the language, then click ok. A bunch of confirm and warning dialogs will come up asking if you want to convert everything now. The UI will hang while it does this (since this would be rarely-used, I didn't offer progress/cancel functionality). Takes a few seconds on my machine, or around 30 seconds in debug builds. So things may appear hung for a while. If you have open script files, you'll need to close and re-open them to see the changes.
(You can also convert on a script-by-script basis by clicking the convert button at the top of the script editor. It's enabled if the current script is in a different language than the default game language).
I don't have a converted template-game in there yet, but you can just create a new one (but make sure to choose SCI Studio as the language when you do that), then convert. Should work with both SCI0 and SCI 1.1 template games.
The template game also has a lot of changes, but I've been keeping the last few posts in this thread up-to-date, particularly this one: http://sciprogramming.com/community/index.php?topic=1458.msg7971#msg7971
If you want to update an existing game you're working on, there will be lots of find-and-replace and file renaming. Or if you don't care, you can just keep your game as is. There were a few small changes to sci.sh which will cause compiles to fail though.
-
Awesome.
-
Sweet.
-
A crash that most would probably never encounter, but I was experimenting with Brian's SCI1 demo that Omer posted. I wanted to see if I could get Companion to pack the resources into a single resource file. I did not expect it to work and it did create a zero length resource file. I deleted this and accidentally deleted the map file. This caused Companion to open a message that the file could not be found and then crashed after hitting the rebuild. This is with the latest build.
One other observation is that Companion will properly display the PIC resources is you set the version detection and reload the game. Not sure if this is already known and I missed it or not. I guess it is not properly detecting the version of Brian's VGA demo, but then as Kawa found out, neither does SV.
-
The whole LSL1 comparison kinda falls flat when SV can load that perfectly fine X3
-
Any crash is a bad crash. What do you mean by pack the resources into a single resource file?
Can you explain your 2nd paragraph a bit more? I don't really understand... what do you mean "set the version detection and reload the game"?
-
Any crash is a bad crash. What do you mean by pack the resources into a single resource file?
I agree, which is why I was reporting it. Brian's demo has all of the resources as individual files. I wanted to see if I could pack them into a single RESOURCE.000 file.
This is what you get when you load Brian's demo and open the Version detector dialog. If you set everything to SCI1 VGA and hit the reload game Companion will properly display the graphics.
-
SCI1 doesn't support RESOURCE.000.
-
Ok, last night I launched SCI Companion 3.0.1.0 and it worked fine. Today I try to launch it and it crashes immediately. No idea what the problem is...
EDIT: Weird, I extracted and overwrote everything from the zip and it launches fine now...
-
Right, we knew that Brian's demo worked if we set the pic to VGA and reloaded it.
It would be very difficult to detect which version his demo is, since there's no resource package file, and the resource.map has no entries in it. So there's nothing to inspect, really.
And as you found, Companion doesn't support packaging stray files into the resource map/package. You'd need to add them manually.
MusicallyInspired, very suspicious. Let me know if it happens again, and if so, zip up the contents of the directory and send it to me.
-
Will do.
Also, I didn't want to derail Kawa's Christmas Card thread so I thought I'd share the results of my attempting to compile KQ2SCI with Sierra Script. The result was an instant "Oops!" error message when the game loaded and quit immediately.
EDIT: I ran it with "SCIV.EXE -d" for debug mode and it said there was an attempt to divide by zero. The first object it lists in the debug window is:
-
Lol, just like in Collector's case I can also not repro. Works fine for me. Can you attach the zipped game directory or something?
[edit:] hmm, ok, I can repro with the version of Companion that I uploaded... interesting...
-
I didn't want to derail Kawa's Christmas Card thread
I'm active on Byuu's Board. I'm more than used to derailed threads.
-
In other news, SCI Companion won't properly quit anymore if you've opened a game in it. My first thought: the "don't allow closing the game tab" thing.
-
What do you mean it won't properly quit?
-
There are no visible windows and I have to kill it from a task manager.
-
Not getting that here..
-
Mind you, only when you first open a game. Any game.
-
This is what I tried:
- Open SCI Companion (no game loaded)
- Open a game from the MRU
- Click the close button (X) in the frame of SCI Companion
Result: SCI Companion closes properly
If you're reporting a bug, please please please list the repro steps explicitly.
-
What would it take to take any pre-SCI1.1 game and convert it to SCI1.1? Like, say I wanted to take my old SCI0 game and remake it in VGA. Since the script language is largely the same (there really isn't any difference, is there?), could there be some kind of conversion process to turn everything into SCI1.1? Putting aside for a moment the complication of the different graphics asset formats...
I know, I'm bringing up another big question when there's already so much going on...I'm sorry. Is there some way to do this now without a built-in function? I guess just create a new SCI1.1 game and overwrite the SRC folder with the contents from the older game?
EDIT: The reason I ask is because way back when Brian was first talking about SCI Studio VGA and how easy it was to make he also mentioned how easy it was to upgrade an existing SCI0 game to SCI1 by just changing parser commands to verb interactions along with a few other things, and I wonder if it really is as simple as that.
-
We seem to have a heisenbug, because just now I've tried to reproduce it a few times and sometimes it did sometimes it didn't.
Considering I had a loud fan and like six leftover instances earlier today, that miffs me.
-
The syntax is the same, yes. But Saids and synonyms are not supported in SCI1.1. synonyms just won't be output in the script resource, and I'm not sure what happens if you call Said. I would guess it just returns false or crashes the interpreter.
Since, other than a few fan games I've seen, everything is text-parser based, I can't see this as being much use.
At any rate, one other reason it might not work is that the interpreter makes assumptions about some of the classes. In particular the offsets of certain selectors need to be at certain positions in the classes's property list. We had issues with this before when moving the SQ5 decompiler source to the LSL6 interpreter.
Probably the easiest thing to do is to create a new SCI1.1 game, and copy your source files in there... but not the ones that overwrite Actor/Prop and such. Leave all the SCI1.1 base classes there. Just copy over your room classes. Hmm... well, now I'm not sure. I guess you still want all the menubar stuff (which is not used in the SCI1.1 template game, but I think still supported by the interp). I dunno, hurts my head to think about it. I guess... give it a try? The issue with selector positions I mentioned above is just a problem with Sierra's interpreter, not with ScummVM. So if you manage to get it working in ScummVM, there's probably some tweaks we could make to have it behave ok in Sierra's interp too.
I don't think there could ever be a tool to do this automatically though...
-
We seem to have a heisenbug, because just now I've tried to reproduce it a few times and sometimes it did sometimes it didn't.
Considering I had a loud fan and like six leftover instances earlier today, that miffs me.
It's possible it was fixed by this, which I think I checked in after the release I made.
https://github.com/icefallgames/SCICompanion/commit/23b14f6cbbe78e23708f9152d83f23b035093d31
That was stopping the release build in the debugger when trying to close Companion. But if not run in the debugger, it closed fine... I think.
-
The syntax is the same, yes. But Saids and synonyms are not supported in SCI1.1. synonyms just won't be output in the script resource, and I'm not sure what happens if you call Said. I would guess it just returns false or crashes the interpreter.
Since, other than a few fan games I've seen, everything is text-parser based, I can't see this as being much use.
At any rate, one other reason it might not work is that the interpreter makes assumptions about some of the classes. In particular the offsets of certain selectors need to be at certain positions in the classes's property list. We had issues with this before when moving the SQ5 decompiler source to the LSL6 interpreter.
Probably the easiest thing to do is to create a new SCI1.1 game, and copy your source files in there... but not the ones that overwrite Actor/Prop and such. Leave all the SCI1.1 base classes there. Just copy over your room classes. Hmm... well, now I'm not sure. I guess you still want all the menubar stuff (which is not used in the SCI1.1 template game, but I think still supported by the interp). I dunno, hurts my head to think about it. I guess... give it a try? The issue with selector positions I mentioned above is just a problem with Sierra's interpreter, not with ScummVM. So if you manage to get it working in ScummVM, there's probably some tweaks we could make to have it behave ok in Sierra's interp too.
I don't think there could ever be a tool to do this automatically though...
Well, my idea is not to simply to carry everything over and play exactly the same as in SCI0 with no difference (obviously there would be no parser, for instance). There's not much point in that at all, I agree. I'm talking about remaking a game with VGA graphics, speech, and all the enhancements of P&C and SCI1.1. Completely remake the game. It would just be easier because I wouldn't have to script everything from scratch again. I wouldn't miss anything like the menubar and other SCI0-centric aesthetics. Like, take KQ4 and make it a SCI1.1 game with a typical SCI1+ interface and remake VGA graphics. Or SQ1VGA, even, and give it speech. Or KQ5, just to mess around and remove dead ends (or add new ones lol).
I'll test it out. What are the SCI1.1 base classes then?
-
I'll test it out. What are the SCI1.1 base classes then?
You mean the ones where the selectors are at assumed positions? We never found out, exactly. I determined it was Feature and most of the ones that inherited from that, but also others.
It doesn't really matter though... it sounds like you understand the implications of moving from SCI0 to SCI1.1, and so probably the best course of action is just to copy your rooms over (and rename Rm to Room, Act to Actor, etc...). No reason that shouldn't work.
-
What if you had the compiler choke on those parts so that by attempting to compile it would ID the lines that need manual intervention/conversion?
-
Choke on which parts?
-
The parts that differ between compilers I guess?
-
That's just it, there's only one compiler. So I'm not really sure what he means.
I guess I could output a warning if there is a synonyms clause in the script and I'm writing to a SCI1+ script resource. That's about all I can think of. But hardly anyone uses those, so it seems a bit pointless.
-
I was just kicking around ideas to facilitate MI's suggestion to ease porting an SCI0 game to SCI1.1. What cannot be automated needs to be identified to manually fix it. If the compiler would halt when it finds an unsupported elements and the script and line number were identified it would make finding what needs to be fixed faster.
-
It would be nice, but I can't really think of anything in that category (easily identifiable and obviously wrong).
-
I've uploaded a new version with the fix for the corrupted SCI0 script resource generation (it also affected SCI1.1, but not in a fatal way).
-
OK, Aquarius converted to Sierra script works now. I will try a few more as I get time.
I tried NSIS Publisher as a plugin with this version. It is not passing the argument of the project's path, so no automatic publish. I also need to make some adjustments to handle reading the Sierra scripts.
-
OK, Aquarius converted to Sierra script works now. I will try a few more as I get time.
I tried NSIS Publisher as a plugin with this version. It is not passing the argument of the project's path, so no automatic publish. I also need to make some adjustments to handle reading the Sierra scripts.
I think I see the problem... it doesn't work with paths with spaces in them. I'll try enclosing the path in quotes...
[edit:] yup, that fixed it.
-
Could you upload a binary? I am trying to track down an odd problem where I am getting a CRC mismatch on the installer. Adding a wait solves it, but that causes a delay in the form showing for a few seconds, which I would rather avoid. I would like to track it down by calling it from Companion.
-
http://icefallgames.com/Downloads/Temp.zip
Replace your SCICompanion.exe with this one ^^^^
-
Thanks
-
I've done another update of the documentation at scicompanion.com. Mostly just syntax and class renaming, but also some basic tutorials here:
http://scicompanion.com/Documentation/sci11_tutorial.html
I think that's the extent of the tutorials I'll do for the core documentation, so any further (or more explanatory) stuff should go in the tutorials forum here.
-
I suppose there's no offline version of these docs is there? Just download the htmls?
-
They're included with SCI Companion, accessed from the Help menu. The ones on the site are slightly more up-to-date though (eventually they'll be the same).
-
Using 3.0.1.1 and opened my current project. Without changing anything, compiled all.
In View.sc
Undeclared identifier 'noCycler' line 118, col:55
Unknown procedure 'CanBeHere'. lin:854, col:27
Just to make sure I wasn't crazy, opened game back up in v .13 and compile all finishes fine.
-
See here:
http://sciprogramming.com/community/index.php?topic=1458.msg7971#msg7971
noCycle has been renamed to skipCheck (sci.sh change)
CanBeHere has been renamed CantBeHere (kernel change)
-
Is there a list of the changes that could be referenced for conversions? I am thinking of going through all of the fan games to convert them to Sierra script.
-
Basically just in that thread.
For fan games, they are all SCI0, so I don't think any changes are needed (with the possible exception of new reserved keywords being used for variable names - though I do try to recognize those and change the names). All the changes are for the SCI 1.1 template game.
If the fan game was made with SCI Studio, there might be compile errors that need to be fixed before converting (the game needs to compile without errors in Studio script before converting). Companion was always stricter than Studio when it came to parentheses, and some parts of the original SCI0 template game fail to compile. For instance in Gauge.sc:
= ctlX (- (- nsRight (send btnCancel:nsRight) 4) )
needs to be
= ctlX (- (- nsRight (send btnCancel:nsRight)) 4 )
-
It might be a false impression, but I think that outside of the earliest games like Eigen's games, the majority were probably done with Companion. In any case, I will probably re-upload everything with both the original Studio source and well as the ported Sierra script source.
-
I think there were a total of 3 games ever made in Studio. That's when Brian abandoned it, methinks. After this community opened up due to MT's demise and Companion was released, that's when the games started again.
-
That was my impression. Also part of the reason that Brian gave up on SCI before SCI Studio VGA was done. Not enough games for his efforts. He was probably hoping that Studio would have led to a flood of fan games the way AGI Studio did. This was probably a unreasonable expectation given that most of the AGI fan games little more than demos of abandoned games.
-
And AGI was easier to make. I had to give myself a crash course in OOP with Studio. That was my introduction to scripting/coding. Certainly helped, but not everyone is as patient about these things as I am. Also, AGI graphics are infinitely easier to make and get away with. On top of that, everyone just wanted VGA P&C and eventually abandoned him for AGS. After a while Brian himself started linking to and recommending AGS. I'm glad he did SCI0, though. If he didn't nobody would have. It's a great parser engine with incredible EGA graphics capability.
-
Agreed.
-
While adding priority colors to a pic resource.
I drew several of the priority areas, changing colors between each. I decided that I needed another area of the same color I had already used. So I moved to the appropriate area in the command list, picked my spot and drew another line. As soon as I completed the line (which entered at the correct spot in the list), the position I was in on the command list jumped down to the end, so that the next line I draw was in the wrong area of the command list, thus rendering the line incorrectly.
-
Ooo, that's a bad one. I'll try to release a patch today.
[edit:] Version 3.0.1.2 released with the fix.
-
How does Companion behave when there's a patch Script resource in the game directory? It lists both the patch and the embedded one in the resource list, but when it disassembles where does it disassemble from? The patch or the embedded one? Or does it disassemble both?
EDIT: Strange, I'm trying to decompile the KQ5 floppy version and there are certain scripts that won't decompile at all. It doesn't give a reason, it just says 0% successful for those scripts. Any idea why? They are:
- setControls (755)
- sysLogger (952)
- PolyPath (965)
- Polygon (966)
- DCIcon (967)
- MoveFwd (972)
- RFeature (973)
- Follow (975)
- Chase (977)
- Rev (978)
- Wander (979)
- SysWindow (980)
- myWindow (981)
- n982
- Path (983)
- n984
- Avoid (985)
- Orbit (986)
- Sound (989)
- SRDialog (990)
- Jump (991)
- Cycle (992)
- gamefile.sh (993)
- Game (994)
- InvI (995)
- User (996)
- Class_997_0
- MyLooper (998)
- Obj (999)
Also, my attempts to compile a script for KQ5CD have been a failure. It just gives me an Oops error when it encounters the script. However, in ScummVM it shows the changes properly. I'm throwing a wild guess that it has something to do with Companion not detecting all the resource formats of KQ5CD properly or something.
-
Patch files generally have precedence over the same resource in the resource map. So if you disassemble or decompile, it should take the patch resource.
Some parts of the code (for instance the one that rebuilds the resource packages) ignore patch files.
-
EDIT: Strange, I'm trying to decompile the KQ5 floppy version and there are certain scripts that won't decompile at all. It doesn't give a reason, it just says 0% successful for those scripts. Any idea why? They are:
KQ5 CD is a weird one. I'm making assumptions that are incorrect. So... that's not supported right now. i.e. it's Script resources have a combination of things that no other game has (specifically: lofsa opcode is absolute, heap resources are not separate, and the export table is 16-bit instead of 32-bit).
-
The save restore script needs some serious work...
When Saving...
- selecting a previous save slot, it does not change the description text to selected.
-- Assuming it will save correctly, clicking save, it does overwrite the file in description not the selected.
-- Changing description to match the text selected, creates another save game with the same description.
Basically, here, there is no way to overwrite an old save game slot, only the most recent one.
When Deleteing...
- Like with saving, selecting a previous save game does not change the description text to selected
-- Clicking Delete, all save game descriptions take the name of the most recent saved game
I have attached a couple images of the before and after of deleting
-
That reminds me. I wanted to try and replace srdialog.sc with OmerMor's save.sc. With the unsupported bits removed of course.
-
Oh, I see the problem. It's a disassembler issue.
code_0706:
lsl local4
ldi 1
eq?
bnt code_0404
pushi #cursor
pushi 1
pushi 1
pushi 2
lsp param1
[i] ; lat temp2
lea @[temp3 temp2][/i]
push
callk StrCpy, 4
push
callk StrLen, 2
Change the italicized lines I surrounded in i tags above. For Studio syntax, you'll probably want @temp3[temp2] instead (and // for the comment instead of ;, or just delete that line)
That will fix the edit box not updating issue.
The other problem is basically the same, but not as easily fixable as the indexer is not a simple value. And there are actually a number of other cases of this in there. This will probably require a fix in Companion.
Probably it can be fixed with the current Companion by introducing a few more temp variables into the method. How urgent is this?
-
Not urgent at all, just a bug I came across.
-
Ah, that is annoying. I always hated that you couldn't overwrite save games in AGS. Always preferred the way SCI did it.
-
What's happened? Who was that guy with the overdeveloped hair dryer? Why did you let yourself be talked into jumping into some strange shimmering hole? Why are you talking to yourself? These incredibly intriguing questions will quickly be forgotten with barely an electron stirred in that well-armored orb atop your shoulders.
Space Quest 4's CD version has messages. That's neat. But what about the earlier floppy version?
What's happened? Who was that guy with the overdeveloped hair dryer? Why did you let yourself be talked into jumping into some strange shimmering hole? Why are you talking to yourself? These incredibly intriguing questions will quickly be forgotten with barel
...oh. Okay, so the problem here is that Companion's text resource editor clips off too-long lines. The rest of the line is most certainly there -- I just checked in-game real quick -- but if I were to edit it...
Naturally, this gets worse in multilingual games.
Obvious difference: the text editor is a grid with in-place editing, while the message editor is two parts, the actual text being a nice multi-line textbox. Perhaps Brian was on to something with Studio's text editor?
-
What's happened? Who was that guy with the overdeveloped hair dryer? Why did you let yourself be talked into jumping into some strange shimmering hole? Why are you talking to yourself? These incredibly intriguing questions will quickly be forgotten with barely an electron stirred in that well-armored orb atop your shoulders.
As I read your quote it of course played in my head with Gary Owens' voice.
-
As I read your quote it of course played in my head with Gary Owens' voice.
But only the top quote of course!
-
Is that the 256-character limit again? I ran into that with SCI0 and had to use SCI Studio to get the TEXTs that I wanted. I had thought it was fixed.
-
It might well be, I never bothered to count.
Also, if text entries can contain newlines...
-
Yes, it's that. It wasn't properly fixed I guess.
Also, if text entries can contain newlines...
What does this mean? When you report bugs, please try to be specific and clear.
-
They behave just like strings so you can put '/n' there and the game will interpret it as a new line.
-
That wasn't a bug report -- only the length limit thing was. In the Message editor, a multi-line entry shows up with "\n" in the overview, but with much clearer and user-friendly actual newlines in the separate edit box. In the Text editor, you have to write the literal "\n" yourself, which is somewhat less user-friendly I think. Same thing with tabs and "\t".
-
Even more user-friendly would be to have the text resources created automatically from strings in the code, like Sierra did it.
-
And even more user-friendly decompiler would reintroduce these strings back into the decompiled scripts whenever possible... 8)
-
And even more user-friendly decompiler would reintroduce these strings back into the decompiled scripts whenever possible... 8)
Err, it already does that, at least for calls to procedures named Print.
The problem is, it depends on text resource support in the procedure you're calling, so there's no automatic way to do this... there needs to be a whitelist.
-
I think supporting reverse message lookup for calls to the Format kernel function would help tremendously.
They are all over.
-
It's interesting that the official docs never describe any distinction between the brace syntax and double-quote syntax for strings. The "Script programming language" document from April 1988 uses only double-quote syntax, while the "changes" document (which starts in October 1988) makes no mention of brace syntax being introduced, and just kind of assumes it.
So the "double-quote strings automatically generate text resources" functionality must have not been present at first, but then introduced very early on.
-
Interesting.
I tried to look it up as well, but found no mention of it.
-
New version released, with fixes for a lot of compile issues people were having for games outside the SCI0/SCI1.1 template games. AFAIK, scripts resources should be generated correctly for any SCI0-SCI2 game now*.
There were some "risky" changes to how the compiler works, but it is now a little simpler and should be a little more flexible as to how it generates script resources now (which allowed me to better debug issues the compiler was having with some SCI1 games). I've done my standard test passes, and every seems ok though.
I had thought about seeing if I could strip down LSL5, which is what I believe he started from. While the game will open in the new Companion, every time I try to do anything with the resources in the new companion it makes the resources unreadable.
Hmm... I'm sort of able to repro this. I had a bug specific to VGA views in SCI1 games. It should be fixed now. It resulted in corrupt views (still readable, they were just garbled) Can you explain a bit better what you were experiencing? Which resources did you modify? Did it affect other resources or just that one?
-
I was trying to strip out unneeded resources from LSL5 to match the scripts from Brain's SCI1 template. It was just an experiment to see how much work there might be in trying to finish Brian's SCI1 template game. Just deleting a couple of Pics will make the game unreadable. The Map goes from 3.14 KB to 6 bytes. and the RESOURCE.001 drops from 1.05 MB to 1.02 MB. RESOURCE.000 and RESOURCE.002 are unchanged. I am assuming that the pics were in RESOURCE.001, but rewriting the map fails.
-
Sweet! Thank you again so much!
-
Just deleting a couple of Pics will make the game unreadable. The Map goes from 3.14 KB to 6 bytes. and the RESOURCE.001 drops from 1.05 MB to 1.02 MB. RESOURCE.000 and RESOURCE.002 are unchanged. I am assuming that the pics were in RESOURCE.001, but rewriting the map fails.
Ah, ok. That should be fixed in this latest release.
-
I just tried the newest and it properly rewrites the map. So you can take this one off your bug list. Now I am wondering it it might make more sense to decompile an SCI1 game to do a template game or see if something can be done with Brian's unfinished SCI1 template scripts.
On another note, fooling around with this I noticed that if a source is not found when trying to open a script in the resources that Companion offers to disassemble the script for you. How difficult would it be for it to call the decompiler instead of disassembly?
-
I fail to recompile scripts from King's Quest 5 CD.
Script #0 appears to be accessing property called 'yourself' from KQ5Cursor, but the KQ5Cursor class (from script #768) doesn't appear to have it.
Any idea?
-
I haven't tried compiling script 0, but I messed around with room 1 just fine by itself. I didn't try to compile all scripts.
-
I fail to recompile scripts from King's Quest 5 CD.
Script #0 appears to be accessing property called 'yourself' from KQ5Cursor, but the KQ5Cursor class (from script #768) doesn't appear to have it.
Any idea?
You mean a method? yourself: is a method on Obj, which is the base class for most objects. What's the error? I get errors too, but about not finding the cursor property on TheMenuBar. TheMenuBar kind of looks corrupt.
I'll be away from my main computer for several days, so I won't be able to help much unfortunately. All I can do is helplessly watch the bug reports file in :P
-
fyi, it has come to my attention that some changes I made to the decompiler have exposed a bug in the compiler.
Specifically, assignments are no longer pulled out into separate statements by the decompiler. If the assignment is an array though, Companion emits the wrong bytecode. So if you encounter any problems with crashes with decompiled scripts, check to see if you see this pattern (old syntax):
(send (= localVar[arrayIndex] (SomeClass:new())):
someSelector(3)
anotherSelector(blahblabhlah)
)
and instead pull the assignment out into a line above, and just use localVar[arrayIndex] as the send target.
-
I'll be away from my main computer for several days, so I won't be able to help much unfortunately.
Enjoy your (well deserved) time off!
-
Indeed!
-
Some SCI games use kernel functions that are not specified in the their vocab.999 file.
One such example is the Astro Chicken (http://sourceforge.net/projects/scummvm/files/demos/sci/astrochicken-dos-demo-en.zip/download) demo from SQ3.
In script #0, in SQ3::init, there is a call to kernel function 112, which according to ScummVM is the Graph kernel function.
The decompiler and the disassembler fails to output something compilable:
= global598 ?(2)
This is how ScummVM disassembles it:
0001:0102: 39 57 pushi 57
0001:0102: pushi 57
0001:0104: push0
0001:0105: super 34 04
0001:0108: push1
0001:0109: push2
0001:010a: callk Graph[70] 02
0001:010d: sag 0256
...
Another issue with the same game:
In the same script, there is a weird instance declaration that fails to compile:
(instance logFile of {gamefile.sh}
(properties)
)
I remember you're out Phil; just documenting this for when you get back... :)
-
Ah yes, the File class wackiness.
-
I fail to recompile scripts from King's Quest 5 CD.
Script #0 appears to be accessing property called 'yourself' from KQ5Cursor, but the KQ5Cursor class (from script #768) doesn't appear to have it.
Any idea?
You mean a method? yourself: is a method on Obj, which is the base class for most objects. What's the error? I get errors too, but about not finding the cursor property on TheMenuBar. TheMenuBar kind of looks corrupt.
I'll be away from my main computer for several days, so I won't be able to help much unfortunately. All I can do is helplessly watch the bug reports file in :P
Here's a complete repro:
- Open up KQ5 from the King's Quest Collection (version 1.000.052).
- Decompile all scripts twice.
- Open script #0.
- Compile script.
Here's the complete compilation output:
Script 65535 (n000) declared itself as resource 0
[Warning]: 'Polygon' has no effect on code. Line: 1531, col: 2
[Warning]: 'PolyPath' has no effect on code. Line: 1532, col: 2
[Warning]: 'RFeature' has no effect on code. Line: 1533, col: 2
[Warning]: 'Timer' has no effect on code. Line: 1534, col: 2
[Error]: cursor is not a property or method on type 'TheMenuBar'. Line: 1590, col: 11
[Error]: cursor is not a property or method on type 'TheMenuBar'. Line: 1594, col: 11
[Error]: cursor is not a property or method on type 'TheMenuBar'. Line: 1598, col: 11
[Error]: cursor is not a property or method on type 'TheMenuBar'. Line: 1602, col: 11
[Error]: cursor is not a property or method on type 'TheMenuBar'. Line: 1606, col: 11
[Error]: cursor is not a property or method on type 'TheMenuBar'. Line: 1610, col: 11
[Error]: cursor is not a property or method on type 'TheMenuBar'. Line: 1614, col: 11
[Error]: cursor is not a property or method on type 'TheMenuBar'. Line: 1618, col: 11
[Error]: select is not a property or method on type 'TheMenuBar'. Line: 1909, col: 20
[Error]: select is not a property or method on type 'TheMenuBar'. Line: 1919, col: 20
Unable to find name for script #766
[Error]: yourself is not a property or method on type 'KQCursor'. Line: 1988, col: 12
Unable to find name for script #766
[Error]: yourself is not a property or method on type 'KQCursor'. Line: 2008, col: 12
Unable to find name for script #766
[Error]: yourself is not a property or method on type 'KQCursor'. Line: 2026, col: 12
Unable to find name for script #766
[Error]: yourself is not a property or method on type 'KQCursor'. Line: 2044, col: 12
Unable to find name for script #766
[Error]: yourself is not a property or method on type 'KQCursor'. Line: 2064, col: 12
Unable to find name for script #766
[Error]: yourself is not a property or method on type 'KQCursor'. Line: 2084, col: 12
Unable to find name for script #766
[Error]: yourself is not a property or method on type 'KQCursor'. Line: 2104, col: 12
Unable to find name for script #766
[Error]: yourself is not a property or method on type 'KQCursor'. Line: 2124, col: 12
Unable to find name for script #766
[Error]: yourself is not a property or method on type 'KQCursor'. Line: 2144, col: 12
Unable to find name for script #766
[Error]: yourself is not a property or method on type 'KQCursor'. Line: 2164, col: 12
Unable to find name for script #766
[Error]: yourself is not a property or method on type 'KQCursor'. Line: 2182, col: 12
Unable to find name for script #766
[Error]: yourself is not a property or method on type 'KQCursor'. Line: 2202, col: 12
09:31:30PM
--------------------------------------------------------
Compiling n000.sc failed.
22 errors, 5 warnings.
And here's the complete decompiled script #0:
(version 2)
(include "sci.sh")
(exports
0 KQ5
1 proc0_1
2 proc0_2
3 proc0_3
4 proc0_4
5 proc0_5
6 proc0_6
7 proc0_7
8 proc0_8
9 proc0_9
10 proc0_10
11 proc0_11
12 proc0_12
13 proc0_13
14 proc0_14
15 proc0_15
16 proc0_16
17 proc0_17
18 proc0_18
19 proc0_19
20 proc0_20
21 proc0_21
22 proc0_22
23 proc0_23
24 proc0_24
25 proc0_25
26 proc0_26
27 proc0_27
28 proc0_28
29 proc0_29
30 proc0_30
)
(use "n255")
(use "n403")
(use "n765")
(use "n768")
(use "n931")
(use "n933")
(use "n937")
(use "n945")
(use "n946")
(use "n958")
(use "n967")
(use "n973")
(use "n978")
(use "n989")
(use "n992")
(use "n994")
(use "n996")
(use "n997")
(use "n998")
(use "n999")
(script 0)
(local
gEgo
gGame
global2
gNewSpeed = 6
global4
gCast
gRegions
gTimers
gSounds
gInv
gAddToPics
gNumber
gGNumber
gNewRoomNumber
global14
global15
global16
global17 = 7
global18
gCursorNumber
gArrowCursor = 999
gSpeakCursor = 20
global22 = 1
global23 = 4
gPEvent
gTheNewDialog
global26 = 1
global27
gLocales
global29
global30 = 10
gPicAngle
gFeatures
gSFeatures
global34
global35
gPicNumber = -1
global37
gKQ5Window
global39 = 3
global40
global41
global42
global43
global44
global45
global46
global47
global48
global49
global50
global51
global52
global53
global54
global55
global56
global57
global58
global59
global60
global61
global62
gKQ5Controls
gFtrInit
gKq5DoVerbCode
global66
global67 = 1
global68
gIconBar
gPEventX
gPEventY
gMyKeyDownHandler
gMyMouseDownHandler
global74
gTheGameCursor
global76
gKQPMouse
gTheDoits
global79 = 60
gUser
global81
gNewSync
global83
gNewEventHandler
gFont
global86
global87
global88
gTheInvCursor
global90
global91
global92
global93
global94
global95
global96
global97
global98
global99
global100
global101 = 5
global102
global103 = 1
global104
global105
gGTheGameCursor
global107
global108
global109
gGEgoX
gGEgoY
global112
global113
global114
global115
global116
global117
global118
global119
global120
global121
global122
global123
global124
global125
global126
global127
global128
global129
global130
global131
global132
global133
global134
global135
global136
global137
global138
global139
global140
global141
global142
global143
global144
global145
global146
global147
global148
global149
global150
global151
global152
global153
global154
global155
global156
global157
gGlobalSound3
global159 = 256
global160
global161
global162
global163
global164
global165
global166
global167
global168
global169
global170
global171
global172
global173
global174
global175
global176
global177
global178
global179
global180
global181
global182
global183
global184
global185
global186
global187
global188
global189
global190
global191
global192
global193
global194
global195
global196
global197
global198
global199
global200
global201
global202
global203
global204
global205
global206
global207
global208
global209
global210
global211
global212
global213
global214
global215
global216
global217
global218
global219
global220
global221
global222
global223
global224
global225
global226
global227
global228
global229
global230
global231
global232
global233
global234
global235
global236
global237
global238
global239
global240
global241
global242
global243
global244
global245
global246
global247
global248
global249
global250
global251
global252
global253
global254
global255
global256
global257
global258
global259
global260
global261
global262
global263
global264
global265
global266
global267
global268
global269
global270
global271
global272
global273
global274
global275
global276
global277
global278
global279
global280
global281
global282
global283
global284
global285
global286
global287
global288
global289
global290
global291
global292
global293
global294
global295
global296
global297
global298
global299
global300
global301
global302
global303
global304
global305
global306
global307
global308
global309
global310
global311
global312 = -1
global313
global314
global315
global316
gGlobalSound4
global318
global319
global320
global321
gPolyList15
gPEventX_2
gPEventY_2
global325
global326
global327
gGlobalAudio
gGlobalSound2
global330
global331
global332
global333
global334
global335
global336
global337
global338
global339
global340
global341
global342
global343
global344
global345
global346
global347
global348
global349
global350
global351
global352
global353
global354
global355
global356
global357
global358
global359
global360
global361
global362
global363
gTheHenchManX
gTheHenchManY
global366
global367
global368
global369
global370
global371
global372
global373
global374 = 1
global375
global376
global377
global378
global379
global380
global381
global382
global383
global384
global385
gMordObj
global387
gNewActorCloner
gNewActorCloner_2
gNewActorCloner_3
gNewActorCloner_4
gNewActorCloner_5
global393
global394 = 1
global395
gTheCrownCursor
gGlobalSound
gEmptyBagCursor
global399
global400
global401
)
(procedure public (proc0_1 param1 param2)
(if (>= paramTotal 1)
(send gEgo:loop(param1))
)(else
(if (== paramTotal 2)
(send gEgo:view(param2))
)
)
(send gEgo:
setLoop(-1)
setPri(-1)
setMotion(0)
moveSpeed((send gGame:egoMoveSpeed))
setCycle(KQ5SyncWalk)
cycleSpeed((send gGame:egoMoveSpeed))
setStep(3 2)
normal(1)
illegalBits(-32768)
ignoreActors(0)
)
)
(procedure public (proc0_2)
(send gGame:setCursor(gSpeakCursor 1))
(User:
canControl(0)
canInput(0)
)
(send gEgo:setMotion(0))
(send gIconBar:disable())
= global102 1
)
(procedure public (proc0_3)
(User:
canControl(1)
canInput(1)
)
(send gIconBar:enable())
(send gGame:setCursor((send ((send gIconBar:curIcon)):cursor) 1))
= global102 0
)
(procedure public (proc0_4 param1)
return > MemoryInfo(1) param1
)
(procedure public (proc0_5)
Animate((send gCast:elements) 0)
)
(procedure public (proc0_6)
(if (gTheNewDialog)
(send gTheNewDialog:dispose())
)
)
(procedure public (proc0_7 param1 param2 param3)
(var temp0)
proc0_24(param1 = temp0 GetAngle((send param1:x) (send param1:y) (send param2:x) (send param2:y)) param3)
(if (== paramTotal 4)
proc0_7(param2 param1 param3)
)
)
(procedure public (proc0_8 param1 param2 param3 param4)
(var newEvent)
(send (= newEvent (Event:new())):
type(param2)
message(param3)
modifiers(param4)
)
(if (param1)
(send param1:handleEvent(newEvent))
)(else
(KQ5:handleEvent(newEvent))
)
(send newEvent:dispose())
)
(procedure public (proc0_9 param1)
localproc_1315(0 rest param1)
)
(procedure public (proc0_10 param1)
localproc_1315(2 rest param1)
)
(procedure public (proc0_11 param1)
localproc_1315(3 rest param1)
)
(procedure public (proc0_12 param1)
localproc_1315(1 rest param1)
)
(procedure public (proc0_13)
)
(procedure public (proc0_14)
)
(procedure public (proc0_15 param1 param2 param3 param4)
(var temp0, temp1, temp2)
(if (global156)
Display(0 2 108 global157)
Display(0 2 108 global156)
= global156 0
)
(if (param1)
= temp1
(if ((> paramTotal 1) and (>= param2 0))
param2
)(else
5
)
= temp0
(if ((> paramTotal 2) and (>= param3 0))
param3
)(else
5
)
= temp2
(if ((> paramTotal 3) and (>= param4 0))
param4
)(else
0
)
= global156 Display(param1 106 (- 260 temp0) 100 temp0 temp1 101 0 105 9 102 temp2 107)
= global157 Display(param1 106 (- 260 temp0) 100 temp0 temp1 101 0 105 8 102 15 107)
)
)
(procedure public (proc0_16)
)
(procedure public (proc0_17)
)
(procedure public (proc0_18 param1 param2 param3)
(var temp0)
= temp0 0
(while (<= temp0 100)
Palette(4 param1 param2 temp0)
Wait(param3)
= temp0 (+ temp0 5)
)
)
(procedure public (proc0_19)
(var temp0)
(while (not <> (= temp0 proc255_3("Teleport to:")) -1)
)
= global103 0
(send gGame:setCursor((= gGTheGameCursor gTheGameCursor) 1))
(send global2:newRoom(temp0))
)
(procedure public (proc0_20)
)
(procedure public (proc0_21)
(var temp0, newEvent, temp2)
(if ((User:canInput()))
= temp0 (send gGame:setCursor(gTheInvCursor))
= global126 0
(signalView:
view(942)
loop(0)
cel(10)
posn(gPEventX - (signalView:y) 10 - (signalView:y) gPEventY)
forceUpd()
show()
)
Animate((send gCast:elements) 0)
= temp2 GetTime()
(while (not not (< Abs((- temp2 GetTime())) 40) and not proc999_5((send ((= newEvent (Event:new()))):type) 4 1))
(send newEvent:dispose())
)
(if (IsObject(newEvent))
(send newEvent:dispose())
)
(signalView:
posn(1000 1000)
hide()
)
(send gGame:setCursor(temp0 1))
)
)
(procedure public (proc0_22)
)
(procedure public (proc0_23)
)
(procedure public (proc0_24 param1 param2 param3)
(var temp0)
(if (not & (send param1:signal) $0800)
(if ((< paramTotal 3) or not (= temp0 param3))
= temp0 NumLoops(param1)
)
(if (> temp0 8)
(send param1:loop(
(if ((> param2 22) and (< param2 68))
6
)(else
(if ((> param2 67) and (< param2 113))
0
)(else
(if ((> param2 112) and (< param2 158))
4
)(else
(if ((> param2 157) and (< param2 203))
2
)(else
(if ((> param2 202) and (< param2 248))
5
)(else
(if ((> param2 247) and (< param2 293))
1
)(else
(if ((> param2 292) and (< param2 338))
7
)(else
3
)
)
)
)
)
)
)
))
)(else
(if (> temp0 4)
(send param1:loop(
(if ((> param2 44) and (< param2 136))
0
)(else
(if ((> param2 135) and (< param2 225))
2
)(else
(if ((> param2 224) and (< param2 316))
1
)(else
3
)
)
)
))
)(else
(if (temp0)
= param2 (% (+ (= param2 (- param2 (/ 180 temp0))) 360) 360)
(send param1:loop((/ param2 (/ 360 temp0))))
)
)
)
(if ((send param1:respondsTo(#head)))
(send ((send param1:head)):look())
)
)
)
(procedure public (proc0_25)
)
(procedure public (proc0_26 param1 param2 param3 param4)
(asm
pushi 0
call proc0_2, 0
pushi #setCursor
pushi 1
lofsa arrowCursor
push
lag gGame
send 6
lap paramTotal
bnt code_13df
pushi 2
pushi 128
lsp param1
callk Load, 4
jmp code_13e9
code_13df:pushi 2
pushi 128
pushi 248
callk Load, 4
code_13e9:pushi 5
pushi 1
lap paramTotal
bnt code_13f6
lap param1
jmp code_13f9
code_13f6:ldi 248
code_13f9:push
pushi 6
pushi 1
lap paramTotal
bnt code_1407
lap param2
jmp code_1409
code_1407:ldi 0
code_1409:push
pushi 217
pushi 1
lsp paramTotal
ldi 3
lt?
bnt code_141b
ldi 0
jmp code_141d
code_141b:lap param3
code_141d:push
pushi 216
pushi 1
lsp paramTotal
ldi 4
lt?
bnt code_142f
ldi 30
jmp code_1431
code_142f:lap param4
code_1431:push
lofsa deathIcon
send 24
pushi #number
pushi 1
pushi 19
pushi 6
pushi 1
pushi 1
pushi 97
pushi 1
pushi 127
pushi 63
pushi 1
pushi 500
pushi 164
pushi 0
lag gGlobalSound
send 28
pushi 2
pushi 2
lsg global330
callk DoAudio, 4
code_145c:pushi 18
lofsa "LOOKUP_ERROR"
push
pushi 70
pushi 220
pushi 82
lofsa deathIcon
push
lsp param2
pushi 0
pushi 30
pushi 1
pushi 81
lofsa "Restore"
push
pushi 1
pushi 81
lofsa "Restart"
push
pushi 2
pushi 81
lofsa " Quit "
push
pushi 3
calle proc255_0, 36
push
dup
ldi 1
eq?
bnt code_14a5
pushi 1
pushi 3
callk DoAudio, 2
pushi #restore
pushi 0
lag gGame
send 4
jmp code_14d1
code_14a5:dup
ldi 2
eq?
bnt code_14bd
pushi 1
pushi 3
callk DoAudio, 2
pushi #restart
pushi 1
pushi 0
lag gGame
send 6
jmp code_14d1
code_14bd:dup
ldi 3
eq?
bnt code_14d1
pushi 1
pushi 3
callk DoAudio, 2
ldi 1
sag global4
jmp code_14d5
code_14d1:toss
jmp code_145c
code_14d5:ret
)
)
(procedure public (proc0_27 param1)
(rm0Sound:
priority(15)
number(65)
loop(1)
play()
)
(if (paramTotal)
= global15 (+ global15 param1)
)
)
(procedure public (proc0_28 param1 param2 param3 param4)
(var temp0, temp1[500])
(if (<u param2 1000)
GetFarText(param2 param3 @temp1)
)(else
StrCpy(@temp1 param2)
)
(talkerIcon:
view(param1)
cycler(Fwd)
cycleSpeed(6)
count(+ (/ StrLen(@temp1) 20) 1)
talker(1)
)
(if (<u param2 1000)
proc255_0(@temp1 rest param4 82 talkerIcon 0 0)
)(else
proc255_0(@temp1 param3 rest param4 82 talkerIcon 0 0)
)
)
(procedure public (proc0_29 param1 param2)
(var temp0, temp1, temp2, temp3)
(asm
pushi 1
pushi 3
callk DoAudio, 2
lsp paramTotal
ldi 3
eq?
not
bnt code_1674
lag global401
not
bnt code_1674
ldi 1
sag global401
pushi #masterVolume
pushi 0
lag gGame
send 4
sat temp3
pushi #masterVolume
pushi 0
lag gGame
send 4
push
ldi 4
ge?
bnt code_1674
pushi 379
pushi #superClass
lst temp3
ldi 4
sub
push
lag gGame
send 6
code_1674:lsp paramTotal
ldi 2
eq?
bnt code_16a0
lsp paramTotal
ldi 3
eq?
not
bnt code_16a0
pushi #theVol
pushi 1
lst temp3
pushi 150
pushi 2
lsp param2
pushi 2
pushi 2
lsp param1
callk DoAudio, 4
push
class SpeakTimer
send 14
jmp code_176d
code_16a0:lsp paramTotal
ldi 3
eq?
bnt code_16b2
pushi 2
pushi 2
lsp param1
callk DoAudio, 4
jmp code_176d
code_16b2:pushi #setCursor
pushi 1
lofsa speakCursor
push
lag gGame
send 6
sat temp0
pushi 2
pushi 2
lsp param1
callk DoAudio, 4
push
ldi 2
add
push
pushi 0
callk GetTime, 0
add
sat temp2
code_16d3:pushi #type
pushi 0
pushi #new
pushi 0
class Event
send 4
sat temp1
send 4
not
bt code_1702
pushi #type
pushi 0
lat temp1
send 4
push
ldi 2
eq?
bt code_1702
pushi #type
pushi 0
lat temp1
send 4
push
ldi 512
eq?
bnt code_1731
code_1702:pushi 0
callk GetTime, 0
push
lat temp2
lt?
bnt code_1731
pushi 1
pushi 6
callk DoAudio, 2
push
ldi 65535
ne?
bnt code_1731
pushi 1
lst temp1
callk IsObject, 2
bnt code_16d3
pushi #dispose
pushi 0
lat temp1
send 4
ldi 0
sat temp1
jmp code_16d3
code_1731:pushi 1
lst temp1
callk IsObject, 2
bnt code_1745
pushi #dispose
pushi 0
lat temp1
send 4
ldi 0
sat temp1
code_1745:pushi 1
pushi 3
callk DoAudio, 2
lsg global401
ldi 1
eq?
bnt code_1763
pushi #masterVolume
pushi 1
lst temp3
lag gGame
send 6
ldi 0
sag global401
code_1763:pushi #setCursor
pushi 1
lst temp0
lag gGame
send 6
code_176d:ret
)
)
(procedure public (proc0_30 param1 param2 param3 param4 param5)
DoAudio(2 param1)
proc255_0("" 82 param2 param3 param4 rest param5)
)
(procedure (localproc_1315 param1 param2)
(var temp0, temp1, temp2, temp3)
(asm
ldi 0
sat temp0
code_131b:lst temp0
lsp paramTotal
ldi 1
sub
lt?
bnt code_1390
lat temp0
lapi param2
sat temp1
push
ldi 16
div
sat temp2
pushi 1
lst temp1
ldi 16
mod
shl
sat temp3
lsp param1
dup
ldi 1
eq?
bnt code_134a
jmp code_1390
jmp code_138a
code_134a:dup
ldi 2
eq?
bnt code_1361
lat temp2
lsgi global129
lat temp3
bnot
and
push
lat temp2
sagi global129
jmp code_138a
code_1361:dup
ldi 0
eq?
bnt code_1377
lat temp2
lsgi global129
lat temp3
or
push
lat temp2
sagi global129
jmp code_138a
code_1377:dup
ldi 3
eq?
bnt code_138a
lat temp2
lsgi global129
lat temp3
xor
push
lat temp2
sagi global129
code_138a:toss
+at temp0
jmp code_131b
code_1390:lat temp2
lsgi global129
lat temp3
and
ret
)
)
(procedure (localproc_14d6) of SpeakTimer
(var theClient)
= theClient client
= client 0
(if (IsObject(theClient))
(if ((send theClient:respondsTo(#timer)))
(send theClient:timer(0))
)
(if ((send theClient:respondsTo(#cue)))
(send theClient:cue())
)
)
)
(class KQ5SyncWalk of SyncWalk
(properties
client 0
caller 0
cycleDir 1
cycleCnt 0
completed 0
xLast 0
yLast 0
)
(method (doit)
(if (<= (send client:loop) 3)
(super:doit())
)
)
)
(class ego of Body
(properties
x 0
y 0
z 0
heading 0
noun 0
nsTop 0
nsLeft 0
nsBottom 0
nsRight 0
description 0
sightAngle 26505
actions 0
onMeCheck $6789
approachX 0
approachY 0
approachDist 0
_approachVerbs 26505
lookStr 0
yStep 2
view 0
loop 0
cel 0
priority 0
underBits 0
signal $2000
lsTop 0
lsLeft 0
lsBottom 0
lsRight 0
brTop 0
brLeft 0
brBottom 0
brRight 0
palette 0
cycleSpeed 0
script 0
cycler 0
timer 0
detailLevel 0
illegalBits $8000
xLast 0
yLast 0
xStep 3
moveSpeed 0
blocks 0
baseSetter 0
mover 0
looper 0
viewer 0
avoider 0
code 0
edgeHit 0
head 0
caller 0
lookingDir 1
normal 1
)
(method (init param1)
(if (not cycler)
(self:setCycle(KQ5SyncWalk))
)
(super:init(rest param1))
)
(method (handleEvent pEvent)
(if (((& (send pEvent:type) evJOYSTICK) or (== (send pEvent:type) evMOUSEBUTTON)) or ((== (send pEvent:type) 16384) and (== (send pEvent:message) JOY_UP)))
= gPEventX (send pEvent:x)
= gPEventY (send pEvent:y)
(super:handleEvent(pEvent))
)
(if (((send pEvent:claimed) or (<> (send pEvent:type) 16384)) or not proc255_5(self pEvent))
return
)(else
(switch ((send pEvent:message))
(case JOY_UPRIGHT
(if (proc0_12(74))
proc0_29(82)
)(else
proc0_29(83)
)
(send pEvent:claimed(1))
)
(case JOY_DOWNRIGHT
(if (== (send gInv:indexOf((send gIconBar:curInvIcon))) 10)
(if ((<> gNumber 90) and (<> gNumber 85))
(rm0Sound:
number(52)
loop(1)
play()
)
proc0_29(136)
(send pEvent:claimed(1))
)
)(else
(if (== (send gInv:indexOf((send gIconBar:curInvIcon))) 26)
(if (proc0_12(15))
proc0_29(137)
(send pEvent:claimed(1))
)(else
(if (not proc999_5(gNumber 29 30))
proc0_29(138)
(send pEvent:claimed(1))
)
)
)(else
(if (== (send gInv:indexOf((send gIconBar:curInvIcon))) 34)
(if ((proc0_12(15) or not proc999_5(gNumber 29 30 85 2 90)) or ((== gNumber 2) and proc0_12(47)))
(rm0Sound:
number(50)
loop(1)
play()
)
proc0_29(139)
(send pEvent:claimed(1))
)
)(else
(if (== (send gInv:indexOf((send gIconBar:curInvIcon))) 17)
(if (<> gNumber 24)
proc0_29(140)
(send pEvent:claimed(1))
)
)(else
(if (== (send gInv:indexOf((send gIconBar:curInvIcon))) 6)
(send global2:newRoom(208))
(send pEvent:claimed(1))
)(else
(if (proc999_5((send gInv:indexOf((send gIconBar:curInvIcon))) 2 19 27 17 32 15 33 18 12 22 25 36 8 5 37))
(switch ((send gInv:indexOf((send gIconBar:curInvIcon))))
(case 2
proc0_9(16)
proc0_29(141)
(send gEgo:put(2 1))
(send pEvent:claimed(1))
)
(case 19
(if (== ++global316 1)
proc0_27(4)
proc0_9(16)
proc0_29(142)
(send ((send gInv:at(19))):cel(5))
(send ((send gInv:at(19))):
cursor(halfLambCursor)
yourself()
)
(send gEgo:put(19 gNumber))
(send gEgo:get(19))
)(else
proc0_29(143)
(send gEgo:put(19 1))
)
(send pEvent:claimed(1))
)
(case 27
(if (proc0_12(84))
proc0_29(144)
)(else
proc0_29(145)
(rm0Sound:
priority(15)
number(65)
loop(1)
play()
)
proc0_9(84)
)
(send pEvent:claimed(1))
)
(default
(if (proc0_12(15) or not proc999_5(gNumber 29 30))
proc0_29(
(switch ((send gInv:indexOf((send gIconBar:curInvIcon))))
(case 32
146
)
(case 15
147
)
(case 33
148
)
(case 12
149
)
(case 22
150
)
(case 25
151
)
(case 36
152
)
(case 8
153
)
(case 18
154
)
(default
155
)
)
)
(send pEvent:claimed(1))
)
)
)
)
)
)
)
)
)
)
(case JOY_DOWN
(if (proc0_12(74))
proc0_29(157)
)(else
proc0_29(158)
)
(send pEvent:claimed(1))
)
(case JOY_RIGHT
(if (proc0_12(74))
proc0_29(130)
(send pEvent:claimed(1))
)(else
(send pEvent:claimed(0))
)
)
)
)
)
(method (setMotion theMover)
(self:
cycleSpeed((send gGame:egoMoveSpeed))
moveSpeed((send gGame:egoMoveSpeed))
)
(super:setMotion(rest theMover))
)
)
(instance gControls of Controls
(properties)
)
(instance globalSound of Sound
(properties
flags $0001
priority 1
)
)
(instance globalSound2 of Sound
(properties
flags $0001
priority 2
)
)
(instance globalSound3 of Sound
(properties
flags $0001
priority 3
)
)
(instance globalSound4 of Sound
(properties
flags $0001
priority 4
)
)
(instance rm0Sound of Sound
(properties
flags $0001
priority 15
)
)
(instance public KQ5 of Game
(properties)
(method (init)
(var temp0[270], temp270, temp271[19], temp290)
= global394 1
DoAudio(9 1)
DoAudio(7 11025)
(if ((>= (= global105 Graph(grGET_COLOURS)) 2) and (<= global105 16))
= global159 0
)(else
= global159 1
)
= gKQ5Window KQ5Window
= gKq5DoVerbCode kq5DoVerbCode
= gFtrInit FtrInit
= global330 159
(send gGame:
egoMoveSpeed(2)
setSpeed(1)
masterVolume(12)
)
= gKQPMouse kQPMouse
proc958_0(130 932 756)
Polygon
PolyPath
RFeature
Timer
= gEmptyBagCursor emptyBagCursor
(super:init())
= global27 "1.000.052"
= global100 0
(if (= temp270 DeviceInfo(5))
(if (== (= temp290 StrAt((= temp270 DeviceInfo(5)) (- StrLen((= temp270 DeviceInfo(5))) 1))) 58)
GetCWD(global29)
)(else
StrCpy(global29 temp270)
)
)
= global17 10
(User:
canControl(0)
x(-1)
y(150)
init((User:inputLineAddr) 30)
alterEgo((send (= gEgo ego):
looper(MyLooper)
yourself()
)
)
)
= global16 260
= global22 4
(globalSound:
owner(self)
init()
)
(globalSound2:
owner(self)
init()
)
(globalSound3:
owner(self)
init()
)
(globalSound4:
owner(self)
init()
)
= gGlobalSound globalSound
= gGlobalSound2 globalSound2
= gGlobalSound3 globalSound3
= gGlobalSound4 globalSound4
= gGlobalAudio globalAudio
= gTheInvCursor theInvCursor
= gSpeakCursor speakCursor
= gArrowCursor arrowCursor
= gTheCrownCursor theCrownCursor
= gTheGameCursor theGameCursor
DoSound(sndPLAY 1)
proc0_6()
(send (= gIconBar IconBar):
add((icon0:
cursor(walkCursor)
yourself()
)
(icon1:
cursor(eyeCursor)
yourself()
)
(icon2:
cursor(handCursor)
yourself()
)
(icon3:
cursor(talkCursor)
yourself()
)
(icon4:
cursor(arrowCursor)
yourself()
)
(icon5:
cursor(arrowCursor)
yourself()
)
(icon8:
cursor(arrowCursor)
yourself()
)
(icon9:
cursor(helpCursor)
yourself()
)
)
eachElementDo(#init)
eachElementDo(#highlightColor 1)
eachElementDo(#lowlightColor
(if (global159)
19
)(else
7
)
)
curIcon(icon0)
useIconItem(icon4)
helpIconItem(icon9)
disable()
disable(icon4)
)
(send (ScriptID(758)):init())
= global103 0
= gGTheGameCursor (= gTheGameCursor 6)
(self:setCursor(theGameCursor))
= global67 1
(if (GameIsRestarting())
= gPolyList15 1
)
(self:newRoom(99))
)
(method (doit)
(var gEgoLoop, temp1, temp2[2])
(send gGlobalAudio:check())
(if (((((<> (= gEgoLoop (send gEgo:loop)) (= temp1 (- NumLoops(gEgo) 1))) and not proc0_12(22)) and not (send gEgo:avoider)) and (send gEgo:normal)) and (not (send gEgo:mover) or (send gEgo:isBlocked())))
(send gEgo:
loop(temp1)
cel(gEgoLoop)
setMotion(0)
signal(& (send gEgo:signal) $fbff)
)
)
(super:doit())
)
(method (newRoom newRoomNumber)
(send gGlobalAudio:stop())
(if (SpeakTimer)
(SpeakTimer:dispose())
)
proc0_6()
(super:newRoom(newRoomNumber))
)
(method (startRoom param1)
(var temp0)
(send gGlobalSound3:stop())
(send gGlobalSound4:stop())
proc958_0(0 972 970 760 762 929 930 941 759 982 949 202 888 889 764 928 767 771)
(if (== gGNumber 99)
(if (== global87 0)
(send (ScriptID(755)):init())
)(else
(send (ScriptID(755 1)):init())
)
)
proc958_0(136 6 7 8 9)
Load(rsFONT 4)
(if (global14)
= global14 0
SetDebug()
)
(if (((>u MemoryInfo(1) (+ 20 MemoryInfo(0))) and (| $0001 Palette(4 0 255 100))) and proc255_0(0 1 81 "Who cares" 0 81 "Debug" 1))
SetDebug()
)
(super:startRoom(param1))
(if (not proc0_12(33))
(signalView:
init()
posn(1000 1000)
setPri(15)
hide()
)
)
= global124 160
= global125 105
(send gFeatures:eachElementDo(#init))
)
(method (restore param1)
DoAudio(3)
(super:restore(rest param1))
)
(method (save)
DoAudio(3)
(super:save())
)
(method (handleEvent pEvent)
(var temp0, newEvent, pEventX, pEventY, pEventModifiers, temp5[278])
(if ((send pEvent:claimed))
return
)
(switch ((send pEvent:message))
(case JOY_DOWNRIGHT
(if (== (send gInv:indexOf((send gIconBar:curInvIcon))) 28)
(if (proc0_12(60))
proc0_29(134)
)(else
proc0_29(135)
)
(send pEvent:claimed(1))
)(else
(if (== (send gInv:indexOf((send gIconBar:curInvIcon))) 35)
proc0_29(156)
(send pEvent:claimed(1))
)
)
)
)
(switch ((send pEvent:type))
(case (super:handleEvent(pEvent))
)
(case evMOUSEBUTTON
(if (not (send pEvent:claimed) and global100)
(send pEvent:localize())
= pEventX (send pEvent:x)
= pEventY (send pEvent:y)
(if (& (= pEventModifiers (send pEvent:modifiers)) $0008)
(send pEvent:claimed(1))
(while (<> 2 (send ((= newEvent (Event:new()))):type))
(send newEvent:localize())
(send ((User:alterEgo)):
posn((send newEvent:x) (send newEvent:y))
setMotion(0)
)
Animate((send gCast:elements) 0)
(send newEvent:dispose())
)
(send newEvent:dispose())
)
)
)
(case evKEYBOARD
(if ((not (send pEvent:claimed) and not global327) and (User:controls))
(send pEvent:claimed(1))
(switch ((send pEvent:message))
(case KEY_TAB
(send gInv:showSelf(gEgo))
)
(case KEY_SHIFTTAB
(if (HaveMouse())
(send gInv:showSelf(gEgo))
)
)
(case KEY_F1
(send (ScriptID(753)):doit())
)
(default
(if (global100)
(send (ScriptID(889 0)):doit(pEvent))
)
)
)
)
)
)
)
(method (setCursor cursorNumber param2)
(var theGCursorNumber)
= theGCursorNumber gCursorNumber
= gCursorNumber cursorNumber
return
(if (global400)
(if (IsObject(cursorNumber))
(send cursorNumber:init(rest param2))
return theGCursorNumber
)
)(else
return
(if (IsObject(cursorNumber))
(send cursorNumber:init())
theGCursorNumber
)(else
(super:setCursor(rest param2))
)
)
)
(method (quitGame)
DoAudio(2 9254)
(super:quitGame(proc255_0(0 0 81 "Yes" 1 81 "No" 0)))
DoAudio(3)
)
(method (pragmaFail)
(if ((User:canInput()))
proc0_21()
)
)
)
(class SpeakTimer of Timer
(properties
cycleCnt -1
seconds -1
ticksToDo -1
lastTime -1
client 0
theVol 0
)
(method (doit)
(var theLastTime)
(if (<> cycleCnt -1)
(if (not --cycleCnt)
localproc_14d6()
)
)(else
(if (<> seconds -1)
(if (<> lastTime (= theLastTime GetTime(1)))
= lastTime theLastTime
(if (not --seconds)
localproc_14d6()
)
)
)(else
(if ((<u (+ ticksToDo lastTime) GetTime()) or ((>u lastTime GetTime()) and (>u (+ ticksToDo lastTime) lastTime)))
= global401 0
(send gGame:masterVolume(theVol))
localproc_14d6()
)
)
)
)
)
(class SpeakTimeOut of TO
(properties
timeLeft 0
theVol 0
)
(method (doit)
(if (== DoAudio(6) -1)
= global401 0
(send gGame:masterVolume(theVol))
(send gTheDoits:delete(self))
)
)
(method (set)
(send gTheDoits:add(self))
)
)
(instance signalView of View
(properties
view 942
)
)
(instance icon0 of TheMenuBar
(properties)
)
(instance icon1 of TheMenuBar
(properties)
)
(instance icon2 of TheMenuBar
(properties)
)
(instance icon3 of TheMenuBar
(properties)
)
(instance icon4 of TheMenuBar
(properties)
)
(instance icon5 of TheMenuBar
(properties)
(method (select)
(if ((super:select()))
(send gInv:showSelf(gEgo))
)
)
)
(instance icon8 of TheMenuBar
(properties)
(method (select)
(if ((super:select()))
(send gIconBar:hide())
(if (== global87 0)
(send (ScriptID(755)):show())
)(else
(send (ScriptID(755 1)):show())
)
)
)
)
(instance icon9 of TheMenuBar
(properties)
)
(instance deathIcon of DCIcon
(properties)
)
(instance talkerIcon of DCIcon
(properties
state $0010
)
)
(instance kq5DoVerbCode of Code
(properties)
(method (doit)
(send gGame:pragmaFail())
)
)
(instance globalAudio of Audio
(properties)
)
(instance FtrInit of Code
(properties)
(method (doit param1)
(if (== (send param1:sightAngle) 26505)
(send param1:sightAngle(90))
)
(if (== (send param1:actions) 26505)
(send param1:actions(0))
)
)
)
(instance kQPMouse of PseudoMouse
(properties)
(method (handleEvent pEvent)
(var temp0)
= temp0 (send ((send gIconBar:curIcon)):message)
(send ((send gIconBar:curIcon)):message(0))
(super:handleEvent(pEvent))
(send ((send gIconBar:curIcon)):message(temp0))
)
)
(instance arrowCursor of KQCursor
(properties
view 942
loop 1
cel 7
)
(method (init param1)
(if (global400)
(self:
number(999)
yourself()
)
)
(super:init(rest param1))
)
)
(instance theGameCursor of KQCursor
(properties
view 942
loop 1
cel 5
x 8
y 9
)
(method (init param1)
(if (global400)
(self:
number(456)
yourself()
)
)
(super:init(rest param1))
)
)
(instance theInvCursor of KQCursor
(properties
view 942
loop 1
cel 6
)
(method (init param1)
(if (global400)
(self:
number(69)
yourself()
)
)
(super:init(rest param1))
)
)
(instance walkCursor of KQCursor
(properties
view 942
loop 1
y 20
)
(method (init param1)
(if (global400)
(self:
number(6)
yourself()
)
)
(super:init(rest param1))
)
)
(instance eyeCursor of KQCursor
(properties
view 942
loop 1
cel 1
x 15
y 12
)
(method (init param1)
(if (global400)
(self:
number(7)
yourself()
)
)
(super:init(rest param1))
)
)
(instance handCursor of KQCursor
(properties
view 942
loop 1
cel 2
x 14
y 10
)
(method (init param1)
(if (global400)
(self:
number(8)
yourself()
)
)
(super:init(rest param1))
)
)
(instance talkCursor of KQCursor
(properties
view 942
loop 1
cel 3
x 10
y 13
)
(method (init param1)
(if (global400)
(self:
number(9)
yourself()
)
)
(super:init(rest param1))
)
)
(instance helpCursor of KQCursor
(properties
view 942
loop 1
cel 4
x 10
y 15
)
(method (init param1)
(if (global400)
(self:
number(70)
yourself()
)
)
(super:init(rest param1))
)
)
(instance speakCursor of KQCursor
(properties
view 942
loop 1
cel 5
x 8
y 9
)
(method (init param1)
(if (global400)
(self:
number(456)
yourself()
)
)
(super:init(rest param1))
)
)
(instance theCrownCursor of KQCursor
(properties
view 942
loop 1
cel 8
x 5
y 5
)
(method (init param1)
(if (global400)
(self:
number(997)
yourself()
)
)
(super:init(rest param1))
)
)
(instance halfLambCursor of KQCursor
(properties
view 941
loop 1
cel 7
)
(method (init param1)
(if (global400)
(self:
number(52)
yourself()
)
)
(super:init(rest param1))
)
)
(instance emptyBagCursor of KQCursor
(properties
view 941
loop 5
cel 3
x 9
y 10
)
(method (init param1)
(if (global400)
(self:
number(54)
yourself()
)
)
(super:init(rest param1))
)
)
I'm attaching the complete decompiled source for the game.
-
New release available, addressing most of these issues.
And there is a new download link (http://scicompanion.com/Downloads/SCICompanion.zip)
-
Okay so here's what I can see when I re-decompile an SCI0 game, like Larry 3.
1. All Said statements are mangled -- (Said _get_drink_water_) instead of (Said 'get,drink/water'). Some end up as (Said ______) (amount of _ may vary) and are flagged as "expected an expression". It seems that "better token cleaning for object names" thing from 19 days ago is a bit too eager.
2. Synonym blocks are considered "expected word" errors.
-
Is this 3.0.1.4?
-
Ugh
-
If there are any other problems you notice, let me know soon, because I won't have much time to work on this in the coming months.
-
I see that the run.cmd file is no longer present.
I found this in the game > Properties: C:\Users\Shane.laptop-Gold\Desktop\sciCompanion\Tools\DOSBox\DOSBox.exe
So I am assuming that this means since it is packaged with companion that it means we no longer have to have it preinstalled while developing but upon release, we will either need to include instructions for install or package it with the game as well.
-
upon release, we will either need to include instructions for install or package it with the game as well.
Correct. It has always been that way though.
Luckily people like Collector and Kawa have stepped in to provide installers :-).
-
My NSIS Publisher can be directly called from Companion. Drop it in Companion's Plugins folder and your game can be published just by clicking Plugins -> NSISPublisher. It will generate an installer for for whatever game is loaded in Companion. It does require that you have NSIS installed on your system. It includes a script editor if you want to manually edit the script and the NSIS compiler can be invoked from the script editor. I still need to do some documentation for it, but the program itself is mostly done.
-
I made an installer too, it just isn't very fancy... not very fancy at all lol
It looks in a few different locations for dosbox.exe and if it finds it, gives you a button that then creates the run.cmd file
It turns out I never put dosbox in the same place twice between any two computers, so depending on which machine I am working on and the last machine I was working on, I would need to adjust the run.cmd. So my little sniffer outer did that for me.
-
If there are any other problems you notice, let me know soon, because I won't have much time to work on this in the coming months.
Okay. King's Quest 6, script 710. dungeon# is renamed to dungeon_ in the property list (and the various dungeon door instances' property lists) but left as-is in ((ScriptID 80 0) dungeonEntered: dungeon#) further down in DungeonDoor::doVerb.
That's all that comes to mind.
Edit: *checks commits* yey~
-
Here's an interesting thing. I tried to compile my own copy of SCI Companion to get those Said fixes ahead of time and found this:
1) When decompiling certain SCI0 games such as SQ3, the Joystick kernel call has been for a while now appeared in the output as ?. Yeah, eth.
2) Phil's builds don't care.
3) Mine, with no source changes on my part besides being a debug build, asserts on it, in EatCommentSemi::EatWhitespaceAndComments's while (isspace(*stream)) loop, when it's building browse info.
4) I know it's that kernel call because editing the .sc file in question in another editor to have Joystick instead of ?, this stops.
*builds a release version for the hell of it*
Confirmed, it's a debug build thing.
-
King's Quest 6, script 710. dungeon# is renamed to dungeon_ in the property list (and the various dungeon door instances' property lists) but left as-is in ((ScriptID 80 0) dungeonEntered: dungeon#) further down in
Yup, legit missing piece of functionality.
When decompiling certain SCI0 games such as SQ3, the Joystick kernel call has been for a while now appeared in the output as ?. Yeah, eth.
Found the problem. That addresses the assert to. I should fix the assert, but don't have time to. Kernel 112 is usually Graph, not Joystick. Joystick is 113. At least that's the case in the SCI0 template game, SQ3 might be different. At any rate, the SQ3 kernel name resource is missing stuff. My fix will change the weird character to kernel_112 during decompilation. That should be enough to help someone figure out what to do in order to build (supply a correct kernel name resource from another game, I guess - or just remove the kernel name resource and hope the fixed list Companion uses is correct).
Synonym blocks are considered "expected word" errors.
The synonym stuff has been busted since October, apparently. It's almost like I never tested it! Luckily pretty much no one uses that :-). Should be fixed in next release.
-
hope the fixed list Companion uses is correct
Negatory. Joystick becomes MemorySegment, and GameIsRestarting becomes NewNode, possibly because the SCI0 file calls are commented out of the list.
/*0x28*/ "SetCursor",
// FOpen (SCI0)
// FPuts (SCI0)
// FGets (SCI0)
// FClose (SCI0)
/*0x29*/ "SaveGame",in Vocab99x.cpp, vs
40 SetCursor
41 FOpen
42 FPuts
43 FGets
44 FClose
45 SaveGamein vocab.999 according to SV. So the internal list is basically valid only for SCI1/11, not SCI0.
-
I just realized I never fixed the issues with the SaveResdtoreDialog in the template game... sigh...
-
There's always another day. If you don't get time for it now, there's no rush. You're making amazing progress into areas I never thought SCIComp would go!
-
New version released :-)
-
And again, small fix.
-
Just downloaded the most recent version, looking very good. Still poking around just in the SCI0 space so far.
I do have a feature request, Troflip. Any thought into implementing asm? I'd love to be able to use this new compiler for my Zork port, but had to fall back to using Studio because of this (and possibly some other issues, I can't remember specifically).
-
Any thought into implementing asm?
You mean like this?
(asm
code_088d: pushi #type
pushi 0
pushi #new
pushi 0
pushi #curEvent
pushi 0
lag gUser
send 4
send 4
sat temp1
send 4That's from invi.sc, SCI11 template.
-
Yeah, like that. I specifically need it to handle labels and jumps, but I couldn't get it working. From the SCI Studio docs:
// the inline assembly is quite versatile. Here's a crafty example:
(if(something)
(asm jmp _a_goto_label)
)
(asm _a_goto_label: )
Any pointers here?
-
I don't know much about the asm block myself, sorry. The only ones I've seen were entire method and procedure blocks that failed to decompile.
-
Phil can say, but I suspect that he does not want to tamper with the Sierra syntax. Not sure how much you have caught up on developments, but we now have have some samples of the original syntax and the new version can convert scripts form SCI Studio to the original Sierra SCI. You can read the original Sierra internal SCI documentation on the Wiki here: http://sciwiki.sierrahelp.com//index.php?title=Official_SCI_Documentation
Also Phil's SCI Companion documentation: http://scicompanion.com/Documentation/index.html
I have yet to delve into the Sierra scripting, so I cannot say if this can be done natively in SCI or not. Take a look at Phil's "SCI Quest" that shows off some of what we can do now. http://scicompanion.com/download/
-
The original Sierra syntax didn't have an asm statement at all. I suspect Brian added it because it made it easy to manually decompile piecemeal (just like Companion needs it to decompile everything, since the decompiler isn't perfect).
The Companion asm syntax is a little different than Brian's. Specifically, you can't jmp to labels in other asm blocks, only within a single block (there are other differences too).
How much asm do you have in Zork? And why???
If it's not too much, you could just decompile it to generate Companion-compatible asm (or with any luck it will turn it into readable source code) (and without luck it will crash or do something weird since I suspect you're using asm to do some "creative control flow" with gotos).
-
Yeah, I'm really behind in what you guys have going with SCI now for sure.
I've got quite a bit of asm in Zork as the decompiler that I use to decompile Zork's z-machine code generates gotos. To give a bit of background, I'm programatically generating room scripts from the output of the z-machine decompilation. So potentially one could take any z-machine game and create a SCI game without writing any code at all. I could manually rewrite/rework the generated scripts and change the gotos to use proper looping constructs (I think, not sure) but I was really hoping not to do that.
Hoping to get back to Zork eventually and I'd really like to see what it would take to get it compiling under Companion as Studio is unmaintained and crash-prone. Not to mention I'm maxed out on heap space and I know that Companion typically consumes less heap than Studio.
I mentioned that there are other things holding me up from using Companion, I just don't remember what they are. If it would be helpful, I can run it through Companion and see what else it balks at besides the gotos and report the findings here.
-
If it would be helpful, I can run it through Companion and see what else it balks at besides the gotos and report the findings here.
Sure, it would be good to track feature requests. Keep in mind that except for bug fixes and easy/low-risk changes, I probably won't have much time to work on Companion in the future though.
I could manually rewrite/rework the generated scripts and change the gotos to use proper looping constructs (I think, not sure) but I was really hoping not to do that.
It's not easy to do robustly (speaking from experience working on the decompiler). That's probably why Zork's decompiler uses gotos. Although handling gotos in source code is likely easier than jmps in asm, since gotos always go to a specific statement (whereas jmps can jump into the middle of a group of instructions that might normally comprise a single statement, and so you have to figure out how to decompose that properly).
Not to mention I'm maxed out on heap space and I know that Companion typically consumes less heap than Studio.
Companion generates scripts that use about 10% less heap IIRC. Have you verified that it's due to the size of your scripts, and not because you're forgetting to unload certain scripts on room changes?
Also, SCI1.1 significantly increases the amount of heap available, since the script logic is no longer in the heap (just the local variables, strings, and class/instance properties and method lists). Oh, but of course there is no parser in SCI1.1.
-
Companion generates scripts that use about 10% less heap IIRC. Have you verified that it's due to the size of your scripts, and not because you're forgetting to unload certain scripts on room changes?
Also, SCI1.1 significantly increases the amount of heap available, since the script logic is no longer in the heap (just the local variables, strings, and class/instance properties and method lists). Oh, but of course there is no parser in SCI1.1.
Oh yes, not much I can do with the heap. The main issue is the sheer number of global variables used to track the state of objects in the game.
With no parser in SCI1.1, maybe it's time to re-imagine the project. Might be good just to blow everything up and start over, might be refreshing to take a point-and-click approach.
-
Or, god forbid, write your own parser :)
-
There's always the XMas Card interpreter possibility...
-
Oh yes, not much I can do with the heap. The main issue is the sheer number of global variables used to track the state of objects in the game.
Any many of them boolean values? You can store 16 of them in one global variable location, saving a lot of space. Sierra did this.
-
Not to mention that booleans don't even have to reside in the main script at all anymore with the whole Bvariables thing.
-
Sure they do. Bset, Bclear, Btest all refer to storage in the main script.
-
There's always the XMas Card interpreter possibility...
Gumby might want to play around with this http://sciprogramming.com/community/index.php?topic=1548.msg8307#msg8307
-
Oh yes, not much I can do with the heap. The main issue is the sheer number of global variables used to track the state of objects in the game.
Any many of them boolean values? You can store 16 of them in one global variable location, saving a lot of space. Sierra did this.
I did consider this at one point, but it wouldn't help much as I recall. Another aspect of the problem is the way that the logic is structured. Any input is valid in any room at any point in the game, and there is a lot of nested procedure calls. I put each procedure in a single script and unload them whenever possible, but when I'm a dozen procedures deep (therefore not able to unload the parent procedures until I return from the current one) and each one is a healthy size, that coupled with the size of the Main script just kills the heap.
It's not impossible for me to move forward, just incredibly painful. One of my tricks is to store stuff in text resources, for example large arrays of data. Sure once the values change I need to keep track of the new value in the Main script, but at least all unmodified data can benefit from not being in memory. I did some really crazy stuff to keep the heap size down.
There's always the XMas Card interpreter possibility...
Gumby might want to play around with this http://sciprogramming.com/community/index.php?topic=1548.msg8307#msg8307
I may look into this, sounds interesting. Thanks for link Collector.
-
There's always the XMas Card interpreter possibility...
Or QfG2? I imagine Gumby already has a bunch of 16 color graphics (some of which we've seen)...
-
Gumby might want to play around with this http://sciprogramming.com/community/index.php?topic=1548.msg8307#msg8307
The correct working version is posted in this thread:
http://sciprogramming.com/community/index.php?topic=1553.0
-
Holy cow I just started poking around with the newest version of Companion, my first taste of creating games with SCI 1.1. I'm blown away, this is amazing work Troflip! Utterly speechless :o
-
I just found a typo in the help files. In Compiler/differences.html, heading "and/or operators are now prefix".
In SCI Studio syntax, and and or behaved differently than all other oeprators in that they were infix instead of prefix.
-
Glad you like it gumby!
Kawa, thanks for letting me know about the typo. I'll have to do an update of the docs on the scicompanion.com site at some point, because I've found a number of small doc bugs (mostly around there still being bits of old syntax in the docs).
-
In other news, I was looking in the docs for a refresher on for loops so I could make this:
(http://i.imgur.com/bquMfIl.png)
Because Graph doesn't respect remapped colors but DrawCel does.
And then I packed it up and put it in storage because the regular windows have two or three different colors and that'd complicate things too much.
-
I tried fooling around with KQ6CD for fun (the one included with the KQ collection) by changing audio resources to different sound effects (tried all 16/8 bit and 11025/22050 Hz combinations). Once the new sound overrides an old one every sound after that gets corrupted and when these corrupted sounds try to play in game it's just a bunch of garbled noise. The new sounds I put it in work fine, though. Apologies if this has been brought up before.
Also, Companion doesn't notice an issue because it's getting files from "audiocache". When I delete that folder it finally looks in resource.sfx where it's supposed to and lists all the audio sounds after the new one as corrupt.
EDIT: Slight correction, it doesn't corrupt anything until I rebuild resources. In Companion, if I don't rebuild, it shows my new sound under "audio cache" in red and the old one is greyed out, says "unused", and is in "resource.sfx". However, when I play the game, it's still using the old sound, not my new one. So it's not unused at all. Only when I rebuild resources does the new sound work....and then a bunch of other sounds after its entry get corrupted.
-
I'm running into some decompilation issues. Changes I made to a KQ6 room script weren't working and kept popping up errors of not being able to recognize certain globals or something. So I deleted the source (since it was of an older decompilation anyway) and re-decompiled with 3.0.1.7. I guess it automatically decompiles to Sierra Script now, which is cool. It'd be nice to have an option, but whatever not a big deal, and I know you can cross-convert between languages.
Anyway, I attempted to make changes again to the same room script (750) but it still pops up errors for not recognizing global variables. The names are correct, and they exist, but it doesn't recognize them. So I figured I have to compile the Main script first. I do that and discover that there are many procedures, variables, and instances (probably others) that have no names and are completely blank. I have no idea what to call them so Main is un-compileable. Any idea why that would be? If I try to guess names it gets passed most of them, but then complains that certain procedures are already declared (not the ones I guessed). Should I work with an older decompilation perhaps?
-
I guess it automatically decompiles to Sierra Script now, which is cool. It'd be nice to have an option, but whatever not a big deal, and I know you can cross-convert between languages.
Game->PRoperties->Script Language. Set this before decompiling. It defaults to Sierra syntax for Sierra games (which don't have any game.ini settings file by default)
Anyway, I attempted to make changes again to the same room script (750) but it still pops up errors for not recognizing global variables. The names are correct, and they exist, but it doesn't recognize them. So I figured I have to compile the Main script first.
I just tried this with KQ6-CD and didn't have any issues. Both script 750 and Main compiled fine.
Can you post your Main.sc?
A few notes:
- you'll need to decompile everything several times (I did it three times, but twice might be enough), because the decompiler keeps picking up better variable names for globals based on their usage. For example, if no yet-decompiled script has used global75 in a descriptive way yet, and then we decompile a script that does, we give it a name. Then, Main (and anyone else who uses global75) needs to be re-decompiled. I know it's not ideal... I should have some button that does "Decompile until there are no more changes to global var and proc names".
- Decompiling generates .sco files. That should be all that's required to have other scripts reference global variables correctly... i.e. you shouldn't need to recompile Main in order to be able to compile script 750.
Also, the script browsing info stuff (goto definition, etc) isn't working again. Was that taken out again? I thought it was reimplemented. Sorry, I haven't used this in a while.
Is "Enable browse info" checked in Tools->Preferences?
(Note if you're making patches for games, you'll probably want to uncheck "Compile modified scripts before run", since that can cause scripts other than the ones you're explicitly compiling to be compiled... a problem if there are any errors in the decompiled code).
-
My mistake, the script info stuff does work, it just didn't work for variables that weren't declared (obviously); the ones it kept erroring out on during compile. I'm decompiling a couple more times and I'll report back.
EDIT: It worked. :) Can compile easily now. Sorry for the bother. What do you think of my audio issue, though? Should I try the "Repackage Audio" function or is that the same thing as what I've done?
-
I hope to look into the audio issue soon, I'm not sure what's going on there yet... I thought it had something to do with 65535.map being a patch file, but it doesn't seem to.
-
While I'm waiting on that, does every Audio sound need a corresponding MIDI sound? In the meantime I've attempted to create new Audio sounds starting at 4000 (so that nothing after it will be corrupted), but when they are triggered from script the game can't find 4000.snd. Of course, I never rebuilt resources or repackaged audio, so the new sounds still might not be showing up to the game I guess. I'll try rebuilding and see if putting new audio files at the end of the list solves the corruption issue.
-
Ok, I think it does actually have something to do with this.
Try the following (with an uncorrupted KQ6-CD, lol):
- File->Import Patch File, and choose the 65535.map in the KQ6 directory
- Give it resource number 65535 and click ok to import
- Close the game
- Delete 65535.map from the KQ6 directory (or rename it to something else so neither Companion or Sierra.exe will find it)
- Re-open the game...
Now if you add sounds, etc..., does everything work properly?
I no longer see corruption in Companion if I do this, but I haven't tried the game out to see if it can handle having 65535.map embedded in the main resource package instead of being a patch file.
-
While I'm waiting on that, does every Audio sound need a corresponding MIDI sound? In the meantime I've attempted to create new Audio sounds starting at 4000 (so that nothing after it will be corrupted), but when they are triggered from script the game can't find 4000.snd. Of course, I never rebuilt resources or repackaged audio, so the new sounds still might not be showing up to the game I guess. I'll try rebuilding and see if putting new audio files at the end of the list solves the corruption issue.
Nah, it's probably the same issue as before... Companion writes 65535.map to the resource package, and the game (and Companion, if you reload the game) read from the 65535.map patch file). Same as having sierra patch file turds left over and scripts not "updating" correctly or whatever. I should have some warning if you save a resource that has a matching patch file.
-
There we go. That was it. Works now. I didn't realize 65535.MAP was a patch file!
-
does every Audio sound need a corresponding MIDI sound?
Negatory.
-
Feature request/Bug report
When a game is loaded it loads all the packaged resources as well as the patch files. When editing a view patch file (or probably anything else) and exporting it (overwriting the original patch file) it does not update the resource explorer list and still shows the older patch file before it was updated. If you double-click to open the patch file in the list it shows the older version. You have to close the game and reopen it to get it to update. Is there a way that after exporting a patch file that you can update the resource list? Or would this run into potential problems if say you weren't exporting to the game directory (so there'd be no need to update the list)? Would anything hinge on this that would be broken in this scenario? I'm trying to think like a programmer here lol.
-
I don't think it's necessarily a risky change, no. I could just detect if it's in the same folder and update the item in the view.
What scenario do you have that requires this though? In general I'd recommend just importing whichever patch files you have into the game and then deleting them, and not bothering with them anymore. (Were I designing SCI Companion from scratch, I might make it *only* deal with patch files, and then have an option to package stuff up).
-
I thought that the 65535.map was a map file for the RESOURCE.AUD and or the RESOURCE.SFX.
-
Well, I'm thinking particularly of scenarios involving patching Sierra games. It's not a big deal. I just have to be careful to reopen the game every time I export. There are other ways around this though, I suppose. Like packaging everything important and then exporting later. Just in this case I wanted to keep the original unaltered resources handy.
-
Well, I'm thinking particularly of scenarios involving patching Sierra games. It's not a big deal. I just have to be careful to reopen the game every time I export. There are other ways around this though, I suppose. Like packaging everything important and then exporting later. Just in this case I wanted to keep the original unaltered resources handy.
Well, but I'm saying you may as well just import the patch files into the game and then be done with them. They exist for a reason (for Sierra to fix bugs), so they should be part of the game... and when editing a game, SCI Companion admittedly doesn't play nicely with them. I would probably be convenient to have "rebuild resources" offer the option of incorporating the patch files then deleting them (or moving them to a backup folder or whatever).
I thought that the 65535.map was a map file for the RESOURCE.AUD and or the RESOURCE.SFX.
It does. It's the map file for the regular audio resources. But it's a resource just like any other, which can be a patch file or included in the game's resource.000 package. Most games have 65535.map included in the resource package. KQ6-CD doesn't (maybe it was patched, because they modified/added some sfx).
-
My line of thinking is distribution. Seeing as it's illegal to distribute an entire copyrighted game (edited or not), customized patch files are a lot less incriminating. And smaller in file size.
Can 65535.map be exported out again?
-
Just starting creating room scripts. I believe I found a bug where if you rename the script within the 'Scripts' tab, the script isn't renamed at the file-system level.
-
Just starting creating room scripts. I believe I found a bug where if you rename the script within the 'Scripts' tab, the script isn't renamed at the file-system level.
Oh yeah, I knew about that one, but never got around to fixing it. It is annoying, I agree.
-
Hey troflip, I was digging through some of the files that house constants, specifically Verbs.sh, Talkers.sh and the .shm files. I notice that you put a disclaimer indicating that "This file should only be edited with the SCI Companion message editor".
Other than just completely jacking your game up by changing the constant names or corresponding values so that scripts won't compile, is there another reason why I cannot generate these external to Companion? Or is there something more going on behind the scenes when a message file is being created from the gui with regard to these files and their values?
-
Sierra's tools put "should only be edited with ME" in there. It really doesn't matter, from what I've seen -- the file is parsed and the message editor uses it to map numbers to names. If a pair is changed, nothing breaks in the editor. The compiler, however, won't know what an N_GRUE is.
-
As long as you adhere to the syntax exactly, it shouldn't be a problem. There are more constraints in the syntax because, while they are just regular header files, the message editor doesn't use the compiler parser to read them when it loads them (partially due to performance issues, and partially due to needing to parse the comments in addition to the code - for instance to disambiguate nouns and cases, which are in the same file). But if you generate them correctly, it shouldn't be a problem.
-
Thank, that's what I figured but it doesn't hurt to ask.
-
Can I request a way to export 65535.map as a patch file? I can't seem to find a way to locate it in the resources. I'm guessing it's the kind of thing that remains hidden and works behind the scenes. It would aid in my ideas for Sierra game patches.
-
I know SCI2 isn't really supported, but a great many of the views in Larry 6 are interestingly broken. A quick look at SQ6 and KQ7 shows they're both working fine. As one example, here's the handcuffs as seen in SV and in Companion, and the actual view as a case study.
-
I know SCI2 isn't really supported, but a great many of the views in Larry 6 are interestingly broken. A quick look at SQ6 and KQ7 shows they're both working fine. As one example, here's the handcuffs as seen in SV and in Companion, and the actual view as a case study.
I guess that's the hi-res version of LSL6? I don't think I ever tested that, as I don't have it. Thanks for the bug report!
-
Can I request a way to export 65535.map as a patch file? I can't seem to find a way to locate it in the resources. I'm guessing it's the kind of thing that remains hidden and works behind the scenes. It would aid in my ideas for Sierra game patches.
I guess I could list them in another tab view (with appropriate warnings if someone tries to delete one), then you could do all the normal things with them.
What happens if you try "extract all resources"? Does it output map files? I forget.
-
I guess that's the hi-res version of LSL6? I don't think I ever tested that, as I don't have it. Thanks for the bug report!
Tis indeed the hi-res version, and I totally understand you not having it -- it was quite difficult to get a copy!
-
I guess that's the hi-res version of LSL6? I don't think I ever tested that, as I don't have it. Thanks for the bug report!
Let me know if you need any files from it. Then again it is not that hard to find it. Besides the stand alone versions it was in the collections past the Hits and Misses.
-
I guess that's the hi-res version of LSL6? I don't think I ever tested that, as I don't have it. Thanks for the bug report!
Tis indeed the hi-res version, and I totally understand you not having it -- it was quite difficult to get a copy!
Was. It's now om GOG; I got it because I had to help someone around these parts with something. :-)
-
What happens if you try "extract all resources"? Does it output map files? I forget.
No, unfortunately it doesn't.
-
What happens if you try "extract all resources"? Does it output map files? I forget.
No, unfortunately it doesn't.
Well, if you're adding any audio, then the audiocache folder should be generated, and you'll find the map files in there.
-
Ah, of course. Thank you.
-
I noticed that the aspect ratio preference is stored in the registry. It might make more sense to store this on a per game basis. If you want to work on an existing Sierra game the aspect ratio should be on to have the graphics displayed as they were intended with aspect correction on, but for new games it should be for however the developer intended. Aspect off would, of course, allow the developer to make his graphics more wide screen friendly. If this setting was stored in the game.ini it would be on a per game basis. The registry setting could remain as the the default. I would think that this change should not be that hard nor be likely to break anything.
If it was in the game.ini I could also add reading this game info to both the NSIS Publisher and SEQTool plugins to have them automatically switch the aspect ratio setting to match the current project.
-
Throw my two cents in, I could add an aspect checkbox to SCILauncher. Which would probably involve manipulating the dosbox.conf that comes with it, but I already have a cross-platform solution for that.
-
Yeah, that makes sense.
-
Just noticed that it won't open my FPFP v 1.000. It throws a warning "Error enumerating items: Corrupt resource header - mismatched types, yet the game does work. I can provide files if needed.
-
Sure, send them my way. I have FPFP v1 and it opens fine for me, so there must be some difference...
-
Check your PM.
-
Hmm, interesting. It looks like it's just unable to load the views, because it encounters something unexpected while enumerating them (starting at view 630). Your resource map does indeed look corrupt (SV.exe can't even open it properly). Have you applied patches to this or anything?
I'm not surprised the game runs, but if it tries to read views 630, 631, etc... it will probably crash.
-
It was the raw files from my floppies and installed from within DOSBox. I'll have to put the disk through the KryoFlux to see if the tracks have been altered. Could I get a copy of your v1.000 map file?
-
check your PMs!
-
Which incidentally reminds me of this one time on an IRC channel related to a board I used to visit, where someone said exactly that without any capitalization. Bloody amusing. That'll be all, good night.
-
Which incidentally reminds me of this one time on an IRC channel related to a board I used to visit, where someone said exactly that without any capitalization. Bloody amusing. That'll be all, good night.
https://ia800501.us.archive.org/17/items/rimshot_739/rimshot.mp3
-
Collector? Damn near wrector!
-
I just came across this project last week, and holy cow I am super impressed! SCI Companion 3 looks amazing. I am in complete awe over the features and amount of work you've put into this. I read through most of this thread and when I got to the part about LipSync support, I just about lost it. That is above and beyond anything I'd ever expected anybody to do.
My mind reels at the possibility of creating mods to some of my favorite Sierra games (goblin's hideout in QFG1? Extra planet in SQ3?), or fan patches for bugs/spelling/consistency, like the SQ1VGA thread, or creating enhancements to existing games like the SQV Fan Talkie thread. Simply amazing!
That said, I gave the latest version a try (3.0.1.7?) and I came across a couple of problems:
In theory, I should be able to recompile any script I've decompiled, right?
Laura Bow 1 was giving me some problems when I tried to recompile script 414. And would actually outright crash. Unhandled exception style. Not sure exactly why. It wasn't in response to me *doing* anything, unless it was trying to do something in the background.
Also, the Find/Replace wasn't working as I'd expected. I enjoyed adding comments to the decompiled code, trying to figure out how it works -- it's like doing the crosswords, for me -- and renaming variables and procedures as I learn what they're for. Trouble is I couldn't find any global Replace command (like the global find CTRL+SHIFT+F), without which it's practically impossible to rename global variables/procedures.
And the CTRL+H replace doesn't replace within the whole document ... only from the cursor down. I have to click it again to replace from the top. Not to mention the message it gives -- "<string> not found" -- is a little less useful than something like "3 occurrences replaced" or similar.
Anyway, these are mostly minor annoyances on what is otherwise and amazing program. If I'm using it wrong, can somebody please let me know the proper way?
-
Charles as in 'Unknown Hero"?
Anyway, I am sure that Phil will answer when he sees this.
-
Re: recompiling Sierra game sources, you must decompile at least 3 times for the decompiler to get a lot of the symbol names right as it learns a little more each time. That said, some games still have problems recompiling be it due to code errors by Sierra, assembly code blocks that the decompiler couldn't decompile, or still yet some minor problems with the decompiler itself. It's not exactly perfect. Compiling single scripts works for the most part, though. Although, I couldn't even get a single script to work for an SCI32 game.
I have to agree that a global Find+Replace function would be great! However, you can easily get around it by just doing a Global Find for the symbols you want, open each of the scripts with that symbol, and then do a Replace on each one. Would be a little tedious, but it's easy enough.
-
I have to agree that a global Find+Replace function would be great! However, you can easily get around it by just doing a Global Find for the symbols you want, open each of the scripts with that symbol, and then do a Replace on each one. Would be a little tedious, but it's easy enough.
Or just use another editor for such tasks. I would.
-
Thanks for the feedback Charles!
Global find and replace would be nice, but I've just been using another editor (visual studio) for that.
In theory, I should be able to recompile any script I've decompiled, right?
Thanks for the report about script 414 in Laura Bow, I'll look into it. SCI Companion compiles scripts in the background to handle symbol lookups, tooltips, autocomplete, etc...
The decompilation is not perfect, so it is not recommended to compile all - but instead selectively compile just the scripts you want to change. Decompilation not only produces scripts with compile errors, but sometimes - the worst thing possible - incorrect code that compiles fine. I hope to release a "service pack" for SCI Companion 3 at some point soon in which I include fixes for some of these issues.
-
Although, I couldn't even get a single script to work for an SCI32 game.
SCI Companion has pretty much no support for SCI32 at all... or did you mean SCI2?
-
Whatever SQ6 is. Too lazy to check right now. :P
-
I hope to release a "service pack" for SCI Companion 3 at some point soon in which I include fixes for some of these issues.
Would this include having the aspect ratio setting in the game.ini for a per game setting? I am planning on new versions of my two plugins that would read this info to automatically switch aspect to match. It would also be nice to be able to load another game with a different ratio than your previous game without having to change the ratio every time.
-
Charles as in 'Unknown Hero"?
Yup, that's me. I see a lot of familiar names around these forums. I read about SCICompanion from MusicallyInspired's KQ6 post on the ScummVM forums.
That said, some games still have problems recompiling be it due to code errors by Sierra, assembly code blocks that the decompiler couldn't decompile, or still yet some minor problems with the decompiler itself. It's not exactly perfect.
Sierra coding errors would only be a problem if troflip's compiler is significantly different from sierra's original compiler, wouldn't it? (Which, I guess "significant" is really subjective... could just be stricter, for all I know) And I was under the impression that (in theory) the asm code segments troflip's decompiler creates are recompilable as is... or do they need to be reconfigured by hand into Sierra Script before they can be recompiled?
Global find and replace would be nice, but I've just been using another editor (visual studio) for that.
Yeah, I'd probably use the same... or Notepad++. Either way, not too crazy. How well does SCI Companion handle scripts being changed out from under it? Or should I just close out SCICompanion beforehand then reopen after?
SCI Companion compiles scripts in the background to handle symbol lookups, tooltips, autocomplete, etc...
Okay, I figured it had to be doing something in the background the way it was crashing. Same thing happened when I was in KQ4, too. I hope it's not related to the fact I was renaming local variables.... for the foreseeable future, that's going to be my strongest use-case.
I always get the later SCI versions mixed up... which came first... SCI32, or SCI 2?
-
Welcome to our little community. Stick around.
I always get the later SCI versions mixed up... which came first... SCI32, or SCI 2?
SCI0 -> SCI0.1 -> SCI1 -> SCI1.1 -> SCI2 -> SCI2.1 -> SCI3(2)
http://sciwiki.sierrahelp.com//index.php?title=Sierra_Release_List
-
Glad I could finally swing someone over this way! :D Welcome, indeed!
Unfortunately, (unless it's changed) ASM is not compile-able in Companion. Troflip will have to explain further on the differences between his decompiler/compiler and Sierra's original compiler...
-
Unfortunately, (unless it's changed) ASM is not compile-able in Companion.
But the template game has ASM blocks, doesn't it?
-
I could have sworn it was said that you couldn't compile asm. In fact, I thought I remembered you trying to translate asm sections so thay it would compile. If I'm speaking false information someone please correct me!
-
Just look at Controls.sc in the template game, DText::handleEvent. At some point they added clickable regions, which chokes out the decompiler. I just wanted them readable, which OmerMor's source leaks allow.
*is off to replace his game's DText with OmerMor's*
Okay that's it. The only ASM blocks currently in my game's code are in backup copies. Tricky bit is to adapt the Sierra code to SCI Studio/Companion constant names, and that our GetValueAt is their WordAt, stuff like that.
-
I've been really off my game lately. On forums everywhere. I blame this cold I've had for the past 2 weeks...
-
And to be completely honest with you, no matter the cause, the results are hilarious.
-
Sierra coding errors would only be a problem if troflip's compiler is significantly different from sierra's original compiler, wouldn't it? (Which, I guess "significant" is really subjective... could just be stricter, for all I know)
Yes, it's more strict. Some of the "coding errors" you might find are: duplicate objects (e.g. two objects called "bigRock" in the same script), or duplicate case statements. For the latter, I've made a change to the SCI Companion compiler that will just produce a warning instead of an error. I didn't do this for the former, since I haven't researched which of the duplicate objects the interpreter ends up using...
Either way, not too crazy. How well does SCI Companion handle scripts being changed out from under it? Or should I just close out SCICompanion beforehand then reopen after?
Companion's text editor doesn't track files being changed from under it, but you'll be safe if you just close the script and re-open it. The "browse data" compiled in the background for things like "go to definition" or autocompletion will get out of date until you edit the script again in Companion, but that shouldn't be a big deal.
Okay, I figured it had to be doing something in the background the way it was crashing. Same thing happened when I was in KQ4, too. I hope it's not related to the fact I was renaming local variables.... for the foreseeable future, that's going to be my strongest use-case.
Can you describe exactly what you were doing when this happened? Like, how did you open the script file, had you just saved it, or what?
Would this include having the aspect ratio setting in the game.ini for a per game setting?
Yes.
And yes, asm blocks are compilable. But the format of the asm blocks is different between SCI Companion and SCI Studio.
And if you ever realize there is a problem with a section of code that Companion decompiled (i.e. you know it did a bad job), you can always check the "disassemble only" box in the decompile window, and re-"decompile" that script to generate just pure asm - which should generate the same as the original Sierra code when compiled.
-
Perhaps an aspect ratio selection on the New Game dialog would be a good idea to add, too.
-
I'll try and take better repro notes the next time it happens, but from memory it felt pretty random. Open a previously decompiled KQ4 or LB1, open a script (701 for KQ1, 414 for LB1) by double-clicking on it in the built-in explorer, change a couple procedure names or local variables with the built-in replace command, add some comments at non-specific intervals or locations, grab a coffee (two sugars), return to find it crashed.
It definitely wasn't after saving... I lost my work a couple times, so I started saving pretty religiously.
-
Okay, so I'm now able to consistently reproduce the crashing I'm seeing.
I've seen is in both Laura Bow 1 (v1.000.046) and KQ4 SCI (v1.006.004). I think it's related to tooltips in some way.
In either game, I opened it up fresh, then decompiled the scripts 3 or 4 times. Then open script 000's source.
In KQ4 scroll down to procedure proc0_7 and hover the mouse over "setLoop:" for 2-3 seconds (below in gEgo , i.e. line 517).
In LB1 scroll down to procedure proc0_25 and hover the mouse over "said:" for 2-3 seconds (line 727).
Then SCICompanion will crash with an unhandled exception. (Unhandled exception at 0x00e0eb1e in SCICompanion.exe: 0xC0000005: Access violation reading location 0x000000f0.)
I also was able to make some progress on script 414 not compiling in LB1. It turns out it wasn't actually a problem with script 414, but one of the procedures in a referenced script (999). So I made some changes to script 999 allowing it to compile, and then 414 compiled without complaint.
However, I was surprised that I wasn't able to then take just 414 into a vanilla copy of LB1. It would crash in both SCI and SCUMMVM. I had to recompile all the other scripts (after correcting some minor compiler errors in a handful of other scripts) and I was able to get that running.
So this brought up a couple of questions for me:
If I just change procedure names and variable names without changing the content/order of them, is the compiled output compatible with the existing compiled scripts?
Can I change the contents of procedures and methods etc and expect existing scripts that call those procedures/method to continue calling them, or will they fail outright?
-
Ok, it looks like the LB1 issue (and presumably KQ4) only happens right after a decompile, right? When I re-open the game again, I can't repro it.
I had already made a fix to Companion (unreleased) to avoid the crash, but I never found the root cause. I'll try to look more deeply now.
As for the compile issue with 414, the actual problem is that the global class table (vocab 996) in that game is out of sync with the script files. It's a list of script numbers, and the position of script numbers in that file correspond to the index of a class in that script. For instance, species 5 is supposed to be the 5th class defined in script 999. The 5th class (0-based) in script 999 is Script. But, Script defines itself as species 6 in the script 999 resource. So the script resources are out-of-sync with the class table resource (vocab 996).
I forget the exact way Sierra compiled, but I think the class table was a text file in their compilation system, and the compiler looked at that. Then it would be occasionally compiled in to vocab 996 itself. I'm guessing the game doesn't do anything with vocab 996.
So, to workaround it or fix it, there are a few options:
- Tools -> Rebuild class table. The problem is, this means you have to recompile all afterwards - which is a problem if the scripts don't compile for other reasons. And it it more likely to expose any bugs in the decompiler that may have produced compilable but incorrect code, and your game will behave weirdly or crash for a hard-to-diagnose reason.
- Manually try to fix things up by inserting dummy classes in the right spots. For instance, inserting a class between Code and Collect in script 999 should fix up that particular issue with Script (999 would need to be recompiled). However, script 999 has ten entries in the class table, but only 7 scripts defined in the actual code. And I assume other scripts have similar issues, since the class table is generally out of date. So you'd need to do this for all scripts that define classes*.
- Wait for me to make a fix to the decompiler that will do this automatically :-)
- I could change the way Companion compiles to avoid this mess (e.g. by generating a classtable.txt that would be used, instead of the vocab 996), but I was trying to maintain parity with SCI Studio's compilation system. Plus that's a lot of risky work.
If I just change procedure names and variable names without changing the content/order of them, is the compiled output compatible with the existing compiled scripts?
Should be.
Can I change the contents of procedures and methods etc and expect existing scripts that call those procedures/method to continue calling them, or will they fail outright?
The contents? Sure, that will be fine. Callers are ignorant of the contents of the methods/procedures. Of course, if you change their behavior in a way that affects state the callers use....
*To do this audit, you can get the species index from the class table, and compare it to the one defined by the object in the script resource (Script->View Script Resource). The species of a class is property 0, the first entry right under the "properties:" header for each class. If you do this for script 999, you'll see the classes have species 0, 1, 3, 4, 5, 6, 7. Hmm, so actually just a single dummy class between Code and Collect should fix that particular issue up. Oh actually wait, no, you'll need to add 2 more dummy classes at the end, since we're trying to preserve the integrity of the class table. ugh, complicated.
-
Hmm... I was able to get LB1 script 414 to compile by manually editing the vocab 996 file (attached) by putting invalid scripts in place of the valid 999 ones.
I did exported vocab.996 as a patch file, edited it manually in a hex editor, saved, then re-imported it (make sure to not to save the patch file in the game's directory).
Other entries probably need the same attention, but at least this let me compile that particular script with a fresh decompile of LB. Dunno if the game barfs on it or not...
[edit:] also, the game re-writes the class table on compile, so this might not be a good permanent solution.
-
Ok, it looks like the LB1 issue (and presumably KQ4) only happens right after a decompile, right?
No, I should have been clearer. That's how I first got the crash. I could then immediately re-open SCICompanion, hover over the lines I specified, and watch it crash again.
So let me see if I understand this: each script keeps a lookup table of index numbers for each procedure/method in it. SCICompanion will automatically generate that lookup table based on the order each procedure appears (a perfectly logical approach). The Classic Sierra compiler generated that lookup table based on some other reference (likely some sort of text file), the consequence of which is that lookup indexes will not necessarily be in order.
Any script (A) that includes a reference to another script's (B) procedures does so by referencing (B)'s lookup table index. So my recompiled 414 script failed to work because it was referencing procedure index 5 in SCICompanion's compiled 999.scr, when it needed to reference index 6 in Classic Sierra compiled 999.scr.
I'm happy for you to add automagic anywhere you want, but I'm not one for waiting. I like your idea of adding in a dummy procedure in the 3rd spot so the other indexes realign. I suspect I wouldn't need to add the other two dummy's to padd out the end of the table, but 'ellifiknow. As for compatibility with SCI Studio... I'm new to this scene, so my opinion shouldn't have that much weight, but honestly my impression has always been that there was minimal serious development on SCI Studio anyway due to the whole chicken/egg thing with VGA support.
I wonder how prevalent missing procedures are in Sierra games in general... I've already seen Colonel's Bequest has a couple. Heck, there's a whole missing script file referenced in there (984).
Soon as I get the chance I'll try the dummy filler method. I'll have to compile 999 for SCICompanion's benefit, but I shouldn't have to include that if I wanted to patch a vanilla copy of LB1, should I?
-
No, I should have been clearer. That's how I first got the crash. I could then immediately re-open SCICompanion, hover over the lines I specified, and watch it crash again.
Hmm... maybe I haven't fixed the issue then. Did you decompile all the scripts in the game? I can see the issue still happening if User.sc wasn't decompiled, but if you decompiled everything and it still is happening, then I might not have the right repro... hmm...
So let me see if I understand this: each script keeps a lookup table of index numbers for each procedure/method in it. SCICompanion will automatically generate that lookup table based on the order each procedure appears (a perfectly logical approach). The Classic Sierra compiler generated that lookup table based on some other reference (likely some sort of text file), the consequence of which is that lookup indexes will not necessarily be in order.
Any script (A) that includes a reference to another script's (B) procedures does so by referencing (B)'s lookup table index. So my recompiled 414 script failed to work because it was referencing procedure index 5 in SCICompanion's compiled 999.scr, when it needed to reference index 6 in Classic Sierra compiled 999.scr.
That's the general gist of it, but this is specific to species indices - it has nothing to do with procedures or methods. Each class (or species) has a number associated with it.
When SCI Companion encounters this line:
(identify state: 4 seconds: 0 cycles: 0)
It looks and sees that (defined in the same file, script 414) "identify" is an instance of the "Script" class. It then tries to validate that state, seconds and cycles are all properties or methods on Script.
To do so, it needs to find the species number of the class. It looks at the included .sco files (which are generated by the compiler or decompiler when compiling or decompiling a script). It sees that "Script" is the 5th class in Obj.sco (for script resource 999). It then looks at vocab.996, which tells us that the 5th class defined in script 999 has species index 5. So the compiler goes "ok, I need to look up properties on species index 5".
Then it goes back to the .sco file and says "ok, give me info about the class that says it's species 5". And in the .sco file, that's EventHandler that says it's species 5 (which is correct). So we compare against the methods and properties of EventHandler (instead of "Script") and fail.
Listing the details of it out like this make me think I can fix how we obtain the species index (italicized above). The .sco file actually has information about which species each class is already inside it - I don't need to touch the vocab.996 resource. Need to think about this a bit more. At any rate, this would require a fix in SCI Companion, so it's of no use to you now.
I wonder how prevalent missing procedures are in Sierra games in general... I've already seen Colonel's Bequest has a couple. Heck, there's a whole missing script file referenced in there (984).
Well I've decompiled a lot of games, and this is the first I've seen of it that I can remember. Although I think there are still some mysterious compile errors in decompiled games that I haven't had time to look into - so perhaps this was the cause of those too.
Soon as I get the chance I'll try the dummy filler method. I'll have to compile 999 for SCICompanion's benefit, but I shouldn't have to include that if I wanted to patch a vanilla copy of LB1, should I?
Correct, it shouldn't need to be included. Compiling 999 should generate an 999.sco and a vocab.996 resource that makes everything consistent for the compiler - i.e. compiling other scripts that reference 999 will now reference valid species numbers.
btw, I hope you're not making a patch to remove the fingerprint "copy protection".
-
I've bypassed copy protection in my own Sierra games for my own personal use (because I just don't want to dig out my manuals) by a fairly simple means, but when I went to attempt the same with LB1, I was surprised to see just how complex they made it. Now, I didn't have the Troflip's decompiler like we do now, so I was just looking at disassemblies and the copy protection, from what I remember, was so convoluted between different scripts that it was impossible to do it they way I had easily done it in past games. I never bothered to look at it decompiled to see just how it was done, but mad props to Sierra for convoluting it like that. Reminds me of the store Scott Murphy told once on how Ken Williams added the "kiss sarien" bonus point to SQ1 and he couldn't figure out how to remove it from the game because Ken had tied it into a bunch of other things in the game and removing it broke everything. So he had to leave it in lol. He said it as a compliment to his programming skills.
-
Did you decompile all the scripts in the game?
Yup. Decompiled them all a couple times each. Which script number is generally User.sc?
(And just to double-check, SCICompanion's About Box says it's version 3.0.1.7, which I believe is still the latest official release...)
That's the general gist of it, but this is specific to species indices - it has nothing to do with procedures or methods. Each class (or species) has a number associated with it.
Ah, I was mixing up classes and procedures. So the fact that 999 itself wasn't compiling was a bit of a red herring.
I wonder how prevalent missing procedures are in Sierra games in general... I've already seen Colonel's Bequest has a couple. Heck, there's a whole missing script file referenced in there (984).
Well I've decompiled a lot of games, and this is the first I've seen of it that I can remember. Although I think there are still some mysterious compile errors in decompiled games that I haven't had time to look into - so perhaps this was the cause of those too.
I don't know if it decompiled properly or not, but it sure looked like it decompiled properly. Script 996 has the reference to phantom script 984, and even references a specific procedure from it:
(proc984_0 alterEgo gSFeatures gCast gFeatures)It's funny, LB1's showing several areas that I would consider to be bad coding practice. This if statement that leads to a procedure call that doesn't exist, for one. For another I believe there's a 1 in 600 chance of the game crashing on startup at the copy protection screen.
Correct, it shouldn't need to be included.
And it did. The compiled script now behaves exactly as expected.
btw, I hope you're not making a patch to remove the fingerprint "copy protection".
I'm certainly not doing any such thing for distribution purposes. At some point in the future I want to create my own game in the vein of QFG (There's been a bit of a boon of those types of games lately, Quest for Infamy, Heroine's Quest, Betrayed Alliance), but for now I'm satisfying myself with decompiling/commenting existing games, making minor bug fixes, then making slight mods to existing games. But mostly just soaking in the SCI coding structure.
-
Yup. Decompiled them all a couple times each. Which script number is generally User.sc?
(And just to double-check, SCICompanion's About Box says it's version 3.0.1.7, which I believe is still the latest official release...)
Ah, so you didn't do a SetFilenames to get good file names? (don't have src handy at the moment, don't know which one is User.sc). Shouldn't matter though. I can give you a build to test to see if the crash goes away.
Ah, I was mixing up classes and procedures. So the fact that 999 itself wasn't compiling was a bit of a red herring.
Procedures do have a bit of the same issue, but I added the "public" exports section to assign fixed export number for them, so they are stable and don't change when you add/remove public procs. There's no master table to get out of sync with though, since calls to public procs are identified by script number + export index (as opposed to some global index)
It's funny, LB1's showing several areas that I would consider to be bad coding practice. This if statement that leads to a procedure call that doesn't exist, for one. For another I believe there's a 1 in 600 chance of the game crashing on startup at the copy protection screen.
Well, they probably just removed that script then forgot it was accessed in an if statement that (apparently) never gets hit. Dunno if it's bad coding practice - maybe just the victim of a compiler that didn't treat this as an error.
-
I don't know if it decompiled properly or not, but it sure looked like it decompiled properly. Script 996 has the reference to phantom script 984, and even references a specific procedure from it:
(proc984_0 alterEgo gSFeatures gCast gFeatures)It's funny, LB1's showing several areas that I would consider to be bad coding practice. This if statement that leads to a procedure call that doesn't exist, for one.
If you're interested in this missing script, here some information:
The original name for script #984 was SORTCOPY.SC.
It has one procedure in it:
(procedure (SortedAdd theOrigin theLists
&tmp
i toList fromColl
node dist obj ang
invisible
objMinFront distMinFront frontList ;features ego can see on screen
objMinOut distMinOut outList ; " " " " off "
objMinBack distMinBack backList ; " behind ego
)
; ...
)
The original code that calls this procedure from User::said() is this:
(if useSortedFeatures
(SortedAdd alterEgo sortedFeatures cast features)
else
(sortedFeatures add: cast features)
)
Here's some documentation on it's usage:
12/12/88 Pablo
There is a new global variable called "egoBlindSpot" which should contain
the size of ego's blind spot in degrees, ie. how many degrees from
"straight behind" are not visible to ego. Default is zero (360 degree
vision), recommended value is 90 (ego only sees ahead). If
useSortedFeatures is TRUE then objects in ego's blind spot do not have
their handleEvent method invoked on Said events.
The useSortedFeatures and egoBlindSpot globals were numbered 54 and 56 respectively.
I saw LB1 doesn't use this feature, so there was no need to include the SORTCOPY.SC script with the game.
-
Well, they probably just removed that script then forgot it was accessed in an if statement that (apparently) never gets hit. Dunno if it's bad coding practice - maybe just the victim of a compiler that didn't treat this as an error.
You're absolutely right. I'm making wild assumptions without knowing any of the facts.
I saw LB1 doesn't use this feature, so there was no need to include the SORTCOPY.SC script with the game.
And there ya go.
If you're interested in this missing script, here some information:
I'm very interested in this sort of stuff. The Sierra games of old have given me thousands of hours of entertainment over the years, at least, and I find it fascinating to peel back the layers or look behind the curtain, so to speak. Thank you very much for sharing.
-
Wow! A blind spot script! That'd be something interesting to play with...
-
If you're interested in this missing script, here some information:
I'm very interested in this sort of stuff. The Sierra games of old have given me thousands of hours of entertainment over the years, at least, and I find it fascinating to peel back the layers or look behind the curtain, so to speak. Thank you very much for sharing.
I think you described pretty much everyone in this little community. :)
And you're welcome.
-
*To do this audit, you can get the species index from the class table, and compare it to the one defined by the object in the script resource (Script->View Script Resource). The species of a class is property 0, the first entry right under the "properties:" header for each class. If you do this for script 999, you'll see the classes have species 0, 1, 3, 4, 5, 6, 7. Hmm, so actually just a single dummy class between Code and Collect should fix that particular issue up. Oh actually wait, no, you'll need to add 2 more dummy classes at the end, since we're trying to preserve the integrity of the class table. ugh, complicated.
I've taken another look at some other LB1 scripts, with an eye to the species order... am I reading this correctly? If I look at the Script Resource for Feature.sc (script 998), I see there are 7 classes and they start at index 24 (in hex). So does this mean using the "dummy" method of correctingit, I would have to insert 36 dummy classes before the "Feature" class?
-
No. Species are global numbers, not per-script. I don't have LB1 on hand since I'm not at home now, but looking at the SCI0 template game, Feature.sc is script 998. In the global class table (vocab.996), I see the following entries for script 998:
species 35: script 998
species 36: script 998
species 37: script 998
species 38: script 998
species 39: script 998
species 40: script 998
species 41: script 998
If the numbers you see in LB1 match the species numbes in the Features script, then you're fine.
If, though, you looked at the features script, and saw that it had 6 classes with species: 35, 36, 38, 39, 40 and 41 (decimal), then you'd notice that 37 is missing. So you'd need to add a dummy class between the class with species 36 and species 38.
[edit:] Just looked at the LB1 998 script, and it seems to correspond fine with the global class table, don't think you need to do anything.
-
I'd like to report what looks to me like a decompiler bug:
In Quest for Glory 3, script #23, Teller::doChild(), the disassembly is the following:
(method (doChild key &tmp index)
(asm
ldi 0
sat index
code_0713:
+at index ; (++ index)
bnt _end
pushi 2
pTos keys
push ; <== BUG HERE
calle WordAt, 4
push
lap key
eq?
bnt code_073d
pushi #stuffArray
pushi 2
pushi 2
pTos arrays
lst index
calle WordAt, 4
push
pushi 1
self 8
ldi 1
ret
code_073d:
pushi 2
pTos keys
lst index
calle WordAt, 4
push
ldi 999
lt?
jmp code_0713
_end:
ldi 1
ret
)
)
And the decompiled source is the following:
(method (doChild key &tmp index)
(= index 0)
(while (++ index)
(if (== (WordAt keys (++ index)) key) ; <== BUG HERE
(self stuffArray: (WordAt arrays index) 1)
(return 1)
)
(< (WordAt keys index) 999)
)
(return 1)
)
In the lines I marked, the script is calling WordAt with 2 parameters. The 2nd parameter is the accumulator (push), which has the value of the previously incremented index (+at index).
However, the decompiler copies the whole (++ index) expression as the 2nd parameter, which is incorrect, as the index is only incremented once.
-
It's possible I've already fixed this (are you using the official Companion release, or private build?). I'll check tonight. I'm waiting to release an official update until I've tackled one other decompiler bug involving chained operators (e.g. (< 3 4 5 6)).
[edit:] nope, not fixed. I'll add it to my bug list.
-
wait what
I can understand (+ 1 2 3) and such but <?
-
Yeah, Sierra used that a lot to check ranges.
(if (< 5 (ego x?) 20)
(Prints "Ego x is between 5 and 20")
)
It's one of the few places that uses the pprev register, and the decompiler doesn't handle that properly (and it's not trivial to fix).
http://scicompanion.com/Documentation/Compiler/relationaloperators.html
-
wait what
I can understand (+ 1 2 3) and such but <?
if 2 < a and a < 5 then ....
becpmes
(if (< 2 a 5) ...)
-
Reminds me of Python's chained comparisons: if (a < b < c) ...
-
Reminds of Python's chained comparisons: if (a < b < c) ...
Python has that? *goes to test* ... hm, sure does. I learned something new there.
-
I am intrigued.
-
Reminds of Python's chained comparisons: if (a < b < c) ...
Python has that? *goes to test* ... hm, sure does. I learned something new there.
Yeah, I was shocked the first time I learned that. Now I wish every other language had that as well... ::)
-
Minor bug:
When decompiling both "old" and "new" versions of KQ4-SCI (1.000.111 / 1.006.004), script #120, I noticed that the old version sometimes confuse properties with methods, and call class methods with getter notation '?'.
For example, in introSc::changeState()
Old:
(addToPics dispose?)
New:
(addToPics dispose:)
Their disassembly is the same:
pushi #dispose
pushi 0
lag addToPics
send 4
the dispose method is declared in the Collect class, and is decompiled correctly in both versions.
This behavior is not consistent: sometimes method are called correctly with the ':' notation:
(hatActor hide: stopUpd:)
I am using the Sierra Script flavor in both games.
-
Well it doesn't really matter from the compiler's view point, as you know. But it's still weird that this is happening.
I'm confused by what you're saying is inconsistent... are you saying that the same method (dispose) is being output with both ? and : notation within the same version of a game?
The logic should be that a ':' is used when there are more than zero parameters passed, or when a method of that selector name is implemented on any object in the game and never used as a property on any object in the game. Given that dispose() is almost certainly a method on some objects in any version of KQ4, it should always be output with ':' notation. So it looks like I have a bug somewhere.
-
are you saying that the same method (dispose) is being output with both ? and : notation within the same version of a game?
Yes. Even for the same objects:
Room29.sc:
(if (timers contains: local4) (local4 dispose?))
Room3.sc:
(if (timers contains: local5) (local5 dispose: delete:))
Both scripts from version 1.000.111.
-
Ok, so the early KQ4 uses a slightly different script resource format. I'm surprised it even decompiles :-). At any rate, my code that attempts to discern props vs methods doesn't read the selectors properly.
I actually doubt anything will compile successfully unless I do more work to make that happen. I could at least put up a warning or something saying compiling to this version of SCI isn't supported.
Although it might not be too much work to support it...
fyi, SV.exe doesn't even show KQ4 scripts...
-
fyi, SV.exe doesn't even show KQ4 scripts...
Yes, I know - I assumed you had special treatment for early KQ4, and it was related to the bug.
Just wanted to repeat that this is a very minor bug - so don't bother too much with it. I just wanted to let you know.
-
That is only with the earlier versions of the game. SV does see the scripts in later versions. I do not have all versions, but I suspect that it does from 1.003.006 on. SV does not see the scripts in the earlier versions 1.000.106 and 1.000.111. They also do not support patch files. 1.000.111 seems to be one of the more commonly available, so I assume that is the version that Phil has.
-
Correct, 1.000.111 is the KQ4 I have.
-
There is one very old version of LSL2 that uses the old script format as well.
-
I can see the scripts in SV's list, but I can't actually see the disassemblies. So I guess I have those KQ4 and LSL2 versions.
-
More bugs:
- adding a new word to the vocab caused all entries in the view to be duped (guess no one is making SCI0 games anymore!)
- you couldn't modify the type of word of the first word in the vocab view
- dragging multiple resource patch files into the game explorer only added the first one
yikes!
-
I'd been planning to get back to KQ2SCI at some point just to have something SCI to work on. Kind of glad this stuff was spotted first! ;)
-
More bugs (in my private build from trunk):
- It's no longer possible to retain numbered filenames for decompiled scripts. The application is setting the file names to their script names regardless of what you do.
- Using the Search & Replace dialog to replace a string throughout a whole script file, it will only replace that string in the region below the cursor/selection, and skip the region above.
-
More bugs (in my private build from trunk):
- It's no longer possible to retain numbered filenames for decompiled scripts. The application is setting the file names to their script names regardless of what you do.
That's an intentional change. It will automatically set filenames now.
-
Using the Search & Replace dialog to replace a string throughout a whole script file, it will only replace that string in the region below the cursor/selection, and skip the region above.
Ah yeah, that has fucked me over once or twice :D
-
There is one very old version of LSL2 that uses the old script format as well.
Version 1.000.011. It does not accept patch files, either.
-
...that explains my failure to disable the phone number screen.
What? I was bored, a'ight?
-
More bugs (in my private build from trunk):
- It's no longer possible to retain numbered filenames for decompiled scripts. The application is setting the file names to their script names regardless of what you do.
That's an intentional change. It will automatically set filenames now.
There's a bug with setting filenames in the current release. Case is not ignored. In QFG1 EGA for instance, script 32 is called Rock and script 54 is called rock. Needless to say, only the latter is saved when decompiling (or rather script 32 is created first, then script 54 overwrites it. Also in the same vein, sorting by script name in the explorer doesn't ignore case, so all Uppercase scripts come first, followed by lowercase ones.
[edited: I was mixing up case sensitive and insensitive. SCI companion is currently case sensitive for script names. ]
-
Those are good bugs, thanks.
Well, Windows filenames are case-insensitive, so the "set filenames" logic of the decompiler will need to ensure the filename is not already being used - if it is, change the name (it already supported this, but wasn't case insensitive like it needs to be).
-
...that explains my failure to disable the phone number screen.
What? I was bored, a'ight?
You can can get passed it by entering 555-0724.
-
...that explains my failure to disable the phone number screen.
What? I was bored, a'ight?
You can can get passed it by entering 555-0724.
Al Lowe's birthday =)
-
Yep.
-
I don't believe you guys understand my boredom.
-
Have some kids. They'll make you miss being bored. ;)
-
I should not ever have children.
-
I'm adding a new feature to SCI Companion that auto-generates text resources from strings in the scripts (much of the functionality already existed, it was just disabled - because I was focused on SCI1.1 where this isn't as useful... and I wasn't sure how to expose the functionality).
The plan is to support the following syntax at the top of the script (only in the Sierra syntax):
(text# number) ; usually this would be (text# scriptNumber)
When this is done, the compiler will replace all appropriate double-quoted strings with resource/number pairs when it generates the script resource. Then it will write those strings to the text resource number that was specified in the text# directive (overwriting any previous text resource). Curly-brace strings are left alone so that you can still call methods/procedures that don't understand text resource/number pairs.
This saves on heap space when making SCI0 games.
Since this overwrites the existing text resource, it can be pretty destructive - hence why I require an explicit directive.
What is an appropriate string? Strings in method and procedure calls. That's about it. (Possibly I could include array initializers too, but it doesn't really make sense anywhere else).
A nice bonus feature would be to warn when you try to manually edit a generated text resource - perhaps by including some sentinel string in it.
Thoughts/comments? (I know it's not really exciting SCI1.1 stuff).
-
A sentinel might be good. And yes, this does seem useless when 99% of your text is in Message resources :D
-
One external tool that Gumby made was intended to dump the text resources to a file that could be run through a spell checker. How hard would it be to implement a text import/export function to feed strings through an external spell checker?
-
I'm not sure... I don't know the right way to interface with external spellcheckers, or what spellcheckers there are.
Text resources can already be exported and imported to/from a text file - but of course you want that to be pushed back into code. I don't think any totally-automated way really makes sense (you'll always need to vet the spell check errors one by one).
Starting with Windows 8, there is a built-in spell-checking API, apparently. I'm still on Win 7, but when I upgrade to 10 I could see if I could integrate with that. Maybe underline text strings with squigglies or something.
-
I've interfaced with aspell once.
-
Dumping to a txt file that could at least be dropped in a word processor would at least catch the typos/misspelled words, even if you had to manually correct them in the code. Simply adding a spell checker to the script editor that could add real time spellchecking for strings and comments would be the ideal solution. I have never looked into any such extensions for C++ and have no idea what is available or how much work it would be to integrate.
By the way, I mentioned SCI Companion to a couple of Sierra alums and Lorelei Shannon (of KQ7, Phat2 and other games) said it was "really freaking cool."
-
And that, in turn, is really freaking cool.
-
Hahahah, that's great :-). Do these alums have any jobs for me? :P
-
One external tool that Gumby made was intended to dump the text resources to a file that could be run through a spell checker. How hard would it be to implement a text import/export function to feed strings through an external spell checker?
Yes, this would be a great feature to add. The spellchecking I implemented was done with aspell. I think I also implemented a grammar checker, but maybe that feature never got completed. The tool was buggy as hell, I remember running Betrayed Alliance through it while it was in development and I hadn't considered Print()s with additional properties specified. Or maybe it was Display()s. Anyway, worked great if you had simple print statements in your game.
-
I had a spell checker in SCI Developer's script editor. It was designed for the Fast Colored TextBox control, but but it had problems. It was written in VB.NET and used a couple of things exclusive to VB. I tried porting it to C# so I could see what was going on, but could not fully port it. I hate VB.
-
By the way, I mentioned SCI Companion to a couple of Sierra alums and Lorelei Shannon (of KQ7, Phat2 and other games) said it was "really freaking cool."
That is awesome. Nice to have some attention at all, let alone from ex-Sierra employees!
-
I had a spell checker in SCI Developer's script editor. It was designed for the Fast Colored TextBox control, but but it had problems. It was written in VB.NET and used a couple of things exclusive to VB. I tried porting it to C# so I could see what was going on, but could not fully port it. I hate VB.
Unfortunately there aren't any designed for the crappy old syntax coloring editor I'm using, so integrating anything into the editor would be a lot of work.
Best I could probably do is pick out all the strings in the scripts, and run them through a spell checker and produce a list of "errors" in the output pane at the bottom.
But for the message editor (where strings are never in script files anyway), then there is a path that already works. You can import/export from/to a text file, then run that text file through a spellchecker. I suppose it's not very automated though...
-
Still better than having to simply proof read it.
-
Another fix of interest to SCI0 folks (i.e. no one?) in the upcoming SCI Companion "service pack" is the support of gamma correction for dithered images.
Companion currently assumes that, say, blue dithered with black should be matched to a color that is halfway between those two. But that's incorrect because of a monitor's gamma curve. As a result, the "import bitmap to pic" functionality has never produced very faithful colors. With the addition of gamma correction, this should be fixed.
In the attachment, the top image is the original. Below that, on the left is the non-gamma-corrected image. In the middle is the gamma-corrected image. The bottom row shows what it looks like after being undithered (say in ScummVM).
The right hand side shows the "non-smooth" option in "import bitmap to pic", where dithered colors with very different component colors are allowed. Looks terrible dithered, but more accurate when undithered (look at the ice on the lake).
Note that this only affects dithering, so doesn't apply to the SCI1+ case at all.
-
Actually, I take that back, it is slightly used for SCI1.1 - it affects the accuracy of the color matching. But it's definitely more useful for EGA, where you'd use dithering and the difference between the intended color and the chosen color is greater (because of the limited palette).
Here's another example.
At the top left is the original image. Top center is what the dithered EGA image would look like before if you imported it into a view. Top right is with gamma correction - a huge improvement!
The bottom row is VGA using the default KQ5 static palette (64 colors), undithered. Left is without gamma correction, right is with. The difference here is more subtle, but still somewhat noticeable.
-
Indeed it is a welcome addition!
-
For those decompiling things... here's an "alpha" build of the "service pack"....
http://scicompanion.com/Downloads/SCICompanionAlpha.zip
It's not really an "alpha", as it should be in pretty good shape and has pretty much all the features that will appear in the "service pack". I haven't done a thorough test pass on it I suppose, but it passed all my regression tests.
Download is a little larger because it includes the .pdb file instead there are crashes I need to debug or something.
Please don't complain about the version string in the about dialog, I don't think I updated it :P
Too tired right now to list all the changes, but it has most of the bug fixes/features folks have requested in this thread (including find-and-replace that no longer misses stuff earlier in the file!).
Regarding the decompiler, I *know* there are still decompiler issues, but it works quite well for the games I've recently tried decompiling: LSL3, LSL5, QFG1, QFG2, LB1, KQ6.
(LSL2 and KQ4 don't turn out too well since they are an earlier SCI0 format).
Features/bug fixes in this release:
https://github.com/icefallgames/SCICompanion/commits/master
and page back until January sometime :P
-
Thanks. Would it be possible to add the Ctl+A keyboard shortcut to the script list box of the decompiler?
-
yaaaaas
-
I've downloaded the new "alpha" version and I think there's a bug with how the Decompiler handles some arrays in .sco files.
You can consistently reproduce it in QFG1-EGA, as follows:
Start with a fresh copy of the game, and decompile as you normally would. (btw, I love the new changes to the decompile dialog; It think it really flows a lot more naturally than before... including the prompting to decompile all if none are selected, and the auto-re-decompiling if any global names change.)
Everything should be fine so far. The .sco file is as expected. (We're going to be interested in offset 0xB57).
Now Open up Main.sc and change:
global190 = 2
global191 = 2
global192 = 3
global193 = 3
global194 = 3
global195 = 4
global196 = 5
global197 = 5
to
[global190 8] = [2 2 3 3 3 4 5 5]
(fyi, global190 is spellCost). So now we've converted it to an array.
Compile Main.sc, and it compiles without error. The .sco file is still as expected. The first position of the array is recorded as [0a 00] [67 6c 6f 62 61 6c 31 39 30 00] (aka the name is 10 bytes in length including the null terminator, and is 'global190'). The subsequent positions are each recorded as [01 00] [00], seven times. i.e. the name is just 1 byte; the null terminator. I assume this should already be familiar to anybody familiar with the .sco file format.
At this point, everything is working correctly.
Now, to introduce the error, go back to the decompile window, and decompile just Main.sc. The new Main.sc will now show that array as
global190 = 2
= 2
_2 = 3
_3 = 3
_4 = 3
_5 = 4
_6 = 5
_7 = 5
and save that likewise into the .sco file.
I assume it is doing that in an effort to not allow duplicate filenames, by appending an '_x' to the end of the null variable. Looks like that's only a problem for global variables, too. I'm not seeing any problems in re-decompiling User.sc, for example.
Edited to say, I don't think this bug is a regression, either. I had the same problem on the current official release.
-
Thanks for the report. Yeah, I don't handle global var arrays properly in the decompiler - both in how I read from the .sco (apparently), and also no attempt is made to determine what is an array or not (that only works for temp/param/local vars) - so that means you have to do what you are doing, which is go back to the script editor, compile to generate an .sco, then go decompile your re-compiled script again.
I could try to identify global var arrays across script decompiles... but I think maybe a better thing might be to offer support for modifying global vars and public procedure names in the script editor and having these picked up by the decompiler. That is, it would generate the .sco files from your modified script, which could be picked up by the decompiler. Basically, like compiling but without actually generating a script resource.
Let me ask this: What would be your ideal workflow for decompiling? I'm thinking it would be nice to be able to just make modifications in the script editor for variable/parameter/procedure names, then press a button and re-decompile it from the original resources - and it would re-decompile all dependent scripts too, so they would pick up any new public proc names, for instance.
-
Let me ask this: What would be your ideal workflow for decompiling?
Ideally, I don't think I'd want to have to rely on decompiling to re-align things. Obviously I'm coming from the perspective of somebody documenting existing games rather than developing one from scratch (at this point), so my workflow may be different from somebody else. For me, as I'm going through a script (or multiple scripts) I will start commenting things immediately... all in an effort to identify what a procedure is doing or a variable is for. I'll generally do this by picking an undocumented global variable, say global593 for instance, and see it's only referenced in 2 scripts (000 and 32). I'd already identified 32 as the Mages Maze game, and after a little more digging around, I see that variable is a counter for how many times you've played Mage's Maze. In that process, I may have uncovered other things (and left appropriate comments for them) that will help me to document other items.
I cannot fathom a simple and reliable method of preserving comments across a re-decompile. Doesn't mean a way's not out there, it just seems far more trouble than it's worth.
I don't think it's necessary for the decompiler to identify array's from scratch, but I definitely want the decompiler to respect array's I've already created and recmpiled / recreated an sco for.
I wouldn't want to do this for every go-round, but being able to decompile from scratch with an existing set of sco files is something I certainly feel is valuable. That way I can take advantage of the latest improvements in the decompiler (if there are further decompiler improvements... although to be honest, it sounds like you're 99.99% there for as good as can be.) And that's one situation where I wouldn't necessarily mind losing any comments I've made.
Something that would help that workflow from the get go is a simple "auto-commenting" system for global variables when decompiling. There are certain things I manually look for to start documenting a game: What scripts are a global variable used on, if any. That last part helps me determine if it's an old game features that's been pretty much removed from this release, or if it's possibly an array or not.
So, for example this kind of auto-commenting on decompile would be beneficial:
global14 ;referenced in 3 scripts: 197, 167, 015
global15 ;unreferenced
global16 ;unreferenced
global17 = 7 ;referenced in 50 scripts ('Find in all files' for more details)
global18 ;referenced in 1 script: 999
gCursorNumber ;referenced in 3 scripts: 999, 998, 000
global20 = 999 ;unreferenced
global21 = 997 ;unreferenced
-
Found a small bug. Renaming a script in Companion doesn't rename it on the filesystem, so attempts at opening the script after the rename fails with the message that the script "... could not be opened. Would you like to see the disassembly insead?".
-
Found a small bug. Renaming a script in Companion doesn't rename it on the filesystem, so attempts at opening the script after the rename fails with the message that the script "... could not be opened. Would you like to see the disassembly insead?".
I have code that explicitly handles this, so it should work (it works for me).
What's the circumstance? Decompiled game? Which SCI version? etc...
It looks like I don't pop up an error message if the rename failed, so maybe it's a permissions issue with the folder?
-
Brand new game, SCI 1.1. Tried running it under local admin, didn't make a difference (Run as administrator). Seems to fail consistently for me. My OS is Win 10 if that makes any difference. Created multiple new games, different locations (under 'My Documents' for example), same result.
The 'About SCICompanion' reports that I've got version 3.0.1.6. Is this the most recent build?
-
No, that's old. Use the download link I posted just above:
http://scicompanion.com/Downloads/SCICompanionAlpha.zip
-
Using that download fixed the issue I was experiencing, thank you.
-
I think I've found a bug in the new decompiler. This is from QFG1-EGA, Main.sc, Proc0_27.
Here's output from the new alpha decompiler:
(procedure (AskQuit)
(= isQuitGame (Print {How about a slice of quiche?}))
)
And here's code from the previous public release decompiler (with my defined constants and comments):
(procedure (AskQuit)
(= isQuitGame
(Print
0 64 ; Text 0, Line 64: "How about a slice of quiche?"
PRINT_CAPTION {Giving up, huh?} ; PRINT_CAPTION = 80, 1 parameter: label
PRINT_BUTTON {Quit} 1 ; PRINT_BUTTON = 81, 2 parameters: label, value
PRINT_BUTTON {Don't Quit} 0 ; PRINT_BUTTON = 81, 2 parameters: label, value
PRINT_VIEW 800 1 4 ; PRINT_VIEW = 82, 3 parameters: view, loop, cell (or 1 param: object)
)
)
)
-
Oops, heheh :D
-
I think I've found a bug in the new decompiler. This is from QFG1-EGA, Main.sc, Proc0_27.
Here's output from the new alpha decompiler:
Can you list the repro steps you took? Like, does this only happen after renaming certain things?
When I decompile, I get:
(procedure (proc0_27)
(= global4
(proc255_0
0
66
80
{Giving up, huh?}
81
{Quit}
1
81
{Don't Quit}
0
82
800
1
4
)
)
)
Clearly I have a different version of the game, since I have 66 as the text resource, not 64. What's your game's version? Mine is 1.000.
[edit:] ok, it looks like it happens after renaming to Print, since I special case this and substitute the text resource in the code... and that functionality is broken. Don't know if it's a regression though...
(So the workaround would be to rename your Print procedure to PrintTemp or something, then do a global rename at the end)
[edit again:] It's supposed to look like this, if it were working:
(procedure (proc0_27)
(= global4
(Print
"How about a slice of quiche?"
#title
{Giving up, huh?}
#button
{Quit}
1
#button
{Don't Quit}
0
#icon
800
1
4
)
)
)
-
I have v1.200.
When I decompile it from scratch, I get the same as yours (except with text resource 0 64).
(procedure (proc0_27)
(= global4
(proc255_0
0
64
80
{Giving up, huh?}
81
{Quit}
1
81
{Don't Quit}
0
82
800
1
4
)
)
)
If I then rename proc255_0 to Print and re-decompile, it comes out as
(procedure (proc0_27)
(= global4 (Print {How about a slice of quiche?}))
)
Is Print a reserved word? I don't see it under the list of Kernel commands.
-
There's nothing special about the Print procedure in general, but it is handled specially by the decompiler since it's such a common one and benefits from extra work done to make it more readable.
Kernels are built-in interpreter functions. Print is defined in the game scripts.
Here, I built a version with the fix for the Print issue:
http://scicompanion.com/Downloads/SCICompanionAlpha.zip
-
Here, I built a version with the fix for the Print issue:
http://scicompanion.com/Downloads/SCICompanionAlpha.zip
404 error... is that me, or is the file offline?
-
Sorry... fixed the link...
-
Wow, you're awesome! That was an amazingly fast turnaround fixing the Print decompiling.
Now a clean QFG1-EGA decompiles to:
(procedure (proc0_27)
(= global4
(Print
"How about a slice of quiche?"
#title
{Giving up, huh?}
#button
{Quit}
1
#button
{Don't Quit}
0
#icon
800
1
4
)
)
)
It didn't work when I tried re-decompiling code I'd made a bunch of changes to, but I don't really have much time right now to debug that, so I'm just gonna forge ahead for now. Maybe tomorrow I'll be able to try copying my sco files to a fresh QFG1 and see if that works or not.
So, now that code block brings up a couple questions... I found reference to the #'s in the Selector documentation:
http://scicompanion.com/Documentation/Compiler/selectors.html (http://scicompanion.com/Documentation/Compiler/selectors.html)
Selectors are identifiers for properties and methods of classes and instances. Each property and method has a numerical selector index, which points to its name in vocab.997.
(...)
You are also able to retrieve the numerical selector index of a property or method selector.
Which, when I look in vocab.997, I see that #title is 80, #button is 81, and #icon is 82, so that all makes sense. Can I reference those anywhere in code, including asm blocks, and the compiler will replace it with the index lookup value found in vocab.997? And then the interpreter will treat that as either a property/method index or an integer as appropriate? (It's not like there are any strongly typed variables here...)
Is it possible to add a tooltip that shows the index value when hovering over #selectors? Even if they're only used like constants for Print procedures, that's still a very commonly used procedure.
Then there's the "" vs {}. I read somewhere here that the original Sierra compiler would automatically convert "" strings into Text resources and leave {} string inline, but the last I read, SCICompanion did not duplicate that behaviour. Does this mean it does now?
I assume Text resources are generated in the order they appear in script.So, does that mean that if I were patching a game (either my own release, or a Sierra game) and I had changed the order of some things in the script, I would need to distribute the new script.xxx and text.xxx files?
-
Which, when I look in vocab.997, I see that #title is 80, #button is 81, and #icon is 82, so that all makes sense. Can I reference those anywhere in code, including asm blocks, and the compiler will replace it with the index lookup value found in vocab.997? And then the interpreter will treat that as either a property/method index or an integer as appropriate? (It's not like there are any strongly typed variables here...)
A symbol that is preceded by a pound/hash sign (#) does a selector lookup and replaces the selector name with the number. So #title will evaluate to 80, #button to 81, and so on. It should work anywhere a value like a number (or a string, etc..) can be used. Literally all the compiler does is lookup the number of the selector and replace it with that number.
You'll see this used a lot in code that operates on lists. For example, "call this method on every object in this list":
; Call dispose on every member of the cast.
(gCast eachElementDo: #dispose)
... you use the # notation to pass the method number to the eachElementDo method.
The fact that these are used in the Print procedure is just kind of random. They could easily have used hard-coded enums too. There's no #at or #button or #title method ever being called. The Print procedure just uses them as identifiers to indicate what the next few parameters are.
Is it possible to add a tooltip that shows the index value when hovering over #selectors? Even if they're only used like constants for Print procedures, that's still a very commonly used procedure.
Yes, should be easy.
Then there's the "" vs {}. I read somewhere here that the original Sierra compiler would automatically convert "" strings into Text resources and leave {} string inline, but the last I read, SCICompanion did not duplicate that behaviour. Does this mean it does now?
I don't know if Sierra ever did that - I know you'll find quotes of me saying that, and claiming that in the documentation, because I heard it somewhere :P. But we've seen no evidence of that in all the documentation that Omer has surfaces, as far as I know.
And yes, SCI Companion does support that now, but you have to turn it on explicitly for each script (since overwriting text resources when you compile a script is "risky" default behavior). Open the SCI Companion help and search for "auto generation". There should be one hit, and it's explained on that page. This isn't in the online help yet, because the official release from back in January does not have that functionality. So you have to use the help from the Help menu.
I assume Text resources are generated in the order they appear in script.So, does that mean that if I were patching a game (either my own release, or a Sierra game) and I had changed the order of some things in the script, I would need to distribute the new script.xxx and text.xxx files?
Yes, you would, if you enable the auto-generation of text resources. Or you could just leave it disabled as it is by default - then the strings will be compiled directly into the script of course, since the decompiler has replaced the resource/num tuple with a string (bloating the script resource, and potentially causing out of memory errors). Then the text resource won't even be used by the recompiled script.
Actually, enabling auto-generation of text resources is risky for a decompiled game, since I can't identify every place they are used. All the decompiler has to go on is two numbers in a row, and it only makes the assumption that they are a text resource tuple if the procedure call is "Print". So it'll miss some if they are used elsewhere, and then those tuples will be invalid once the text resource is auto-generated by compiling the script. So the game would show the wrong strings or crash.
Perhaps I should include an option in the decompiler to not replace the tuples - leave them as is. Maybe try to put a comment next to the Print call or something that contains the text, so it's still easy to follow a script's logic.
-
Maybe try to put a comment next to the Print call or something that contains the text, so it's still easy to follow a script's logic.
That's what I do in my decompiles.
-
I think a comment is better than changing the script to use inline strings instead of text resources.
-
Potential new piece of syntax to get the size of an array:
(local
; implicitly sized array (currently supported)
myArray = [1 2 3 4]
)
And now instead of this:
(= i 0)
(while (< i 4)
(FormatPrint "hello %d" i)
(++ i)
)
You can do this:
(= i 0)
(while (< i &sizeof myArray) ; compiler knows the size of the array
(FormatPrint "hello %d" i)
(++ i)
)
The benefit being, you don't need to hardcode a value for your loop. If you change the number of elements, the number will change.
Similar benefit for explictly-sized arrays too, of course:
(method (init &tmp i [someArray 6])
(for ((= i 0) (< i &sizeof someArray) ((++ i))
; ... something
)
)
Currently, you'd need to make a define so you don't repeat the number twice (and risk it getting out of sync as you make changes):
(define SOMEARRAY_SIZE 6)
(method (init &tmp i [someArray SOMEARRAY_SIZE])
(for ((= i 0) (< i SOMEARRAY_SIZE) ((++ i))
; ... something
)
)
Not sure about the exact syntax yet...
-
I like the &sizeof thing. Little things like that.
About the Print inlining, I've been looking through Police Quest 2 a bit and there's a minor snag:
(procedure (localproc_0060)
(Print &rest #at -1 15)
)
; ...
((Said 'display,flash/badge')
(if (gEgo has: 7)
(localproc_0060 20 2) ; would be (localproc_0060 "\"I didn't do it! She made me!\"")
else
(localproc_0060 20 3) ; would be (localproc_0060 "You don't have your identification with you.")
)
)It doesn't exactly work when you're using a wrapper like that. Of course, it's perfectly understandable why this is. Other'n that, I dig it.
Fun fact: rm20 has exactly two Print calls -- the wrapper and the narration when you draw a gun on the guard.
-
It's not possible to know if two numbers passed to a procedure are meant to be resource tuple, so it is (was) hard-coded to only check for Print. I've changed it (in a forthcoming release) so that it can be configured in the Decompiler.ini:
[textResourceTuples]
textResourceTuples = [ "Print", "FormatPrint" ]
And also it will by default simply add a comment with the text, instead of replacing with the text.
-
I wonder how that'd work with local procedures, if at all.
-
It matches by procedure name, so as long as you find out the name of the local procedure by decompiling first (the given name just involves it's offset in that script resource), then you could add it to the decompiler.ini and re-decompile. Decompiler.ini is copied to the src folder (if it doesn't already exist) whenever you open the decompile dialog, and read in every time you do a decompile... so any changes should be picked up and you can basically customize it for a particular game.
I don't think I ever made any documentation for the Decompiler.ini file, because it's just meant as an "escape valve" to allow customization if needed. If you put bad things in there, it might cause SCI Companion to crash, because I'm not very rigorous about validating its contents.
But the info in Decompiler.ini is how Companion knows, for instance, that the signal property should be expressed in hex:
(instance Ball1 of Act
(properties
y 99
x 183
view 136
signal $4000
illegalBits $0000
)
)
Or that the first parameter to a handleEvent method should be called pEvent, or to a changeState should be called newState:
(method (changeState newState &tmp gloriaX_2)
(switch (= state newState)
...
... that the parameter passed to a respondsTo method call should be a selector literal:
((param1 respondsTo: #nsLeft)
... or that code that compares numbers to the type property of a variable called pEvent should turn the numbers into event defines:
(switch (pEvent type?)
(evKEYBOARD
...
Instead of hard-coding that "magic", I put it in Decompiler.ini so it could potentially be modified by someone.
-
Tying procedure names to this text matching functionality could be a bit problematic because each function might have that tuple located elsewhere in its signature.
Maybe it would be possible to somehow annotate parameters in a way that would hint the decompiler?
Of course, the annotation should "survive" future decompilations so would probably need to be added to the SCO file, like the procedure names and their signature.
Here's an example of how ReSharper is using custom annotations to hint it about functions that format strings:
http://www.jetbrains.com/help/resharper/2016.1/Code_Analysis__String_Formatting_Methods.html#custom
-
That would be nice functionality to have, for sure.
Tying procedure names to this text matching functionality could be a bit problematic because each function might have that tuple located elsewhere in its signature.
I don't think I've ever seen a case of that... seems like it's always the first two parameters.
-
Tying procedure names to this text matching functionality could be a bit problematic because each function might have that tuple located elsewhere in its signature.
I don't think I've ever seen a case of that... seems like it's always the first two parameters.
I agree that non-matching signatures would be an edge case at best. In the limited examples I've seen in QFG1, all the tuples are located at the start, so they can all take advantage of passing &rest to the Print statement. It is variable whether the tuple is one parameter or two, so it kinda has to appear first in the Print statement (and thus any Print wrappers). Unless there's a specific counter-example?
-
It matches by procedure name, so as long as you find out the name of the local procedure by decompiling first (the given name just involves it's offset in that script resource), then you could add it to the decompiler.ini and re-decompile.
That's what I thought. Thanks.
-
I agree that non-matching signatures would be an edge case at best. In the limited examples I've seen in QFG1, all the tuples are located at the start, so they can all take advantage of passing &rest to the Print statement. It is variable whether the tuple is one parameter or two, so it kinda has to appear first in the Print statement (and thus any Print wrappers). Unless there's a specific counter-example?
Here's a counter-example:
Quest for Glory 2, script 25, rm250::handleEvent, right at the end of the method, it calls proc2_28, which was originally named SayThanks:
((Said 'thank') (SayThanks keapon 250 12))
Here's the original SayThanks procedure:
(procedure (SayThanks) ; Pass a "You're welcome" string
(if (<= (++ roomThanks) 2) ; Not more than twice per room visit
(SkillUsed HONOR 10)
(SkillUsed COMM 5)
)
(Say &rest)
)
And here's the Say procedure from script 23 (proc23_0):
(procedure (Say whom) ; Kludge to keep args as far strings
(whom messages: &rest)
)
Adding the SayThanks procedure to the decompiler.ini file does not work.
BTW, to further complicate things, the Say procedure is accepting multiple tuples, for example:
(Say keapon 250 6 250 7)
Here's another problem:
I tried to add the keapon::showText method and its base Talker::showText to the decompiler.ini file, but it didn't work as well.
It is also used in the same rm250::handleEvent method. Here's a snippet:
(keapon showText: 54)
-
Here's another problem:
I tried to add the keapon::showText method and its base Talker::showText to the decompiler.ini file, but it didn't work as well.
It only works for procedures at the moment.
-
btw, have we seen any indication of how the compiler managed this?
There is a tool that extracts quoted strings into a text file, which was then presumably processed in to a text resource. Ok, so that gets them into the text resource.
But then how did the compiler handle turning the text strings into tuples? I don't recall seeing anything that differentiated {} strings from "" strings, or that performed that functionality. And it was certainly never mentioned in any of the docs we have.
-
But then how did the compiler handle turning the text strings into tuples? I don't recall seeing anything that differentiated {} strings from "" strings, or that performed that functionality. And it was certainly never mentioned in any of the docs we have.
You can see an example of {} versus "" in CHARSAVE.SC which Omer posted a few days ago.
-
btw, have we seen any indication of how the compiler managed this?
There is a tool that extracts quoted strings into a text file, which was then presumably processed in to a text resource. Ok, so that gets them into the text resource.
But then how did the compiler handle turning the text strings into tuples? I don't recall seeing anything that differentiated {} strings from "" strings, or that performed that functionality. And it was certainly never mentioned in any of the docs we have.
Here's what I was able to gather:
A special SCI file with a .TC extension was used. It contained named arrays of text messages. Each file was assigned a unique script #.
The TC files were compiled using the TC.EXE tool (text compiler?).
This tool generated header *.TH files, and the TEXT.* resources.
The generated TH file defined 3 symbols for each array:
- ArrayName.FILE: The file #
- ArrayName.FIRST: The index of the first text message
- ArrayName.LAST: The index of the last text message
Here's an example from MSG254.TC in QfG2:
; msg254.tc -- Text messages for QG2 Keapon Laffin (compile with tc)
;Note:
; compile using "tc filename"
; filename must end in .TC
; include filename.TH in your .SC file
; Names have max length of 9 characters
; do not use parens or quotes in comments
; does not support includes or defines
; must have quotes around sentence
(script# 254) ; msgKeapon
(KeaponHi
"Buon giorno!__Good and tag!__Buenas Dias, Senor Caws.__I haven't seen
you in so long."
"Hello!__Bone Jar!__Hi, guy!__Set a spell, take your shoes off!__What
may I do to you?"
"Konnichiwa!__Come and tell me who!__Hola!__How now, brown cow?"
)
(KeaponHi2
"Top o' the morning to ya!__Mar Haba!__What's New, Pussycat?"
"Hail, fellow, well met!__What da ya know, Joe?"
"Ahoy, Goy!__Howdy, Duty.__What's up, Doc?"
)
The resulting MSG254.TH looked like this:
(define KeaponHi.FILE 254)
(define KeaponHi.FIRST 0)
(define KeaponHi.LAST 2)
(define KeaponHi2.FILE 254)
(define KeaponHi2.FIRST 3)
(define KeaponHi2.LAST 5)
The TH file was included by the dependent script, for example in RM250.SC we have:
(include msg254.th)
The included definitions allowed the SC script to refer to the text resource.
The Talker class used a msgFile property to construct the text tuple. It was assigned for example in the keapon Talker instance, like that:
(instance keapon of Talker
(properties
; ...
msgFile KeaponGNR.FILE
; ...
)
KeaponGNR is one of the text arrays in MSG254.TC. All of them had a FILE symbol with value of 254, so any of them could be used to initialize the msgFile property.
The keapon::showText method was called with the text index like this:
(keapon showText: KeaponSpells.FIRST)
The keapon::showText method called the base Talker::showText with the text index. Talker::showText used the msgFile property to build the complete text tuple:
(method (showText what)
(self messages: msgFile what)
)
-
Hmmm... that sounds like kind of a convoluted process. There are still raw "" text strings in the source code though. It doesn't *only* use defines created by those tools. (don't have QFG2 handy at the moment to see if maybe raw strings didn't make their way into text resources).
What you're describing sounds more like the precursor to message resources (indeed, it looks like QFG2 EGA is classified as SCI1, not SCI0 - and uses concepts like Talkers). I'm not convinced compiling SCI0 worked this way.
-
Hmmm... that sounds like kind of a convoluted process. There are still raw "" text strings in the source code though. It doesn't *only* use defines created by those tools. (don't have QFG2 handy at the moment to see if maybe raw strings didn't make their way into text resources).
What you're describing sounds more like the precursor to message resources (indeed, it looks like QFG2 EGA is classified as SCI1, not SCI0 - and uses concepts like Talkers). I'm not convinced compiling SCI0 worked this way.
The CHARSAVE.SC file I referred to is not from QfG2, but QfG1... and yes, 'convoluted' is the word I would use for this as well. I have seen other (*cough*) code that uses the TC program to generate text resources, but uses simple calls (Print, GetFarText, Format, etc.) with explicit numbers to refer to the strings.
EDIT: The QfG2 talker system is indeed a precursor to the more modern ones, but it is special as well; it has to support Said strings, for example, and quite some engineering effort was spent on this.
-
But in the QFG1 charsave script, the original that Omer provided had some double-quoted strings (and no including of .th header files). In the compiled script resources, those end up being string tuples, and those strings are in the text resources.
So clearly there was some mechanism other than this TC.exe thing that was used.
-
But in the QFG1 charsave script, the original that Omer provided had some double-quoted strings (and no including of .th header files). In the compiled script resources, those end up being string tuples, and those strings are in the text resources.
So clearly there was some mechanism other than this TC.exe thing that was used.
That's not what I meant. The QfG1 script does not use TC (that I can tell), but does use {} and "". The former strings are stored in the script resource, the latter are automatically put in the text resource. The two approaches are mutually exclusive (you can't use TC if you have a script with the same number, or at least you'd have to be very careful). Also, the weird convention with _ for space is demonstrated (several spaces are folded to one by the compiler, if you really want several spaces you need to use the underscore). This makes it easier to have an string that spans several lines of source, in that you don't have to terminate it because newlines and spaces just get folded as needed.
-
Ok, just a mis-communication. Yes, I know about {} and "", and the underscores. SCI Companion has all that same logic too.
I was just wondering about the process Sierra used to extract the "" strings and stick them in the text resource. Because I've tried the sierra compiler (SC.exe that Omer provided), and I'm pretty sure it didn't do that. Maybe I was using a later version of SC.exe, and that functionality was removed because most stuff moved to message resources?
-
I was just wondering about the process Sierra used to extract the "" strings and stick them in the text resource. Because I've tried the sierra compiler (SC.exe that Omer provided), and I'm pretty sure it didn't do that. Maybe I was using a later version of SC.exe, and that functionality was removed because most stuff moved to message resources?
Sierra used the SCI message extractor tool (XMESSAGE.EXE) to extract double-quoted text strings into text resources.
They used a batch file to go over all the script files, and generated the text files using that tool.
For example:
xmessage c:\ll3\400.sc > F:400.txt
-
xmessage (in conjunction with rmessage) is intended for translation, it is not the main tool for text resource generation (that is, in fact, the compiler; I've checked). What xmessage does, if you look closely, is it generates pairs of original strings and empty strings. You then edit the file, replacing the empty strings with translations and run rmessage, which updates the .SC file with the translated strings.
Finally, the compiler can be run to generate text resources.
-
Thanks Lars! I trust your knowledge in SCI much more than mine! :D
-
Working on supporting the VGA palette adjustments (tint, saturation, lightness, hue) for EGA pics... it certainly doesn't work perfectly for such limited palettes, but it's a start if you want to make a night scene, etc....
-
Pretty cool and useful!
-
There's a recurring issue when pasting images from external sources.
(http://i.imgur.com/RUkX0B7.png)
(http://i.imgur.com/iDOms3U.png)
Interesting, how the key color is involved...
-
I'm not quite sure what I'm looking at...
How are you pasting? Just ctrl-V?
Where are you pasting from? Within Companion or from some external source? If an external source, what happens if you use the import image dialog?
What about if you paste transparent? (ctrl-shift-v)? (actually no, that won't help...)
Also note that if you're pasting from another app, I believe the palette information is lost, so Companion has to re-map the RGB values of the pasted image to the view's palette.
(nice font, btw)
[edit:]
I suspect this is happening because I'm removing the current transparent color from the list of colors we can "map to". I'm not sure I should change that default behavior, otherwise folks will get random transparent parts in the images they paste in...
[edit:]
You can also "paste special" (ctrl-b), which will bring up the dialog that gives you more control. I think you can get this to work if you uncheck "Exclude from palette" in the transparency box. Yeah? (you'll need to uncheck it each time you invoke it, it doesn't remember the setting :-( )
-
Try this:
http://scicompanion.com/Downloads/SCICompanionAlpha.zip
-
"Try again" gives the original unwanted results, "This is OK" is what I want. In fact, it'd always be what I want.
The "external application" in this particular case is Paintshop Pro 8 but that shouldn't matter -- Paint gives exactly the same results, given the same source PNG.
-
Correct, that was the intention.
The external application doesn't matter, but when copy/pasting from within SCI Companion the behavior is a little different since I know the source/target palettes.
-
Still hacking SQ1VGA whenever I get a spare minute, and only two scripts are still giving me trouble in your current build of SCI Companion v3: 700 ('Sarien.sc') and 703 ('RegionFeature.sc').
Compiling either one, while successful, always gives me the warnings "Ignoring public class for export: arcadaRegion" (for Sarien.sc) and "Ignoring public class for export: DeltaurRegion" (for RegionFeature.sc).
Playing with these compiled scripts crashes the game when it attempts to load up any screens on the interior of both the Arcada and the Deltaur. Obviously, neither area can properly function without these classes being properly defined/programmed.
Is there any way to fix this?
EDIT: Here are the script files btw
-
What happens if you make DeltaurRegion and ArcadaRegion instances instead of classes? (That's basically what it's complaining about). Not sure that will work... if not, then the compiler is making incorrect assumptions about what's possible.
-
What happens if you make DeltaurRegion and ArcadaRegion instances instead of classes? (That's basically what it's complaining about). Not sure that will work... if not, then the compiler is making incorrect assumptions about what's possible.
Changing them to instances only produces a string of errors, with the most prominent stating that "Instances can not declare new properties."
-
You can probably work around that by changing the DeltaurRegion definition to DeltaurRegionBase:
(class DeltaurRegionBase of Rgn
... etc..
and then adding an instance of it called DeltaurRegion:
(instance DeltaurRegion of DeltaurRegionBase
(properties)
)
Hmm.... no actually I think that won't work, because lots of other scripts refer to DeltaurRegion directly (which they will no longer be able to do if it's not a class), and they would need to be changed to refer to the instance, which they get by ScriptId.... sigh.... You might be out of luck for now..
At any rate, I guess I need to support exporting classes in the exports section of a script. I feel like I've dealt with this issue before though, and maybe it's an invalid thing to do in some SCI versions.
-
Here, try this out and let me know if it works (compiles and actually runs correctly) for SQ1 VGA:
http://scicompanion.com/Downloads/SCICompanionAlpha.zip
-
At any rate, I guess I need to support exporting classes in the exports section of a script. I feel like I've dealt with this issue before though, and maybe it's an invalid thing to do in some SCI versions.
I think technically you can export anything, even said strings. Never tried it, though.
-
I think technically you can export anything, even said strings. Never tried it, though.
The SCI0 interpreter will crash when calling ScriptID for an exported class.
-
The SCI0 interpreter will crash when calling ScriptID for an exported class.
Not here. I just whipped up a quick script:
(script# 777)
(public
MyClass 0
)
(class MyClass kindof Object
(methods greet)
(method (greet)
(Print {Hello World!})))compiled it with the original compiler and injected it into LSL3. Works fine.
-
I'm sorry, you're right. I had a bug when I tried re-enabling it with my script generation!
-
Looks like it works! Both scripts compile with no errors. I'll take the game through another test run when I get some spare time.
Thanks!
EDIT: Yep, everything checks out.
-
Could somebody explain to me like I'm twelve what the deal is with exporting classes instead of instances?
-
I guess it was used for regions, when you want the region to have extra properties (since instances can't define new properties)
-
I have a feature request: when importing a MIDI file to a sound resource, recognize markers (FF06) and/or cue points (FF07) as such. Perhaps the former could serve to quickly set a loop point, while the latter is obvious from its very name.
Since they're basically Lyrics (FF05) with different semantic value, the signal numbers could be specified in their text values.
-
Doesn't look like it would be too hard to do. Got some midi files that have this information that I could use to test?
I don't really know much about MIDI.
MusicallyInspired, do you have any feedback on this suggestions? The cuepoint thing seems obvious.
For the loop point, doesn't really seem like there's a standard. Is marker a reasonable thing to turn into a loop point?
-
These three events all have the same structure -- FF [05, 06, or 07] [text length] [text], not bound to any particular playback channel like Note On and Program Change are. Attached is a short piece of shit I whipped up that contains all three kinds. In order: cue "up", cue "down", cue "cue" (gasp), cue "larry", and lyric "todokete~".
Funnily, Anvil Studio uses markers for its bookmark-like list labelled "cues".
I'd personally suggest the string "loop", "+n" for cumulative, and just a number for non-cumulative.
(The "cue" cue was supposed to be a "marker" marker but I fucked it up.)
-
I'm afraid I don't know as much about MIDI as I'd like. Sometimes I wish I was born earlier so I would have been forced to learn more than I currently do (which is more in the realm of the digital). I do know that different implementations use different MIDI controllers (CC messages) for cue/loop points and such. In short, no two MIDI interpreters used it the same way. I'd suggest using certain controllers like this to create cue points for SCI sound resources. You can pick any one as long as it's not used by the MT-32 or SC-55 (if you want to retain compatibility with those synths, anyway). There are 128 MIDI controllers. Some are more or less standard and control things like pitch bend range, modulate, reverb and chorus (for the SC-55), etc. It's basically a free range. MIDI was designed that way so different synths could interpret controllers in their own way. The Build engine's EMIDI API (used for Duke Nukem 3D) used MIDI controllers to control cues (specifically CC 116, CC 117, CC 118, CC 119 for Loop Start, Loop End, Global Loop Start, and Global Loop End respectively). Something like this is what would come to me naturally when I think about converting MIDIs to an SCI sound resource.
As for hooking into these controllers and interpreting them in a program, I haven't the foggiest. There must be some information on how MIDI files are setup, though.
EDIT: MIDI controller channels 102-120 are undefined and free to use in a proprietary setup. Here's a list of the standard (http://www.indiana.edu/~emusic/cntrlnumb.html).
-
Hmm, maybe it makes more sense to use the ones Sierra already uses then? I mean, their sound resources are basically just midi files.
-
I still think cue commands make the most sense, tbh. They're standard to boot.
-
What cue commands are you talking about?
-
He's talking about the ff 07 meta event, which is described as Cue Point
Used to include cues for events happening on-stage, such as "curtain rises", "exit, stage left", etc
FWIW, in the Sierra sound resources,
- MIDI CC 96 is a cumulative cue (this is called "Data button increment" in the official MIDI spec, from what I can tell... I guess that kind of corresponds?).
- Program change 127 on channel 15 sets a loop point
- Program change <127 on channel 15 sets a non-cumulative cue point
I guess those last two don't really correspond to anything in "standard MIDI", right?
Are most MIDI composing apps flexible enough to let you create those commands? If so, then I'd rather re-use the same commands that Sierra used.
I mean, it sounds like the midi meta event ff 07 is standard... but I'd be inventing a new standard to parse those into cumulative or non-cumulative cues (or loop points). I guess that's fine if these cue events are commonplace across midi composing apps.
-
FWIW, in the Sierra sound resources,
- MIDI CC 96 is a cumulative cue (this is called "Data button increment" in the official MIDI spec, from what I can tell... I guess that kind of corresponds?).
- Program change 127 on channel 15 sets a loop point
- Program change <127 on channel 15 sets a non-cumulative cue point
Just to be clear, I believe these things are different between SCI versions. It's been a long time since I worked with sound resources, though.
-
sounds resources are my least favorite resource!
-
Ah, sure then. Shows what I know about MIDI. I've just never had to delve into this stuff before. Going off the scattered knowledge I've acquired over the years. Like I said, my main focus has been digital audio and mixing. I just know what I need to know to get that done.
-
If anyone has had issues with undo in the script editor, please let me know if you can figure out a repro.
Occasionally, undo will undo way too much (and so you've essentially lost a granular log of your changes). Really annoying, because you have to basically redo, and then remove the little bits you added recently. I've been trying to track this down, but I don't know how to repro it - it seems to happen randomly.
-
Oh yes, very much so. I have to be real careful when undoing stuff.
-
If you can figure out what causes it, please let us know. It hasn't happened to me at all today, so clearly I'm not doing the right things (or actually doing the right things :P )
-
Well, off the top of my head it just looks like it undoes in too-large chunks. For example, I'd change something over on the top of a file, then scroll down to about midway and change a single character there. Undoing would take that single character and half or more of the earlier block up top.
Perhaps flushing (is that the word?) an undo state when clicking or otherwise changing the caret position (not by changing the text!) would help? In the above scenario, the undo would then only hit the one character in the middle, and leave the block up top for the next hit of Ctrl-Z.
Of course, this is all blind cellphone-in-bed rambling.
-
It's not as simple as that. I tried to diagnose it yesterday, but it was behaving correctly. No matter where I added text, an undo always undid a reasonable amount. The last few characters, the last word, the last thing pasted, etc...
But, I think I may have just found a repro using the find dialog....
-
Ok, looks like the repro is:
- do something
- then click elsewhere in the document and go type a letter (usually you would type a space or hit enter to make a new line or something - at least that 's what I was doing when I was trying to repro it - and when you do that is breaks the ties with the current undo record)
Result, the letter (and subsequent letters) get merged with the previous undo record.
Now I have to figure out how this text editor thingy is actually supposed to work. #notmycode
-
I was going to ask doesn't the control you are using for the script editor manage the undo stack. Sounds like you would need to go through the code for that control. How much work would it be to replace it with another one?
-
It's much easier to just modify it than to replace with another control.
-
I was wondering as I seem to remember that you had mentioned before not being happy with it. Is it still being actively maintained?
-
Yeah, it annoys me, as does anything MFC-related (so, like all of SCI Companion's UI). It's not being maintained. But, that doesn't really matter, I can just make the changes I need to it. And I've made a number of modifications to it to suit SCI Companion's needs, so switching to some other syntax-coloring editor doesn't really make sense.
-
I found out (actually was told by csnover from scummvm) that SCI Companion can open and even decompile SCI2.1 games.
The trick is to rename the resources from resmap.nnn and ressci.nnn to resource.map/nnn.
I tested it on Hoyle 5 (Classic Games) and it worked perfectly.
It would be nice if SCI Companion could support these games natively, but until then renaming the files is a good workaround.
-
Wait what?!
Edit: can confirm, LSL7 doesn't seem to work at all resource-wise, GK2 works for graphics.
-
The trick is to rename the resources from resmap.nnn and ressci.nnn to resource.map/nnn.
How does the naming scheme work? Like, why does the master resource map have a number?
-
How does the naming scheme work? Like, why does the master resource map have a number?
That must be why the GK2 scripts and such were just plain missing -- they'd be listed in RESMAP.001, while I looked in RESMAP.000 :)
-
How does the naming scheme work? Like, why does the master resource map have a number?
That must be why the GK2 scripts and such were just plain missing -- they'd be listed in RESMAP.001, while I looked in RESMAP.000 :)
Actually, they hide in RESSCI.PAT (the corresponding map being RESMAP.PAT) ::)
EDIT: And to answer troflip's question, there is one per CD, and an additional one to copy to the hard drive.
EDITEDIT And .AUD and .SFX volumes too.
-
Haha what the hell :D
-
It would be nice if SCI Companion could support these games natively, but until then renaming the files is a good workaround.
If you mean to open games I agree. If by creating games don't forget that there is no template game beyond 1.1.
-
Wait what?!
Edit: can confirm, LSL7 doesn't seem to work at all resource-wise, GK2 works for graphics.
Don't forget that LSL7 is an SCI3 game.
-
How does the naming scheme work? Like, why does the master resource map have a number?
That must be why the GK2 scripts and such were just plain missing -- they'd be listed in RESMAP.001, while I looked in RESMAP.000 :)
If your game has been concatenated with UniSCI then the map file will be named "RESMAP.000"
-
How does the naming scheme work? Like, why does the master resource map have a number?
That must be why the GK2 scripts and such were just plain missing -- they'd be listed in RESMAP.001, while I looked in RESMAP.000 :)
Actually, they hide in RESSCI.PAT (the corresponding map being RESMAP.PAT) ::)
EDIT: And to answer troflip's question, there is one per CD, and an additional one to copy to the hard drive.
EDITEDIT And .AUD and .SFX volumes too.
Seems like the RESOURCE.AUD and RESOURCE.SFX files are usually the same across all discs.
-
It would be nice if SCI Companion could support these games natively, but until then renaming the files is a good workaround.
If you mean to open games I agree. If by creating games don't forget that there is no template game beyond 1.1.
Of course. My main aim was decompilation.
Regarding the template - I have Sierra's system scripts circa 1995 that I could possibly share eventually. When SCI Companion would be able to handle all the resource types from that era we could use that.
-
It would be nice if SCI Companion could support these games natively, but until then renaming the files is a good workaround.
If you mean to open games I agree. If by creating games don't forget that there is no template game beyond 1.1.
Of course. My main aim was decompilation.
Regarding the template - I have Sierra's system scripts circa 1995 that I could possibly share eventually. When SCI Companion would be able to handle all the resource types from that era we could use that.
:D :D :D
-
Fantastic!
-
Some SCI games (e.g. GK1 CD) have their patched scripts located inside a PATCHES subfolder.
ScummVm is already scanning this folder:
https://github.com/scummvm/scummvm/blob/master/engines/sci/sci.cpp#L159 (https://github.com/scummvm/scummvm/blob/master/engines/sci/sci.cpp#L159)
I believe SCI Companion should do that same.
-
https://github.com/scummvm/scummvm/blob/master/engines/sci/sci.cpp#L159 (https://github.com/scummvm/scummvm/blob/master/engines/sci/sci.cpp#L159)
I believe SCI Companion should do that same.
But as the comment in that code says, doing it unconditionally is not unproblematic. Additional problems might arise in Companion when saving resource volumes (which is a moot point for ScummVM).
-
I thought the patches folder was listed in resource.cfg.
-
I thought the patches folder was listed in resource.cfg.
It is, at least starting with around SCI1.1. I would have to check what interp that flag first appears.
-
https://github.com/scummvm/scummvm/blob/master/engines/sci/sci.cpp#L159 (https://github.com/scummvm/scummvm/blob/master/engines/sci/sci.cpp#L159)
I believe SCI Companion should do that same.
But as the comment in that code says, doing it unconditionally is not unproblematic. Additional problems might arise in Companion when saving resource volumes (which is a moot point for ScummVM).
(for the lazy):
// Add the patches directory, except for KQ6CD; The patches folder in some versions of KQ6CD
// is for the demo of Phantasmagoria, included in the disk
That used to really bug me way back when, when they'd make compilation discs or what have you... they'd just throw all the files into the same root together. I remember that in the QFG Anthology disc... All the games would be in nice little sub-folders, except QFG4CD would just be all there in the root, with it's own subfolders intermixed in there.
-
King's Quest Collector's Series too, IIRC. KQ5w and KQ6w would be annoyingly all clumped together in various ways on disc 2. Plus it didn't include the GITT redbook audio track so the game throws up an error at the end.
-
I thought the patches folder was listed in resource.cfg.
It is. You can parse it if you don't mind the extra work.
Of course, we can workaround this by copying the patches to the root folder. But it's an easy thing to miss when you decompile a game (csnover from scummvm was stumped by this, and this is how I learned of this issue).
-
King's Quest Collector's Series too, IIRC. KQ5w and KQ6w would be annoyingly all clumped together in various ways on disc 2. Plus it didn't include the GITT redbook audio track so the game throws up an error at the end.
I take it that you mean the Collection Series. The Collector's Edition had only 6 (with Redbook Audio track) on the 2nd disc and all of the earlier games on the first disc, including 5 CD and localized floppy 5 & 6 on disc 1.
-
I thought the patches folder was listed in resource.cfg.
It is. You can parse it if you don't mind the extra work.
Of course, we can workaround this by copying the patches to the root folder. But it's an easy thing to miss when you decompile a game (csnover from scummvm was stumped by this, and this is how I learned of this issue).
Colin Snover?
-
Colin Snover?
Yep. One of the most prolific scummvm-sci devs.
-
He is the one who started VOGONS. The current style was originally designed by him and was recreated for phpBB3 by Qbix and myself. He has not been around in years and gave the board to Qbix. Curious that he never seemed to express much interest in the Sierra games at the time.
-
He is the one who started VOGONS. The current style was originally designed by him and was recreated for phpBB3 by Qbix and myself. He has not been around in years and gave the board to Qbix. Curious that he never seemed to express much interest in the Sierra games at the time.
I know he started VOGONS.
I recall he joined scummvm to brush up his C++ skills.
He's working on SCI32 and making great progress; just see the commit history for the SCI engine and see how much of it is his work:
https://github.com/scummvm/scummvm/commits/master/engines/sci (https://github.com/scummvm/scummvm/commits/master/engines/sci)
-
Nice!
-
Think I found a bug. When you copy a pic into a view, some of the colors get changed. Here's a screenshot, notice the cyan pixels on the bridge and the tree have been converted to navy. The pic is room 42 from KQ1. The pic is on the left, view on the right. The copy operation was just a ctrl-c/ctrl-v between the pic editor and the view editor.
I'm using version 3.0.1.7.
-
Looks like teal, not cyan. Teal is usually the transparent color, so that's probably why it's not using it. In the newest (offically unreleased) version, a dialog will come up offering a choice (should be a post about this a few pages back).
In the version you're using, you can using ctrl-b instead, which brings up the paste image dialog, where you can uncheck the "exclude from palette" button in the transparency group.
-
But isn't that a vector image from SCI0?
-
Yes. So what?
-
I thought those had white as their transparant color? And even then only when overlaying on another pic.
Wait, now that I'm properly awake I see the part I missed: "copied into a view." nvm
-
Looks like teal, not cyan. Teal is usually the transparent color, so that's probably why it's not using it. In the newest (offically unreleased) version, a dialog will come up offering a choice (should be a post about this a few pages back).
In the version you're using, you can using ctrl-b instead, which brings up the paste image dialog, where you can uncheck the "exclude from palette" button in the transparency group.
Ctrl-B worked, thank you.
-
Tjhe Coles had a new update and mentioned a new tool they got that sounds like it could be very useful:
Adam immediately started to bring new tools to our development process, such as ways of showing the interaction points for all of the objects in a scene. This is a great way to make sure that every object has a waypoint and that they?re in the right places.
Not sure how such a tool could be implemented in Companion as a plugin. I guess it could look at a room's script to find all of that room's interactions. I guess that it could find the pic and views called from the room script and overlay the views on the pic, but to do that within in Companion and not an external viewer is the main thing I wouldn't know how to implement.
-
It's probably a lot more feasible to do something like that in-game.
-
After thinking about it I was starting to think that, too. Perhaps some thing that could be called like debug and removed from the release version.
-
I've lost sight of the various alpha versions flying around, but I'm using the SCICompanion.exe dated July 20th 2016. When recompiling the decompiled script 998 (original name "ACTOR.SC") of SQ1, the following sequence in Actor.setLoop:
(method (setLoop param1 &tmp theLooper)
(if
(= theLooper
(cond
((== argc 0) (super setLoop:) 0)
((not (IsObject param1)) (super setLoop: param1 &rest) 0)
((& (param1 -info-?) $8000) (param1 new:))
(else param1)
)
)
(if looper (looper dispose:))
((= looper theLooper) init: self &rest)is properly decompiled, but after recompilation, it becomes: (method (setLoop param1 &tmp theLooper)
(if
(= theLooper
(cond
((== argc 0) 0)
((not (IsObject param1)) 0)
((& (param1 -info-?) $8000) (param1 new:))
(else param1)
)
)
(if looper (looper dispose:))
((= looper theLooper) init: self &rest)
)In other words, the "super setLoop" in the first two conds somehow gets lost, which results in the wrong loops being displayed in SQ1's intro. Right now, I am working around this bug by rewriting the code as (method (setLoop param1 &tmp theLooper)
(cond ((== argc 0) (super setLoop:) (= theLooper 0))
((not (IsObject param1)) (super setLoop: param1 &rest) (= theLooper 0))
((& (param1 -info-?) $8000) (= theLooper (param1 new:)))
(else (= theLooper param1))
)
(if theLooper
(if looper (looper dispose:))
((= looper theLooper) init: self &rest)
)
)
The other problem I had was that "Replace all" sometimes would never finish. The last issue is more of a small quibble: When recompiling an existing script that I opened by double-clicking on the resource in the Explorer, the selection in the Explorer is reset to the start after compiling. I understand that recompiling causes the list to be refreshed, but it would be great if the selection could stay on the resource on which it was before the list is refreshed. Otherwise, SCI Companion works great for me.
If I may request an additional feature: the ability to produce a RESOURCE.TXT file from an existing set of RESOURCE.* packages, so I can use it with Sierra's MAKEVOLS to repackage a changed game with compression. This could be implemented as an option in the "Extract all resources" window. I have, more or less manually, written a file for SQ1 that MAKEVOLS will accept (http://symphoniae.com/nrs/sciprogramming/RESOURCE.TXT) and yields identical RESOURCE.* files to the released game when fed with extracted unmodified resources.
-
The scummvm team found that SCI32 changed its handling of zero-offset exports: https://github.com/scummvm/scummvm/commit/55222ec (https://github.com/scummvm/scummvm/commit/55222ec)
SV and SciCompanion are both affected by this change.
You can see this in Space Quest 6, where in rm500.sc sEndChapter1::changeState(6) is calling __proc64909_0 (originally ShakePlane) but the 64909 script has "export64909_0 = $0" (in SV) and the procedure is not detected and decompiled.
EDIT:
I have added this issue and the previous ones reported by NewRisingSun to the project's github page: https://github.com/icefallgames/SCICompanion/issues
I hope it'll help you track it.
-
He is the one who started VOGONS. The current style was originally designed by him and was recreated for phpBB3 by Qbix and myself. He has not been around in years and gave the board to Qbix. Curious that he never seemed to express much interest in the Sierra games at the time.
I know he started VOGONS.
I recall he joined scummvm to brush up his C++ skills.
He's working on SCI32 and making great progress; just see the commit history for the SCI engine and see how much of it is his work:
https://github.com/scummvm/scummvm/commits/master/engines/sci (https://github.com/scummvm/scummvm/commits/master/engines/sci)
Just noticed that snover has just registered here.
-
He is the one who started VOGONS. The current style was originally designed by him and was recreated for phpBB3 by Qbix and myself. He has not been around in years and gave the board to Qbix. Curious that he never seemed to express much interest in the Sierra games at the time.
I know he started VOGONS.
I recall he joined scummvm to brush up his C++ skills.
He's working on SCI32 and making great progress; just see the commit history for the SCI engine and see how much of it is his work:
https://github.com/scummvm/scummvm/commits/master/engines/sci (https://github.com/scummvm/scummvm/commits/master/engines/sci)
Just noticed that snover has just registered here.
Yes, I asked him to. I urged him to report his bugs with SCI Companion, but ended up reporting them before he got to do it himself.
-
Just noticed that the 'while' keyword isn't highlighted in the script editor as a keyword (like 'do'). Probably already fixed, but thought I'd point it out in case it got overlooked.
-
So earlier today I was working on a new 2017 version of the Dating Pool demo, replacing some renders, the iconbar, and adding shadows to views and such. I found out that SCI Companion 3.1.0.3 doesn't compile things quite right. The iconbar's verb buttons wouldn't actually select their respective verbs (so you gotta right-click cycle instead) and the glint on the Firrhna Productions logo insisted on using loop 1 instead of 0, so it was a big ol' "DEMO" instead. Version 3.0.1.5 meanwhile, given exactly the same inputs, does not result in these issues.
Much like gumby said, this is probably already fixed, considering there's been a whole lotta commits since then, but I've no way to compile my own. Just thought it was an interesting thing to mention.
Fake edit: just downloaded 3.0.1.7 and recompiled, it started some time after.
Real edit: script 937 "IconI" has many differences. If anybody wants a copy...
Update edit: http://helmet.kafuka.org/sci/937.html -- some bnot are missing, and IconI::select and IconBar::select have large parts missing.
-
Okay, so I compiled my own from the latest git. On the one hand, the compiler seems to be fixed. On the other, the thing crashes when I try to open a picture resource with an associated shp file, on Polygon.cpp line 507. Because on line 80, "it" is apparently empty so pValue is null.
-
Thanks for finding this (Beta tester ;-) )
Fixed:
https://github.com/icefallgames/SCICompanion/commit/99a2b38f462f54a0331b064c8a0e71f2756d9f90
-
I'm sure there will be other bugs,as I haven't done too much testing with SCI1.1 (which is why I haven't officially released it yet).
In particular, "Game properties"->"MAnage resources as patch files (good for source control)" doesn't work with SCI1.1.
Most of the new features involve SCI0 pics, but there is some new functinoality in views:
- you can shift a view's pixels up, down, left, right (I think SCI Studio even offered this!)
- you can rotate a view by any amount
- you can enable "onion skins" to see ghosts of the previous or next cel, to make animation easier
If you make your views in some external program though, then these aren't that useful.
You can "Extract all script strings" to make spell-checking easier.
-
So I'm looking at a few SCI0 games in the latest SCI Companion and testing the EGA undither switch when...
owo what's this?
(http://i.imgur.com/MhjRIBI.png)
...oh!
(http://i.imgur.com/Gl1Keom.png)
And so, the downside of EGA undithering comes to light -- it doesn't work on manual dithers like the above and certain babe portraits in the Larry games? :)
I have a patch for this particular file to enhance the undither effect a bit, because I'm me and I am a bored me (http://helmet.kafuka.org/sci/dumb/Iceman%20undither%20enhancement%20test.061).
? not to mention their eyes and such, being sprites, are never undithered so that looks real weird in practice.
-
And so, the downside of EGA undithering comes to light -- it doesn't work on manual dithers like the above and certain babe portraits in the Larry games? :)
I don't think I've ever seen results this bad in FreeSCI, FWIW.
-
That Iceman pic isn't a problem with undithering per se, it looks like it just has a bug in it... they left the visual screen on when drawing the zig zag priority lines, and happened not to notice because the blue color lined up with the dither pattern (they also missed a fill spot behind the plant on the center left!). Not sure how FreeSCI would fix that...
SQ3 has some undither issues, like the scene with Roger's head and the window light shining on it.
-
SQ3 has some undither issues, like the scene with Roger's head and the window light shining on it.
That'd be because the part you seem to refer to isn't a fill, but individual lines.
(http://i.imgur.com/Cqh3ADw.png)
Much like how this uses a ton of pen dots. And again, even the portraits that don't hand-dither like LSL3's 435 end up looking weird because views as face parts.
-
I have a persistent issue with pasting graphics that has finally gone too far to ignore.
This (https://i.imgur.com/rU2DWlR.png) is the new closeup for Alhor[/url] in The Dating Pool. I imported this, then extracted the actual palette for use in Paintshop. I applied this exact same palette to the separately-cut out mouth and eye frames, and copy-pasted them back into SCI Companion.
Look closely. (https://i.imgur.com/ybpUQwl.png) See how the white part around his mouth is redder than the rest? How there's bits of global palette in his nose? The same thing happens with the eyes, turning them from olive to brown and making the blink look particularly as if there's only 32 or so colors.
Even though I guarantee you every single RGB value in that source pic I'm pasting is in the actual, current palette.
I have a worse example, (https://i.imgur.com/M0bHXYA.png) (palette included for illustrative purposes towards Letrune) but I can't bear to link to the version with the sprite on. Suffice to say it comes out looking so bad.
-
You didn't describe your exact workflow, so it's hard to know what the problem might be.
What options did you use for mapping the palette? Where are your images from? Paintshop? SCI Companion? In-game?
What does SCI Companion tell you about the palette indices that ended up being used for the view?
What happens if instead of pasting the image into Companion, you save it to a indexed-palette file (e.g. gif) and import it that way? A lot is lost when pasting images through the clipboard (transparency for one, and probably the 8-bit-ness too).
Can you post a comparison of how it looks in Paintshop vs how it looks in Companion vs how it looks when you paste it into another app (e.g. mspaint)
I tried importing your image into a pic, then copying the resulting palette into a view.
Then I pasted the image into photoshop and cropped it down to the mouth and nose. Then I pasted that into the view, choosing to map it to the custom part of the palette. Looks identical to me.
-
Motherfucker I used palette 141 instead of 121!
Curse my bad memory and Paintshop's color picker not being 16x16.
(http://i.imgur.com/KFIX9hu.gif) <- Fake Ego preview
-
Feature request. Import CUR and ICO files as VIEWs (or CURSORs in SCI0/1 games maybe?).
-
A question about the Documentation. Is this section in Sierra Script or Studio Script? Because my room is not compiling with the given code.
http://scicompanion.com/Documentation/Tutorial/RoomBackground.html#some-static-objects-with-canned-responses (http://scicompanion.com/Documentation/Tutorial/RoomBackground.html#some-static-objects-with-canned-responses)
-
I think that's Studio.
-
Managed to Sierra Script-ify idea. I thought there were two different versions of the documentary, though. One entirely in Studio Script and one entirely in Sierra Script?
-
Feature request. Import CUR and ICO files as VIEWs (or CURSORs in SCI0/1 games maybe?).
If you have another program that can view them, you should just be able to copy paste into a view in SCI Companion (assuming that program can copy an image onto the clipboard).
I thought there were two different versions of the documentary, though. One entirely in Studio Script and one entirely in Sierra Script?
Not that I recall...
-
If you have another program that can view them, you should just be able to copy paste into a view in SCI Companion (assuming that program can copy an image onto the clipboard).
Indeed. I can and did for ICO files, but for some reason GIMP will not open the CUR files I'm trying to access. I had to use an online converter to convert them to BMP first. Must be an old version of CUR files or something. So I've found a way for now anyway.
Either way, the functionality would be welcome, similar to the ability to import TTF fonts as FONT resources.
Not that I recall...
Must be thinking of something else then.
-
View editor won't save a new hotspot location if that's the only change made to a view. Open an existing view, move the hotspot, save the view. Open the view back up, hotspot is in previous location. Simple workaround is just to edit a pixel, then the hotspot will be saved.
Running version 3.0.1.7
-
Found minor bug (v. 3.1.0.3). When creating a new room (File->New->New Room), the public variable for the room gets created twice:
Example:
...
(use System)
(public
rm800 0
rm800 0
)
(instance rm800 of Room
...
-
Here's a silly thing: in the template scripts for SCI32, class property lists have type specifiers.
(class Cursor kindof Rectangle
;;; The Cursor class is an object used to control the user's cursor.
(properties
int top 0
int left 0
int bottom 200
int right 320
id client 0
int view 0
int loop 0
int cel 0
int x 0
int y 0
int hotX -1
int hotY -1
)These seem to be optional, since some classes don't have them, and they were probably just warning-raising hints for SC so you don't assign a number to a pointer (except for NULL) and vice-versa. The only types I've noticed so far are int and id, which also takes {strings}.
Personally, I'd go with a third type, str.
Another thing you can find is this:
(class ScreenDialog of Dialog
;;; This is a windowless Dialog that represents the screen.
(properties
name: "screen"
)This can be combined, too:
(class VirtualRoom kindof Room
(properties
id name: "VirtualRoom"
-
Here's a silly thing: in the template scripts for SCI32, class property lists have type specifiers.
SCI3 incorporates some similar information in the script format (.CSC). When I wrote the script loader for SCI3 scripts I had to come up with some way to distinguish the selector types - property/method/nothing - since ScummVM needs more information at runtime than SSCI. There is an algorithm in the ScummVM source that doesn't have a counterpart in SSCI; it came originally from a disassembler I wrote, and I let ScummVM have it.
EDIT: Also, it looks like LSCI scripts (TSN/INN); the SCI32 scripts I have don't show this particular quirk. I figured the flag mentioned above was computed by the compiler since it does have access to that information.
-
Right now, I'm sitting on a hack that lets things like SQ4's status line decompile nicer:
(switch gTimePeriod
(1
(StrCat @temp1 {\1B - The Sarien Encounter})
)
(3
(StrCat @temp1 {\1C - The Pirates of Pestulon})
)
(4
(StrCat @temp1 {\1A - Roger Wilco and The Time Rippers})
)
(10
(StrCat @temp1 {\1E - Latex Babes of Estros})
)
(12
(StrCat @temp1 {\1D - Vohaul's Revenge \1F})
(= temp0 global148)
)
)See what it did there?
It's a pretty bad hack -- I couldn't be arsed to figure out how to do this in the correct way, but the results pan out.//in OutputCodeHelper.cpp
std::string EscapeString(const std::string &src)
{
std::string result;
for (char ch : src)
{
char escaped = 0;
//KAWA: escape unprintables because many aren't in practice
if (ch < ' ')
{
result.push_back('\\');
result.push_back("0123456789ABCDEF"[(ch >> 4) & 0x0F]); //ugleh
result.push_back("0123456789ABCDEF"[ch & 0x0F]);
continue;
}
switch (ch)
Somehow, \0A roundtrips into \n but that's perfectly okay. That's great, actually.
-
When testing the decompiler on QFG1EGA (1.200), QFG1VGA, QFG2 (1.102), and LSL1VGA (2.0) (all from GOG), immediately recompiling the resulting scripts caused some errors. Here are the logs:
QFG1EGA compile log
Warning: (TownOverlook.sc) Duplicate case values. Already encountered a case for '3' Line: 580, col: 4
Warning: (Antwerp.sc) Duplicate case values. Already encountered a case for '18' Line: 1084, col: 4
Warning: (TownOutlook.sc) Duplicate case values. Already encountered a case for '65' Line: 168, col: 4
Warning: (EndGame.sc) Duplicate case values. Already encountered a case for '13' Line: 1056, col: 4
Warning: (EndGame.sc) Duplicate case values. Already encountered a case for '14' Line: 1059, col: 4
Warning: (EndGame.sc) Duplicate case values. Already encountered a case for '15' Line: 1062, col: 4
Error: (CharSave.sc) Unknown class 'gamefile_sh' . Line: 64, col: 9
Error: (CharSave.sc) Unknown type 'gamefile_sh' Line: 94, col: 6
Error: (CharSave.sc) Unknown type 'gamefile_sh' Line: 101, col: 9
Error: (CharSave.sc) Unknown type 'gamefile_sh' Line: 102, col: 6
Error: (CharSave.sc) Unknown type 'gamefile_sh' Line: 105, col: 39
Error: (CharSave.sc) Unknown type 'gamefile_sh' Line: 110, col: 14
Error: (CharSave.sc) Unknown type 'gamefile_sh' Line: 161, col: 5
Error: (CharSave.sc) Unknown type 'gamefile_sh' Line: 162, col: 5
Error: (CharSave.sc) Unknown type 'gamefile_sh' Line: 166, col: 6
Error: (CharSave.sc) Unknown type 'gamefile_sh' Line: 169, col: 5
Error: (CharSave.sc) Unknown type 'gamefile_sh' Line: 170, col: 5
Error: (Actor.sc) Undeclared identifier '--UNKNOWN-PROP-NAME--' . Line: 570, col: 16
291 scripts compiled.
--------------------------------
Time elapsed: 5.42 seconds.
QFG1VGA compile log
Error: (Forest-43.sc) &rest cannot be used if the send target itself contains nested procedure calls or sends. Assign the result of the procedure call or send to a temporary variable and use that instead. Line: 56, col: 27
Error: (WizardGame.sc) Duplicate label 'code_0448' Line: 145, col: 0
Error: (WizardGame.sc) Duplicate label 'code_0453' Line: 152, col: 0
Error: (RTRandCycle.sc) modeless is a property. Only one parameter may be supplied. Line: 525, col: 13
Warning: (HermitCave.sc) Duplicate case values. Already encountered a case for '50' Line: 235, col: 4
Error: (inputBox.sc) Undeclared identifier '--UNKNOWN-PROP-NAME--' . Line: 1262, col: 32
Error: (egoFight.sc) Undeclared identifier '--UNKNOWN-PROP-NAME--' . Line: 330, col: 32
Error: (TownOutsideBar.sc) &rest cannot be used if the send target itself contains nested procedure calls or sends. Assign the result of the procedure call or send to a temporary variable and use that instead. Line: 416, col: 29
Error: (TownOutsideBar.sc) &rest cannot be used if the send target itself contains nested procedure calls or sends. Assign the result of the procedure call or send to a temporary variable and use that instead. Line: 419, col: 29
Error: (TownOutsideBar.sc) &rest cannot be used if the send target itself contains nested procedure calls or sends. Assign the result of the procedure call or send to a temporary variable and use that instead. Line: 551, col: 29
Error: (TownOutsideBar.sc) &rest cannot be used if the send target itself contains nested procedure calls or sends. Assign the result of the procedure call or send to a temporary variable and use that instead. Line: 554, col: 29
Error: (TownOutsideBar.sc) &rest cannot be used if the send target itself contains nested procedure calls or sends. Assign the result of the procedure call or send to a temporary variable and use that instead. Line: 595, col: 29
Error: (TownOutsideBar.sc) &rest cannot be used if the send target itself contains nested procedure calls or sends. Assign the result of the procedure call or send to a temporary variable and use that instead. Line: 598, col: 29
Error: (TownOutsideBar.sc) &rest cannot be used if the send target itself contains nested procedure calls or sends. Assign the result of the procedure call or send to a temporary variable and use that instead. Line: 748, col: 29
Error: (TownOutsideBar.sc) &rest cannot be used if the send target itself contains nested procedure calls or sends. Assign the result of the procedure call or send to a temporary variable and use that instead. Line: 751, col: 29
Warning: (Forest.sc) Duplicate case values. Already encountered a case for '4' Line: 1661, col: 5
235 scripts compiled.
--------------------------------
Time elapsed: 3.97 seconds.
QFG2 compile log
Warning: (rm130.sc) Duplicate case values. Already encountered a case for '54' Line: 1023, col: 5
229 scripts compiled.
--------------------------------
Time elapsed: 4.50 seconds.
LSL1VGA compile log
Error: (DiscoExterior.sc) z is a property. Only one parameter may be supplied. Line: 339, col: 6
Error: (DiscoExterior.sc) z is a property. Only one parameter may be supplied. Line: 345, col: 6
Error: (CasinoEvesBedroom.sc) z is a property. Only one parameter may be supplied. Line: 562, col: 92
Error: (CasinoEvesBedroom.sc) z is a property. Only one parameter may be supplied. Line: 563, col: 36
78 scripts compiled.
--------------------------------
Time elapsed: 1.54 seconds.
-
A lot of those are bugs in the game scripts. "Duplicate case values", or "blah is a property only one parameter may be supplied." Fixes can be made to the code so it compiles correctly and doesn't affect gameplay.
Some are limitations in the decompiler (&rest cannot be used...) where the code needs to be restructured.
The rest are probably bugs in the decompiler I guess? The gamefile_sh thing is familiar...
-
gamefile_sh is a File that messes up a bit because it has name "gamefile.sh" in its properties. You could do the neat thing and rename the class in script 996 to File, then just find all uses of gamefile_sh and adjust them too.
-
As mentioned on Twitter and related to the above post, my SCI Companion now has special handling for the File class. Assuming script 996 is always File.sc and Class_996_0 is File, it'll notice if it's that or gamefile_sh and call it File after all.
I also found a feature buried in Phil's experimental branch (among various nefarious features involving his own engine fork) that I copied into my own that I particularly like: Shrinkwrap Cel. This does exactly what it sounds like, cropping the blank edges off and adjusting the offset to match. Enable "affect all" and go to town!
Next in my plan list is finding and massaging Display calls to not have magic numbers all over. So, having (Display "foo" dsCOORD 8 16 dsCOLOR 14) instead of (Display "foo" 100 8 16 102 14).
Anyway, do you guys want a copy of that now or after I try to do that thing? If so do you want my personal hacks included? These include and are limited to¹ not having a 256-character limit on fonts (also affects view loops so watch out?), hardcoding a bunch of global variables², showing hex numbers instead of decimals in the font editor, pretending Studio syntax isn't a thing, and (mostly for my own sanity) not nagging about pasted images including the key color.
¹: These are the ones I can easily disable via defines. Others include strings with control characters being escaped, and the font preview panel being at 2x zoom instead of 3x.
²: This should and will be wrapped in a define, as will the File class thing after a bit more study. Shrinkwrapping will not.
-
I wish you could get past your differences with GIT. It would make tracking your additions it easier.
-
Another idea:
You could make a new section in the decompiler.ini file (read by DecompilerConfig.cpp) and read default global variable names from there (if you can tolerate the library I use to read ini files - it's a bit verbose and weird and whomever wrote it liked shared_ptr way too much). That way you can change the variable names without needing to recompile SCI Companion.
-
I have no issues with Git as a whole. My issue is that I've never managed to push anything because lolkeys. So it's Mercurial or nothing.
The ini file is a good call, but I'd like to confirm more entries and maybe version-specific differences first.
-
hardcoding a bunch of global variables
Oooh, that's a feature I like the sounds of. That sounds like it would be easy enough, with a bit more research. Sierra was a business, so it wouldn't make sense for them to make drastic changes from one version to the next, just incremental ones. From the SCI16 files OmerMor shared long ago, they originally defined the first 50 variables as global variables reserved for the system classes.
From the CLASS.TXT documentation:
Script Classes for Adventure Games
Author: Jeff Stephenson
Date: 5 April 1988
<snip>
Global Variables
Global variables 0 through 49 are reserved for use by the system classes.
Game-specific global variables start at 50. The following global variables
are defined by the system.
ego
The ID of a static instance of class Ego defined in game.sc. This is
the protagonist of the game.
curRoom
The ID of the current Room.
userFont
The number of the font to be used in Print statements, etc. Default is
1. Set it to the font you wish to use in the init: method of your
Game, or change it at will in the game.
cast
The ID of a Set of Actors and Egos which constitutes the characters on
the screen.
quit
The main loop of the game is
(while (not quit)
(theGame doit:)
(Wait speed)
)
so setting quit to TRUE breaks out of the main loop and terminates the
game.
addToPics
A Set of PicViews which have been added to the current picture.
debugOn
A generic debugging flag. I usually have a Debug menu item to set it,
and trigger any debug display that I want off of it, rather than
creating a special trigger whenever I want to debug something.
sounds
The Set of Sounds currently playing.
inventory
The ID of the Inventory class or instance which is the Set of all
InvItems (inventory items) in the Game. Inventory related issues are
not well defined yet...
theGame
The ID of the Game instance.
regions
The Set of Regions currently in effect.
curRoomNum
The number of the current Room.
prevRoomNum
The number of the previous Room. (So you know how you got where you
are.)
newRoomNum
Used by a Room to signal to the Game that it should change to a new
Room.
showStyle
The global style for the transition from one picture to another. This
may be overridden by the style property of a given room. See the
DrawPic kernel function for the possible styles.
overRun
The number of timer ticks more than the Game's speed which it took to
complete the last animation cycle. A non-zero overRun means that the
system is not keeping up.
However, that was the original documentation... by Hero's Quest 1 they'd expanded that to 100 variables, and the order had changed from their original documentation, and that was just 1989.
Here's the global names as best as I was able to determine them when I was was remastering the HQ1 source. Some that I flag as unused are really because they're part of an array, like curSaveDir... I left them as individual variables because I kept hitting a bug if I tried to decompile from scratch with arrays in just the sco files.:
(local
;system-defined global variables
ego ;pointer to ego (original SSCI name)
theGame ;ID of the Game instance (original SSCI name)
curRoom ;ID of current room (original SSCI name)
gNewSpeed = 6 ;CI: used for overRun speed testing.
quit ;when TRUE, quit game (original SSCI name)
gCast ;cast ;The ID of a Set of Actors and Egos which constitutes the characters on the screen.
gRegions ;regions ;The Set of Regions currently in effect.
gTimers ;timers ;list of timers in the game
gSounds ;sounds ;set of sounds being played
inventory ;set of inventory items in game (not used in Hero's Quest)
gAddToPics ;addToPics ;list of views added to the picture
curRoomNum ;current room number
prevRoomNum ;previous room number
newRoomNum ;number of room to change to
debugOn ;generic debug flag -- set from debug menu
score ;the player's current score
possibleScore ;highest possible score
showStyle = 7 ;The global style for the transition from one picture to another. This
;may be overridden by the style property of a given room. See the
;DrawPic kernel function for the possible styles.
overRun ;The number of timer ticks more than the Game's speed which it took to
;complete the last animation cycle. A non-zero overRun means that the
;system is not keeping up.
theCursor ;the number of the current cursor
normalCursor = ARROW_CURSOR ;number of normal cursor form
waitCursor = HAND_CURSOR ;cursor number of "wait" cursor
userFont = USERFONT ;font to use for Print
smallFont = 4 ;small font for save/restore, etc.
lastEvent ;the last event (used by save/restore game)
modelessDialog ;the modeless Dialog known to User and Intrface
bigFont = USERFONT ;large font
global27 = 12 ;CI: unused, unknown purpose
version = {ego} ;pointer to 'incver' version string
; WARNING! Must be set in room 0
; (usually to {x.yyy } or {x.yyy.zzz})
theDoits ;list of objects to get doits each cycle
curSaveDir ;current save drive/directory string [20 chars long]
global31 ;unused
global32 ;unused
global33 ;unused
global34 ;unused
global35 ;unused
global36 ;unused
global37 ;unused
global38 ;unused
global39 ;unused
global40 ;unused
global41 ;unused
global42 ;unused
global43 ;unused
global44 ;unused
global45 ;unused
global46 ;unused
global47 ;unused
global48 ;unused
global49 ;unused
animationDelay = 10 ;
perspective ;player's viewing angle: degrees away
; from vertical along y axis
gFeatures ;features ;locations that may respond to events
gSFeatures ;CI: saidFeatures?
useSortedFeatures ;enable cast & feature sorting? (default is FALSE)
isDemoGame ;enabled if this is a game demo, and not a full game.??
global56 ;unused
overlays = -1
doMotionCue ;a motion cue has occurred - process it
systemWindow ;ID of standard system window
global60 = 3 ;unused/unknown
defaultPalette
modelessPort
global63 ;unused
global64 ;unused
global65 ;unused
global66 ;unused
global67 ;unused
global68 ;unused
global69 ;unused
global70 ;unused
global71 ;unused
global72 ;unused
global73 ;unused
global74 ;unused
global75 ;unused
global76 ;unused
global77 ;unused
global78 ;unused
global79 ;unused
global80 ;unused
global81 ;unused
global82 ;unused
global83 ;unused
global84 ;unused
global85 ;unused
global86 ;unused
global87 ;unused
global88 ;unused
global89 ;unused
global90 ;unused
global91 ;unused
global92 ;unused
global93 ;unused
global94 ;unused
global95 ;unused
global96 ;unused
global97 ;unused
global98 ;unused
global99 ;unused
Assuming script 996 is always File.sc and Class_996_0 is File, it'll notice if it's that or gamefile_sh and call it File after all.
That's probably a safe assumption. From another file from OmerMor, SYSTEM.SH:
;;;;
;;;; SYSTEM.SH
;;;;
;;;; (c) Sierra On-Line, Inc, 1992
;;;;
;;;; Author: Unknown
;;;;
;;;; This is the header file for the SCI system
;;;;
;;;; Last Updated:
;;;; Brian K. Hughes
;;;; August 19, 1992
(include kernel.sh) ;kernel external declarations
;ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
;º º
;º Module Defines º
;º º
;ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
(define SYSTEM 999)
(define ACTOR 998)
(define MENU 997)
(define USER 996)
(define INVENT 995)
(define GAME 994)
(define FILE 993)
(define MOTION 992)
(define JUMP 991)
(define SAVE 990)
(define MUSIC 989)
(define EGO 988) ; was EXTRA
(define GAUGE 987)
(define ORBIT 986)
(define FLAGS 985) ; was AVOIDER
(define REGPATH 984) ; was SORTCOPY
(define PATH 983)
(define SIGHT 982)
(define WINDOW 981)
(define TUTORIAL 980) ; was TEXTRA
(define UNUSED_4 979) ; was MOUSER
(define GCONTROL 978)
(define GROOPER 977)
(define CAT 976)
(define SCALETO 975) ; was DEMO
(define NAMEFIND 974)
(define TIMER 973)
(define CHASE 972)
(define FOLLOW 971)
(define WANDER 970)
(define REVERSE 969)
(define SMOOPER 968)
(define DCICON 967)
(define SORT 966)
(define COUNT 965)
(define DPATH 964) ; will be merged into PATH
(define RELDPATH 963) ; will be merged into PATH
(define UNUSED_7 962) ; was QSCRIPT
(define STOPWALK 961)
(define UNUSED_8 960) ; was TIMEDCUE
(define QSOUND 959)
(define LOADMANY 958)
(define UNUSED_10 957) ; was LASTLINK
(define FORCOUNT 956)
(define TRACK 955)
(define DOOR 954) ; was GOTOSAID
(define APPROACH 953)
(define LOGGER 952)
(define MOVEFWD 951)
(define FEATURE 950)
(define BLOCK 949)
(define WRITEFTR 948)
(define DLGEDIT 947) ; was DELAYEVT
(define POLYGON 946)
(define POLYPATH 945)
(define FILESEL 944)
(define POLYEDIT 943)
(define MOVECYC 942)
(define RANDCYC 941)
(define UNUSED_11 940) ; was PRINTD
(define OSC 939)
(define RANGEOSC 938) ; was PCYCLE
(define ICONBAR 937)
(define BORDWIND 936)
(define SCALER 935)
(define SLIDEICON 934)
(define PMOUSE 933)
(define PFOLLOW 932) ; was LANGUAGE
(define CDACTOR 931)
(define PCHASE 930)
(define SYNC 929)
(define TALKER 928)
(define PAVOID 927)
(define FLIPPOLY 926)
(define CONV 925)
(define MESSAGER 924)
(define INSET 923)
(define DIALOG 922) ;Contains DIcon, DButton, DEdit, DSelector, Controls
(define PRINT 921) ;Front-end for dialogs
(define INTRFACE 255)
Okay, that was a much bigger info-dump that I intended... and a bunch of stuff that's probably not news, either.
Oooh, now that I think about it, Folder support would be a really neat feature. You could put all the 900-scripts into a system folder, and put game scripts into a game folder to make organization easier.
-
I actually did (still do) my own studies, using system.sh and comparing the globals it lists to what the games actually use.
From global 27 on, things get a little wobbly between SCI0 games (defined here as non-multilanguage, EGA with parser), and all the others. gVersion is global 28 in SCI0, but it's global 27 in all the others up to at least SCI16 (that is, the one OmerMor released and that I'm hacking, don't @ me). From there, it gets difficult to pin down, so the highest-numbered global I'm willing to pin down is global 26, gBigFont.
...At least with SCI2 the only difference in that set is that global 10 gAddToPics is now gPlanes, so if can tell from _GetGlobalVariableName which engine we're talking about I can at least handle that ;D
-
I actually did (still do) my own studies, using system.sh and comparing the globals it lists to what the games actually use.
Sorry, I didn't mean to imply you haven't researched it... I got overeager to contribute.
From global 27 on, things get a little wobbly between SCI0 games
Pity. :(
I've had an idea for a while now to decompile a bunch of the SCI0 and SCI01 games, then do some automated cross-comparisons against the system-level scripts to what changes if any existed between games, but it hasn't been a priority for me. There are, what, 10 classic SCI0/01 games? Have you done that kind of comparison before, yourself?
-
I'd love to document those changes myself, and since I am unbelievably bored and gifted with an immense amount of free time to waste, I probably wouldn't even automate it. Last time I did automate something, it was extracting and analyzing all the fonts to see how many of them had how many characters in them (128 for American, 226 for European because ß is #225 in Codepage , very very few 256).
-
I've set up three build targets -- Release, which is as I described earlier; Kawa, with all of my hacks defined in; and Mild, with only a few, namely taking forced script names from decompiler.ini, massaging the Display command's parameters, the hardcoded globals (yet to be listed in decompiler.ini), and renaming script 993 class 0 to "File". It does not include hex numbers in the font editor, fonts with more than 256 characters, the lack of Studio support, or the lack of transparency paste nagging.
This'll make it pretty easy for me to keep my own copy and the public release in the stash separate. In fact, have a new Mild build right now! http://helmet.kafuka.org/sci/SCICompanion.exe
To use the new script name override feature, put this in decompile.ini:[kawaForcedScriptNames]
0 = "Main"
993 = "File"
Yeah, even Main's no longer hardcoded.
-
This build can't call the game properties dialog.
-
So it can't. I'm on it.
Found the problem. Mild compiles aren't supposed to define KAWA_NOSTUDIO in the resource file, so the dialog template and the code didn't agree, trying to set up the items for a dropdown that didn't exist. Uploaded a fixed and tested version to the same place, in place.
Also, I can't quite figure out the ini thing, so I'm keeping the global variable names as I originally implemented them... for now.
-
One minor thing. Ticking the "Select All" box in the decompiler dialog does not select all of the scripts. When tou
hit the decompile button it says that no scripts have been selected and then ask if you want to decompile all.
-
Can't reproduce.
I open the SCICompanion.exe specifically from the site, load a random game (Castle of Dr. Brain), open the decompiler. I observe no scripts are selected. I click "Select All" and observe that all of the items in the list get a gray background (not blue, because the focus is on the checkbox). I click "Decompile", and it decompiles all the scripts. Several times because that option was also enabled.
-
I got what I assumed is your latest build and it stopped doing this, so it must have been from an earlier build. It seems to be OK now.
-
Heads up, when I said "several times" I apparently meant "until I unchecked that option in the middle of a run because of a weird interaction with my global vars name thing".
-
As mentioned on Twitter and related to the above post, my SCI Companion now has special handling for the File class. Assuming script 996 is always File.sc and Class_996_0 is File, it'll notice if it's that or gamefile_sh and call it File after all.
Astro Chicken names script 993 as File.sc with you build. the only error is "Error: (Main.sc) Unknown class 'gamefile_sh' . Line: 759, col: 9"
-
Right, forget that feature then. Between that and the endless redeco loop I encountered it might be better to just not enable those hacks.
-
So apparently there's a bug where expressions like (+= [array someThing] 5) don't compile right. This has been fixed in the latest Experimental-branch commit, and I just integrated it in my own builds.
New MILD release: http://helmet.kafuka.org/sci/SCICompanion.exe (http://helmet.kafuka.org/sci/SCICompanion.exe)
Included hacks: some vocab resource preview stuff, Display argument massaging.
Not included: the globals and script names thing... and the latest compiler feature, the &exists keyword. If you want the ability to say (if (&exists someParm) ...) instead of (if (>= argc 2), let me know.
-
I wish you could get past your differences with GIT. It would make tracking your additions it easier.
I don't know if this influences anyone's decisions to use it one way or the other, but I've just learned today that Github was purchased by Microsoft for $7.5 billion. The co-founder has already stepped down.
-
I don't know if this influences anyone's decisions to use it one way or the other, but I've just learned today that Github was purchased by Microsoft for $7.5 billion. The co-founder has already stepped down.
GitHub is not Git. Just sayin'.
-
Oh. Please ignore my ignorance.
-
there are other GIT services. All of my stuff is on Bitbucket.
-
Well, gentlepeople, I hope you're happy. Despite previous experiences with keys and shit, I found a way to git Git to work.
Which means yes, my horrible, horrible changes (https://github.com/Kawa-oneechan/SCICompanion) are now exposed to all the world.
-
Thanks for that.
-
If you were to look at a random polygon-using Sierra game's decompilation, you'd see something like this.
(method (init)
(gRoom addObstacle:
((Polygon new:)
type: 2
init: 150 108 114 115 ...... 187 80 191 102
yourself:)
)
)
(super init:)
...
)That's quite unlike what a Companion game would have.
; from (include 200.shp)
(local
[P_Default200 29] = [1 PBarredAccess 13 150 108 114 115 ...... 187 80 191 102]
)
(method (init)
(AddPolygonsToRoom @P_Default200)
(super init:)
...
)Especially when you consider that the resulting bytecode is nothing alike, and the raw polygon data remains in the heap throughout the room's lifetime as locals. And you get a limit on how many points you can have under a single name.
In that light, I've been sitting on an idea that I implemented this morning, inspired by Phil's foreach keyword and my own "make it iterate through a Collection" hack. I made a getpoly keyword.
Giving each individual polygon a distinct name because reasons, you can now remove the include line, add a (use Polygon), and do this:
(method (init)
(gRoom addObstacle: (getpoly {Beach}) (getPoly {Path}) ...)
(super init:)
...
)When compiled, each getpoly will expand into a ((Polygon new:) type: X init: ... yourself:) statement matching the .shp file. Convert all rooms and you can throw away those helper functions entirely.
This feature is available now on Github (https://github.com/Kawa-oneechan/SCICompanion).
Edit: (getpoly {}) is now acceptable and will grab the "Default" poly. The internal thing that the polygon editor uses doesn't expose that with a name, hence the empty text box in the editor. This also allows the New Room dialog to generate something with minimal fuss.
-
It would be a good idea to add support for non-integer defines. Sierra themselves used such defines, as seen in the SCI16 source scripts. These defines include complex equations. The SMOOPER script uses these defines extensively.
Also, the "repeat" statement tends to cause problems with the decompiler. The best example of a function that uses this is "death message" procedures.
-
It would be a good idea to add support for non-integer defines. Sierra themselves used such defines, as seen in the SCI16 source scripts. These defines include complex equations. The SMOOPER script uses these defines extensively.
Also, the "repeat" statement tends to cause problems with the decompiler. The best example of a function that uses this is "death message" procedures.
I added a feature request for the define statements:
https://github.com/icefallgames/SCICompanion/issues/19 (https://github.com/icefallgames/SCICompanion/issues/19)
I'd open one about the repeat statements, but I don't understand what the issue is. Can you formalize it a bit?
-
BTW, here's Sierra's documentation (https://github.com/OmerMor/SCI16/blob/master/DOC/SCRIPT.TXT#L667) about repeat statements:
(repeat code)
Continually execute the code until some condition in the code (a
break) causes the loop to be exited. This is equivalent to
(while TRUE code)
or
(for () TRUE () code)
[/tt]
-
The basic issue with repeat is that the decompiler can't hack it, gives up, and makes it an asm block instead. This also affects things like save-restore and asking for a new path.
-
The basic issue with repeat is that the decompiler can't hack it, gives up, and makes it an asm block instead. This also affects things like save-restore and asking for a new path.
Thanks. Here's the bug report: https://github.com/icefallgames/SCICompanion/issues/20
You might want to add a comment there with an example of a repeat statement, the resulting bytecode, and what the decompiler outputs for it.
-
It's the stupidest thing but I can't make it happen? If I copy-paste GetDirectory from SCI16's SAVE.SC to a test project, compile, and then decompile it works fine. It just puts the repeat block inside a return and such little things. Perhaps it's a difference between the system code at the time preserved in SCI16.zip and at the time of SQ6... and looking at these two files, I'm inclined to believe it. I'll take a look at death messages later.
...I just did my best to rewrite LSL3's DyingScript, which is also undecompileable, and decompiled it. I hate this issue.
-
If I copy-paste GetDirectory from SCI16's SAVE.SC to a test project, compile, and then decompile it works fine.
Have you tried SCI32's SAVE.SC (https://github.com/OmerMor/SCI32/blob/master/SYSTEM/SAVE.SC)?
-
I was going to say the same thing! SQ6 uses SCI32, so using the SCI32 SAVE.SC would have made more sense.
Also, here is the EgoDead procedure from the SCI01 template game. It doesn't decompile, so it falls back to assembly.
Decompile results:
Decompiling script 0
WARNING: ::EgoDead: Analyzing control flow: Expected node with two successors (then/else): 1 at 0178
Falling back to disassembly for EgoDead
Generated c:\scicompanion\templategame\sci0.1\src\Main.sc
Decompiled 13 of 14 functions successfully (92%).
Overall bytecount success rate: 84%.
Fell back to assembly for the remaining functions.
For reference, here is the uncompiled code:
(procedure (EgoDead message &tmp printRet)
;This procedure handles when Ego dies. It closely matches that of QFG1EGA.
;To use it: "(EgoDead {death message})". You can add a title and icon in the same way as a normal Print message.
(HandsOff)
(Wait 100)
(= normalCursor ARROW_CURSOR)
(theGame setCursor: normalCursor TRUE)
(SFX stop:)
(music number: deathSound play:)
(repeat
(= printRet
(Print message
&rest
#width 250
#button {Restore} 1
#button {Restart} 2
#button {__Quit__} 3
)
)
(switch printRet
(1
(theGame restore:)
)
(2
(theGame restart:)
)
(3
(= quit TRUE) (break)
)
)
)
)
And here is the asm that the decompiler fell back to:
(procedure (EgoDead param1 param2 &tmp temp0)
(asm
pushi 0
call HandsOff, 0
pushi 1
pushi 100
callk Wait, 2
ldi 999
sal normalCursor
pushi #setCursor
pushi 2
lsl normalCursor
pushi 1
lal theGame
send 8
pushi #stop
pushi 0
lal SFX
send 4
pushi #number
pushi 1
lsl deathSound
pushi 42
pushi 0
lal music
send 10
code_012d:
ldi 1
bnt code_0187
pushi 12
lsp param1
&rest param2
pushi 70
pushi 250
pushi 81
lofss {Restore}
pushi 1
pushi 81
lofss {Restart}
pushi 2
pushi 81
lofss {__Quit__}
pushi 3
calle Print, 24
sat temp0
lst temp0
dup
ldi 1
eq?
bnt code_0168
pushi #restore
pushi 0
lal theGame
send 4
jmp code_0184
code_0168:
dup
ldi 2
eq?
bnt code_0178
pushi #restart
pushi 0
lal theGame
send 4
jmp code_0184
code_0178:
dup
ldi 3
eq?
bnt code_0184
ldi 1
sal quit
jmp code_0187
code_0184:
toss
jmp code_012d
code_0187:
ret
)
)
The part where the decompiler fails is at code_0178, the part that handles the Quit button. It must be the break statement that it can't handle.
-
Oh crap, I meant SQ5, wow! And that break is exactly the part my attempt was missing, too. And that makes the little test routine as follows:
(procedure (TheTest)
(repeat
(switch (== 1 1)
(1 (break))
)
)
)which decompiles to
(procedure (TheTest)
(asm
code_000a:
ldi 1
bnt code_001a
pushi 1
dup
ldi 1
eq?
bnt code_0017
jmp code_001a
code_0017:
toss
jmp code_000a
code_001a:
ret
)
)
Notably, breaking on an if works fine:
(procedure (TheTest)
(repeat
(if TRUE (break))
)
)
-
While trying to decompile the '90 EGA Christmas card it crashes on script 996 (User). It handles all of the other scripts. If I pull the user.sc and user.sco from the VGA '90 card the compiler crashes on the same script.
-
While trying to decompile the '90 EGA Christmas card it crashes on script 996 (User). It handles all of the other scripts. If I pull the user.sc and user.sco from the VGA '90 card the compiler crashes on the same script.
I figured out the cause of that problem - The Seasoned Professional has no VOCAB.900 resource. Taking the VOCAB.900 from another game, like the QFG2 demo, allows the script to decompile.
-
I know someone that is about to release a new replacement for the INN server.
https://www.facebook.com/groups/69704136680/permalink/10156005666256681/
I tried an early alpha of it and it could let you into areas that the Revival could not. James Leiterman was a developer in the old INN barn. "INN Barn" supports all of the original INN games and should work with new games. Not sure if they need to be developed with LSCI, but it does make make me curious as to how hard it would be to add LSCI support to SCI Companion.
-
I've been asked to help out with LSCI support for ScummVM, and I helped fix a bug in the INN Barn last month. So, a few things that come to mind:
- The file extension for script patches is different (.SO instead of .SCR), and the format is likely to be different. Also, small differences in syntax.
- LSCI scripts often don't contain the names of objects, so we are left to guess (this is technically possible in ordinary SCI as well, it was just never used), which would make decompilation less useful.
- There's a bunch of new kernel calls that would have to be documented. This is not only for network access, but also for strings/arrays. The latter has a very SCI32-like flavor, I sure wish they'd ported that to ordinary SCI16. Oh well.
- How to use the networking protocols and such to integrate one's code with INN
- And of course a bunch of new classes.
-
There's a bunch of new kernel calls that would have to be documented. This is not only for network access, but also for strings/arrays. The latter has a very SCI32-like flavor, I sure wish they'd ported that to ordinary SCI16. Oh well.
*coughs guiltily*
-
The scripts still have the .sc extension
;;;;
;;;; NETUSER.SC
;;;; (c) Sierra On-Line, Inc, 1988
;;;;
;;;; Author: Jeff Stephenson
;;;;
;;;; A network version of User.
;;;;
;;;; Classes:
;;;; NetUser
(module# NETUSER)
(define INPUTLEN 210)
(class NetUser of User
(properties
id name: "NetUser"
int sid 0
int numLines 2 ;; number of lines for getText.
int disposeOfIncomingMessage TRUE
)
(method (init)
(super init: (String new: INPUTLEN))
(= prompt (super prompt?))
)
(method (getText nLines &tmp rect retVal saveFont)
(= saveFont (DEdit font?))
(DEdit font: smallFont)
(= rect (Rectangle new:))
(TextSize rect "M" smallFont)
(rect
height: (* (if argc nLines else numLines) (rect height:)),
width: 256,
)
(= retVal
(Print
prompt
#p_at: x y
#p_width: (rect width:)
#p_rEdit: inputLine (inputLine strMax:) rect
&rest
)
)
(rect dispose:)
(DEdit font: saveFont)
(return retVal)
)
(method (handleEvent event &tmp msg)
(switch (event type?)
(remoteEvt
(if haveConnection
(= msg (Msg with: (event message?) (event modifiers?)))
(if (== msg NULLID)
(return)
)
(if (& debugMsgs SHOW_MSG)
(Debug DInspect msg)
)
(cond
((IsObject (msg to?))
(if netMsgProcessor
;; if there are already any messages in the nmpSystemQueue
;; then do not allow any incoming messages to be
;; handled.
(if ((netMsgProcessor nmpSystemQueue?) size:)
(netMsgProcessor putMsg: msg)
(return)
else
((msg to?) handleMsg: msg)
)
else
((msg to?) handleMsg: msg)
)
)
;; big time kludge for OLS
;;
((== (msg to?) 0)
(if curRoom
(if (== (curRoom number?) 14) ;; ONLINESIGNUP
(curRoom handleMsg: msg)
)
)
)
((== (& debugMsgs RCV_NOT_OBJ) 0)
)
;RWL (
;RWL (Print
;RWL "Message receiver not an object."
;RWL #p_button " Debug " 1
;RWL #p_button " Ignore " 0
;RWL )
;RWL )
)
(if disposeOfIncomingMessage
(msg dispose:)
)
)
)
(else
(super handleEvent: event)
)
)
)
(method (said event)
(or
(cast handleEvent: event)
(features handleEvent: event)
(theGame handleEvent: event)
)
)
(method (parse line evt)
(evt message: line)
(return TRUE)
)
)
-
small differences in syntax.
That'd be stuff like the optional type specifiers in Collector's example file, right? Cos besides define taking more than just a single value and kindof being a deprecated synonym to of that's about the only syntax differences I know of. Which kernel calls are available has no bearing on the syntax or format after all.
Which explains why the script source files still have the .sc extension.
-
Which explains why the script source files still have the .sc extension.
But the include files have an .si extension.
-
But the include files have an .si extension.
You called them "include" files with an 'i' so why not?
-
A sample
-
All right! There's another version of GAME.SC in that archive! I've just now used it along with SCI16's GAME.SC to carefully document the ones in my templates.
-
Possible bug? I'm generating lip-sync data for my speech portrait. I have set it all up in Companion and the Edit Lip Sync Information dialog has a fully functioning custom View with mouthed phenomes. Everything looks perfect in Companion. However, when I load the game up and trigger the message with gMessager what ends up animating on the screen is nothing close to what the Companion lip sync editor dialog is showing me. Has anyone else successfully created some custom Talkers with lip sync? There are talkers in SCI Quest but unless I missed it I haven't seen any lip synced examples.
While I'm here talking about lip sync data, another issue I have is that my custom egoTalker script that gets called for ego speech portraits doesn't animate a mouth at all, even though it's all set up and defined properly in the Message and lip sync editor. The only difference is the Ego one is contained in its own script. Main is using it properly (the portrait comes up, just no animating mouth) but does the script I use it in have to "Use" it as well?
-
I just tried getting the Speak-O-Tron to use lipsync data in SCI Quest (room 210), and it seemed to work in the game.
Not sure why it wasn't enabled by default... (maybe I implemented the lipsync stuff after making SCI Quest? I dunno, I forget), but I tried both the Quick Lip Sync and the one in the dialog.
-
From the thread about decompiling KQ6CD I gave it a go and got only about 5 errors and a few duplicate case warnings with version 1.000.00G, Interp 1.cfs.158. I then tried the build in Kawa's link and got many errors. This still happened when decompiling from original RESOURCE.000/RESOURCE.MAP files and no previously decompiled scripts. The first build was an earlier Kawa build, with an MD5 of EDD9ED9DB127965243D984513C08B2D1. I am including the MD5 to ID it since it has the same version number (3.103.3) as the linked build (latest?) in that thread. Not sure what got broken or when, but I thought I would let Kawa know.
-
I touched the compiler, not the decompiler. I don't need that black magic in my life.
-
I'm wondering if this feature is in the current build or not: Can I flip a Pic so that it is essentially mirrored? I noticed in Quest for Glory, they have certain rooms that are essentially the same, only flipped on the x-axis.
I would really like to replicate this process for my game as well and was just wondering if it was implemented in Companion.
(https://i.imgur.com/hJIZ5O7.png) (https://i.imgur.com/TqCXvud.png)
-
It is not a feature in SCI Companion and frankly the picture editor's code scares me so I don't think I'd want to try and add it.
I did just mirror a random pic from Larry 2 using Sierra's own picture editor though. It was pretty easy, just a few clicks. Would you like a copy?
-
I did just mirror a random pic from Larry 2 using Sierra's own picture editor though. It was pretty easy, just a few clicks. Would you like a copy?
Sure! I didn't even know we had access to something like that!
-
You can do this in SCI Companion. It's a bit flaky, but you need to select all pic commands, cut (ctrl-x), then paste (ctrl-v). Then, there are some hot keys for manipulating the pasted commands. Looks like numpad 2 and 8 flip horizontally. I think there used to be a bug where the result was off by one, I forget if it's fixed in the official version of SCI Companion, or what. After you're done moving/modifying the pasted commands, double click on the selection rect in the pic view area and to commit the commands.
switch (nChar)
{
case VK_RIGHT:
{
_cxPastedScale++;
break;
}
case VK_LEFT:
{
_cxPastedScale--;
break;
}
case VK_UP:
{
_cyPastedScale--;
break;
}
case VK_DOWN:
{
_cyPastedScale++;
break;
}
case VK_NUMPAD4:
case VK_NUMPAD6:
_fVFlip = !_fVFlip;
break;
case VK_NUMPAD8:
case VK_NUMPAD2:
_fHFlip = !_fHFlip;
break;
case VK_NUMPAD7:
_iAngle -= 5;
break;
case VK_NUMPAD9:
_iAngle += 5;
break;
-
I did just mirror a random pic from Larry 2 using Sierra's own picture editor though. It was pretty easy, just a few clicks. Would you like a copy?
Sure! I didn't even know we had access to something like that!
Omer Mor posted quite a few of Sierra's internal tools here. Just search his attachments
-
You can do this in SCI Companion. It's a bit flaky, but you need to select all pic commands, cut (ctrl-c), then paste (ctrl-v). Then, there are some hot keys for manipulating the pasted commands. Looks like numpad 2 and 8 flip horizontally. I think there used to be a bug where the result was off by one, I forget if it's fixed in the official version of SCI Companion, or what. After you're done moving/modifying the pasted commands, double click on the selection rect in the pic view area and to commit the commands.
Cool! that worked pretty well! It was a pixel off, but that's not too much of a problem to fix.
(https://i.imgur.com/mvdaT9p.jpg) (https://i.imgur.com/SygLL8d.jpg)
-
I did just mirror a random pic from Larry 2 using Sierra's own picture editor though. It was pretty easy, just a few clicks. Would you like a copy?
Sure! I didn't even know we had access to something like that!
Omer Mor posted quite a few of Sierra's internal tools here. Just search his attachments
There you go:
Sierra's Internal SCI Tools (http://sciprogramming.com/community/index.php?topic=1631.msg9564)
Sierra's Internal AGI Tools (http://sciprogramming.com/community/index.php?topic=1814.msg12232)
-
So the code to flip the vector image is there already, but hidden... and there's an off by one bug that is fixed in Experimental?
Hmmm...
-
you need to select all pic commands, cut (ctrl-c), then paste (ctrl-v).
Any reason that you did not use the standard Ctrl+x for cut? Ctrl+c is usually the standard for copy.
-
Any reason that you did not use the standard Ctrl+x for cut? Ctrl+c is usually the standard for copy.
typo, fixed it
-
There you go:
Sierra's Internal SCI Tools (http://sciprogramming.com/community/index.php?topic=1631.msg9564)
Sierra's Internal AGI Tools (http://sciprogramming.com/community/index.php?topic=1814.msg12232)
Thanks! I look forward to checking this out!
-
I've found it pretty easy and discoverable how to mirror a random LSL2 pic in PE.
-
Is there a feature in the current companion that will run a spell check on text resources? If not, what do you all think is the best way to do this?
-
There is not.
The last time something I made (unlike SCI Companion lol) had a spellcheck feature... I think it was an IRC bot? I did it by shelling out to ASpell. That still wouldn't get you any red squiggles though — at best I could present it like find or compile results. Another possible way is to have a "dump all text" feature whose output you can feed into your spell checker of choice.
-
Is there a feature in the current companion that will run a spell check on text files? If not, what do you all think is the best way to do this?
Are you talking about texts or messages?
Because if what you need is spell checking the text resources - I have created a small Python tool that extracts them all to a CSV file.
Then, as Kawa said, you can feed it to whatever other tool (even open it with text editor with spell checker, or some big IDE).
It's https://github.com/ZvikaZ/HebrewAdventure/blob/master/tools/texts_export.py (https://github.com/ZvikaZ/HebrewAdventure/blob/master/tools/texts_export.py)
It operates on the Sierra text resources as exported by SCICompanion.
Note, that currently it's an internal tool, without bells and whistles, and the paths are hard wired inside.
In the future it will be changed of course, but for now, you can just edit the first lines with the paths (and the encoding, if it's relevant for you - if you just use English, it doesn't matter).
If you want, there's also a counterpart https://github.com/ZvikaZ/HebrewAdventure/blob/master/tools/texts_import.py (https://github.com/ZvikaZ/HebrewAdventure/blob/master/tools/texts_import.py) which create Sierra-format text patches from the CSV.
EDIT
====
Note that is part of translation suite. Therefore, the import script creates text resources only if it has at least one translated item. Otherwise, it ignores it.
You can easily change this by removing the check in lines 24-26.
The rest of the script takes the string from the 'translated' column, if there is one, and otherwise, it takes it from the 'original' column.
-
There is, it turns out, a menu item to extract all script strings. That's... 82 lines for The Dating Pool, because most of it is in messages. I wonder if I could extend that to include text and messages...
Edit: that was easier than I expected.
-
Not that is needed with the current Companion, but Gumby made a tool for this. http://sciwiki.sierrahelp.com//index.php?title=Gumby%27s_SCI_Tools#SCI_Text_Dumper
-
Not that is needed with the current Companion, but Gumby made a tool for this. http://sciwiki.sierrahelp.com//index.php?title=Gumby%27s_SCI_Tools#SCI_Text_Dumper
I tried Gumby's program but found it confusing to use...honestly I feel like a caveman troglodyte here sometimes! I also went to ZvikaZ's script and found it equally arcane to use.
I think most people here are experienced in programming (it is the programming community after all!), but I'm still at level 1 when it comes to programming!
-
Not that is needed with the current Companion, but Gumby made a tool for this. http://sciwiki.sierrahelp.com//index.php?title=Gumby%27s_SCI_Tools#SCI_Text_Dumper
I tried Gumby's program but found it confusing to use...honestly I feel like a caveman troglodyte here sometimes! I also went to ZvikaZ's script and found it equally arcane to use.
I think most people here are experienced in programming (it is the programming community after all!), but I'm still at level 1 when it comes to programming!
Well, I'm aware that my script isn't currently user friendly.
But you just need to change 2 lines, and run it: (I'm talking about the export script - exports to csv)
line 11, INPUT_FILES = # write here the full path to the directory containing all your text.* files
line 12, OUTPUT_FILE = # write here the full path to the csv file you want to create
That's all, just run it.
If there are any problems, and you want my help, you can report it to me.
But maybe on another thread, as it doesn't really belong to SCI Companion V3 - alpha build notes/bugs/feature requests
-
If you want an easy way to get all the text from any game that'll load in SCI Companion, here's an experimental build (http://helmet.kafuka.org/scicompanionwithextractalltext.zip) that changes "Script/Extract all script strings" to "Tools/Extract all text".
-
If you want an easy way to get all the text from any game that'll load in SCI Companion, here's an experimental build (http://helmet.kafuka.org/scicompanionwithextractalltext.zip) that changes "Script/Extract all script strings" to "Tools/Extract all text".
That's great!
You might consider now adding an import function - after user has edited the text in external tool, it's not fun to manually copy it, it'd be better to press a button, and let it auto-magically imported back to SCICompanion. (of course, that might need extracting in some specific format, so the user will keep it, in order to facilitate importing)
Just an idea...
You could ignore it. I've already implemented something similar for myself, so I don't need it ;D
-
How about spell check and translate plugins for Companion?
-
I wonder if I could take the "extract all text" feature and hook it up to Aspell, returning clickable results in the output panel...
-
If you can I could try to do a GUI for it like I did for your SEQ tool.
-
I think you might have misunderstood me.
SCI Companion knows where all the text (be it words you looked for or spelling mistakes) come from. That's why you can double click lines in the output panel, right? A plaintext file containing only the raw text does not include anything about where that text came from, and adding that information introduces things that should not be proofed. Also, importing the changes is not as easy as you might think, especially with the way the script strings are found and exported because those are done quite differently from how "find" does it.
So besides the script strings being Weird...
Non-interactive - already hard enough I'd say.
1) Load up a hidden ASpell instance and a pipe.
2) Iterate through all text and message resources.
3) Pass each line to ASpell, read back its judgment.
4) If it's not "*", put a clickable line in the output panel.
5) Let the user click each line and apply each fix as they see fit.
Interactive - would need creation of an all-new dialog box and holy shit this is MFC and oh god oh god
4) If it's not "*", pop up that dialog box, with the original line and ASpell's suggestions in it, let the user judge or edit it, apply the fix.
External - can't be plain .txt but who knows, would require some kind of re-import feature
1) Hope source data is available for the script strings.
2) Iterate through all text and message resources.
3) Write each line to a specially-designed file marked with its source.
4) Let an external tool work with only the "text" fields.
5) Re-import everything, somehow.
...yeah. And then there's things like words it simply doesn't know that need to be added to a personal dictionary, which the non-interactive option can't really do. (It's done by sending a special command line to ASpell.)
-
I love this idea. I had a stand-alone tool that did spelling (and maybe grammar checking?) at one time, but it was clunky - extract the resources, run the tool, re-import the resources. Having it integrated into Companion would be great.
-
Look what I've done - I upgraded SCI Quest!
Lots of changes have been made to more closely match the original SCI code. Any SQ5 remnant that is not used has been removed, and the status line is drawn entirely by the kernel, to name a few. The game has been tested to completion.
Get it here. (https://drive.google.com/file/d/1tkgh269Xs31at9_inqfqK6_c8oygx1W4/view?usp=sharing)
-
One issue with using SCI11+ is that it won't let you use colors 253-254. Those are for remapping purposes.
-
Look what I've done - I upgraded SCI Quest!
Lots of changes have been made to more closely match the original SCI code. Any SQ5 remnant that is not used has been removed, and the status line is drawn entirely by the kernel, to name a few. The game has been tested to completion.
Get it here. (https://drive.google.com/file/d/1tkgh269Xs31at9_inqfqK6_c8oygx1W4/view?usp=sharing)
Nice! I appreciate this effort!
-
Using the ThunderBoard driver is a standard workaround scratchy or noisy SB sounds for games from that era. It would be nice to track down the underlying problem.
-
One issue with using SCI11+ is that it won't let you use colors 253-254. Those are for remapping purposes.
I just added a slightly smelly hack to the Extended build that works around this issue.
Edit: added screenshots to show the effect. "Fixed" is what you'd see in a stock SCI11 interpreter. "White" is what you'd see in the terp that's currently included.
-
I tested it with the original debug interpreter (1.001.097), and the white pixels are still there. So the issue isn't related to SCI11+, but rather with the original interpreter. Specifically, 1.001.094 (May 25, 1993) introduced color remapping, using color 254.
My advice when making palettes is thus to not use colors 253-254. The graphics will need to be updated to reflect this.
-
I don't know if this has been asked but would it be possible to get code folding in the text editor? It's beyond my understand about how hard it would be to code but I would imagine could be tied into the lexing for syntax highlighting etc?
Another nice to have would be renaming/refactoring. Especially when working on decompiled code from official games. I've been using Notepad++ to "Replace in files" but it's not perfect.
-
Code folding is basically a no, unless there's a newer version of the Crystal Edit control out there that added it.
Renaming would be much more doable, but tricky... how exactly is NP++ imperfect?
-
Code folding is basically a no, unless there's a newer version of the Crystal Edit control out there that added it.
Renaming would be much more doable, but tricky... how exactly is NP++ imperfect?
I think code folding shouldn't be too hard should it? I mean the editor already recognises opening and closing parenthesis etc, and it looks like it has been extended elsewhere (such as right click context menu etc).
The main difference between notepad renaming and built-in renaming is that the editor can recognise "symbols", rather than plain text. So for example if you wanted to rename the Print function to "Output" you can do a find and replace but you'd also end up replacing any other instance of the word Print - so PrintFormat would become OutputFormat which you may not have wanted.
-
With how ridiculously popular it seems to be I'm sure NP++ would support whole word search, which would handily make it ignore "Print" when it's part of another word like "PrintFormat".
Anyway, code folding and context menus are not the same ballpark. They're barely the same sport. Not only would you need to draw the little + boxes in the margin, you'd have to
- Determine where those little + boxes go — determine where each block starts.
- Handle actually collapsing the blocks — line numbers are now non-contiguous, selecting and copying is suddenly all weird...
And that first part is a particular brand of nightmare on its own, even if the control supported collapsing! This is a Lisp-like, you can't just add fold markers to every ( you find or they become useless noise! In C at least you can detect { knowing that it means "here's the start of a code block".
Context menus are not an inherent part of the control you clicked on to begin with. You detect a right-click, determine what word you clicked on so you can offer to "Go to definition: User" or whatever, adjust the context menu accordingly, and pop it up yourself.
And anyway, I found where the Crystal Edit control came from (https://www.codeproject.com/Articles/272/Crystal-Edit-syntax-coloring-text-editor) and it doesn't seem there's been a new version of it for twenty years.
(Edit: running the demo for Crystal Edit and right-clicking on a whim, it gave me a message box saying to "Build your own context menu!" so take that as you will lol)
-
I feel like renaming is the difficult task and code folding is the simple one. You misunderstood my example - there are more issues with a straight up find/replace than the one I suggested. Nevertheless it would be a "nice to have" rather than using notepad.
Either way it's probably not easy like you say. We'll just have to agree to disagree on this one.
-
DISCLAIMER: I'm an AGI guy, and have never used any of the SCI tools, so this may be of no help at all!
Renaming is probably not the hardest thing to do. In WinAGI, that functionality has been around for awhile now. If you change resource IDs, or rename globally defined variables, it will automatically update all your source code. CosmicR is right that it's more than just find/replace text; you have to find/replace tokens. Whole word search is not the answer, because that will also grab words in strings, words in comments, etc.
I didn't have anything like the Crystal Edit control available in VB, so I wrote my own custom control for the text editor. I figured out it wasn't too hard to add token search (as opposed to word search) by using an approach similar to what the parser uses when it compiles the source. I imagine something similar could be added to your SCI editor - a custom find/replace token function that uses a similar strategy to the compiler to identify tokens.
-
Not actually using the editor control itself to find the tokens to replace is actually what I had in mind myself. Instead I would iterate each script, looking through the syntax tree.
Only reason I won't is because I can't. Yet. I need more experience with the inner workings of SCI Companion first.
Edit: I agree, code folding sounds like an absolute nightmare to retrofit to an existing editor!
...
Yeah, best option would be something that already has it built in. But then... you'd need to reimplement all the SCI-specific syntax highlighting, and the auto suggest UI, and so on and so on...
-
A quick rundown of features, not bug fixes, since last year, in chronological order:
- Support saving older Message resource formats.
- Allow mass-importing resource files
- Allow importing SCI 1.0 views in SCI 1.1 without ending up with gray boxes
Which is not a lot, but still...
-
Kawa, I have a request from a friend for your fork of Companion. Is it possible for you to re-add the ability to disable auto-renaming script files on decompilation? Sometimes it gives script names like Obj and Game which confuse the compiler.
-
I could do that and add a checkbox that makes DecompileDialog::_AssignFilenames() always shrug and return n47 or whatever. Which is not as easy as I just made it sound.
Or I can remind you that after it auto-assigns "Obj", you can click the script item in the decompiler's list and rename it there. This will affect Obj.sc, Obj.sco, and 999.scr. It will not rename the Obj class itself.
-
Of course, it's just a bit more manual labour. :P
But fair enough.
EDIT: But also, this was a feature that was already there that has since been removed. Why? There used to be a "Reset Filenames" button in the decompilation process window. Sometimes there are so many scripts that need to be renamed.
-
There used to be a "Reset Filenames" button in the decompilation process window.
You mean this "Reset Filenames" button that does exactly what the on-screen documentation says, giving them "meaningful names based upon their contents"?
By the way, while I was messing with a temporary hack involving escape "chutes", I realized the "substitute text tuples" checkbox didn't actually do anything. Turns out somewhere down the line it ignored that value and just went with false. So guess what?
-
I must have been on something when I posted this. And mostly taking my friend's word for it. Don't mind me. ;D Sorry about the confusion.
-
No worries, it made an excellent segue into announcing that the text tuples checkbox works now.
-
Which is great news!
-
Yeah I mean it doesn't do the thing where "these strings" are replaced by text resource tuples when you compile, which makes round-tripping a disaster waiting to happen but it certainly makes the things more readable.
-
There used to be a "Reset Filenames" button in the decompilation process window.
You mean this "Reset Filenames" button that does exactly what the on-screen documentation says, giving them "meaningful names based upon their contents"?
By the way, while I was messing with a temporary hack involving escape "chutes", I realized the "substitute text tuples" checkbox didn't actually do anything. Turns out somewhere down the line it ignored that value and just went with false. So guess what?
The filenames seem to get reset when decompiling scripts even if the "Reset filenames" button wasn't pressed in SC 3.2.3.2. Is that a bug?
Edit:
Well, I guess it does say that right there in the description. Sorry, the behavior is different in 3.0.1.7 which threw me.
VVVVVV
-
The filenames seem to get reset when decompiling scripts even if the "Reset filenames" button wasn't pressed in SC 3.2.3.2. Is that a bug?
Says so in the Decompiler window:
Start with "Reset filenames" to give scripts meaningful names based upon their contents (or this will be done automatically upon first decompile if no script filenames have been set yet).
-
I've run into this issue a couple of times, but previously hesitated to report it as it's pretty tough to reproduce. I'm getting an error on compilation of my game "Error enumerating items: Corrupt resource header - mismatched types." For context, I was working on modifying a script - no other resource manipulation activities.
Game is SCI 1.1, I'm running version 3.2.3.2, Kawa's build.
EDIT: The quick-fix for this was to discard my resource file and map and recompile everything, which was viable for me because I hadn't introduced any other resources since my last commit.
-
Interesting. Good thing it has quick fix though, but too bad it requires no other changes or you lose stuff.
By the way, 3.2.4 has been out for a few months now. Who knows?
-
Not that it would be a viable solution, but can treating resources as patches still cause the same error?
-
Interesting. Good thing it has quick fix though, but too bad it requires no other changes or you lose stuff.
By the way, 3.2.4 has been out for a few months now. Who knows?
Thanks, just downloaded.
Not that it would be a viable solution, but can treating resources as patches still cause the same error?
I would think that would work, yeah. If I continue to have problems I'll go that route. In fact, maybe I should just do that anyway, would make versioning easier.
-
I would think that would work, yeah. If I continue to have problems I'll go that route. In fact, maybe I should just do that anyway, would make versioning easier.
Might be a good plugin for companion. I did that backup program for the old companion. Perhaps something modified like that with versioning in mind rather than just backup. Something that could work from Companion's Plugin folder. Maybe if I get a little bit of time to look into it. It would be nice if Companion had some command line options or flags for some of its functions like packing/extracting resources, map manipulation, exporting/importing, etc. that an external program (specifically a plugin) could call. Sadly, my C++ skills to add such flags are next to nonexistent.
-
I think it's already built-in functionality under Properties? "Manage resources as patch files (good for source control)"
-
Oh, I know about that setting, I was just mulling over the idea of something automated. A set it and forget it thing. Something that can automatically do versioning. I have never used that setting. Does it automatically rename any saved resource so it does not overwrite an older version?
-
It does not.
-
It could be done with a plugin I suppose. Something that uses a file watcher task and monitors the patch files and upon change issues a commit to a 3rd party source control repo. It's not really in the traditional spirit of source control (commits-on-change could result in a bunch of bad/useless commits), but that would fulfill the 'automatic' portion of your concept Collector.
-
I wasn't thinking about duplicating something like Sourcetree, but perhaps some kind of staging control to not lose anything before a commit. If you have the source on a git then you could use a regular program like Sourcetree.
-
Just a heads-up, I just fixed some crap involving file dialog filter lists (https://twitter.com/Kawa_oneechan/status/1557837090334937088) having random garbage, and an uncaught exception causing a CTD involving the VGA Picture palette editor and not having any image commands. Well, it's not much of a fix, but at least you'll not lose any work to a CTD and you'll know why. Also includes a tiny fix in the pattern pen bitmaps (https://helmet.kafuka.org/logopending/2022/03/01/pattern-pen-implementation-differences/) from a few months back.
Latest build is in the stash in my signature as always.
-
Thanks Kawa.
-
Awesome.
-
Eric Oakford's latest SCI10 Template commit inspired me to add SCI1 cursor saving support. It's about time, huh? Link's in my signature as always.
-
I know there is a request from the SCI translation communities to add support for text resources above 999. Conquest of Longbow has TEX files 1000-2162 that aren't getting repacked into the resource files.
I haven't had time to look into it, but I'm passing the request along in case anyone has the desire to do the leg work. ty
-
That's something to look into indeed, and I have legs from my hips to the ground.
Edit: I just repacked Longbow and I still seem to have all the text resources?
-
I have not tested, only received the request. You were able to alter the strings and repack in 1000.tex and above? I'll try for myself if I can find time.
-
I didn't *alter* the texts, no...
Edit: did it, altered the last line of the last text resource ("desperate"->"disparaged" because I'm nothing if not silly) and repacked it again. Close game, reload, everything's still there.
-
Confirmed working in SCICompanion 3.2.4.0. The issue must be elsewhere. Thanks for checking!
-
Ah, they were trying to import .TEX resources as a number > 999 which produces an error.
-
That should be allowed for any resource type in an 1.0 game. I'll look into it.
Edit: return SeparateHeapResources ? ((PackageFormat >= ResourcePackageFormat::SCI2) ? 64999 : 16384) : 999;No separate heap resources? Then you're not getting more than 1000 resources at all. That seems wrong, considering Longbow has no script/heap split but does use the SCI1.0 map.
Edit: okay try it now.
-
New version works. Thanks, Kawa!
-
I'm not sure what was up with that. Outdated code perhaps?
-
Confirmed working in SCICompanion 3.2.4.0. The issue must be elsewhere. Thanks for checking!
Howdy. I'm new to the forum. But this post caught my attention. doomlazer, where are you getting SCICompanion 3.2.4.0? I'm at 3.0.1.7 from this site: http://scicompanion.com/download/
Is there another location of downloadable zips of SCICompanion? Thanks
-
Is there another location of downloadable zips of SCICompanion? Thanks
Link's in my signature as always.
Meaning you can get the latest SCI Companion from here: https://helmet.kafuka.org/sci/
-
Update: we have nightly builds now so you can get the latest version from here instead: https://github.com/Kawa-oneechan/SCICompanion/releases
-
Feature request:
I'd love it if I could select multiple lines of code, then right click and have an option to shift everything one tab right or left.
-
But you already can? Just select the block and press Tab or Shift-Tab.
-
I think he's asking for a context menu option. Some people like to use keyboard shortcuts, some people prefer mouse/menu commands. Some like toobars.
A good UI offers multiple options.
(Full disclosure - I don't use SCI Companion, so I have no idea if it already includes indenting options on context menu or not.)
-
I acknowledge the difference, but would counter that Visual Studio 2015, TextPad, and just for fun Word 2010 don't offer such options in their context menus. What the first two do have is increase/decrease line indent items in their Edit menus, and TextPad even has Ctrl-<> listed as alternatives to Tab/Shift-Tab. Seems a bit weird to have both.
Another thing to consider is that the Edit menu in SCI Companion works for almost every resource editor that has selection support. Indenting lines would need to be available only for the script editor, and does not feature what's in the script editor's context menu. This may be specifically because Edit applies to all. (I'll also note that "Select All" is grayed out in the script editor, but Ctrl-A works fine.)
A good UI would have context menu items be a subset of the main menu items. SCI Companion's script editor's context menu has unique items. And given it's an MFC project I'm in no hurry to correct that.
-
eh, I don't need a context menu option. I'm just an idiot who's been doing it manually line by line for two years. Thanks for the tip.
-
Visual Studio 2015, TextPad, and just for fun Word 2010 don't offer such options in their context menus.
A good UI offers multiple options.
Another thing to consider is that the Edit menu in SCI Companion works for almost every resource editor that has selection support. Indenting lines would need to be available only for the script editor, and does not feature what's in the script editor's context menu. This may be specifically because Edit applies to all. (I'll also note that "Select All" is grayed out in the script editor, but Ctrl-A works fine.)
A good UI would have context menu items be a subset of the main menu items. SCI Companion's script editor's context menu has unique items. And given it's an MFC project I'm in no hurry to correct that.
I don't know much about MFC, but I'm surprised that it's that difficult to create context menus that are not actually context-sensitive. I.e. that change depending on what window/control you click on and what the state of the program is when you click. That's what I did in WinAGI. (pretty easy to do in VB6!)
-
I should also point out that WinAGI actually DOES NOT include indent/outdent as context menu options either - I thought it did, but then realized I never actually added it. It's been at the bottom of the 'TODO' list for a very long time.
So I guess this is still true:
A good UI offers multiple options.
:D
Maybe I'll add it in the next update...
-
Just... implying that Visual Studio has a bad UI is just funny to me. As one does. 😸
Word? Sure, plenty hate for the ribbon to go around but that's not even near to the point and the indent/outdent buttons are literally right there front and off-center.
(Correction on that by the way: turns out Word does show 'em on right click. Just not quite in the context menu itself but in the mini toolbar above it.)
-
If I've given you something to laugh about, that's a good thing. The world needs more laughter.
You're welcome.
-
Some people like to use keyboard shortcuts, some people prefer mouse/menu commands. Some like toobars.
A good UI offers multiple options.
Agree 100%.
Since I am not a C++ programmer I can only imagine how difficult working with MFC is. In C# context menus are extremely easy to have multiple different menus as well as modifying a single menu as needed on the fly. That said, there are a couple of features from MFC that I wish were in .NET winforms, like being able to undock a toolbar and have it be free floating.
-
That's the fun part isn't it? In VB Classic as well as WinForms, you can just go like thisOneMenuItemInParticular.Enabled = false. In raw Win32 you would do something like SetMenuItemInfo(entireMenuHandle, positionOrCommandId, boolMatchingThePreviousArg, weirdStruct);. I can't go into more detail than that because Microsoft's web site is being Very Weird recently.
But in MFC? Sure, you can do the same thing considering it's built on top of Win32 (as are VB Classic and the first version of WinForms' menu bar) but you're supposed to use ON_UPDATE_COMMAND_UI to bind a function that does the actual disabling? It's kinda whack. And there's an ON_WM_CONTEXTMENU message that causes ::OnContextMenu to be called, and then you get to mess with an MFC Menu that in turn wraps a Win32 one and EEEEUUUUGH WOAH I get why it's like that but jegus!
-
Does anybody have any thoughts on this idea I had regarding how the original games use DOS-437 text encoding while SCI Companion uses Win-1252??
https://github.com/Kawa-oneechan/SCICompanion/issues/19#issuecomment-1596308677
TL;DR: I have long ago disabled the Studio/Sierra language dropdown in favor of having only Sierra script code. Now I would like to turn that into a codepage dropdown. This way I can hopefully solve the issue without having to mess with MFC in an attempt to add an all new dropdown. Selecting "DOS-437" will make text/message editors convert to and from Win-1252, and (de)compilation will likewise convert string literals. Template games might be set to Win-1252, while the default/fallback is DOS-437.
(?: gross assumption, I know.)
-
I think it's a positive change even if it's mostly only beneficial to translators.
Related to that, but slightly off topic - One of the biggest challenges for SCI0 translators is that players cannot enter extended characters. This greatly limits the commands available to non-english players. I know what you're proposing does not address this, but it got me thinking about the problem.
Most SCI0 interpreters do not allow entering extended characters, the one exception I know of being the French version of LSL3. I tried copying its sierra.com and sciv.exe into the english version of SQ3 hoping it would allow ext chars there too. On launch it complains about the missing French vocab resources (902, 910, 911, 912, 913). I exported those and it tries to start, but freezes on a black screen with the hand cursor. Perhaps, exporting some other scripts from LSL3FR that would allow it to run, or maybe I'm headed down a dead end here.
Even if it were to work, there are other hurdles to overcome in SCICompanion. Typically you can only edit vocab 000 or 900. It seems like one way around that would be exporting, say, vocab 910, importing it as 900, making changes and then exporting again. However, there is yet another problem. SCICompanion will not allow you to enter extended characters into a vocab. If you try, it gives a warning when saving.
Extended characters in player commands is a problem that was recently solved in AGI thanks to AGK's string hack. It would be nice if a solution could be found for SCI0 as well.
-
I have implemented the codepage thing. Last night's nightly is bugged though and the Version Detection window will crash the program because I made a tiny mistake while making the DLGINIT resources more readable. Tonight's release should work fine.
-
Hello.
I'm new to the forum and am wanting to get familiar with the SCICompanion code base/development. I want to make sure I understand the administrative/flow/history of how the forum/project works. Please correct my assertions or provide more information to my answers if possible.
- The most worked on repo is Kawa's fork (https://github.com/Kawa-oneechan/SCICompanion). Is this now the defactor SCICompanion source code moving forward?
- Was there a reason for the fork? Are the original developers no longer contributing?
- Is there documentation about getting your feet wet? (ie. core logic, example PR, etc...)
- Are there requirements for PR submissions?
- Can any issue just get picked up and worked on?
- I'm brushing off my c++ skills (been a year or two). I primarily work in a linux environment. I figure all development is done in a windows environment, correct? I'm not familiar with windows development. Anyone have any luck with developing on a non-windows environment, or do I need to get exposed to windows development for a better experience?
- Are there rules/guidelines to this forum? (ie. tech questions go here, general questions go there, etc...)
Thanks for the responses and help. :)
-
Hello.
Hii~
Is this now the defactor SCICompanion source code moving forward?
(de facto) Basically yes, because...
Was there a reason for the fork? Are the original developers no longer contributing?
... Phil mostly changed focus on his own Unity-based SCI games like Cascadia Quest and Snail Trek. His last changes were fixing a pen brush difference (https://helmet.kafuka.org/logopending/2022/03/01/pattern-pen-implementation-differences/) and working on a scripted particle animation generator for his games two years ago.
Is there documentation about getting your feet wet? (ie. core logic, example PR, etc...)
I don't understand the question.
Are there requirements for PR submissions?
As far as I care, don't break stuff.
Can any issue just get picked up and worked on?
If you think you can, you're free to try.
Anyone have any luck with developing on a non-windows environment, or do I need to get exposed to windows development for a better experience?
SCI Companion and its predecessor are pretty much the only applications of their kind that I'm aware of and both are very much Windows only. Sorry.
Are there rules/guidelines to this forum? (ie. tech questions go here, general questions go there, etc...)
I'm not gonna answer that one, I was never supposed to have this much power to begin with. Uh... don't be a dick I guess?
-
Thanks for the response. One last question:
I'm developing a game with my two brothers. While sending individual script files back and forth is doable, are other SCICompanion game files able to be version controlled? (ie. shp files, etc...) I realize anything can be version controlled because it's just file diffs, but many files (other than scripts) are not easily human readable; thus, resolving merge conflicts is tough. Perhaps the answer to this question will make more sense after getting familiar with how the application works under the hood rather than simple familiarity with using it to make games. But if anyone has tried using version control for whole games, then please let me know your experience. Thanks.
-
There's an option in the game-specific settings specifically for source control purposes, it causes all the individual resource files to be handled separately. Not entirely unlike how the Sierra people originally made 'em.
The only real problem is that only the script source files are plaintext. Polygon editor's shp and message editor's shm files are just source code in a tightly controlled format though.
-
There's an option in the game-specific settings specifically for source control purposes, it causes all the individual resource files to be handled separately. Not entirely unlike how the Sierra people originally made 'em.
Cool. I did not know that. Thanks.
The only real problem is that only the script source files are plaintext. Polygon editor's shp and message editor's shm files are just source code in a tightly controlled format though.
Yeah. I've noticed this. Makes it tough to share shp files (and shm) when working on polygons (or messages) separately then want to combine them.
Continuing with the questions to show my Windows inexperience, would there be any issue building SCICompanion from source on a mac by getting a Windows vm or using parallels (https://www.parallels.com/products/desktop/ (https://www.parallels.com/products/desktop/))? I partitioned my mac for bootcamp Windows and was able to build it, but a vm would be less hassle, so I'm gonna try that out.
-
Well there certainly ain't no way you're gonna compile it as a native Mac application, that's for damn sure.
-
So I made a discovery today while perusing the SQ4CD sound resources that I wanted to share (unless someone else already knew this). We know that some early games doubled the sound resources for Windows starting with resource numbers 1000 and up (like KQ5CD and SQ4CD). The scripts add 1000 to the sound resource calls if running in the Windows interpreter. There are two "music devices" flagged in these sound resources much like the music devices in DOS (for PC Speaker, Tandy, Adlib, MT-32, etc). In the Windows resources it uses two flags. Flag $07 is for "Extended MIDI" (which uses MIDI channels 1-10) and flag $0b is for "Base MIDI" (which uses MIDI channels 13-16).
You probably well know that Extended MIDI and Base MIDI aren't something we deal with now, but in early Windows and the early days of GM and synth hardware/keyboards there were MIDI devices that used either only Extended or only Base as their implementation. Base puts percussion on channel 16 instead of 10. When installing Windows versions of Sierra games the setup utility outright asks you if you have extended or base MIDI and depending on which one you select it will save configuration to make the Windows interpreter use the appropriate "device". This is why the Windows resources are separate from the DOS resources because there aren't enough channels to delegate to share with PC Speaker, Tandy, Adlib, MT-32, etc and General MIDI Extended and General MIDI Base.
Now, if you inspect these sound resources you'll notice that the "Base MIDI" music device actually flags channel 11 for the percussion and not 16. Why? Because (in SCI sound resources) channel 16 is reserved for cue and loop data as well as program changes and other MIDI controllers and can't be used for melody. So the Windows interpreter must take the percussion MIDI notation from channel 11 and remap it to channel 16 on output when it's configured for Base MIDI.
So in light of that, we come to my feature suggestion. Currently device flag $07 in Companion is defined as "General MIDI" while $0b is defined as "Unknown" (in the SCI Sound driver dropdown menu when previewing/editing sounds). I propose changing the label for $07 to "General MIDI / Extended MIDI" and $0b to "Base MIDI" in those dropdown menus since we now know what they're for.
I'd also like to report an issue where when selecting an SCI Sound driver device in the dropdown menu of Game Explorer when previewing sound resources (not opening them in the sound editor), the selected device seems to be ignored when playing back. It doesn't do this in the sound editor, it seems to work properly there. I'm not sure if this is an old bug that's since been fixed or if we just never noticed it before.
-
I'll gladly change those labels, and can confirm that the preview panel ignored the device selection since version 3.0.1.7 (the last official release).
-
Hello. I'm trying to build and run the application from the github repository. I'm running into some issues that I can't figure out and would appreciate help.
After downloading the repo and installing all the necessary build components (Windows 8.1 SDK, VS 2015 Build Tools), I can successfully clean and rebuild the solution. However, when I launch the Local Windows Debugger (using Kawa / Win32 as the build configuration), I get "path/SCICompanion.sln is not a valid Win32 application". I'm running Visual Studio 2022 on Windows 11. I've seen SO posts saying the issue is the .sln file is not selected when debugging, but I'm pretty sure it is selected. Is my issue is that I'm not launching with the correct build configuration? Or is my issue that Windows 11 can't execute Win32 applications? Or perhaps is it something else entirely?
As a side question, are there pros/cons to setting the Solution Explorer to "Solution View" vs. "Folder View"? "Folder View" makes sense to me as the structure of the files matches what's on disk, but "Solution View" has many configurations supposedly already set and ready to use.
My goal right now is just to get the application launched in a debugger mode via Visual Studio. If there is a guide that I can follow, then please pass it along if it exists. Thanks.
-
Okay, so I was misunderstanding what these build configurations do. I realize setting "Kawa/Win32" compiles and packages the code into the target directory (this case the "Kawa" directory). I can compile, create, and run the executable from the target directory.
Perhaps, I'm misunderstanding what "run the application in debug mode" means. To me, that means being able to launch the application via the "Local Windows Debugger" and able to set breakpoints in the code. Is that an incorrect assumption? Thanks for any help.
-
The "Kawa" configuration is also a kind of "Release" build so you don't get the ability to properly step through. You can use breakpoints, sure, but the cursor will do what it wants because of optimizations.
I know you can because that's how I traced out how strings work when I added codepage translation support.
-
You can use breakpoints, sure, but the cursor will do what it wants because of optimizations.
I know you can because that's how I traced out how strings work when I added codepage translation support.
Do you have steps on how to launch with breakpoints attached and able to step through the code? What build configuration allow breakpoints? I'm having a hell of a time figuring out how to do it.
Earlier, Kawa, you said
There's an option in the game-specific settings specifically for source control purposes, it causes all the individual resource files to be handled separately. Not entirely unlike how the Sierra people originally made 'em.
Where is this? I'm looking at "Game/Version detection" but cannot see how to set individual resource files handled separately. Maybe it's already enabled because when I change a polygon the respective .shp file is updated (I see this via git diff), and when I change a message the respective .shm files is updated. However, when I add "Control" or "Priority" commands in the pic editor, only the `resource.000` and `resource.map` files are updated, which are both binary. I'm looking into a way to store these "Control" and "Priority" commands in human readable files. That way I can source control all resources I currently care about (scripts, polygons, and commands). Thoughts on this effort? Already been tried?
-
"Game Properties" > "Manage resources as patch files (good for source control)". Hit OK and you should find all your game assets spilled out horrifically into the game's folder.
HOWEVER, control and priority screen data is an intrinsic part of a given Picture resource, unlike its polygons, so if you change that, you change the .pic/.p56 resource file as a whole.
-
It took some digging, but I found the problem with the sound previewer. I am right now chilling to the Tandy 3-Voice version of the Space Quest 3 theme, playing from the preview bar. I also went and normalized all user-visible instances of "midi" and "Midi" to "MIDI" while I was at it, correcting that "unknown" to "Base MIDI".
All this will be in the upcoming nightly.
-
It took some digging, but I found the problem with the sound previewer. I am right now chilling to the Tandy 3-Voice version of the Space Quest 3 theme, playing from the preview bar. I also went and normalized all user-visible instances of "midi" and "Midi" to "MIDI" while I was at it, correcting that "unknown" to "Base MIDI".
All this will be in the upcoming nightly.
Nice!