All strings put into mechcomps by users are run through adminscrub(), which puts them through html_encode() as its final step having html_decoded them as its first. This leads to issues when trying to send signals over wifi, you end up with things like this:
Which end up getting interpreted as something like
There is also an issue with the examine text of mechcomp buttons re-encoding the already encoded signal.
This fix is the absolute bare minimum required to solve the problem, adding html_decode() to any string about to be transmitted by the wifi component and removing an html_encode() from mechcomp/trigger/button/get_desc(). There are probably more thorough ways to go about fixing the underlying issues, like adminscrub() encoding stuff that it never decoded in the first place.
If the 3 in that first code tag looks funny, it's because it's a ȝ, putting a real 3 in there made the whole thing turn into an apostrophe even in the code tag which muddied the waters a bit.
Code:
command=text_message&sender_name=Man Jackson&message=This&#ȝ9;s a test.
Which end up getting interpreted as something like
Code:
command=text_message
amp=/list
sender_name=Man Jackson
message=This
#39=
s a test=
There is also an issue with the examine text of mechcomp buttons re-encoding the already encoded signal.
This fix is the absolute bare minimum required to solve the problem, adding html_decode() to any string about to be transmitted by the wifi component and removing an html_encode() from mechcomp/trigger/button/get_desc(). There are probably more thorough ways to go about fixing the underlying issues, like adminscrub() encoding stuff that it never decoded in the first place.
If the 3 in that first code tag looks funny, it's because it's a ȝ, putting a real 3 in there made the whole thing turn into an apostrophe even in the code tag which muddied the waters a bit.