SCI Companion V3 - alpha build notes/bugs/feature requests

[troflip]

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....

[MusicallyInspired]

Pretty cool and useful!

[Kawa]

There's a recurring issue when pasting images from external sources.


Interesting, how the key color is involved...

[troflip]

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 :-( )

[troflip]

Try this:

http://scicompanion.com/Downloads/SCICompanionAlpha.zip

[Kawa]

"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.

[troflip]

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.

[spiffythedog]

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

[troflip]

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.

[spiffythedog]

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."

[troflip]

You can probably work around that by changing the DeltaurRegion definition to DeltaurRegionBase:

Code: [Select]

(class DeltaurRegionBase of Rgn
... etc..

and then adding an instance of it called DeltaurRegion:

Code: [Select]

(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.

[troflip]

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

[lskovlun]

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.

[troflip]

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.

[lskovlun]

The SCI0 interpreter will crash when calling ScriptID for an exported class.

Not here. I just whipped up a quick script:

Code: [Select]

(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.