Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Kawa

Pages: 1 2 [3] 4 5 ... 93
31
SCI Development Tools / Re: Strings: {} vs "", and underscores
« on: July 21, 2020, 08:21:19 AM »
Worse: not only is your post much shorter than mine, but I'd written a completely different long post explaining why SCI has text resources to begin with before I reread the question, scrapped it all, and wrote the above post instead.

32
SCI Development Tools / Re: Strings: {} vs "", and underscores
« on: July 21, 2020, 06:36:40 AM »
Naively, you can't have text resource tuples as a format string parameter.

I don't know about SCI0, which Larry 3 used, but I can confirm that SCI11 can in fact handle them. But unfortunately in this case the if else ruins it.

Y'see, in the Larry 3 code above, it directly returns either a description of the piece of wood or a blank string, right? Those are a single 16-bit pointer to some text, each. If the wood is there, we pass the one value on to Printf. If it's not there, we pass the other. Tuples are two values, which can't be returned like that.

The solution that comes to mind, if SCI0's Format kernel call is also able to do so, is to rewrite it like this:
Code: [Select]
(if (InRoom iWood)
(Printf "The granadilla is short and graceful, with a gray trunk, and delicately spreading branches.%s" " Beneath its outstretched boughs lies a beautiful piece of wood, probably cut by a native then forgotten.")
else
(Printf "The granadilla is short and graceful, with a gray trunk, and delicately spreading branches.%s" {})
)
Or in tuples:
Code: [Select]
(if (InRoom iWood)
(Printf 210 0 210 1) ;or whatever number it'd assign to the wood part.
else
(Printf 210 0 {}) ;empty string is actually shorter than a text resource tuple here.
)

If I remember correctly, SC would notice the second line is identical to the first and reuse the 210-0 tuple.

33
GPL, it seems, from looking at the blurb at the top of a random .cpp file.

34
SCI Development Tools / Re: Strings: {} vs "", and underscores
« on: July 21, 2020, 05:17:02 AM »
Underscores are indeed used as spaces that don't whitespace fold. It's like HTML, really, with _ as  

Historically the difference between {} and "" was that {} would be kept as literal strings in the script resource, and "" would be automagically stored in a text resource and replaced with a tuple. Of course, they stopped using text resources as much when messages were introduced, and later versions of the Sierra compiler did not do the text resource thing, much like SCI Companion.

Practical example:
Code: [Select]
;LSL3 Decompilation
(proc255_4 210 0
(if (proc0_23 3)
{ Beneath its outstretched boughs lies a beautiful piece of wood, probably cut by a native then forgotten.}
else
{}
)
)

;Original source
(Printf "The granadilla is short and graceful, with a gray trunk, and delicately spreading branches.%s"
(if (InRoom iWood)
{ Beneath its outstretched boughs lies a beautiful piece of wood, probably cut by a native then forgotten.}
else
{}
)
)
Where text.210 line #0 is what was originally the "" string.

35
It's spelled "gibberish". Best idea I have to offer is to not edit the script files in SCI Companion, only blindly compile them. So long as the editor you do use has the right encoding in mind, it might Just Work then.

Aaaaand no, I wouldn't know where to begin adding command line controls. Parsing out the arguments, sure, I literally just learned where and how that's done (because MFC does things its own way), but actually acting on them? Preferably without showing the main window, or even taking all the time and effort to load it? No can do.

36
What you haven't said is why compiling edited SC files is "problematic". You just said it was, no further elaboration, and went on to consider hacking the raw script resources which by all means ought to be harder than editing plaintext .sc files.

Why then can you not compile edited .sc files? How is it "more problematic"?

37
SCI Syntax Help / Re: Old SCI0 Template Save Bug
« on: July 18, 2020, 03:14:38 PM »
It's a clean fix and holy shit that's a sneaky one haha

38
SCI Syntax Help / Re: Old SCI0 Template Save Bug
« on: July 15, 2020, 06:09:00 AM »
Very much not needed, yeah, much like most of the development tools. Now, debug tools...

39
I've found it pretty easy and discoverable how to mirror a random LSL2 pic in PE.

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

41
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?

42
SCI Syntax Help / Re: Old SCI0 Template Save Bug
« on: July 09, 2020, 06:32:52 AM »
If the save/load scripts don't have path separators in any of their strings, they're not affected by what I fixed.

43
SCI Syntax Help / Re: Sierra Script Conversion Issues
« on: June 29, 2020, 10:43:01 AM »
Smells like the latter possibility, then 🤔

44
SCI Syntax Help / Re: Sierra Script Conversion Issues
« on: June 29, 2020, 09:33:14 AM »
For whatever reason, main.sc does not have the line (include sci.sh) in it, or it is including a version of sci.sh that for whatever reason is missing all these define statements.

45
SCI Syntax Help / Re: Converting sciAudio to Sierra Script
« on: June 23, 2020, 01:21:12 PM »
It's not SCI I don't think that's confused by the backslash. If I decompile this test script with "sciAudio\\command.con" in it, I get "sciAudio\mmand.con" in the disassembly and syntax tree alike. I'll look into the string parser and report back.

Okay I think I found it. In ParserCommon.h:
Code: [Select]
default:
    if (isxdigit((uint8_t)ch))
    {
        chHex = charToI(ch);
        lookingForSecondHex = true;
    }
    else
    {
        str += "\\"; // Add it, the following char was not an escape char
        processCharNormally = true; // Add the current char too
    }
That last line is what mucks it up. Commenting that out seems to help the co part survive without apparently being mistaken for an invalid hex sequence and eaten. A new build will be is available from the stash in my signature shortly now.

Pages: 1 2 [3] 4 5 ... 93

SMF 2.0.14 | SMF © 2017, Simple Machines
Simple Audio Video Embedder

Page created in 0.102 seconds with 21 queries.