The online racing simulator
LFSLib.NET update in the works
(16 posts, started )
LFSLib.NET update in the works
I've been getting a number of emails and private messages about this, so I figure I should post here.

I know the lib is a couple of revs behind the InSim protocol and I do intend to catch it up to the current state. I don't have a timeline as rl issues have kept me from even trying out the latest patches of LFS. I hope to get some cycles from my other tasks this week to at least determine the scope of the changes I need to undertake and will update this thread once i have more information.
did you have ever thought about making this project opensource ? i think this could be a good sourceforge project, so there will be a lot of interested people, who holds the spec within the lap up-to-date with the current lfs insim protocol.
it's already opensource.... Oo
so stupid from me but with hosting it in another way (sourceforge gives u a lot of communication tools ), some choosen people can directly edit the source, so the work does not need to be done by one man
do you know if this dll can be used with a smartdevice C# project?

EDIT:

I think the answer is not

Read at: https://forums.microsoft.com/M ... stID=1231117&SiteID=1
Quote :class libraries run on the device must be built against the .NETCF version of the BCL (mscorlib.dll, system.dll, system.xml.dll, etc.). .NETCF will not resolve types that are compiled against the desktop version of these assemblies. If you want to share the same binary on device and PC, you need to build against the .NETCF assemblies. The desktop CLR will retarget .NETCF assemblies to their desktop counterparts.

Can I compile LFSLib.dll with Compact Framework? so it can work with a PPC C# project
#6 - buedi
Quote from DeXteRrBDN :Can I compile LFSLib.dll with Compact Framework? so it can work with a PPC C# project

AFAIK you can not just "compile" it against the .NET CF. You will have to go through the Sourcecode and rewrite / find new ways for all the Code which uses Parts not available in the .NET CF. At least this is what I am doing ATM for the .NET VB 2005 Sources posted by T-RonX here in the Forum.
I am looking forward for an update of you lib. I am using it for my prequal system to the Norwegian championship. Hope it will be available soon
Quote from DeXteRrBDN :do you know if this dll can be used with a smartdevice C# project?

It won't compile for .NETCF in its present form. There are a couple of things it does that .NETFC doesn't support. I have a branch on my local machine that compiles on runs the basic tests on my phone, so it is possible. (not over activesync.. no UDP support on activesync)
Quote from haelje :so stupid from me but with hosting it in another way (sourceforge gives u a lot of communication tools ), some choosen people can directly edit the source, so the work does not need to be done by one man

It's open source, so you can fork it and do whatever you want with it, but it's not a community project. The copyright still lies with my company and has to for separate non-gpl licensing, which is also, unfortunately, why I can't accept patches unless the copyright is assigned to me.
So this is taking longer than I thought. For ease of future support, I ripped out my internal packet representation and replaced with with data structures that mimic the Insim header file as much as possible. So the guts were entirely replaced. At this point I have the entire protocol implemented, but not exposed. I plan to release a stop-gap version by Monday that at least provides what was previously possible with relatively minor code changes for people using the lib (some packets changed beyond the ability to maintain the API).

Then I'll implement all the new features and TCP mode and release the full version.

The one thing that I'd been punting on for a long time and still don't like the solution to is I18N text. My internal string representation is unicode, so I can easily parse mutli-encodings coming from LFS. But I haven't found a way to take unicode and determine what codepage to use on a per character basis so i can construct a proper LFS string. Even once i figure that out, I plan to leave it as a config option whether to do any encoding processing or not and maybe even add the ability to input/output encoding via the html entity encoding model.
#11 - wabz
sdether, thanks for updating LFSLib, your work is really appreciated.

Regarding going from unicode to LFS's structure - something like the following will do it:

public static string convertToLFSString(string str) {
string ret = "";
Encoding current = Encoding.GetEncoding(1252);
Encoding lat = Encoding.GetEncoding(1252);
Encoding jap = Encoding.GetEncoding(932);
Encoding greek = Encoding.GetEncoding(1253);
Encoding bal = Encoding.GetEncoding(1257);
Encoding cryl = Encoding.GetEncoding(1251);
Encoding euro = Encoding.GetEncoding(1250);
Encoding turk = Encoding.GetEncoding(1254);
char[] c = str.ToCharArray();
for (int i = 0; i < c.Length; ++i) {
if (current != jap && jap.GetBytes(c, i, 1)[0] != lat.GetBytes(c, i, 1)[0]) {
current = jap;
ret += "^J";
} else if (current != greek && greek.GetBytes(c, i, 1)[0] != lat.GetBytes(c, i, 1)[0]) {
current = greek;
ret += "^G";
} else if (current != bal && bal.GetBytes(c, i, 1)[0] != lat.GetBytes(c, i, 1)[0]) {
current = bal;
ret += "^B";
} else if (current != cryl && cryl.GetBytes(c, i, 1)[0] != lat.GetBytes(c, i, 1)[0]) {
current = cryl;
ret += "^C";
} else if (current != euro && euro.GetBytes(c, i, 1)[0] != lat.GetBytes(c, i, 1)[0]) {
current = euro;
ret += "^E";
} else if (current != turk && turk.GetBytes(c, i, 1)[0] != lat.GetBytes(c, i, 1)[0]) {
current = turk;
ret += "^T";
}
ret += lat.GetString(current.GetBytes(c, i, 1));
}
return ret;
}

However it has a fundamental problem - if the original LFS string that you converted to unicode has, for example, unnecessary ^Js, the strings won't match. For example, ノマed may have originally come as ^Jノ^Jマ^Led, or just ^Jマed and you simply don't know - so received/sent LFS strings won't match, and however you do the conversion, they never will (BFS deals with this by storing the raw data alongside the unicode equiv). This isn't a corner case hypothetical problem - I found that people put these extraneous conversion chars in _all the time_. It would be nice if LFS removed them as they were entered...

So maybe just let the application deal with it, or provide a (static?) method apps can use if they want to convert to unicode for display.

By the way, is your new version going to support going through the insim relay? I think I sent you a patch with copyright assigned to you...
Ok, 0.12b is out. It's just 0.11b with patch X compatibility. Docs are not updated (switching to Sandcastle by 0.13b) and i haven't exhaustively tested it, but it at least should allow 0.11b people to get up and running against path X with only a few code changes.

More info is here and the zip is here.

Can't give a timeline for 0.13b, but i'm actively working on it and I have time set aside for it for the foreseeable future.

Wabz -

I tried your code and had some problems with some of characters working others not. I've settled on a lookup table from Unicode to codepage/bytevalue instead, which also has the benefit of being nice and fast.

As for the relay server, it's on my plate, but i'm also waiting to see if the protocol for its extra packets gets revved for the new patch X packet header.
One change I'm considering in 0.13b is creating sync and async models for InSim Requests. Especially since we now have requestId's to match up responses. Currently all methods that cause an event handler to fire as reponse follow the naming convention of Request<action>(). For each one of those, I'd add a method or property (if no arguments are required) that operates synchronously. For example:


// current, async way to get Camera Position
inSimHandler.LfsCameraPosition += new CameraPositionEventHandler(cpHandler);
inSimHandler.RequestCameraPosition();

// and then you get cpHandler() called with
// the results on a different thread than your request.

// proposed synchronous equivalent
CameraPosition pos = inSimHandler.CameraPosition;

I'd also add a timeout param to the config so you can prevent blocking your app in case of a communication snafu. Anyone else find this useful or is listening to events asynchronously better for the way you work as is?
#14 - wabz
Quote from sdether :Ok, 0.12b is out. It's just 0.11b with patch X compatibility. Docs are not updated (switching to Sandcastle by 0.13b) and i haven't exhaustively tested it, but it at least should allow 0.11b people to get up and running against path X with only a few code changes.

More info is here and the zip is here.

Thanks! I'll test this stuff (though BFS certainly doesn't use most of your library's functionality) soon.

I think the current event based model is nicer than your proposal - for example, how would that work with LFSMessage or RaceTraceConnection stuff, where there isn't a request for each response? Probably the one way to do things would be cleaner. Or am I missing something?
The lib is complete, undergoing testing and doc clean-up over the weekend.

I want to remove the asyncEventHandling option from InSimHandler. Aside from the mess of code it requires, it's behavior is underhanded in its parallelism in ways that most people that turn it on won't realize. I think it's going to be a lot safer for people receiving the events to spawn off their own threads if they really need to do complex operations at event receipt. Scream now, if you think this is a feature I should be keeping.

Quote from wabz :I think the current event based model is nicer than your proposal - for example, how would that work with LFSMessage or RaceTraceConnection stuff, where there isn't a request for each response? Probably the one way to do things would be cleaner. Or am I missing something?

This feature wouldn't be as a replacement to the current async behavior of request/event and would only apply to calls that follow the request/event pattern (i.e. not Send() and not events that come without request). But I'm punting on this addition for right now anyway, so i can get the update out.
sd,

I agree with that. I did something very similar way back when InSim was very new (code is gone bye-bye in harddrive crash) in that my thinking was that I didn't want to slow down API's ability to process incoming packets because someone was doing something really slow.

But the more I thought about it, I think thats outside of the scope of the API and more on the developer using it to do the right thing either by using another thread, adding it to a queue for processing later, etc.

LFSLib.NET update in the works
(16 posts, started )
FGED GREDG RDFGDR GSFDG