[KQ5 CD] StrSplit and kernel_123

[L@Zar0]

More quiz about KQ5 CD.   

Let's see. I'm trying to compile Language.sc. It has the method (or kernel procedure, I'm not sure what is) kernel_123 when decompiled.
Ok, looking at sluicebox decompiled sources, it seems to be the StrSplit procedure. But when I try to use StrSplit, I get an error when compiling:



I'm asking this because I want to use this function for separate two types of strings depending on language (I see this works in another mod), but I can not make it work when trying to split the string (the separator is {#S} in a string for example {Hello#SHola}.

So, here the question would be if kernel_123 is working as expected, as StrSplit function, or even why I can not use StrSplit? I read StrSplit is of SCI 1.1 and AFAIK KQ5 CD uses SCI 1.0. Should I change the SCI version in SCI Companion? I'm a bit lost on this...

[Kawa]

It's called kernel_123 in your copy because: in a certain Vocab resource it lists each kernel function by name and number. Which functions are available differs per version of SCI -- for example text parser games had Parse and Said functions, which were later both replaced with Dummy. StrSplit used to be #120, but it was then moved around to #123.

If a game provides its own copy of vocab.999 (old) or 999.voc (new), SCI Companion's decompiler and compiler alike will know what to do. If they don't, built-in copies of these lists may be used depending on what version is detected.

In the SCI 1.001.100 that I use specifically, StrSplit is in fact RemapColors. There is no StrSplit in that particular version.

But technically, the name of a kernel call doesn't matter, so long as you call the right one with the correct arguments. If you're absolutely sure kernel #123 is StrSplit, just use kernel_123 as if you wrote StrSplit. The final bytecode output would be the same either way.

Some more tech details: when faced with the string (StrSplit engBuf @thisBuf 0), the compiler will look through that list of kernel calls and any known procedures to see if any of them match by name. There is no procedure by the name StrSplit, nor is there a kernel call (because it's kernel_123) so it gives the error shown.

[lskovlun]

I have added a command to my local scummvm that dumps the kernel table it actually uses for any given game (rather than the one found in the resources, which is almost always incomplete/outdated). Here's the one from KQ5CD. Try importing that into your copy of the game, and see if that makes the compiler behave (untested).

[L@Zar0]

But in this game there is no kernel 123 as I can see:



So, how can the decompiler assume is kernel_123? There is Parse and Said, but they are not for the same purpose.
Also I think 113: Intersections is called MoveCursor.

@Iskovlun: I will try later, now I must go.

[lskovlun]

Adding to that, since this version of 999.voc is a good deal larger (by 700 bytes), it may push the game into out-of-heap territory on SSCI - in which case put back the original file after compiling. It's not ideal, but there you go.

EDIT: I could make a version that omits ScummVMSleep...

[Kawa]

The first 122 kernel calls are named by 999.voc, but anything higher-numbered than that is missing and therefore has to fall back to automatically-generated names, so you get Graph instead of kernel_108, but kernel_123 instead of StrSplit.

[L@Zar0]

Ok, thanks.

It seems that with this new 999.voc is compiling when I use StrSplit. In any case, I'm not sure if it works as it should. I have not been able to perform the split in the script. I will need to follow the code and see what it does when calling it.

[L@Zar0]

I finally made some tests for StrSplit (with the new vocab 999). It seems to work well, at least playing in DosBox. I can even change the language in-game in the options windows (I had to add it because in KQ5 CD is inexistant). I have yet to update "King's Quest V..." horizontal position.



After pushing the button:


But the issue that has appeared is that ScummVM is not accepting this language thing. No matter what I do, it always shows the english language (or the first entry as default). I made a question in scumm forums, but  I don't know if anybody will answer it. Maybe you people, after proving your expertise and knowledge can help me a bit more with this multilanguage feature (in the ScummVM part). I changed also the scummVM.ini parameters and changed "language=en" for "language=es" and updated Main.sc with printLang and parseLang with 34 (spanish). So, I think the issue is in scummVM, as in DosBox it works, but in scummVM not.

Let's see if you can help. The last chance I have is to open a bug in scummvm tracker.

PD: Anyway, issue solved.

[Collector]

SCI has a language flag for the RESOURCE.CFG. It uses the phone country code numbers, US is 1 and French is 33.

language = 1

for English and

language = 33

for French. Of course you cannot do this on the fly. I don't think that ScummVM uses the RESOURCE.CFG anymore, but I think it is settable from the GUI and/or ini. The only official SCI game that I know of that language can be set from within the game is "Mixed-up Mother Goose Deluxe".

[L@Zar0]

Theorically, scummvm uses in the .ini the lang=es (or fr, en, it, de...) flag. But the problem I described is in the own code of scummvm, because it is doing something that the original SCI interpreter does in a different way. I opened a ticket with the issue and sluicebox has confirmed it.

[lskovlun]

The only official SCI game that I know of that language can be set from within the game is "Mixed-up Mother Goose Deluxe".

This is done using the SetLanguage kernel call which is available in most SCI32 versions. It's just that only MGDX used it. Of course, this is not an option in SCI1.0 or SCI1.1.

EDIT: And it only affects sound resources. The message resources are not touched.