More stuff...
Okay... I've done a bif comparison with Sergei and Sean's different versions of 1.61 (using BeyondCompare 2 - try it if you do Windows development, it's very good!!) and discovered the only differences are
(1) Sergei uses man->Setvalue("ver", "1") anywhere the CommandBlockManager is used to create a command block for the server. A quick squizz at the LJ API specs reveal this to flip it in to UTF-8 mode. I'll provide a configuration switch for this, though I don't see any real issue with just using UTF-8. It may fix one or two issues I guess.
(2) in the EncodeString method for the LJApplication, Sean creates a string, fiddles with encoding the data withing the string and then returns that string. For some reason in Sergei's version, it does all this, but returns the unencoded string we passed intot he routine!! Alarm bells!! This is possibly why Sean's code works with URL's but the Sergei UTF version does not. Normal plain text/ASCII probably goes through without a problem. However, anything needing encoding is seemingly truncated at that point on the server, I guess.
Don't quote me on point (2) as it's purely speculation at the moment. I'm at work and on a Windows machine, so I can't run any tests. However, this is the only major change (bar the adding of the ver flag) from Sean's code, so unless UTF-8 adds in extra encoding requirements, I think this'll fix it... (not sure, have to look into this if my fix doesn't work)
More news from the "front" as it happens ;-)
(1) Sergei uses man->Setvalue("ver", "1") anywhere the CommandBlockManager is used to create a command block for the server. A quick squizz at the LJ API specs reveal this to flip it in to UTF-8 mode. I'll provide a configuration switch for this, though I don't see any real issue with just using UTF-8. It may fix one or two issues I guess.
(2) in the EncodeString method for the LJApplication, Sean creates a string, fiddles with encoding the data withing the string and then returns that string. For some reason in Sergei's version, it does all this, but returns the unencoded string we passed intot he routine!! Alarm bells!! This is possibly why Sean's code works with URL's but the Sergei UTF version does not. Normal plain text/ASCII probably goes through without a problem. However, anything needing encoding is seemingly truncated at that point on the server, I guess.
Don't quote me on point (2) as it's purely speculation at the moment. I'm at work and on a Windows machine, so I can't run any tests. However, this is the only major change (bar the adding of the ver flag) from Sean's code, so unless UTF-8 adds in extra encoding requirements, I think this'll fix it... (not sure, have to look into this if my fix doesn't work)
More news from the "front" as it happens ;-)