What?
Yeah. Telephone country codes. Those SCI games that let you switch between two languages without exiting? They used telephone country codes internally.
(instance sq4 of Game (properties parseLang 0 printLang 0 ) ;... ) (procedure (byLang german spanish french italian other) (switch (gGame printLang?) (49 german) (34 spanish) (33 french) (39 italian) (else other) ) )
Unfortunately, I don’t have the source code for an SCI interpreter that has the string splitting function needed — it only has the telephone number codes. So I’ll go with what ScummVM does.
Given a call to StrSplit with a parameter like You have an empty jar.#FVous avez un vase vide., the current printLang is matched with a separator character. In this case, if it’s zero we cut off and return the left part of the string. If it’s nonzero (say it’s 33), it’s matched to F for French. Looking for the split marker #, we then look at the next character and see if it’s our request. If it is, if we found a #F, we return the right part of the string. But what if we don’t find the right language? Let’s say for example I took the “see ya on the chronostream” message in the French version of SQ4 and made a Dutch secondary line?
What happens is, the interpreter gives up. ScummVM or the original, they just return the whole string.
But then of course, Dutch isn’t a supported language at all. The interpreter only recognizes the country codes for English, Japanese, German, French, Spanish, Italian, and Portuguese. And two of those aren’t supported by the game script I started this post off with. Surely if I gave the French SQ4 a German line it’d react differently?
Well, yeah. If the split marker is for a language the interpreter can recognize, it just returns the left part.
(Bonus: For no good reason beyond a little harmless pride in my country, I added the number for Dutch to the list in SCI11+. Which is stupid. It has no StrSplit function… but it could get one. Which would be stupid because we have patchDir support and can use it to just switch languages externally.)
… but why telephone numbers though?
Answer: numbers are easy to work with I guess.
