Either it's a EU thing or I'm missing something crucial here. I'm especially confused as to the listing of the ampersand (&) as a viable character... also I just did a bit of testing specifically with "\" and there didn't seem to be any problems.
"\" in addition to certain letters behind them can transform into new symbols. \n turns into a newline. That can mess up the string and you might not be able to retrieve it correctly - at the very least it'd make displaying that string messy and bugged.
And the ampersand can be used in strings, so why not have it as a valid character?
Whenever I save a string containing "&" it becomes "&"
"<" and ">" save as "<" and ">" respectively
I'm not familiar with XML but it's obviously some methodology of tracking what XML considers special characters, that's why I figure "&" of all characters is out of the question. Again my only answer for this discrepancy is some regional difference, or else some trick I'm not aware of.
"&" is an XML character.... which has special implecations.... no idea how it would effect a string in a bank file... or in your maps... xml file either.
Rollback Post to RevisionRollBack
Skype
KageNinpo = SN
My Libraries
DialogLeaderboard & TeamSort
My Projects
SPACEWAR Tribute
Infinite TD
However, this special way of storing them also means they take up more space. Having a few of the characters take up 4 instead of 1 invalidates the entire idea of having a compression in the first place.
I haven't done any math on that but I believe the compression is actually better by excluding these and going on with a slightly smaller base.
I did further testing with "\" making a point to try and produce line breaks but had no problems. I also took a look at a few tooltips and noticed that line breaks and every other formatting was contained within <>... so "\" still appears to be completely harmless, even if you convert the string to text it reads it literally without the <>
I took my information directly from the starcode thread, without testing this myself. I tried it out now, and you appear to be correct in every way. So I guess, Starcode needs to get rid of > and & and may add \
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Yes but I mean usable characters for the purposes of compression, every character that consumes only a single byte in the file.
<> are valid, too, but \ and < usually should be skipped, because \ is an escape character and < opens a tag.
Have a look at the Starcode thread.
Either it's a EU thing or I'm missing something crucial here. I'm especially confused as to the listing of the ampersand (&) as a viable character... also I just did a bit of testing specifically with "\" and there didn't seem to be any problems.
"\" in addition to certain letters behind them can transform into new symbols. \n turns into a newline. That can mess up the string and you might not be able to retrieve it correctly - at the very least it'd make displaying that string messy and bugged.
And the ampersand can be used in strings, so why not have it as a valid character?
Whenever I save a string containing "&" it becomes "&"
"<" and ">" save as "<" and ">" respectively
I'm not familiar with XML but it's obviously some methodology of tracking what XML considers special characters, that's why I figure "&" of all characters is out of the question. Again my only answer for this discrepancy is some regional difference, or else some trick I'm not aware of.
@TheZizz: Go
"&" is an XML character.... which has special implecations.... no idea how it would effect a string in a bank file... or in your maps... xml file either.
@TheZizz: Go
'&' will be stored as '&' (for ampersand).
However, this special way of storing them also means they take up more space. Having a few of the characters take up 4 instead of 1 invalidates the entire idea of having a compression in the first place.
I haven't done any math on that but I believe the compression is actually better by excluding these and going on with a slightly smaller base.
@s3rius: Go
So there is no discrepancy, the STARCODE thread I was directed to is simply inaccurate. It lists & and > as practical characters:
http://forums.sc2mapster.com/resources/trigger-libraries/5091-library-starcode-v1-4/#p10
I did further testing with "\" making a point to try and produce line breaks but had no problems. I also took a look at a few tooltips and noticed that line breaks and every other formatting was contained within <>... so "\" still appears to be completely harmless, even if you convert the string to text it reads it literally without the <>
@TheZizz: Go
I took my information directly from the starcode thread, without testing this myself. I tried it out now, and you appear to be correct in every way. So I guess, Starcode needs to get rid of > and & and may add \