Most of the problems with this sort of "karma counting" stems from keeping a running count of each user's karma/thanks. That is, the "Thanked 7 Times in 2 Posts" line under the user's avatar.

I think it's much better to judge each post individually and leave it at that. That way there's no reason to "game" the system, you avoid the whole ePenis thing, and people still get kudos for making good posts.

Quote from AnyBodyKilla :

i tried this program and it crashs as soon as i leave a garage, no error message just says report to microsoft or dont report.
I also lose my forcefeedback on my g25 too. have to restart game to get FF back.

I suggest you look into LFSRelax by Gai-Luron as I am planning on merging my TeamSpeak application with LFSRelax which does the TeamSpeak stuff and a whole lot more. AFAIK, LFSRelax is quite stable.

Quote from mrodgers :

Yahoo! I just spent 90 minutes + (9 ten minute races) waiting for the track to change in the XFG/RG server, it finally changes, and it restarts almost immediately! I get a join timer so I can't get on the track, then I'm not allowed to join for 2 laps!

I've experienced the same thing. There really needs to be a bit more time between the track change and when the next race starts. By the time you switch setups and/or cars you can actually miss the start of the race.

I'll have a look at your source code and have a look which is better. I suspect it will be yours since this was my first C# application. The only problem is that I'm rather busy at the moment, so I may not get around to it for a little while. I'll report back here when I do. (Alternatively, if you have more time, I could send you my code and you could merge the two.)

I had already thought about allowing users to change TS channel from within LFS, so I agree that is a good idea.

Also, I am happy to release the source.

Gai-Luron, I created the other TS application that mkinnov8 linked to. While I haven't had a chance to try your version yet, from what mkinnov8 is saying it looks like my version is a little more flexible than yours, hence, I was thinking that we could collaborate and merge the two programs into one.

I don't see any point in having two programs that do the same thing, and development will probably happen a lot faster if there are two of us working on it.

To further expand on what Tweaker said... Static camber is available all the time, so it's there when you begin to turn in, giving you good turn-in right from the start. Caster gradually applies more camber as you turn the wheel, so it takes a bit more time to become effective.

Are you using ISF_LOCAL in the ISI pakcet?

From InSim.txt:

// The ISF_LOCAL flag is important if your program creates buttons.
// It should be set if your program is not a host control system.
// If set, then buttons are created in the local button area, so
// avoiding conflict with the host buttons and allowing the user
// to switch them with SHIFT+B rather than SHIFT+I.

I think that time-zones would make this league just like any other; only with people from similar geographical locations participating.

If you set the races to be at a convenient time for, say Europe, then Asia and the Americas won't be able/want to race. It is then no longer a "best of the best" series, and just becomes another league.

Thanks, that's great, much faster to get around

I've had a quick look at the library and it's looking very good. I've been using Red Runner's C# library until now, but I think I may give yours a go in the future to see which one is nicer to use in practice.

Is it possible to include the documentation in the .zip file? It would be a bit faster to browse around if the pages were served locally.

If the setup with high caster is a good one, then you're better off reducing your force feedback strength than reducing the caster.

The reason being that reducing caster will reduce the additional camber generated from your steering inputs. Assuming that the setup is a good one, then by reducing the caster you won't have enough camber when you need it (in the corners) and you'll lose grip (especially in tight corners).

Perhaps I have missed something, but as far as I am aware there is no way to tell when LFS is about to terminate the InSim connection. Can we get LFS to send a "I'm closing" packet when the InSim connection is about to be terminated (e.g., user quits LFS)?

Thanks for the replies. I ended up runing LFS on a different machine on the network and am looking at the traffic that way instead.

I'm trying to use Ethereal to look at the packets going between LFS and an InSim program that I am working on. Unfortunately, I just found out that Ethereal doesn't support the loopback interface on Windows, so I can't look at local packets.

Is there a way around this? Is there a different packet analyzer that allows you to capture loopback connections?

Quote from kamo2000 :

oh and it crashes after i close lfs on nl_lsp.dll
addres 12349fd

I thought I had fixed that. I'll have to look into it some more.

The problem is that the app is multithreaded, so it doesn't always crash, only if something happens at the "wrong time".

Quote from kamo2000 :

It's not working for me - check the video attached - it's get not connected everytime and not working .

My fault?

That is weird, I've never seen it behave like that before. It does connect, but then seems to lose the connection. The strange thing is that LFS isn't reporting the connection loss.

Unless you can give me some more information then I can't really help as I have no way to recreate the problem to test it.

Quote from gwendoline :

One other program existing to display names under TeamSpeak, fps, time'clock etc...look there TeamSpeak Overlay (working all games)
Dont need open insim port.

Yes, TSO does a similar thing, but it replaces the d3d8.dll file, meaning that it is incompatible with some mods. I guess you now have a choice as to which TeamSpeak application you like better.

I have made a new InSim application that interfaces with LFS and TeamSpeak. At the moment, the application:

• Places the name of anyone who is talking in the same TeamSpeak channel as you onto the LFS screen.
• Tells you when people enter and leave your TeamSpeak channel.
  

Requirements:

• LFS W20 or later (X works)
• .NET 2.0

A zip archive and screenshot of it in action is attached to this post. Unzip the archive to any folder and follow these steps to use it:

1. Start TeamSpeak and connect to a channel.
2. Start LFS
3. Type /insim 29999 into LFS (put the line "/insim 29999" into your data/scripts/autoexec.lfs file to make this automatic).
4. Start the LFS TeamSpeak application.

You will need to edit the file config.xml if your address or InSim port differs from 127.0.0.1:29999.

Feel free to experiment with the other values in the file. They allow you to control how the application draws information onto your screen.


Other Stuff:

This is a kind of pre-release. I'm hoping to iron out all of the bugs and lock down the functionality of the application before writing detailed documentation on its use.

I'm also looking for feedback and suggestions, so if you have some please post them here.

(Also, thanks to Red Runner for his InSim library.)

I've identified an issue with the Connected property. It's not an error in your code, just something I thought I should point out for anyone else who is using this library.

The connected property behaves just like the Socket class' Connected property in that it tells you whether the socket was connected in the LAST operation; i.e., it does not tell you whether the socket is connected now.

JB: Have a look at AutoHotkey, it'll solve numbers 2 and 3 for you.

Quote from GeForz :

If you just send a button with the same id the old one is deleted. So ... just store the position somewhere

That is how I have done it in the end; I wrote a button manager to handle the button logic.

Thanks for your reply Jens. I'd like to re-iterate that I really like your library and I'm looking forward to further developments in it.

I'm using your library in an InSim app that I'm working on at the moment. Overall it's very good work, and quite easy to use

The only problem that I am having at the moment is that it doesn't handle any socket exceptions. Is that by design? (i.e., should I handle the exceptions in my code?)

Also, is the Connected property a 100% foolproof way to test if the InSim socket is connected? I only ask because my application is multithreaded and I'm getting some funny results.

Quote from Insim.txt :

NOTE : If width or height are zero, this would normally be an invalid button. But in that case if there is an existing button with the same ClickID, all the packet contents are ignored except the Text field. This can be useful for updating the text in a button without knowing its position. For example, you might reply to an IS_BTT using an IS_BTN with zero W and H to update the text.

It would be useful if some of the other fields were updated along with the Text field when W and H are zero. This would enable us to move buttons (changing L & T fields) or change their styling (BStyle field) without having to delete the original button and create a new one.

Furthermore, if the above change was made, an invisible button style would also be useful as it could simplify the control logic of our InSim programs.

Is AutoHotkey somehow related to Auto It? They seem very similar.