Quote from srdsprinter :

People who drive fast and cleanly gain respect.

More importantly, experienced racers who drive cleanly set a good example for others to follow. If even the experienced people drive like they own the track, exactly what example do you expect the less experienced drivers to base their own racing on?

Quote from Gentlefoot :

Nice post. On my server we run dual class FOX and FO8 and so the rules are very specific to my server. The welcome message states the rules are available on the web but I know people don't read them - even some of the people entered in the league. I can tell by the conversations they have.

One could write an insim app that would only allow drivers who have been to the website and confirmed they have read the rules join the race.

If I ran a serious server, I'd probably do that.

Last edited by nathanm, Sun, 17 Jun 2007 08:21.

Quote from sullivan_motorsports :

I cant connect to the main server, can someone help me, i am trying to unlock s1 and for some reason it won't connect. I tried disableing my firewall and that didn't work either, is the main server down?

It moved since then. There's a thread somewhere that has patched S1 binaries that contact the new address.

It should show up pretty much immediately. Make sure you're viewing all servers, and not just ones with people playing.

It goes to show how few servers people actually play on. I was also confused at first until I realized it was only showing servers that were getting used at the time!

That's what I have it doing, in theory. Scawen was mentioning that if I forced the system call to return fewer bytes than would be in the packet, it would verify that my code is working properly. Since I can't do that, I have to either trust that I got it right or send the buffer through a sub to split it up for testing.

At least perl makes the necessary string manipulation easy. As it stands, I just check to see if a flag I set indicates that I already have a partial packet in the buffer. If not, I check the indicated length of the incoming packet against the length of the buffer. If it's the same length, I whistle a tune and magically decode the packet into a nice hash. If it's too short, I get very sad, set the flag, and store what I have and wait for the next callback. If it's too long, I thank my diety of choice for my fortune in having at least one packet to decode and do that, then call my callback function with the remainder of the data so it can figure out what to do with it.

If the flag is set, I unset the flag, prepend the old data onto the new data, and do as above.

It should work, but I make lots of typos. I know the part about having too much data works fine, since it now parses the second packet that came in the same callback that prompted me to start the thread in the first place.

Quote from Scawen :

I think you can do that easily enough, just test using a very small receive buffer and ask LFS to send you loads of information, like loads of NCN packets or something.

Let's say your buffer is 200 bytes in size and there are 160 bytes in it and LFS tries to sends you a 100 byte packet, but your buffer has only 40 bytes of space, then you will only receive 40 bytes of that packet in your buffer.

Another way to say what I'm saying : The "recv" function has a parameter which is how many bytes you can receive. You can use this parameter to force packets to break up.

I could if I weren't using a very high level library to do the socket code. The closest I get to a socket is telling the library what port to connect to and what function to call back to when it's received some data.

Good thing, too. I once tried my hand at writing some socket code in C many years ago, back before I learned better than to use low level languages (I'm not cut out for them beyond minor modifications!) and all I managed to do was get mad.

Perhaps I could split the buffer up after the callback and pretend. Or I could just hope. (the most likely course of action, by far)

Quote from sdether :

The one packet per receive is the one think I like about UDP. The worst thing about TCP receive is that not only can you get more than one packet, you may also get partial packets and you so kind of have to keep a queue of received bytes around. Not sure if that's a scenario that's likely with InSim TCP, because the way each packet is sized they are unlikely to be split up into multiple tcp packets. I just had to deal with that a bunch on larger object serialization that didn't necessarily worry about 4-byte multiples.

That said, I'm still likely to use TCP for all my InSim uses, if for no other reason than the multiple connections. Previously I wrote a single InSim daemon that then used .NET remoting to let my various progs talk over that one connection and that was a pain to debug.

Luckily, it turns out it wasn't too hard to fix..about 15 minutes, but it was nicer with UDP in that I didn't have to think about it at all!

Now I just have to hope that when a partial packet does show up I handled it correctly. :tit:

Quote from Lotesdelere :

Not everyone wearing a [CD] tag has admin rights. In fact very few of the CD members have admin rights untill this will be implemented.

It seems like a simple InSim program could fix that right up.

Yes, scawen, you were indeed right, as proven by my new recv_packet function.

It must be nice always being right.

Quote from Scawen :

Could it be you are reading the TCP receive buffer wrongly?

There's a very common error people make, which is to assume they only receive one packet at a time.

In fact, you can receive any number of packets in a single call to receive data on your TCP socket.

Full details and explanations here : http://www.lfsforum.net/showthread.php?p=439516#post439516

You caught me; tcpdump proved it.

As you point out in that thread, even if it did work that way, I'd need to be more careful about it, since the InSim packet could be broken up across multiple TCP packets. That's going to be harder to deal with in my case than processing the extra packet already in the buffer. Damn perl!

Last edited by nathanm, Thu, 14 Jun 2007 09:35.

Strange..I only get one. Even if I were mis-parsing, which I'm not since it's completely automatic using a slightly modified InSim.txt, I'd still be able to see that I was getting the packets in the first place.

As I mentioned, I get one back when I should get two.


In that particular instance, I shouldn't be receiving any IS_NPLs, since I wasn't actually in the field when the InSim program connected, but I should have received two IS_NCN. (or ISP_NCN as it's printing out there)

Edited to add: IS_NCN works fine if I bring up the InSim program and then connect to the server.

InSim.txt indicates that if a program sends a TINY_NCN packet, LFS should respond with IS_NCN packets for each connection. Similarly for TINY_NPL, only it should respond with an IS_NPL for each player in the race.

When I send a TINY_NCN (so I can get information about the players already on when the InSim program connects to the server), I only get back an IS_NCN for the host, not for any other connected players. Is that the expected behavior?

If so, is there another way to get IS_NCN packets for all connections with patch X?

Quote from X-Ter :

I don't know since I don't know SQL
Actually, I know almost nothing about computers past the bit where you get them installed an connected to the Internet :ashamed: I actually amazed myslef when I managed to configure my own LAN and connect it to the Internet via router

It's pretty easy. Say you had a table called 'races' that looks like this:

You could run a query like 'SELECT racer FROM races WHERE place < 4' and it would return:

So the utility would in turn only allow foo and baz to race, since those were the only names returned by the configured query. To use your specific example, assume that the table I posted was much longer and had more results that happened to be exactly the same (imagine foo, bar, and baz are very consistent racers ) You could do a query like 'SELECT racer FROM (SELECT racer, COUNT(place) FROM races WHERE place < 4 GROUP by racer) AS racer_count WHERE count > 4' (There are really two queries, one to count the number of times they placed 3rd or higher, and one to test whether they did it at least 5 times)

Assuming they ran 5 races, that would return:

It is perhaps a bit complicated to do only what you're asking, but where it's really powerful is if you also had a table with the names of your teammates and wanted to allow both people who had done well yesterday and your teammates to race today, you could join that in with hardly any trouble at all. And you could easily have the qualification period span a week instead of a day, or any other time period you liked. The possibilities are essentially endless.

Maybe if I do go that route I should post some example queries to make the simple stuff easier.

One of my big problems is that I work in IT, so I'm not often in the mindset of a non-technical end user.

Quote from X-Ter :

Sounds like a great tool. I expect it to work with both a dedicated as well as with a non dedicated server, yes?

How about a feature that logs the users stats? Let me explain...
I run the server for 24 hours, UFR and Blackwood GP selected. The next 24 hours I switch to the XFR and only want those who made at least 5 podiums from the previous day to be allowed in. Possible? Please say yes

There's no reason why it shouldn't work with any LFS server, as long as it's running InSim and the two can communicate.

I'll add it to the todo list. My first thought on implementation is using SQLite to log the race and results information, and also allowing the admin to construct an arbitrary SQL query to decide who should be allowed to race.

Would that work for you?

Edited to add: Falcon140, those messages will soon be easily configurable. As it is, it's really easy to edit the Perl file and make it say whatever you want.

One nice thing about the DFP is that when it's set to 270 mode, it engages hard stops, so it doesn't use the FFB motor to create a "virtual" limit.

FWIW, my Rev. A pedals still work fine, but I don't drive as much as many people do.

No screenies, as there's no GUI. All config is done by file. It's just a daemon that runs quietly.

OldBloke, I could do that, since it's easy enough to check if a user is an admin, but your commands would have to be echoed to everyone on the server, since the /mso command doesn't have the originating username as part of the packet, and /mso always sends an MSO packet, rather than an MSS, which does, even when you ask for MSS messages.

Basically, that leaves your options as follows: a) do a command that gets echoed to everybody, like saying "kick <user> <reason>" in a standard talk window, which everyone would see or b) use the /mso command with a password, like "/mso <pass> kick <user> <reason>".

The user could easily be notified via race control message or private message the reason for the kick/ban/whatever, if you don't mind them spectating for a few seconds while they're given time to read what the server is telling them before it actually disconnects them.

Tell me how you want it to work, and your wish is my command.

The pit window enforcement still doesn't work right, but I got the rotator working today, except for the time-based rotation, but you can have it rotate tracks after any number of races you like.

Eh, what the hell, here's the current state of things..see if you can make sense of it.

Get it in tar.gz or ZIP (not that it needs compression :shrug

The README:

Quote from danowat :

Diameter of the DFP?, if I remember rightly it's 254mm (10 inches).

DFP is a VERY good wheel, if you can't afford a G25, the DFP will serve you VERY well.

It's actually a little smaller. I measured it at 9 3/5 inches. I'm nitpicking, though.

DFP is decent enough. It's gotten me around the track a few times.

I think I'm going to get a G25, though. If you look for a good deal, it's the same price as I paid for the DFP a couple of years ago, so it's not that steep.

I've written a Perl utility that uses InSim to perform several functions that I think are interesting.

It can:

* Send a MOTD to the user on connect
* Limit races to certain lfs accounts
* Prevent users who have never driven a car/track combo online from entering a race
* Check personal bests and only allow racers to join who have a time within an admin configurable percentage of the world record

Those pb features are also configurable to only be active at certain times of the day, certain days of the week, or any other combination of times you might dream up. At some point, I plan to make the user list time based as well, so that one might have a server wide open except during league events.

Before releasing, I'm planning to at the very least implement a track/car rotator that will prevent users from joining the race with the wrong car, in the event they have one that is now disallowed still selected.

I'm also working on a function to enforce a pit window, with the admin's option as to what the penalty should be for failing to pit within the window.

I'm hoping to have it cleaned up and released in the next day or two.

What I would like from you, gentle reader, is to help me come up with a reasonable name and a list of features for the future. I intend for it to be a kitchen sink of sorts for add-on features to make your LFS serving experience more interesting.

If you want to see the MOTD (and perhaps other features as I continue to test) in action, you can connect to "Bob's U Drive It" and play around. Try not to be too annoyed by it showing you the MOTD.

Any thoughts or suggestions are welcome.

Just download the latest logitech wheel software from their website. It's not actually specific to any given wheel.

Those sites link to an old version, and logitech deletes the old versions from their server whenever they release a new one.

This is the latest version.

Quote from nilo :

I'm with you. :Handshake

And I would really recommend it to beginners!

In fact, I started creating an insim-lib for python. Not much happened there, tough, due to some serious lack of time.

Choose your future.
Choose Python.

Python is nice, but I always seem to end up using Perl instead, unless I'm programming my s60 phone.

Now if only I could figure out why certain packets aren't unpacking properly.. (I freaking hate binary protocols)

Quote from OldBloke :

The MOTD is, in it's present form, too limited to be much use. And if/when it's expanded ... will anyone read it?

It is too small, especially if you feel the need to spell out the rules in it, which you essentially have to do if you don't want some idiot posting on the forum about how they were banned for no reason. A conundrum, for sure.

DieKolkrabe, a server admin can already make his/her server elitist, although it would require a bit more work.

When they don't listen, you whip out the temp ban. A note in the motd might be helpful, too. Something like "If we tell you that you need to spectate for a while and you don't listen, expect a ban." Sure, many people ignore the motd and the admins..those are the people I mentioned as having a bigger problem than not knowing how to drive, like expecting that they can do whatever they want in someone else's house.

It would be really nice if there was more than the generic disconnection message, so the message could be beaten into the more oblivious without a need to restrict the server as much. Another thing that would be nice, but unlikely to happen in the absence of some sort of scripting engine, is to make it so the inexperienced drivers have to spectate for a bit to get a feel for how everyone else is racing before joining the race, presuming that's how the admin wants to run their server.

I guess the problem is that a lot of people (not me) find spectating boring, so will just go elsewhere instead of trying to learn something.

And s/slow/overly inexperienced/

As a totally crappy racer when it comes to playing well with others, I think it's a pretty decent idea. I'm of the opinion server admins should be able to do what they want..after all, it's their server.

If there is a sudden lack of servers that allow slow drivers to play, I'll be more than happy to host one (or 5, I've got a lot of bandwidth). I'd host one now, but there seems to be little point..there are already a million and five compared to the number of racers.

In the interim, perhaps a better solution than a ban is a gentle reminder that perhaps it's better for them to spectate for a race or two to get a better idea of what they should be doing and where. If they don't respect the admin's wishes in that regard, they have a much bigger problem than not knowing how to drive.