#24 Color coding or string bug
The color coding thing that we use in scripts so happen
to include the exponential signs "^" from variables
attached to the string as well...
This should not happen because since color coding
always comes in the form of "^0000FF text ^000000"
One of my servers' guilds have the name "^ReD DeviL^"
So this made a strange problem occur...
The output expected should be the equivalent of this:
mes "^ff0000 ^ReD DeviL^ ^000000";
On the guildflag, instead of displaying the red
text "^ReD Devil^" it displayed the output equivalent of
mes "^00ffff vil ^0000000";
so its not really good for message boxes which display
names of players or custom names like party and guild
names since the players are likely to use symbols in
them.
Suggestion:
The way the message box is handled gives me an idea
of the order of the processing of a string + variable
I suppose it takes the string, and adds the variable then
checks for color coding portions of the line.
Well, I suggest that it process the color codes FIRST,
and THEN add the variable strings.
Logged In: YES
user_id=707520
It turns out the client does the proccessing of the codes.
The server just sends the string, and the client figures out
the colors.
So the only thing I could do was make it replace
^ with /\ when its displaying the guild name.
so ^ReD DeviL^ would be seen on the guild thing as
/\ReD DeviL/\
This only works in theory, I couldnt test it cause I dont
know where to go to find the thing you are talking about or
how to control it or whatever, I wasnt kidding when I said i
needed step by step instructions.
So you will have to test it, please let me know if it works,
cause if it does, we should prolly implement it on player
name and party name etc...
Get the latest snapshot from:
http://omniathena.sourceforge.net/nightly/
That should have it fixed
Logged In: YES
user_id=1031747
Okay
If the string processing is done client side... (REALLY??? how
come it doesnt happen on the official servers???)
well... If it CAN be fixed on the server side, I have another
suggestion: you could say, check whether the text after
the "^" sign is a color code like 0000FF or AABBCC and if its
not, just display the entire thing from the "^" sign...
And, color codes that occur immediately AFTER another color
code is displayed like: "^FF0000^00FF00" turns out to be the
red text: "^00FF00"
so you will have to do something like this:
"^FF0000 ^00FF00" to avoid it displaying the next color code.
Logged In: YES
user_id=707520
#1.) Did you test the latest snapshot to see if that worked?
#2.) I dont think you understand, the server has no control
over the color. All it can do is send over the string. The
client then proccesses the string. (I checked this out, all
the server does right now, is read the string verbaitum, and
send it including the ^000000 to the client, so that means
the client has to do the proccessing)... There is no way to
choose whether to display things after ^ as a color code or
not, its all client side.
I have no proof that this works on the official servers,
assuming that it does infact work, that likely means there
is an escape character that is passed to tell the client to
not treat ^ as a color code, I unfortunately have no clue
what this escape character is.