Quote from DavidTiger :

Best thing is it dont use Insim or Outgauge so ur ports are free for other mods

I would actually prefer use of InSim and OutGauge, because I'm not a huge fan of brute forcing things that aren't meant to be forced with. You can have many InSim ports, and with a simple forwarding application even OutGauge packets can be sent to multiple OutGauge apps, so I don't think ports remaining open for other mods is very useful.

Quote from John5200 :

and who ownes that?

for example my pc is a "average pc" and already this has a quad-core and dx 10

and if i would buy a cheap small laptop (>200€), even that would have dx 9

cmon 95% of the windows users, use win xp +

Sorry but that is not an average pc. That may (possibly) be an average new pc, but by no means is that the average pc. DX9 is an appropriate average for graphical capabilities; hyper threading / simple dual cores are possible average, or still a little above average. And by average I mean what people actually use in their homes, not what they would buy if they went out to get a new computer.

Sure I would like to see DX9 effects, but changing the engine over from one version to the next really won't add ANY improvement in the graphical quality, it will be a large pain for the developers and not get very far. The only way it would improve is if the developers actually added new effects, some of which even DirectX 8 would support, although in my personal opinion graphical quality of LFS is perfectly fine, it is fully immersive, and to me that is all it needs. To many games these days jump on the 'better graphics' boat. And when new techniques come out they get over used. Sure bloom is a nice effect, and can be present in certain situations, but games over bloom so that their players can recognize it as a special effect.

Gameplay is what is important, graphics need to create an immersive world, and nothing more. LFS's gameplay is all in the physics and racing 'rules'. Meaning, adding features like brake fade, engine overheating would add to the physical gameplay of LFS and adding things like a proper burnout, staging and tree for the dragstrip would add to the racing 'rules' area... These are things the developers should focus on. There are still a few more graphically immersion related effects LFS could benefit from, and I am sure the developers will get there, in their own time, as they knock off the list of things they are implementing.

I can't tell much about it but I have an idea that the problem lies somewhere within this:

Connections[GetConnIdx(Players[GetPlyIdx(BTC.UCID)].UniqueID)]

Also, I noticed that that was copy and pasted several times throughout that code snippet, as an improvement, both for speed and readability you could do:

Connection c = Connections[GetConnIdx(Players[GetPlyIdx(BTC.UCID)].UniqueID)];

and using c.InShop, or c.UniqueID etc for the code rather than the long, and slower access of Connections[...] each time. Small improvement with speed, but a large improvement for readability. Anyways, I have a hunch that your problem would lie within the Connections[] IDs somehow, if possible.

I know this didn't really help you much, but I figured I'd give some friendly advice. (By the way, if the Connection has a UniqueID why can't it just be something like Connection c = Connections.GetConnection(BTC.UCID); or something similar, rather than searching through the player, then the players connection etc... Could that be the source of the problem? If it was my code, obviously it isn't, then GetConnIdx(Players[GetPlyIdx(BTC.UCID)].UniqueID) would be GetConnIdx(BTC.UCID), which is what I was mentioning with my "GetConnection" method above. Anyways, good luck.

Well, if it is money toward LFS Developers directly I have 24 + cost of hi-res skins x 1.

Other LFS related costs include servers that I've borrowed and donated money for, my teams web-site hosting and other costs associated with the team. I am glad I have help from the other founders as well but those costs are 100% "to LFS entertainment" deemed by me.

Then I have the hardware stuff that I bought purely for my LFS enjoyment / immersion. My PC itself can't be described as completely built for LFS, though 1 gfx card and 1 monitor was purely for driving LFS with 3 monitors. TrackIR was purely for LFS as was the ButtKicker, Obutto cockpit (with personally made monitor stand), and the G25 (I had a momo when I started LFS and quickly realized I wanted all three pedals, an h-shifter and things that allow me to get more immersion from the simulator.

These are all costs I attribute to LFS, even if they are useful beyond LFS my original intention was for racing simulations, of which LFS is the only I played at the time, and currently the only I still play. (Tried iRacing for a month but I don't have the funds for a subscription based game, especially when I can't even race multiplayer. . . Damn internet connection.)

So over all, I've spent a lot on this 'hobby' in relation to LFS. But I would, and will likely do it all again. Of course these upgrades happened over quite some time, it isn't like I went out and bought it all in one night.

That goes against everything I've ever taught myself. . . When the car tilts up I react too quickly to put four on the floor... I already know if I got the car up on two wheels, at a stable position and speed, keeping it there wouldn't be much of a challenge when driving in circles like you did. Drive a lap on a circuit with two wheels and I'll be very impressed :P Nice setup though, easy to get it started but my reaction always puts the tires down, and I don't want to train myself otherwise.

I don't know about the licensing behind PPJoy, although I would believe free. It is something the end-user would need to install, or if you're creating special sim-pod type thing you would install it, in which case you might need to look into the legal side. As far as end-user support, I stick to the fact that PPJoy should not be expected for the general public to download, install and use. It can be confusing and not "plug and play" enough for public use. The AIRS project is still in development, although I may need to change gears a bit and develop a simulation world for testing my AI. AIRS stands for: Artificial Intelligence in Racing Simulations. It is a project more for simulation AI Drivers instead of GAME AI drivers which I strongly believe there is a difference. Games are meant to be fun, while the simulation is meant to _simulate_. See the A.I.R.S. thread for more info about that particular project. Beware the length and discussion that has taken place so far.

For the most part I am sure you can do what you need to with the LFS interface just with LFS itself, there are numerous options available from custom camera views to virtual gauges and so on.

Much better, now it somewhat resembles the patterns I feel. I don't know about how accurately but enough to get the point across in a graphical fashion!

While I agree with a lot being said by your post amp88, I would have to disagree with the image. I don't have the motivation to draw my own thoughts on it. You seem to nail my idea though if you were to reverse the colors (IE: the blue is the grip and the red is the temperature). I say this because in the beginning 10 laps your temperature spikes and grip drops because of this spike, but is regained as the spike levels back off for a slow decent of temperature. Then throughout the life of the tire the temperature drops slowly as the grip is increasing. I love tires at about 65 to 70% worn in LFS, (assuming they are worn to my driving pattern which is typically the case) because during this time the tires actually seem to have their own natural 'worn' camber working with me and my setup to provide the best lap-times possible. During the late stage of the tire, the temperature drops significantly because the tread is too thin. This effectively reduces the grip levels and warns the driver to start thinking about a pit stop.

I *just* got done doing 35 laps on R1s with the FOX at AS7 (Aston North), and I ended up popping my right-rear tire on lap 33, though if I wasn't so distracted with watching certain things I likely could have made the tires last all 35 laps. There were a few spins and slides that cut deep into the tires and wore them faster than necessary.

Just as a note there are places where that flag can be set even under racing conditions, so slowing the cars down might set the flag in even more conditions than you would think. These are just words of caution for you to think about as you develop, sounds good but it doesn't seem much like an actual pace car - though is nice to keep people in the ordered manner.

Perhaps make the admin command something like this;

/ignore_car username1
/ignore_car username2
/start_safety

... safety is running
/ignore_car username3 //this guy spun while under safety condition
/finish_safety

Something along the lines of that, where finish_safety clears all 'ignored cars' and any ignored cars are safe to be passed by other cars that are not ignored. Just an idea, it is less automatic, but it is more accurate under different situations.

You can pause with AI, as long as you were in Single Player mode. If you started your own private host and added an AI it wasn't because of the AI but was because it was a multiplayer game that you started.

'P' to pause, just pressing escape won't pause the game even if the menu appears.

I don't know what data you actually need to get, but as AndroidXP pointed out PPJoy works for inputting data from a virtual steering wheel. A few things I've noted while working on my AIRS project using the LFS racing simulation as it is retrieving information from LFS and inputting it back in through PPJoy:

1) PPJoy is likely someone as a casual user would not be able to simply download, install and go. They need a bit of technical knowledge to do this, and the ability to trust unsigned hardware, by clicking "install without certification".

2) I personally had some issues with PPJoy to LFS as a form of input. It took me a few days to get this setup. Within the first day I had input in LFS, but it seemed to me that all axis controls did not center themselves right. For all I know I did something idiotically wrong with the programming interface, though I tried to make it right, in the end I just hacked it so that it moves it offcenter and allows LFS to think it is centered. Enough to the point where the car stayed within 5 inches of the white line down the dragstrip.

3) Getting information from LFS is the easy thing, and I don't know of anything else that supplies the information like LFS (or as much/detailed). If you haven't found it yet Insim.txt in the documents folder would deserve a look over for you. There are three protocols:

3a) InSim Protocol: This is useful for almost everything you would need. When a race starts, what mode LFS is in, are you connected to a server. There is some information available about the car position and orientation. Lap times / split times / qualifying times, etc the list goes on.

3b) OutSim Protocol: Admittedly I haven't been using this like I thought I would need for my AIRS project. Though I may need to in the future, it give more detailed information about the currently spectated / driven car and the motions it goes through. As with my AIRS project though, tabbing to spectate other cars will mess up the 'data output'. Which might not be important to your project.

3c) OutGauge Protocol: This gives you all the information that the driver could get from the gauges and controls of the car; what gear is it in, what location are the pedals / steering wheel actually at? Headlights / indicators on? Fuel level (for player only), speed, rpm etc the list goes on. Again, tabbing to spectate other cars mess this output up, at least for my AIRS project which the AI driver depends on the information!

4) To control LFS, LFS _requires_ focus. Meaning if your application requires focus to get steering wheel input and send it to LFS you will not be able to drive in LFS. Your application will need to run in the background, silently collecting information from the G25 and feeding it back to LFS which is in focus. Otherwise you won't move the car.

5) What about FFB I don't think there is any output of this from LFS, so it might be hard to apply FFB to the wheel. Although, during my AIRS project I believe if the FFB in LFS was still on that my G25 would thrash around even if a PPJoy virtual controller was being used as well. So maybe this is a moot point that will go away.

Finally good luck on the project, although I don't know anything about how you will be manipulating the data. I hope my post is helpful since I've had a bit of experience with things your trying to do, at least it seems.

This is a snail of a thread, pretty much 1 post every ~4 months or more.

Anyways MaKaKaZo, why don't you use the flag provided by InSim to check whether the interface is shown or not. I recently read about it in InSim.txt while I was searching for a solid way to detect certain things.

Ahh, demo and XRR?

I've usually used dynamic arrays, or vectors (std::vector in C++) for tracking my UCIDs and PLIDs. This is an array that grows and shrinks as more/less players/connections come to the server. Though really it is a little more complicated because my 'DriverManagementSystem' which handles new connections, renaming, joining/spectating etc does all this behind the scenes for me and it's been forever since I touched that code (2yrs I think?). But I remember doing something where the PLID and UCID knew about eachother and I think I actually had a list of PLIDs for each connection since there can be multiple.

This way it only takes the memory needed. You might be right with the UCID thing, but if by chance LFS moved the limit to 64 in race and more for spectating what would happen to your code? It'd break, and InSim likely wouldn't need to be updated for that switch to happen. Hope this helps with array stuff, I don't know about dynamically sizing arrays in php because I don't know php : / but I know all about it in C/C++!

Quote from morpha :

They do have indicators, therefor they do have indicator relays.

I wasn't saying they didn't have relays or indicators. Just stating I am not sure the GTR class should since it is a purpose built race car, not a daily driver/track car combo. That said I understand the relay (which is required for the indicator) is what makes the sound we are all familiar with. But I just stated that with the GTR class it is a toss up whether they should even have indicators (lights included) in the first place. It is kinda like the single seaters don't have headlights or indicators - because they are purpose built race cars.

I've always assumed they could get to 255. I guess it depends how fast people are joining/spectating or connecting/disconnecting. I wouldn't go assuming those values though, since the type is a byte the value can range between 0 and 255 even if in practice you rarely see anything larger than what you say. (Unless you have significantly trustworthy documentation, although I still don't know why you'd put in the assumption since it is a byte still... My thoughts / opinions.

How is your C++ practice going?

Umm, we needed to know?

I mean, really that should be your first 'tweet' I believe it is called...

(This is all being said sarcastically not angrily! So please take it as the funny that it is not.)

There was a discussion about this earlier. A few things I remember about it was;

Some people saying race cars remove the sound ticker.
Others saying the sound ticker would exists since it is the mechanism that changes from light on to light off state as some form of mechanical reason.
Some people agreed with the idea,
others did not.
Some people said the improvement is too small, and then the response -> why say no to small improvements.

I am probably forgetting things since I had only briefly read that thread. Not meaning any harm from saying the above, not even saying I agreed with or that there is truth in the statements just saying what I remember.

That said, I think it is an interesting improvement for the road cars. Cars that are daily drivers that are track ready as well. STD, TBO LRF etc. GTR I remain skeptical about since it is a purpose built race car, designed for the track. While some track policies may allow/require indicators, I am pretty sure there are lots that don't/disallow. So my opinion here is 50/50 for the GTR classes.

Does the OP know that you can be driving along the line and all of a sudden be pulled off exactly how he is talking. It is still the drivers fault for not changing the tire sooner, for locking up the brakes often or cutting a tire during a turn. The tires in LFS do pop, for reasons of the drivers fault. And when it pops it can be quite unexpected, go race some longer stints.

S3 isn't finished so you can't download without the 'hassle' of waiting.

If you mean pay for S3 without the promise, guarantee or anything that S3 will or will not ever be yours, you can add money to your LFS account, which would be used for S3 when it is finalized. Since there is no release dates, or things truly set in stone, I would recommend just waiting and paying when it comes.

Are you talking about building to 'exact' specifications?

I stated I'd like to build an LX4/LX6. In real life these cars are comparable to Lotus 7's, Caterham's etc. Or the popular choice for builders; a 'locost'. This doesn't violate copyrights, yet I would still consider when I do end up building mine that it will be like an LX4/LX6 depending on how I do the build.

Eitherway, it wouldn't violate any copyrights or laws to build something to the specifications of a RAC, MRT, BF1 etc - it would only do so if you tried commercially selling it to race teams or the public for that matter. For personal use there isn't anything anyone can do with you buying all the parts and following a pattern/specification etc... It only fails legally when trying to sell the product or trying to patent the idea as your own.

I agree UCID is a faster comparison, as I mentioned above that was the downer for doing it my way, but when your checking events; Grid Reorder, Race Finish, Joining/Spectating then the time wasted in string compare is a fine sacrifice. I consider a 'session' the amount of time my application is running, not the amount of time that a client is connected to the server. Therefor the UCID changes during a session, in my eyes. And whereas I have a solution, by creating a third id unique to my program for each client - I haven't seen the need - though I see the need to if using that for a real-time update (MCI etc... or just running a real-time application instead of event based that runs at 15fps at most).

CPR.PType ?? What is this, I don't have any documentation on it.

LFS does have Single Player mode and Tutorials that get unlocked online to get S1 or S2 licenses. If you get a new LFS patch you need to re-unlock your license, again online.

Yes you can play the demo; a few cars with a track! And even a few tutorials all without an internet connection - assuming you had access to LFS in the first place.