UTF-8 encodes each of the 1,11 ... in the Unicode Standard).

We really do need to have full support for the UTF-8 standard as this could be used on websites as well as in email, or pretty much any transmission. I still don't know what I am going to do about this myself, and I do appreciate the suggestions so far.

Check your file list (resource list) it's saying that LFS_External_Client.Form1.resources is listed twice.

I would love a whole patch update process for just InSim requests, I think what the 3rd party devs could add to the community could be huge.

Quote from morpha :

Perhaps some gifted regular expression expert can find a way to achieve this with preg_split() which would certainly be the most efficient approach.

That's what I was thinking, where's filur when you need him?

Quote from Dygear :

But I first have to get to that point with PRISM.

And I guess that point is now, but I think it will ship with LFSWorldSDK first, and then PRISM later on. Thining of calling the whole thing like LFS DataType or something, but each class will be like LFSTime, LFSString, LFSWhatEver.

I was working on Krammeh's bug report about MST/MTC/MSX Colors breaking in strings that span multiple lines. I'm not one to duck the hard questions, and this one did cause me quite some time to think through. The only conclusion I've come to is that much of PRISM is going to need to be rewritten to handle strings correct in these cases. I now feel that the best way to handle LFS strings is to make each LFS Datatype; Time, String, ect; into it's own class that will be handled and parsed at the packet level and thus make it available on all levels. This idea was one that I had for version 2.0 of LFSWorldSDK, so I might just prototype the system there and move it into PRISM when it's done. But is there an easier way, am I missing something that would allow me to do this without having to rewrite much of the packet system?