This concerns frFR rosters.
Have a look at a recent LUA updated character.
=>
http://www.papy-team.fr/roster/index.ph ... nfo&a=c:58
Line 600 in frFR.php doesn't do its job well.
This :
- Code: Select all
$lang['tooltip_preg_socketbonus']='/Bonus de sertissage...(.+)\n/';
does work, when I modify de
space : space for a triple dot (wild card).
Another example :
Another warrior, this time updated by a tool named ArmorySync
http://www.papy-team.fr/roster/index.ph ... fo&a=c:158The parse problem ("Bonus de certissage.....") present in the first exemple isn't there anymore.
But a nice one shows up : the
armor (= Armure in French) in the tooltip.
From LUA:
Armure : 548 From the Armory with the help of ArmorySync:
548 Armure
[neither one has a + sign - thats ok]
So, parsing fails in this case.
Is this a 'just for the French' inversion ? Is the Armory to blame ?
Can this be solved (inverted) in the ArmorySync addon ? (yes, it could)
Otherwise, the item parser should be adapted for this exeception (if nothing else works).
Another one (the second char, the ArmorySyc one)
Line 602 - frFR.php:
- Code: Select all
$lang['tooltip_preg_durability']='/Durabilité (|:).(\d+) \/ (\d+)/';
Note the point (.) instead of a space.
A complicated one :
The original line is :
- Code: Select all
$lang['tooltip_preg_block']='/(Bloquer).+?(\d+)/i'; // text for shield blocking values
Or, Armory(Sync) return the word
Blocage, not
Bloquer.
The Armory(Sync) syntax is
115 Blocage.
LUA says :
Bloquer : 115
Some code is present (in item.php) to interchange the numeric value (i.e.
115) and the text string (
Bloquer) but if Bloquer becomes Blocage, then stuff does go wrong
Please note : my roster is right now a clean 1665 version with the latest ArmorySync v2.6.0.346.
If you guys want to test, PM, and I PM ftp acces back.
