As far as I know, PRISM never encountered that limit. Most of the packet sending and receiving methods were written by Victor, so maybe take a look at PRISM's implementation as a reference. Considering that he is an LFS dev, he would have more information than I would, or anyone else for that matter.

Quote from Scawen :

I think some of these self-lit displays will need to automatically adjust their brightness for day and night. I've found a few references to car dashboard lighting with automatic adjustment to make them dimmer at night. The other solution could be physical gauges that are naturally visible in the day and have small surrounding bulbs to light them at night.

My dash in the 2018 Hyundai Elantra adjust based on ambient light level. There is a light sensor in the center of the dash all of the way forward so that it's right under the bottom of the windshield. It gives it enough light, but puts it mostly out of the view of the driver and passengers.

Quote from Scawen :

Here's a reference to an LED display (not for cars) with an auto-adjustment.
http://www.colorlight-led.com/new/led-display-brightness-adjustment.html

EDIT: A youtube video reference for self-adjusting traffic lights
https://www.youtube.com/watch?v=vmb1vxUFmwI

I wish we had adjustable traffic lights in America. There is an unlit state road in New York where in the dead of night the VTL (Vehicle Traffic Light) is absolutely blinding, to the point where you can not see past the traffic light itself. It completely floods the area with it's own light, it's so bight it illuminates the air particles, making it impossible to see past it. The speed limit for that road is 55 miles an hour.

Quote from cargame.nl :

thats an olllldddd discussion... No idea if the changes ever made it to the public but I discussion this 2.5 years ago already when this JRR was created, your objectinfo is empty as we discovered earlier. You can read all about it here; https://www.lfs.net/forum/thread/89003

It was never put in a release, but it landed on the GitHub.

What's really insane about the VR code is that Scawen did it without ever having a headset himself.

Oh god! That looks AMAZING!

Quote from KeiichiRX7 :

Holy crap dygear is still here

Lol, from time to time. ;p

Are the InSim devs community going to get a chance to make feature request? I'd really love to see a packet for when a tyre touches different surfaces. For example, when a tyre goes from Asphalt to Paint, or Paint to Crub, or Crub to Grass. This would allow us to make our own rules very easily about the confines of the track. Within the engine it seems that it's possible to at least know when we go from Asphalt to Grass and back again.

Quote from R0ut66 :

Will be possible to change the time with insim without ending the race?

You sir, read my mind!

---

Scawen, I don't think the visuals are there for the headlights. It looks like the lights just apply a luminance value to objects around it based on distance. It doesn't feel like the headlights are really emitting light based on the screen shots, and the headlight paths in front of the car are a fixed texture. I need to see fluid motion to be able to say for sure.

Last edited by Dygear, Sat 23 Feb 2019, 19:42.

In general it’s considered poor form to call someone a liar. It makes other less likely to help you.

There is no way to modify engine settings from within InSim currently.

Is this limited to a single light source? Could you for example add track lights for night races? Can the sun ... set?

TAA, you mean this?

https://www.lfs.net/forum/post/1748707#post1748707

I would love to see an interface into the physics engine via InSim. I know this is not going to be something that would be a priority for Scawen, but damn it would be cool as hell! Allowing for something like LFSTweak, without having to reprogram the interface every time there is a new build of the game, would be pretty great for the community as a whole.

Giving us, the InSim devs, a chance to do things like DRS and the deployable part of the MGU-K / MGU-H would be amazing but would also allow for the game engine to know that it's being modified from an outside source allowing for proper checking of this information.

Quote from skirmantasLTUgamer :

The DDoser(s) already reported the file as dangerous in Avast.
https://prnt.sc/j1uw9o

That's a common false positive with NSIS / LZMA compressed installers.

I banned Legendlfs for a month, 95% of this posts are just trolling.

For more accuracy you should use Z as well.

I would think that you'd also need to populate the `ObjectInfo::$Flags` to be `0` as well within the JRR packet. (Not that I have any idea, I haven't used the JRR packet, ever.)

Hey man, nice work!

Use trigonometry to get the distance between two packets, just as Skinzinho said. You'll want to look up Pythagorean Theorem.

If you want you can send a pull request on github and I will merge it.

I'm pretty sure LFSWorld and these forums are written in PHP and they run great. For the most part, target PHP 7.2 if you're writing something new.

https://github.com/php/php-src/blob/php-7.2.0alpha1/UPGRADING

I think InSim applications are limited to LFS instances that have a license attached to them.

UCID is a Unique Connection ID. It's uniqueness is only for as long as that connection lasts for and the numbers are used over and over again. PName is not Unique at all and are set by the player. So one play could set their name to another player name after they have disconnected. PLID only lasts for as long as the player is actually in the game for. UName is the only that that is Unique to a client across sessions and across servers. You should always use that for saving information on a client.

I get a internal service error when I try to ban him. So, I think we will have to wait for Victor.

Quote from Scawen :

I was discussing with Geraldine... we reckon when the Scirocco comes out there will be all these posts like "WTF, it's just a medium powered FWD! Why have the devs been hyping this up for all these years?".

You sir, are a class act.