[Scummvm-devel] String fragments and system strings in SCI

[Filippos Karapetis]

Further to this: I've now created a patch which removes string fragments, and uses Common::String instead, with no ill-effects. Should I apply it to the trunk, or upload it to the tracker?

Filippos

From: philipk79 at hotmail.com
To: scummvm-devel at lists.sourceforge.net
Date: Mon, 14 Sep 2009 07:17:27 +0000
Subject: [Scummvm-devel] String fragments and system strings in SCI








Hello

I was having a look at how string fragments are done in SCI, and I've ran into some questions/issues. First of all, why do we need the string fragments? I don't really understand their real purpose, even after reading the e-mail from Lars. The way I see it, the engine is supposed to be able to edit strings dynamically. But the only strings that I see which are modified dynamically by the engine scripts are the error messages that show up when the user types something wrong, the savegame directory and the string shown when the game quits (in kSetQuitStr()).
Having looked at the code in question, I see the following:
- The engine does not need to keep a pointer for the error message when typing something wrong, and we could safely change that to a regular string (Lars says so himself in the relevant e-mail)
- We do not, and should not edit the directory where save games are written. This is set outside the engine, and it's not supposed to be edited in the engine itself (as this will certainly not be cross-platform). We set the savegame directory to a dummy value anyway ("/"), which is never changed
- Quit string messages are not changed at all, but the games do show different messages when quitting already, and we don't process the relevant call. Is this even used?

Also, I've noticed that we save the system strings in the save games themselves, which seems quite odd, as we save the savegame directory (why?) and the error string shown when the user types something wrong, which we don't need to. Plus,  we don't save the unused quit string.

I've also checked the different handling of strings and arrays in kStrAt() (which is the whole purpose that string fragments were introduced) and I'm a bit puzzled. Why does kStrAt handle avoid path arrays in a different way than it does strings? It looks like these arrays are actually strings themselves (i.e. "01010" or something like that, but I could be wrong here), but we're storing them as reg_t's... please correct me if I'm wrong here

So my questions are, to sum up:
- Do we need the string fragment code, when we're not really using it? Could we use Common::String instead, if we do need it?
- Do we need to store system strings in save games, since they don't really change (in the case of the save game directory), or are calculated each time they're used anyway (like the error messages)?
- Do we really need separate handling of avoid path arrays and strings?
- If we do need separate handling, can the current heuristic be used? Apart from the LSL5 password, which is XORed (for which there is a workaround), is there any other case where it actually fails? I am not aware of any other Sierra games which store XORed strings (like the LSL5 password)

Regards
Filippos

Ready for Fall shows? Use Bing to find helpful ratings and reviews on digital tv's. Click here.
_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/171222986/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090915/34fa98fa/attachment.html>