@zanix
Sorry about the try to help. For me it looks to be a more or less similar problem. Somerwhere and somewhy the fance characters got replaced by regular characters. "Chár" becomes a "Char" and overwrites an also existent "Char". The ALT_Monitor does a similar comparison by finding the correct Main or ALT-Char; the names have to match when it compares the CharName and the entry in the Note-Field. The script takes the name, interprets it and used the result against the database. Because of the wrong usage of /w instead of /s the result was different and does no longer match a Char in the database so that the relations did not work.
Doing the upload nothing really different happens. The LUA-Files get parsed and the Charname will be extracted - but it looks like WITHOUT the fancy chars - so that then the Member-ID of the wrong Char gets updated or nothing happens because the search-values do not match.
It looks to me that the fancy characters got replaced and not deleted through the parsing process to find the Character-Name. The Script converts "Chár" to "Char" and then if this is also the name of an existent Member the wrong Characterdata gots updated. When the script would misinterpret the name something different would be the result and the script would not find the already used (for "Char") record to update it. It would look for a record which is written quite different.
My guess was that maybe there is some place in the code where this parsing gots effected by some environment settings or throughout the script at runtime. I have not the knowledge about PHP to find this out. Maybe someone could take this hint and check it.
Sorry to have you bothered with a hint.
Holgiranemsi