Text handling in OXPs
Posted: Fri Oct 05, 2012 10:38 am
I’m looking into a rewrite of the string expander, which handles things like
The current version works like this:
As for odd behaviours: the algorithm described above must expand the result of every previous expansion. For instance, if your name is “test[1]",
In a string like
One possibly useful one, at least for legacy scripts, is that you could use
The way I’d like to do it works like this:
I also want to add warnings for things like unmatched close brackets and percent signs not followed by known escape codes. The addition of
Edit: another minor semantic change – it will no longer be possible to override numeric keys (like
[commander_name] and %I in strings. The current version is very slow, and its behaviour is odd in certain cases. I need to know if anyone is relying on the odd behaviours. It seems unlikely now that most OXP scripting is in JavaScript, but you never know.The current version works like this:
- Seatch the string from left to right looking for an open square bracket.
- If found, search for a closing square bracket.
- If found, attempt to look up the text between the brackets in various ways. If a replacement is found, inserts that where the bracketed text was, otherwise remove the brackets leaving only the text that was between them.
- If there was a pair of brackets, it has now been removed; start over from the top in case there are more brackets.
- If found, search for a closing square bracket.
- Having eliminated all open brackets (there may still be closing ones), handle %H, %I, %R, %N and %J.
As for odd behaviours: the algorithm described above must expand the result of every previous expansion. For instance, if your name is “test[1]",
"[commander_name]" would be expanded to "testvery", "testmildly", "testmost", "testreasonably" or "test" at random. The same thing can happen to mission variables, which could perhaps be useful at times but is probably undesirable overall.In a string like
"[some [nested] thing]", it will first try to look up "some [nested". If this fails, it will end up with "some [nested thing]", and try to expand "[nested thing]". From a programmery perspective, there are three saner options: only look up "some [nested] thing", try to expand "nested" first, or report an error. I’m leaning towards the first option, which is simplest. The alternatives would have very little overhead, but also very little value.One possibly useful one, at least for legacy scripts, is that you could use
"%J[mission_mySystemID]" to get the name of a system (for IDs > 99).The way I’d like to do it works like this:
- Scan the string from left to right, and consider each character.
- If it is an open square bracket:
- Scan to the matching closing square bracket. Nested pairs of opening and closing square brackets are skipped over.
- If one is found, look up the result in various ways as before. However, if the match is found in descriptions.plist, expand the result in isolation before inserting it. Results looked up in other places (mission variables, legacy script methods) are not expanded.
- If the lookup succeeded, replace the bracketed key with the result. Otherwise, leave it as it was.
- Scan to the matching closing square bracket. Nested pairs of opening and closing square brackets are skipped over.
- If it is a percent sign:
- If the next character is
H,I,RorN, replace the two-character escape code with the appropriate value. - Otherwise, if the next character is
J, and this is followed by three digits, replace the sequence with the name of the system specified by the three digits. - Otherwise, if the next character is
%,[or], replace the escape code with the unescaped character.
- If the next character is
- If it is an open square bracket:
I also want to add warnings for things like unmatched close brackets and percent signs not followed by known escape codes. The addition of
%%, %[ and %] makes it possible to use these characters in strings that will be expanded.Edit: another minor semantic change – it will no longer be possible to override numeric keys (like
"[14]") with loose strings in descriptions.plist or the overrides parameter to JS expandDescription().