That's kind of the point of the packet getting sent on each node entrance. You don't need 100Hz updates, we get way more mini-sectors, and is dead accurate to the game engine, instead of calculating it outside of the engine. 100Hz updates would actually be more accurate, but also more CPU consuming. I'd love to hear Scawen's takes on both solutions. Just running MCI at 100Hz with extra vector data. Or adding a packet that is sent on each node for each car. What of these would cost more in LFS to implement?

Quote from Bokujishin :

I like the general idea of what you're proposing here, but I think there are some bits that can be removed for optimization:

Yeah, it was just the rough draft. How would you pair it down, showing the struct definition? My goal was mostly to give the most amount of detail possible for not only telemetry data for overlays, but also as a packet you could send to a Web Socket, so that the Web Client would be able to predict, by Dead Reckoning, the vehicle on a map interface.

The trick that Scawen would need to pull, is to send one of these packets every single time each car enters a new node. With the engine running at 1000Hz now, it should be decently accurate. I also wanted to say that I'm 100% OK with getting 15000+ packets per lap for a full server of just these types of packet data. It's over half a MB per lap, but again, I'm 100% cool with this. If this is something that Scawen is willing to add to the InSim interface, it was make timing, telemetry, and location tracking extremely easy. Kind of like an Ultra High Resolution Timer interface. It removes the jitter problem entirely, because the engine would be the one providing the time stamp information directly. It doesn't matter how long it takes to get to the InSim server at that point.

100% Agree with this request.

As this has been deprecated, I've unstuck the thread. So long and thanks for all of the Packets InSim Relay.

So, I implemented something like this for SimFIA around 15 years ago now. It only used the Split packets because it was the only thing that was reliable. We would have the Timing and Scoring interface that would show deltas to car in front, car behind for our league races, but it would only show for 5 seconds when the player passed a sector. The FiA and FOM get their timing information on the F1 cars from the timing lines as well, but not just each sector time, but also the mini-sectors between the marshal posts (around 200 meters apart on average) each have a timing loop on them. The FOM TV feed actually updates the deltas between the cars on each timing loop by calculating the delta between Car 1 and Car 2's time between the same timing loop. That effectively works out to an array of timestamps. It's also why you don't see a sector time display, until all cars have passed the first sector timing line.

The array would be something like ...


If you are going for iRacing type delta for players to compare against themselves, a much higher resolution timing loop is required. I'd want a timestamp for every time they enter each track node. Yeah, that's going to be like 350+ data points for each lap, and sometimes much more. I'd additionally, want their X, Y, Z world cords, as well as their heading vector, and speed (in the LFS meters per second, so the u32 where the upper u16 is the actual meters, and the lower u16 is the 65536th of a meter.)




That should get us pretty close. The
gives you the delta of time into the lap. If you're faster into that node the time delta will be negative.
if positive, you are faster than into that node speed wise than before, negative you are slower speed wise into that node.

Last edited by Dygear, Sun 14 Sep 2025, 06:34. Reason : Added more detail.

Very cool man, great job!

Love that it's on crates.io, congrats for getting it out the door. I've been a huge fan of Rust for a while now and I'm glad to see a real InSim implementation out there. I 100% agree that programming an InSim application in what ever programing language is a great introduction into the language it self. It touches so many areas and requires knowledge about various levels of the system. I didn't really "get" PHP until I built PRISM, even after years, and years, and years of working with PHP professionally.

Worth a conversation with Scawen then.

Quote from ScottLy :

I did come across a notice on GitHub indicating that something had expired. I would appreciate it if you could provide more details or guidance on this matter. Additionally, I'm interested in understanding the current state of the project and any ongoing efforts.

Your invite expired. I have resent it.

Quote from ScottLy :

My focus has been on thoroughly testing the 0.6.1 release, starting from the official release point rather than the latest GitHub commits. The goal is to assess its compatibility with the latest PHP version, specifically PHP 8.2.

As I re-engage with the project, I am keen on fostering community involvement. If there are specific areas that require attention, or if you have insights on potential improvements, I would be grateful for your input.

I think PRISM is due for a re-write. T3 and Zen did a lot of work that never got merged in that does a much better job of using PHP namespaces than I ever did with this project at the time. With things like Named Arguments (huge deal), Constructor Property Promotion, Match Expression (adore these in rust, glad these made to jump to PHP), Nullsafe Operator (cleaner code), Enumerations, Fibers, New in initializers are at the top of the list that would transform the code base today into something much cleaner.

I've never written a fiber before, but that's not the hard part, the hard part is building the event loop to make sure it doesn't miss anything. I don't think that's very well documented at this point on how to actually do that in PHP code. But that could for sure make an interesting underpinning of the engine.

Flame, you got some skill dude! This is great!

@ScottLy You now have commit rights to Dygear/PRISM on GitHub.

Last edited by Dygear, Mon 18 Sep 2023, 21:45.

Quote from gu3st :

I think it'll be a long time before we ever get realistic tracks with the track editor. Most mod tracks in other sims are just rips from other games which likely won't fly here.

I was just having a conversation with my Director of EMS about building a simulator for ambulance driving. I've had this idea for like ... 15 years ... where I would love to build my town and mod in my ambulances to use as a way to teach driving an emergency vehicle without the threat of putting a 175k - 1M dollar ambulance at risk.

God this brings me back to IS1982 (A Battlefield 1942 Mod) that featured this car. Their Death Race maps were epic.

Does anyone know if EQ Worry is ok? I see his last activity was Jan 2022.

Just a heads up, with WWDC going on you can get games that normally only run in Windows running on macOS should you be running the Sonoma macOS 14 beta. You also need to have Xcode 15 (and no other version of Xcode installed), the command line tools installed, and an Apple Developer account so you get access to the Game Porting Kit. After you've done all that they have instructions on building Wine from source using Homebrew and their Rosetta 2 layer to convert x86_64 programs to arm64. I've done all of that and I got Live For Speed working in about an hour on a MacBook Pro M2 Max. Frame rate is a little stutters here and there but it's working and I didn't have to pay Crossover to run it (Although I do have a lifetime license for that as well).

For what it's worth, the first lunch of the game is very slow from loading the textures, and subsequent lunches too. But once it's in the menu everything is pretty quick from that point forward. The GPU is reported as an NVIDIA 8800, and I find that really funny given how much Apple and nVidia hate each other. FPS is around 30-40 @ 1080p. It's fine, enough to get some LFS time in on a laptop that otherwise wouldn't be able to run it. I'd say this is a win. I also unlocked S3 on this, and that process went fine as well.

If the skins and mods are delivered over HTTP, putting the assets in front of a CDN like Cloudflair should result in a significant increase in performance as the Cloudflair servers are distributed around the world. You should also see decreased load on the web server delivering the content.

https://www.cloudflare.com/cdn/

(I do not work for Cloudflare, and I don't use any of their products. This advice comes from seeing the results of other people using the service on their own site that is getting DDoS and Cludflare handling it. Even the free tier should be good enough @Victor.)

Wow, this was quite the necromanced thread. 2008 to 2023.

Quote from manolixsvouros :

Quote from Viperakecske :

When can we see sector times ingame whitout airio?

agreed

You can do that with PRISM, it's free and open source. I'm pretty sure it comes with the Timing and Scoring plugin I made for SimFIA.

If anyone happens to have the time, building a type 3 ambulance would be extremely helpful for me. I teach driver training and I'd love to demonstrate suspension loads of the ambulance in Live For Speed. This way I can safely show how rapid inputs of a heavy emergency vehicle can cause understeer, overloading of the suspicion and potentially a rollover event.

Type 3 ambulances are the typical ambulances you see in the United States. They are truck chassis with a box attached to them where patient care happens. They are typically 6000-7000kg when loaded and powered by a 3.5 - 5.0L Turbo Diesel engine that are often connected to a 8 speed transmission that only drives the rear wheels. The rears are "dualies" meaning that they are two wheels on the left and two on the right to handle the extra load that it must carry. They are around 700-750cm in length, 225-250cm in width, and 260-285cm in height.

Thank you for your time.

It shouldn't be possible to do 200 m/s in game, unless you've crashed and bounced off a wall and are now tumbling. The game resets the car at that point because you are most likely no longer in control of the car at this point under normal conditions.

I do remember you saying that the physics happened at a higher rate, in another post a while back. I didn't realize the relation to cache hits in L1, L2, L3; That makes so much sense but not something that I had really thought about. I do wonder if the AMD 3D V-Cache would make a massive difference here. Just from looking at how the InSim packets are designed that memory alignment and structure packing is really a priority for you. How big is the Struct that contains the cars state? In the event that 64 cars are used, even if you are also running instructions from the cache, a modern CPU might still be able to fit all of that into its L1?

Could you search case insensitive for the whole word `/turn/`?

Quote from Scawen :

For example, with physics at 1000 Hz, rendering at 60 Hz graphically, we could use physics frames with gaps (in ms):
16, 17, 17, 16, 17, 17 (that represents 6 graphical frames in 0.1s).
I don't know if this slight difference between frame times would be humanly perceptible, though I'm sure it would be a lot smoother than any current version of LFS. For example, current LFS rendered at 60 Hz has gaps (in ms):
10, 20, 20, 10, 20, 20 (6 graphical frames in 0.1s).

Anyway, as I said, it's an interesting subject.

Given that people are buying 120 / 144 / 240 / 360 FPS monitors now, being able to use the snapshot from the previous millisecond for the current frame view should massively increase the feel of the car. It's 10 times the workload tho, so I have to ask, how long does a physics calculation take per car? Having to do all of the physics updates within 1 millisecond seems like a huge ask even for current gen CPUs.

This is really cool, good work!

AWS EC2 is free for a year.

t3.micro
2 vCPU Cores
12 CPU Credits/Hour
1GB of RAM
Gbps Up to 5 Gbps

These might be helpful to you.

Explain - MCI Packet information discussion.
InSim Direction help. - Direction of motion for two vehicles with a vector of direction.