poetter wrote:I looked at your cp.lua and I'm confused. There really is some hidden crap in every tooltip in front of every ":". Don't know if that is a cp problem or a utf-8 one. Need to discuss this with the other devs

It's coming from the WoW client (or even WoW it self) because the CP is use is the latest, and I rebuild CP.lua FROM SCRATCH - it still inserts this strange space character.
Anyway, result are good right now, I really have to look for parse errors (didn't found any yet).

I'll down 1669 (only item.php ?) to do some checking, using the fact I have many UniUpLoader fans in my Guild.

Btw : I inited a 26 member Guild last evening from scratch with the latest AS version.
Your "Be Smart" thing really works great - 96 secondes for a full armory update - no errors.


edit : I put up 1669 (test version ) :: http://www.papy-team.fr/roster/index.ph ... nfo&a=c:58

Yep, you saw what I saw. But, now we're really seeing it ....
May be my proposal isn't that bad at all, use 3 dots in the pregmatch string as wildcards. Takes care of that - even if wow takes out these strange chars later on, or not.

We filtered out these non breaking spaces (194 160) right before the db insert in update.lib.php. So please update the whole roster, not only item.php.
BTW: Till svn[1688], thats were we are now, there are more item parsing improvements.

Good to here that you like "be smart" mode!

frFR.php, line 601:

Code: Select all

$lang['tooltip_preg_classes']='/^(Classes[color=red]..[/color]:.)(.+)$/'; // text for class restricted items

The double dot (..) isn't needed, just one (.) makes the parser work.

Original situation : http://www.papy-team.fr/roster/index.ph ... fo&a=c:112 - Poetter's test tool is presnt to amke things clear.

Both LUA and AS update give the correct result afterwards (no more parsing errors).

Didn't find any examples yet, but for the next line 602, the same issue could be valid.
edit : I found "Classes" in my database.Tooltip text strings.
In all the cases it concers mountable animals, present in the sacs of the members, and it looks like these are all parsed simple.
Sacs are always parsed 'simple' ?

fixed svn[1700]