Quote from Zac86 :

how do I calculate my % off the WR times?

Your time in seconds ÷ WR time in seconds × 100

Quote from F1 mainiac :

who cares what is it in the FOM TV Coverage ?

Pirelli, Formula One Management and the 500+million people who watch their coverage I guess.

I made this for anyone who's interested, not just for you, so I did it in the most logical order.

I don't see why it's so vital to be in that specific order?

The order is the same as on the official FOM TV coverage, I figured that would make sense to most people.

Something quick I knocked up:



Cromo_Plain: Blank
Cromo: Supersoft
Torro: Soft
Michelin: Medium
Evostar: Hard
Bridgestone: Inter
Avon: Wet

The Pirelli logo follows the curve of the tyre, because it's probably not possible to make it straight like the originals :/

PROBLEM: Master ban by LFS world.

AFAIK, the ban only "counts" as far as the master server ban goes if the user is actively banned while actually connected to the server. If the user is already in the server's ban list when they try to connect, then it's not counted. This would explain why there are relatively few global bans because of this - multiple connections to a server where you're already banned don't increase your tally. It's presumably also protection to stop some random server repeatedly banning and unbanning a user to get them LFSW banned while they're not even on the server.

You'd only be LFSW banned if:
a) you're stupid enough to do something to get banned on x different servers
b) a malicious server bans and unbans you multiple times and you're stupid enough to keep connecting only to get banned again
c) you're testing a banning system on your own server

SOLUTION:
If that's correct, you could avoid the master server counter entirely by kicking the player on connect, then issuing the /ban command as soon as the user has fully disconnected. That way, the next time the user tries to connect, they're already on the ban list so it won't count towards an LFSW ban.



Edit:

I also have a suggestion that I think would make this useful to a lot more servers.

Ideally, as well as only subscribing to bans made by admins you trust, you'd be able to subscribe to specific pre-defined ban reasons. Specific rules would be referenced by ID within the system, so it wouldn't cause significant network overhead.

Pros: Different servers have different rules - a destruction derby type server probably isn't going to mind if people who've been banned for wrecking on a race server join theirs; similarly a race server admin probably isn't going to care about people who've been banned for breaking many of the obscure, weird and wonderful rules that cruise servers have. I'd assume that most server admins, regardless of the type of server, would want to subscribe to bans for being abusive to other players etc.

Cons: It makes the system more complicated and less automated, particularly when it comes to adding bans to the system in the first place.


This isn't really a necessary feature and can probably be added in a later version if enough people want it, but I think it would help the popularity of the system.

Last edited by Degats, Sat 25 Aug 2012, 00:02.

Quote from cargame.nl :

Would be nice if the server logging is a little bit altered also, with the IP address mentioned in the drivername connected (lfsname) announcement. Currently its a little messy to keep track what IP address belongs to who. Especially on busy servers.

Therefore I am now the only one which can block IP addresses, while, if the log is a little bit more structured I could make a web interface for other admins.

After looking into this a few days ago, it turns out it's actually quite simple for a program to parse the log file and reliably* link IP addresses to usernames. I believe Airio already does something like this and it could fairly easily be integrated into an InSim app/cron job/whatever to populate a database.

*It's worked so far in my tests - it's successfully found my IP every time in a log file containing nearly 10 days worth of connections (3944 total) on a busy server, including a connection queue 7 players long. I've still got some more tests to do to be 100% sure though.

Quote from MadCatX :

Is the window title way guaranteed to work? It's been a while since I moved away from Winamp, but as I recall it it was quite moddable. As long as Winamp always sets its window title like this, it would probably be a viable solution.

When I last looked into it, that was the officially recommended (and only, short of writing a proper plugin) way of grabbing the song title from Winamp.

I knocked up a quick implementation in C/C++ using this method a couple of years ago that displays the current track in a button - still works today. It's also possible to use the Winamp API to control Winamp via InSim (if you'd ever want to - I did it as an experiment).

Edit: Of course, this method will break if you set the Winamp window title to scroll.

Last edited by Degats, Wed 8 Feb 2012, 00:30.

Quote from NovaK :

I don't get your point, why shouldn't it work?

That question was mostly answered on the same line:

Quote from cargame.nl :

Thats exactly why a global ban system will not work. People have different views on adminning servers.

This kind of system is technically possible (probably even relatively easily) provided someone can reliably host a database & web front end. Getting an InSim app to connect to the DB should be simple enough.

The main problem is that different admin teams tend to have different ways of dealing with things - some may disagree on the lengths of bans or the reasons for them. Ban appeals could potentially be tricky as well.


Some of the issues could be worked out using opt-ins for specific ban reasons (intentional wrecking being an obvious example) and most teams probably wouldn't want to opt-in to rules specific to only a few servers.
However, this would make the system more complicated, which brings forward the other potential issue - are there enough persistent trouble-makers to make it worth the effort?


If enough people are interested, it might be worth it, providing people are willing to put the time & effort (and money) in to keep it going in the long run.

Last edited by Degats, Mon 30 Jan 2012, 23:39.

I always used to use:
Mouse X steering
Mouse Y combined throttle/brake
(select the mouse axis in the Wheel/Joystick options)

It's a bit more tricky now that autocut is gone, but I still do use it like this when I'm without my Wheel/Joystick.


Regarding the OP - you may be able to do something using a joystick emulator or similar (glovepie in combination with PPJoy might help)

BTW, the F1 safety car actually *does* have an audible siren.

http://www.youtube.com/watch?v=W1g4g1L3_y4&t=2m35s

Quote from Scawen :

No... tyre warmers in racing are changing with the new tyre physics (most classes don't have tyre warmers any more).

Does that mean there'll be a warmup lap feature? If not, turn 1 is going to be interesting on stone cold tyres

Quote from Dygear :

I would like to be able to bind InSim buttons to keys on the keyboard. For example, should I show a menu on the screen, and allow the player to use a button on their keyboard to activate (click) that button.

A possible solution - not quite as quick to use, but should work with InSim as it is now:

The player would need to bind 3 commands to function keys (!up !down !select for example. "/o " instead of "!" for a local InSim program)

The 'active' button would have a different colour to the others. The player changes the active button using the up and down binds, and the select bind to effectively click the active button. The player would be able to navigate a menu system while still maintaining control.

Last edited by Degats, Fri 27 May 2011, 23:42.

DX10 is not backwards compatable (for code simplification/performance reasons). DX9 and earlier games run on a seperate DX9 API.


FWIW, I've never had aero get disabled by LFS. I generally only get that happen with old DirectX overlay methods - I don't actually remember any games disabling aero, only videos/media players.

However, I have had the occasional graphics driver crash in the past with other games which will knock out aero in the process.
The problem could easily be a broken driver which doesn't play nice with LFS for whatever reason - I have heard a few cases of the newer nVidia cards not being too stable with older games, this may or may not be related.


Do you use any overlays? (Steam/Xfire/gauges etc) I know Steam's isn't (or wasn't) too stable with LFS.


Has anyone else got this issue? If so, post full OS, graphics specs and driver version(s) - might help narrow down the cause.

Wouldn't a far more reliable way of detecting crashers be to use the new collision packet?

Fuel info to the host also requires the host to be 100% trustworthy with the data (ie not share it with certain other teams).

Quote from Bmxtwins :

Before I got 60 FPS no matter what, I still get 60 fps. I don't have anything capped

If it's exactly 60 FPS, you probably have VSync turned on. VSync limits the framerate to your monitor's refresh.

Quote from Bean0 :

It's those bloody Europeans confusing things again, they write 100e etc.

Depends on the country, but supposedly the standard is €100.

Quote from skywatcher122 :

is it possible to get the current throttle, current gear and brakes at MCI / NLP ?

Would be a really easy way to detect players using more gears than the car actually has as well

Quote from Dygear :

We already have that information, just parse the pth or smx files.

Quote from PoVo :

Couldn't the Nodes still be used in open configs? Simply by still using them around the track, coverting every single road of the open track.

Even though it would be quite useless, it would save a lot of time for cruise servers, because using the X and Y coordinates, it would be a pain in the butt IMHO.

Getting the data from the .pth files and converting to the open configurations is easier said than done
- The nodes are in different places on the same bit of track in the different configurations, due both to the way they were created and the different speeds involved
- There'll be much overlapping/intersecting of nodes where different routes intersect, particularly if there's a choice of route. I assume these overlaps/intersections would cause problems.

Not impossible, but the junctions in particular would be tricky, especially if there's no graphical way of removing/shortening them.

Quote from EQ Worry :

Nodes are like little sectors, numbered as incremented integers in the direction of the race path, from start to finish. I have no idea how could you have nodes on an open site where there is no predefined race path at all.

As I mentioned in an earlier post, you'd have to feed information to the InSim program based on the chosen route and use something like a lookup table to convert the non-sequential nodes to sequential equivalents. The order of the non-sequential nodes would have to be different for each route of course.
Multiple choice routes would probably have to use a combination of the above and algorithms similar to route-finding software like google maps. The route junctions could still be tricky though.

I was mostly referring to the node values sent via InSim - I'm afraid I'm not too familiar with PTH files.

It would be impossible to work out the correct direction of travel, unless the order of the nodes (not necessarily consecutive or all ascending/in the same order) is given to the InSim application for every given layout/config.
These could probably be cobbled together if there is a choice of route using techniques similar to those mapping software uses to plan travel directions. Flags & direction info could then be calculated by the InSim application. It wouldn't necessarily be easy, but it's certainly doable.


(The above may have come out in a bit of a mess, I'm tired )


Edit: If there isn't a choice of route, it'd be as simple as a lookup table.

Last edited by Degats, Tue 12 Apr 2011, 01:03.

Quote from Flame CZE :

There won't be any track nodes I'm afraid... so no yellow / blue flags, no wrong way detection.

Are you sure? Scawen has only mentioned no flags/wrong way detection afaik, which doesn't imply there aren't any nodes or similar.

Of course the server itself couldn't have a hope of working out flags or direction, but if there were nodes of some description, an InSim application could potentially do it if it knows the route(s) of the layout.

One question that immediately jumps to mind:
How will the track nodes work in open configurations? They obviously can't be consecutive anymore when there are multiple routes possible.

Quote from geeman1 :

S2 already has speed at the wheels. S1 is an old version and there are not going be anymore updates to it. It was only updated so it can be played on modern computers and the changes to the master server.

This.
LFS currently measures speed calculated from the driven wheels/transmission. There was quite a discussion about it at the time it was implemented IIRC.

If you want 'GPS' speed, this value can be obtained using InSim.

The pic in the OP is the reason LFS has the BF1.

Intel and BMW Sauber did a tour for a few years or something - there's stuff about it on the forum somewhere I'm sure.

Quote from E.Reiljans :

30-50 ms difference is pretty huge really, would you rather prefer 50 ms ping or 100 ms ping in a, for example, first person shooter?

I never said it wasn't huge for near(ish) servers - but when the intercontinental links are 300ms+ themselves, an extra 10-16% isn't going to make all that much difference in the grand scheme of things