Query
-
- Posts: 2
- Joined: Wed Oct 05, 2016 3:18 pm
Query
Hello I am Spanish, game Reino de Leyendas and I want you in the game window as I can create a bar where points indicate my life, energy and experience?
Last edited by sveinvjorn on Thu Oct 06, 2016 1:25 pm, edited 1 time in total.
- SlySven
- Posts: 1023
- Joined: Mon Mar 04, 2013 3:40 pm
- Location: Deepest Wiltshire, UK
- Discord: SlySven#2703
Re: Query
May I ask whether the game Realm of Legends uses just English or does it send you text in other languages - such as Spanish? The reason I ask is that at present Mudlet will not handle characters outside of the ASCII range so if you are trying to get it to "trigger" on something and that something is not written using just ASCII {i.e. the letters which in lower case are just: abcdefghijklmonpqrstuvwxyz, some punctuation characters: ,.;:'#!"$%^&*()-_=+[]{}~<>/? and the numbers: 0123456789} then you may find it cannot detect them...
-
- Posts: 2
- Joined: Wed Oct 05, 2016 3:18 pm
Re: Query
Indeed it is in Spanish https://www.reinosdeleyenda.es in fact I have several problems with them not to use the letter Ñ and accents' now the strange thing is that in the chat if you see these characters but I write not recognize them.
Re: Query
Worst case, you could use a line trigger, and pass each line through a script that checked for patterns you cared about that contained otherwise "invalid" characters in them. The rex.match function has no problem (that I have seen) with non-ASCII characters. It wouldn't be as fast as using the trigger engine, but so long as you don't have a ton of them, it should still work out.
- SlySven
- Posts: 1023
- Joined: Mon Mar 04, 2013 3:40 pm
- Location: Deepest Wiltshire, UK
- Discord: SlySven#2703
Re: Query
I'm not sure that Utf-8 encoding streams would make it through the current code that handles the incoming data stream - it has to process Telnet protocol codes (which use bytes with the MSB set) and spot the ANSI control sequences and parse them and then any bytes for the out-of-band protocols (Channel102, MXP, GMCP and other such things) only then could it assemble the remaining bytes into a Utf8 stream to pass to the "trigger" engine (for lack of a better world for it) - and I suspect that will need work in order to correctly decompose/normalise sequences of characters so that - for instance Å is recognised as being the same as Å (these two samples are NOT the same bytes BTW - at least at the time I typed them in!)
Re: Query
So, even though the text displays appropriately on the screen, you are suggesting it won't make it properly into the line variable? I figured that using a line trigger and using the variable would bypass any issues with the trigger engine itself. Then again, I don't have to deal with non-ASCII characters terribly often... so I don't really know.
Re: Query
Testing with the `echo alias I couldnt get a trigger pattern for swedish characters to work either. I assume it's the same deal as for spanish.
Getting triggers to react should be doable, but non-ascii charcters have do be treated differently, for example by using a regex trigger pattern and replacing those characters in a pattern with a dot (e.g. mañana → ma.ana). And instead of using (\w+) as a pattern, we can use an inverted pattern to match anything we don't want to see, such as spaces, dots, etc:
The pattern ([^ .,:!]+) captures everything until the next space, dot, comma or exclamation mark.
However, I don't think that capturing a string and re-sending the same characters will work well. Things like storing targets and use them in spells etc. could be problematic.
Getting triggers to react should be doable, but non-ascii charcters have do be treated differently, for example by using a regex trigger pattern and replacing those characters in a pattern with a dot (e.g. mañana → ma.ana). And instead of using (\w+) as a pattern, we can use an inverted pattern to match anything we don't want to see, such as spaces, dots, etc:
The pattern ([^ .,:!]+) captures everything until the next space, dot, comma or exclamation mark.
However, I don't think that capturing a string and re-sending the same characters will work well. Things like storing targets and use them in spells etc. could be problematic.
- SlySven
- Posts: 1023
- Joined: Mon Mar 04, 2013 3:40 pm
- Location: Deepest Wiltshire, UK
- Discord: SlySven#2703
Re: Query
Even typing things in is hard, for instance I composed this in a separate editor:
where the first two letters are Latin Upper Case A + Combining Ring Above and then Latin Lower Case C + Combining Cedilla Below, which should appear (eventually) as:
|Åçorn|
|12345|
with the two '|' on each line one above the other.
However the command entry line mangled this on pasting from the clipboard to the command entry line:
lua cecho("|<green>A<̊red>c<̧blue>orn<reset>|\n|12345|\n")
{the combining diacriticals are applied to the following character and NOT the one they should be} before it even got sent to the lua sub system - so it is not surprising what got displayed was:
|A ̊c ̧orn|
|12345| ironically if I copy it from the Mudlet screen direct to here it gets fixed to show the (uncoloured, expected):
|Åçorn|
|12345|
Or if I copy it as HTML it appears thus in my browser: <aside>Actually, thinking about it it might be that in THAT case there is code that thinks that EVERY byte that is appended to a line means the line is extended by one "character" position - which is, of course, nonsense - even when you ARE using a mono-spaced font...</aside>
Anyhow - some work is seriously outstanding in support for characters outside of ASCII - but we do want to get it working (at least I do) - perhaps by Mudlet 4.0.1?
Code: Select all
lua echo("|<green>Å<red>ç<blue>orn<reset>|\n|12345|\n")
|Åçorn|
|12345|
with the two '|' on each line one above the other.
However the command entry line mangled this on pasting from the clipboard to the command entry line:
lua cecho("|<green>A<̊red>c<̧blue>orn<reset>|\n|12345|\n")
{the combining diacriticals are applied to the following character and NOT the one they should be} before it even got sent to the lua sub system - so it is not surprising what got displayed was:
|A ̊c ̧orn|
|12345| ironically if I copy it from the Mudlet screen direct to here it gets fixed to show the (uncoloured, expected):
|Åçorn|
|12345|
Or if I copy it as HTML it appears thus in my browser: <aside>Actually, thinking about it it might be that in THAT case there is code that thinks that EVERY byte that is appended to a line means the line is extended by one "character" position - which is, of course, nonsense - even when you ARE using a mono-spaced font...</aside>
Anyhow - some work is seriously outstanding in support for characters outside of ASCII - but we do want to get it working (at least I do) - perhaps by Mudlet 4.0.1?