Sorry, I can't help, but I don't have a problem with IS_LAP here (tested against Patch X client side, not X10).

I can't see an error in your code, too, very strange...

Regards
Jens

Actually, you don't need VS for C# for this. All you have to do is open a command shell, go into the directory, where the .csproj-file is located and call "%windir%\Microsoft.NET\Framework\v2.0.50727\msbuild".
Append "/?" for further help.

Regards
Jens (Red Runner)

I really can't understand this. As I know you use my library (http://www.lfsforum.net/showthread.php?t=25390), I checked it with my TestApp (included in the zip-file).

The very first IS_MCI has Position 0, while any other values are already filled. But the next IS_MCI have correct Position-values...

Checked with W47 in Single-Player mode, connection type TCP. Both requesting IS_MCI with IS_TINY and waiting for IS_MCI because of 'interval' set in IS_INI works fine here.

Regards
Jens (Red Runner)

Quote from Knu :

I noticed tho, that the IS_MCI's Position bytes are always 0, maybe that's not exactly news for you, but I hope you fix this in your next release.

Tried to reproduce that in V1.0.0.2 without success. I hope it is fixed now. If it isn't, feel free to debug through the code :-).
If the problem persists, please report, I'll take a look at it when I'm back from holidays.

Just a minor note:
There's no information about the number of valid TCP and UDP connections in the InSim.txt, atm, it's just in this thread.

A really low priority request:
A packet informing about "Player xyz sent his setup" would be nice (LFS to InsimApp). With a second packet (InSimApp to LFS) one could reply with "save setup as 'BL1R Username'" or "discard setup".

This would allow us to write an autoaccept-application.

Kind Regards
Jens (Red Runner)

Thanks all for your comments, I appreciate that!

Regarding OutGauge:
I think I will implement "buedi"'s idea, thanks for that. To keep it simple (and safe), I think I will restrict the OutGauge incoming port to be different from the InSim incoming UDP-Port.
@buedi: Remember that OutGauge packets can be both 92 or 96 bytes. Have you tested used a tool like ethereal or Packetyzer to see, if LFS really doesn't send OutGauge-Packets?

Regarding Exception Handling:
To be honest, there's no concept at this stage. Just mentioned that the test app crashes, if it tries to connect to the wrong port.
But I think I won't catch the Socket-Exceptions, as I don't know, how I could react gently to them. All I can think of, is closing the connection and trying to re-establish it using the last connection details. Maybe this is a way, but later...
What I will do quite soon is implement a "UnknownPacketException" to react to packets with an unknown identifier. The "InvalidPacketLengthException" will be thrown, if the size of received message does not match the size expected from the header.

@Peptis: The Connected-property is, ähm, simply wrong. Just looked into the code and if the "clientSocket" isn't instanciated yet, it will throw an error. Stupid error...

Regarding Multithreading, it should work in a multithreaded environment, although I haven't tested it yet. But you should keep in mind that the underlying "socket" uses threading already, that's why I had to implement the "Thread safe UI-Updater".


As last node:
IS_NLP and IS_MCI still don't work properly and Version 1.0.0.1. I have (hopefully) fixed them in my version here, that I'll publish this evening.

Regards
Jens (Red Runner)

Hi there,

I know, there are other libraries for C# (and compatible VB.NET) around. Anyway, I started to work on my own library, just because I wanted to do it on my own to see where I get. I really want to make sure, that this library is not intended to criticise any of the existing ones!

Anyway, I think this library has some Pros (of course I do think, as it's mine ), while having other drawbacks.

Some Pros:
- Connecting to LFS is easy, just supply a string like "localhost:29999" and you're on your way
- You don't have to care about receiving messages, there is a clean event for any InSim message, no need to convert a byte-array to an object.
- To send a message, you just have to create an object and send it, no need to bother with getting it an byte-array or anything else.
- The "structs" (I chose to go for classes) don't know about there byte representation, therefore, it's easy to add new messages or change existing ones
- Although hurting .NET naming conventions, I chose to use class-names as defined in InSim.txt to ease finding, what you're looking for.
- The TestApplication is 90%-reflective, making it ready to go, if the library will be extended / updated.
- Trying to hide C++-specifics, whenever possible (e.g. you don't have to care about zero-ending strings or Numberplates with fixed char[8]).

Anyway, some Cons:
- It's not yet finished, missing a lot of "IS_Sendable"-Attributes [mostly(?) done in V1.0.0.1]
- No udpSocket implemented yet (although it should be quite easy)
- No support for OutGauge yet (missing the right idea for reacting to "no-header-packets" atm)
- Needs some refactoring (IS_Enums and IS_SubPackets both have bad, inconsistent names).
- The RequestManager was a bad idea, the packet themselves should know, how they can be requested.
- The ctor contains fixed size of the packets, will be replaced with dynamic calculation.


I'm posting that library in this early stage, because I will be on vacations next week and I fear that I won't like going on with this library immediatly after. On the other side, I think it would be to sad not to publish this library, as it might be useful for some coders to get some ideas.


I'm considering posting this lib at SourceForge to make it easier keeping up-to-date with it.
Sadly, I saw that there's nearly no traffic at JInSimLib, why is that? Is the audience for an InSimLib really that small?

This is my very first post of own code on the internet, so please be kind to me :-). But of course, I'd appreciate some honest statements about this library and the idea of making an SourceForge-Project.

Kind Regards
Jens Buchta (Red Runner)

Update 05.06.2007:
- Library updated to V1.0.0.1 (I accidently released the first version as 1.0.0.0 and don'T want to decrease the version number. This one is still not finished).
- All packets marked as "instruction" oder "both ways" in "ISP_enum" are now sendable
- Fixed a bug in IS_NLP - packet that caused application to crash
- Updated IS_NLP and IS_MCI to InSim of W32-Patch (variable size)
- Receive / Send - ComboBox in TestApp is now sorted
- minor bugfixes

Update 07.06.2007:
- Library updated to V1.0.0.2
- IS_NLP / IS_MCI contained wrong information, if received length < maximum length
- replaced Logging-Listviews with Treeviews in TestApp
- Added the abbility to see the contents of Sub-Packets (like NodeLap / Compcar) in TestApp - TreeViews

Known Issues
Library related:
- Library doesn't react to invalid packets properly
- Variable length packets always consume full length in memory

TestApp related:
- UI becomes unresponsive, if too many packets arrive (usually, if interval < 500ms and receiving IS_NLP / IS_MCI packets)
- TestApp doesn't handle any exceptions

Last edited by Red Runner, Thu, 7 Jun 2007 16:30. Reason : Informed about updated Library V1.0.0.2

This may be a problem with my sound setup and has not to be related to LFS!

I'm having real problems with interferences here, meaning that the sound gets really loud at some revs.
For example LX4:
1000-8100 rpm: normal sound
8100-8200 rpm: really loud
> 8200 rpm: normal sound again

Really loud means
a) Teamspeak with voice activation triggers
b) I get headaches while racing

I think, I read something about a "stereo effect" before cleaning up here and can imagine that this is related.

Does anyone else feel the same problems?
I did a quick test with lowering the center volume, lowering subwoofer volume and turning / moving the speakers a bit around, but nothing really helped. All I achieved was moving the inteference range a little(!) bit around, e.g. 8000-8100 rpm instead of 8100-8200 rpm.

Greetz
Red Runner

Hi there,

the problem with the Active Sync connection (until version 3.x, which is necessary for WM2003 based PDAs) is, that it supports only TCP-connection. Therefore you do have to either find another of way of data transmission or you have to build an UPD/TCP-relay on your own.
I decided to go for the WLAN-connection.

Greetz
Jens

Hi again!

In the meantime, I developed a very, very, very basic InSim / OutGauge application for my little PocketPC.

The code uses a modified version of sdether's framework.
In my oppinion, the code is not ready to be published yet (I had to try a lot of things, so the code isn't really clean), but if someone wants this as an entry point, feel free to contact me...

Regards
Red Runner

Hi there!

I'm not really sure if it was better to post this here or in the bug-forum.
I decided to post here as I think, Scawen reads here, too...

In Insim.txt there's the statement:

Quote :

You can identify an OutGauge packet by its size (92 bytes) and 4th byte : zero.

The size has already been discussed in sdether's .NET-library thread. It varies between 92 bytes and 96 bytes, if ID is off or on.

But the second statement is wrong, too. The fourth byte is NOT always zero. The 4th byte represents time. If it was always zero, it meant that a race could be max 256^3 milliseconds long (around 4,5h). As a race might be longer, OutGauge would stop working after ~4,5h...


Kind Regards
Red Runner

In the Teams-Struct, the url should be increased (as this was the one that failed some time ago...).

Thanks
Jens (Red Runner)

Thanks for your replies so far!

Of course, I want to write a tiny Insim / Outsim / Outgauge app, that's why I'm posting in the LFS forum and not in some .NET related newsgroup :-). Nothing special, just displaying some values like speed, rpm, maybe a shift-indicator and so on.
To make it short: No real new idea, just a new platform :-)

Maybe you're right and Active Sync is not the right platform to be used. I just found some examples on the net using it's underlying TCP/IP-connection to talk between the pda and the host computer. MS itself has a nice little example app, that lets you control your PDA from your PC, if it's in the cradle.
Therefore, this was my first approach, as Active Sync is available on every PDA, WLAN isn't.

I think, I'll have some thoughts on the WLAN approach, as it is the most "direct" way of networking. I don't know why, but I do have a lot of problems with all this bluetooth-stuff, it never works the way I want it to work.

For the moment, there are technical reasons to seperate the WLAN subnet from my home network, not security related reasons. But maybe I'll have to redesign my little network a bit.

Yes, the more I think about it, the more I do agree, that the UDP/TCP-Relay approach is not the way to go...

Ah, I nearly forgot: VS2005... Yes, I really like to try it (as we will get it at work soon, finally!), but the installer of Visual C# Express always hangs at my machine. Bad thing is: No error message, nothing. I even tried it on a clean windows installation, same problem :-(

Thx & Greetz
Jens (Red Runner)

Hi there!

Has anyone ever tried to implement a small Insim / Outsim / Outgauge app using .NET CF?

I tried but still do have some problems (the first and biggest one was getting visual studio .NET 2003 to work together with my hardware :-)).

At the moment I simply can't get an UDP-Connection to my server. After a lot of googling, I found one entry, stating that Active Sync (<4.0) does not support udp-connections. (http://forums.microsoft.com/MS ... ostID=605596&SiteID=1)

Therefore it seems, I'm stuck using this approach...


My idea for now is to build a small gateway-app for my PC, that establishes a tcp-connection with my PDA and converts those packets to udp-packet to talk to LFS.
What do you think about this approach? Might this be a solution?


The alternatives so far might be:
1) using bluetooth-connection instead of active sync
2) using wlan-connection instead of active sync

Both of these approaches make a solution harder to configure and bound to my special config here. Therefore I prefer the active sync approach... Using the wlan-approach, I additionally have the problem, that my wlan is on a subnet not directly reachable from my lfs-pc. While I do know how to setup a route for my pc, I don't have any idea to do this on my PDA (running WM 2003 SE).

So, what is the best way to go?
Kind Regards
Jens (Red Runner)

Hi!

I just came across an interesting site for all of you, that are experementing with DIY-Pedals and stuff.
http://www.mindaugas.com/projects/MJoy/

This page describes, how a simple (and cheap!) Atmega8 / Atmega16 can be used as an interface between buttons / potis and your usb-controller.
This solution is a lot cheaper than dedicated a/d-usb chips.

I did a quick search on "MJoy" on the whole forum with no results, so I hope, this hasn't been posted before..

Regards
Jens (Red Runner)

Hi again!

I got one more "stupid" idea: I don't know the other games but I assume all if them are DirectX 9 based games while LFS uses DirectX 8.

It could be interesting to use an older DirectX 8 based benchmark to see how it performs. Furthermore, one might try to deinstall DirectX 9 (what isn't that easy, I think) and to downgrade to DirectX 8. Of course, this can be again only for testing purposes.


Another minor point: Did you install all mainboard-related drivers? Like mainboard-USB, mainboard-IDE and so on? Might be important, too.

Greetz
Jens (Red Runner)

PS: I know, these ideas are quite, hmm, strange, but you're in a strange situation ;-)

Have you already tried to remove any unnecessary hardware?

I know, that these kind of incompatibility problems shouldn't exist, but they do.
I once had a mainboard (long ago, K6/2 300) that simply didn't want to run well with my Voodoo Banshee. The board together with a tnt was ok, as well as the graphics card in any other board. But the combination I had simply didn't work well (no graphic problems, but massive performance problem in some, not every application / game).

So I really encourage you again to remove every unnecessary hardware, including the wheel (for testing purposes). Maybe you'll find a conflict that may be solved afterwards...

Just my opinion..
Jens (Red Runner)

Hi!

I'm sorry I can't provide the one and only solution.

I think, it's best to turn off and to remove any unnecessary card, usb-device, ...

Sometimes, stupid hardware can do the worst things to a pc.


Just for example: I had once the problems, that my DVD-Burner burned a lot of crappy DVDs. So first thing I tried, was buying another brand of DVD-Rs. Problems still existed. So I exchanged the DVD-Burner, problems existed. I tested my DVD-Burner / DVD-R combination in a mates PC, no problems here.
So I started to strip my PC down. Finally, it was an older SCSI-Card that seemed to somehow lock the PCI-Bus...


Why do you need a floppy-drive for a bios update? If it is because of the stupid tools you get from the manufacturers and need to write the data to drive A:, there a exists a "Virtual Floppy Driver", that does the trick. The data is written to an image that can be burned as bootable CD-RW.

I can look for a link to this driver, as it was quite hidden in the www.

Regards
Jens (Red Runner)

Hi again!

I just noticed that I can see fuel information of other cars when watching multiplayer replays (.mpr).

I don't know, if this behaviour is by purpose and this was ok until now, but if the idea of Replay-TV evolves, it will get bad.

Regards
Red Runner

Hi there!

First of all: I'm in the lucky position of having very few disconnects, therefore I haven't read through all articles. As I'm not asking for concrete assistance, I haven't posted in that sub-forum. Furthermore, I don't have a concrete improvement suggestion (although I hope, that we can develop one here), I didn't post there.
It's just so annoying seeing others disconnect, if you're in a good race with them (especially in longer and / or league) races.

I think, we should divide disconnection-problems into three categories:
1) Client-side problems
2) Some kind of routing problems
3) Server-side problems


1) Client-side problems
There exist a lot of them. Starting with network-driver-problems, going on with background-tasks and ending with wlan-interferences. I think, nearly everything that could happen here, has been already said and can be found with the search-function.
If anyone likes to collect these problems and links to solutions, feel free to contact me and I will edit this post accordingly.

2) Some kind of routing problems
In my personal opinion, this part is a bit overseen. Everyone knows this situation when you're browsing the web, clicking on a link and waiting, waiting, waiting. Then you decide to hit the back-button of your browser and reclick that link and it loads immediatly.
I know only the very basics of tcp-connections, but it seems, that even they fail to reach their destination and I can only imagine that one node in your initial route failed. After re-clicking your link, another route might be chosen and everythings fine again.

3) Server-side problems
If the provider decides to do some weird updates or the servers capacity is maxed out, we see people disconnecting. It's pretty much the same as on client-side, although we can generally assume, that the server's connection is more stable than the client's one.

Very vague improvement idea:
This is the point where I'd like to start a nice discussion :-)

So we know, there are problems in part 2 and 3. What do we do in the computer-world, if we know, something could fail? We create backups...

Maybe, we could somehow connect 2 servers together, so that a client has two options to send packets to or receive from. We see this solution a lot in everyday usage: DNS-Servers, DB-Servers and so on...
Of course, it'd be way to expensive, if we always need two servers (especially public servers), but for "important" races, it'd be affordable to have a second server.

Where my knowledge and ideas end is a concrete solution of how such a backup-solution could work.
But in general, we can say that
a) the two servers must know each other and be somehow linked together
b) the client needs to know, there exists a backup-server and has to decide where to send position packets.

ATM, I can only think of having the client send its packet always to both servers what would be very stupid. I think, the poor 56K-Users definitly won't have a chance to race us then...
So there needs to be some kind of client-side lag detection, like
a) "Hey server1, I need some updates, where the other cars are!"
b) "waiting..."
c) "Hmm, no packets received. Server2, can you tell me, where they are?"
d) server2 answers

This type of fallback would pretty much eliminate all "mass-disconnect" problems, as both type 2 (different route to second server) and type 3 would be a bit safer...



So, just some vague ideas here. Maybe someone can leave some comments on those :-)

Regards
Red Runner

You can open the DFP. There you'll see a big gearwheel. To this gearwheel, there is a small piece of metal attached.
This small piece tells the controller, where the wheel is centered.

So you have to do two things:
1) Clean this small piece (There might be some grease on it)
2) Adjust it carefully in the opposite direction of the de-centered wheel.

Regards
RR

Thanks for fixing this :-)

Dear Victor,

there's a bug in the team-list: Concerning your readme, the url of a team shouldn't exceed 64 characters.

If you grab all the teams with (&action=teams), then you'll see, that the full url of the team "Forocoches Team" is returned. This url is longer than 64 characters and isn't cut of.

This makes it a bit hard to parse the data behind that team ;-)


Kind Regards
Red Runner

This is exactly the behaviour I posted two weeks ago here: http://www.lfsforum.net/showthread.php?t=7585

Sadly, Scawen hadn't had the time (or overseen it?) to react to it...



Hmm, maybe, it isn't reproducable on all machines.. I think I will make a video and update my bug-report.

Greetz
Red Runner

Some Teammates and myself have been racing on our server today.

One car starts to jump around the track, so our first thought was "you're lagging". But then, other cars began to jump around, too.

So, I made a replay...
Strange thing, when watching it: If you press <Tab> once to switch to "Gogo", then you can see myself (Red Runner) jumping around. So it shouldn't be related to lag.
I recorded this vid because I saw Gogo jumping around in the race.

Another teammate confirmed seeing jumping cars using my replay, so it shouldn't be related to my machine. In general, it wasn't just me who saw jumping cars in the race, nearly everyone mentioned this.


Please let me know, if you can't see the cars jumping around. I'll try to record a video with fraps or something...

Kind Regards & Thx in advance
Jens (Red Runner)

[Edit] I attached a video showing the error. The .avi is encoded using xvid (no sound).

Last edited by Red Runner, Mon, 15 May 2006 17:43. Reason : added video of the error