(In)Frequently Asked Questions

Here is a list of questions that, frankly, no one has ever asked, but I think they ought to have.

What's up with strings?

LFS does not support Unicode, instead it uses its own string encoding system, based on Window's code pages. As .NET only supports Unicode strings, for maximum consistency and reliability, InSim.NET converts LFS encoded strings to Unicode and back again when receiving and sending packets. For the most part this is an invisible operation that you should not even notice, however there are a couple of things you may need to keep in mind.

Firstly when converting a string from Unicode to a LFS encoded string, the resulting string that is produced may end up being longer than you intended, which will cause the string be truncated by InSim.NET before being sent (effectively making it shorter when displayed in LFS... if you follow me). This is because LFS uses double-byte character sets for some types of text, meaning that a single-character can become two bytes in length, thereby reducing the number of characters the fixed-byte LFS strings can contain. Also as all C-style strings must end in a NULL character, InSim.NET inserts a NULL character at the end of each string, which may cause the string to appear in LFS one character shorter than you intended. Ultimately all this should not matter too much if you stick to standard ASCII characters, but it is something you may run into if you use a lot of wide-characters, such as Japanese or Traditional Chinese.

Lastly converting strings from Unicode to LFS encoding is an expensive process, so for best performance you should try to and stick to basic ASCII characters, as InSim.NET contains an optimization that makes converting those sorts of strings incredibly quick. That being said, you shouldn't shy away from using other codepages when you need to, just bare in mind that converting non-ASCII characters can be slower.

Why are some of the packet data-types different from InSim.txt?

CLS, basically. CLS is the Common Language Specification, which dictates what types and features a library can use if it wants to be compatible with all .NET languages. Most of us are familiar with the hugely powerful C# language, but many other languages, such as IronPython and IronRuby, are more minimalistic and do not allows certain types. In order to make InSim.NET compatible with as many languages as possible (all of them, in fact!), some types had to be changed.

All you need know is that, even though sometimes the type may be different than what it lists in InSim.txt, LFS still expects a value that falls within the same bounds. Don't put 297 where it is expecting a byte, or -5 where it is expecting a unsigned short. InSim.NET will try to convert the value to an acceptable type, but it may cause unexpected consequences when the value is received by LFS.

Last edited Feb 1, 2012 at 3:28 PM by AlexMcBride, version 12

Comments

No comments yet.