cyclical keyword expansion

[Dilvish]

While trying to debug the problem reported here, I noticed that the German stringtable would give rise to cyclical keyword expansion errors from things SZ_TINY in

Code: Select all

GRO_SYMBIOTIC_BIO_DESC
'''Erhöht die maximale Bevölkerung von Planeten des Typs [[PE_GOOD]]>, [[PE_ADEQUATE]] oder [[PE_POOR]], abhängig von deren Größe; [[SZ_TINY]]: +1, [[SZ_SMALL]]: +2, [[SZ_MEDIUM]]: +3, [[SZ_LARGE]]: +4, [[SZ_HUGE]]: +5.'''

Note that there is no actual cyclical expansion problem here, it's merely a repeated expansion. The English entry for GRO_SYMBIOTIC_BIO_DESC simply refers to Tiny, etc., directly without keyword expansion.

Looking into it, I saw that the check for cyclic expansion in StringTable.cpp was really just a check for repeated keys. I couldn't resist fixing that, in case it was contributing to the problem with starnames in the above thread (but it turned out it wasn't).

It seems to work fine (and yes, I did rig up a true cyclic expansion to test it with) so I went ahead and committed it; this post is mostly just to explain a bit more than the commit message about why.

[Geoff the Medio]

I vaguely recall that when implementing macros for scripts, there was a similar set of regexes or parsers or somesuch, and I had to specifically change something when implementing the new functionality to avoid issues between cyclical expansion and repeated uses of the same substitution, but didn't make any change to the previously-existing stringtable substitution code it was based on.

You might want to check these commits against your own implementation?

https://sourceforge.net/p/freeorion/code/4657/
https://sourceforge.net/p/freeorion/code/4658/

[Dilvish]

You might want to check these commits against your own implementation?

Well, at a quick review, it appears it was a replacement for the same code I replaced, and the way macro_deep_referenced_in_text() is used looks to me to be a reasonable approach, though rather distinct from mine (I suspect mine would wind up less efficient, doing more repeated work). I don't immediately see any flaws with it, but don't have spare time to test this other code just now. I didn't fully understand your recollection -- is there some particular reason we are not using this code you linked to?

[Geoff the Medio]

I didn't fully understand your recollection -- is there some particular reason we are not using this code you linked to?

No... I just didn't fix the stringtable version at the time.