Quote from Gutholz :

Another option is to record your own racing line.
Just record the coordinates over a few laps and eventually you will have enough data. If LFS's path node system is not accurate for your needs, then you can make your own system.
The advantage would be that it works on custom configs, too.

This is pretty much what the LFS pth files are, it's a reference lap with nodes/lines saved at regular intervals (with additional geometry that isn't required for deltas).

For each lap you care about: save the position, direction, speed, and time since the start of the lap in whatever interval is useful. Compare that reference lap against the current lap/latest IS_MCI data and you can calculate the delta.

I can't remember exactly what the calculations are and I haven't got time to dig into it at the moment, but it uses a combination of speed and position of all cars from InSim, and measuring distances from the .pth node lines which are used as references.

LFS limitations for Simbroadcasts usage are mostly described here https://www.lfs.net/forum/post/2056282#post2056282. I don't think they're show stoppers, just make for more edge cases and added complexity that I will need to deal with.
I don't think they'd stop you from recreating LFS Lazy type stuff though.

You can use the .pth files in data\smx for the approx racing line.

I have a WIP live delta implemented for Simbroadcasts, though it needs work to be robust enough for our uses (I mentioned this in the other thread that asked about deltas).

All the data needed to do personal live deltas is available in InSim + .pth files.

Quote from Scawen :

... if a car has daytime running lights, does that mean it doesn't have a "sidelights" option on the headlights switch (traditionally have three settings: off, sidelights, headlights) is their headlights simply off / on / auto?

Yes, DRLs have a sidelights switch (for LED ones anyway):
DRL: Front only (except Scandinavia where they also have taillights); bright enough to outshine the sun
Sidelights: Dim front to not blind people when it's darker + taillights.
Headlights: Normally still have DRL on in dim mode in addition to dipped/full beam.

Auto lights usually have the above plus an auto position.

(Not suggestions, just an FYI 😉).

Quote from Marty_Deslions :

Hey Scawen, could you also add to the interface the "Lights: off/side/low/high" message when the player does the /light head next command? Now it appears when you manually press SHIFT+3, but not when you run the /light head next command.

Does /shift 3 show the message?
If it does, that's an alternative to /light head next if you want the message

Quote from Flame CZE :

The DashLights and ShowLights properties of OutGaugePack will need to be updated at some point to include all the new light features.


enum
{
DL_SHIFT, // bit 0 - shift light
DL_FULLBEAM, // bit 1 - full beam
DL_HANDBRAKE, // bit 2 - handbrake
DL_PITSPEED, // bit 3 - pit speed limiter
DL_TC, // bit 4 - TC active or switched off
DL_SIGNAL_L, // bit 5 - left turn signal
DL_SIGNAL_R, // bit 6 - right turn signal
DL_SIGNAL_ANY, // bit 7 - shared turn signal
DL_OILWARN, // bit 8 - oil pressure warning
DL_BATTERY, // bit 9 - battery warning
DL_ABS, // bit 10 - ABS active or switched off
DL_SPARE, // bit 11
DL_NUM
};

But the packet doesn't seem to have much spare bytes to use

It already has been (see insim.txt in the patch).
The bitmask is 32bits, so will take some filling up, it's just over half used with the new lights.

Quote from Scawen :

Quick poll:

Dipped / Full Beam or Low Beam / High Beam

FWIW, my car's manual alternates between dipped and low, and calls the other one "main"

Quote from KingOfIce :

Hello Scawen,
are you considering adding the new 7D information "engine damage" to insim (more globally, perhaps a new "damage" or "car condition" package with clutch slip, bodywork, suspensions, etc.)?

Yeah, I was also thinking during the race on Thurs that separating engine damage to a separate InSim repair flag would be useful (though I imagine that would also involve changing it to a unique damage type as well rather than generic, which I assume was done to make implementation simpler?).

Not sure if this is relevant as I was on D42, but I just had a hard crash to desktop while joining a server with lots of mods.
I not sure exactly where in the sequence it was as I wasn't really paying attention, but LFS had to download a lot of mods when I restarted and connected again so must have been soon after clicking join.

FWIW, I have a real-time delta feature mostly implemented (but not enabled) in the Sim Broadcasts InSim. It can be quite accurate (tested down to at least 1ms from a replay) with some limitations and caveats (see below).

It uses a combination of the LFS .pth files (or compatible custom ones that I make as needed for custom configs and entirely new layouts) and car position & speed from MCI packets.

A note for those who are not aware, LFS "nodes" actually refer to lines which are described in the pth files, drawn to the left and right of direction vectors with coordinates (nodes) which make up an approximate racing line.


I haven't fully finished the feature yet, as we intend to use it for more accurate reporting of the race order, and there are a few problems/limitations that raise some tricky edge-cases when needing to implement a seperate timing system. We need this for a couple of reasons:

1. LFS has a "bug" where if two cars are close enough to eachother to be within the same node, LFS might show the cars in the wrong order (I believe it sorts them by PLID or something) causing the positions to flip around a lot when they physically aren't overtaking eachother.
   
2. In custom configs, we only get position changes from LFS at sector lines, which can get confusing for commentary.
   

So, to the limitations (may only be a significant problem for Sim Broadcasts'/T&S use, but they're why I haven't yet finished the feature):

1. The car positions from MSI packets are not always accurate. I need to do some proper testing, but I believe it may be significantly worse when running on a server (though it may be just as bad on the client, TBC). This comes from the fact that MCI packets aren't sent in-line with position packets sent client <-> server within LFS. MCI packets are sent at regular intervals, whereas the internal packets are variable rate. This means that the MCI positions are relying on the LFS prediction, which obviously can't always be correct. Under most condititions, this doesn't cause a major issue, but in cases of severe lag (especially combined with fast control inputs) or heavy collisions into walls etc, the positions can end up being quite wrong for one or more packets.
   
2. In default configs (and most custom pth files), the Start/Finish line (and maybe sector lines?) don't neccesarily match a node. It is often halfway between two nodes, which can be several metres away. There is also no way for InSim to find out exactly where the S/F or sector lines are with default configs, though they can be read from the layout for open config. This may not be a problem when calculating deltas to another car (the purpose of this thread I guess), but does throw a spanner in the works for a custom timing & scoring system (which is Sim Broadcasts' main use) or for calculating more accurate split times than 100th of a second.
   
3. InSim does not know when the actual start of the race happens, or (mostly for custom layouts) the correct order of cars at the moment the race starts. The initial REO isn't neccesarily the final starting order because of cars joining late/spectating. It's possible the REO gets updated later, but I've not yet tested that. This means that you can't reliably start calculating deltas until a car has crossed a split (or potentially some other line, but that would need to be configured per layout).
   

Now, the above may not be a problem if all you need is a mostly correct delta, don't mind not having data till crossing a sector line and can work around some other edge cases. It makes my uses quite a bit more complicated though

Vehicle mod: XF GTI LIGHTBAR
Details page: https://www.lfs.net/files/vehmods/1432AA

SHORT DESCRIPTION:

Quote :

XF GTI with Lightbar

DESCRIPTION:

Quote :

Stock XFG with Lightbar, various marker lights & separated tail/brake lights

Configurations:

• Amber lights
  
• Blue lights
  

COVER SCREENSHOT:

I've raised the rev limiter on the latest version, so auto gearbox should now work properly.

#8

Quote from Scawen :

When practising for tyre changes, I was pressing a controller button I had assigned to run a script with /pitins commands. But I found myself looking in the chat to see the lines "ftyre super" and "rtyre super" confirmed after clicking the button. But I got confused when I couldn't see them. It turns out that because I had F12 open the messages are not displayed (as designed). But to avoid confusion in the heat of the moment, I think I should make the result of /pitins and /liveset visible in the chat regardless of F11 or F12 menus being visible. Any objections?

Quote from three_jump :

Sounds like a reasonable idea.

That actually gets me thinking...
In combination with multiple commands (per line or script) it might also be useful to be able to assign a name (or just use the script name). So instead of having muliple returns in the chat you would get something like "pitconfirm: wet".

Prefacing with the fact that I've not played with the new /pitins commands myself yet, but I imagine if it's confirming every setting in a script the chat may get a bit spammy?

If you want to confirm you ran the correct script, you can always add an /echo command to the end of the script - perhaps with coloured text to add clarity.

For qualifying the option to enforce HLVC, where a fail means the laptime gets deleted, would probably be the simplest solution - though that would involve fixing the HLVC bugs, if they still exist, and presumably wouldn't help for open configs - maybe having checkpoint/circle objects that can trigger HLVC fail would work there.
I suppose a time-penalty option would be needed for one-shot quali.

For races, I like the idea of being able to set somewhat arbitrary time penalties, to be served either at the next pitstop or by a race time adjustment (F1 rules).

However, I'm really not a fan of instant off-track/cut penalties during races as it's often not fair. When racing in close quarters with others, you could end up running afoul of it through no fault of your own and/or without gaining an advantage.
This is usually handled IRL by having a number of strikes where you can trigger a cut timing line x number of times before gaining a penalty. In endurance races, this is usually defined as x per hour.


tl;dr for some "easy" (hah!) wins:

1. Arbitrary time penalties.
   - a) Race: issued by admin/InSim for served at stop/race time. (HLVC is too strict for this, we're not MSV I hope)
   - b) Quali: issued by admin/InSim/HLVC.
   
2. Option to have HLVC delete a lap or add time penalty in quali
   
3. Control objects to trigger HLVC (behaviour as #2)
   

For racing, I think there are so many variables, it may be too complicated for LFS to have a good general solution. InSim preferred IMO (helped by 1. above).
An x strikes system based on race length *may* be doable without settings getting out of hand, but I'm not sure how useful it would be without built-in less-strict-than-HLVC detections.

Quote from Scawen :

How to use it:

- create a text file in your data\script folder
- add a line in the text file like /ff 30 (whatever force value you want)
- rename the text file SKINID.lfs (Skin ID of the mod you want to set)

That's exactly how I used to have my setup back in the day, it works well (though not tried it with mods).

Quote from Ped7g :

So you want to rename the increase/decrease FFB hotkeys to power steering setting? What's the point exactly? Maybe that it leaves global ffb power intact and resets after changing car? Can't see other difference.

IIRC, the idea with the power steering was to make the steering weight more consistent between cars. Like an overall target weight, rather than just a global force multiplier (which is all the ffb setting is).

The high res physics seems to fix the "dancing" car issue we had on the E-Challenge grid (tested by turning on/off in the replay)

The increased CPU doesn't seem to have much of an effect on my PC, which is nice

Quote from Eclipsed :

I would oppose this suggestion - When racing in high numbered field,it's a valuable information from map to see if a driver ahead is lap down or a driver behind is chasing me to lap. And if there are 2 drivers behind me (lapping car and direct opponent),it's a valuable information to know which is which as mirrors are not always showing everything.

Yes, hence it would need to be optional as a server setting.
It would only really be useful for organised events where you can enforce racers to have the *default* colour at the beginning of their name, which would mean the old colour behaviour (ahead/behind/lapped etc) would still apply to racers' arrows, but course cars with coloured names would show that colour instead.

Thought of a potential use for the arrow colours even when lap timing is available - though it would have to be a server option:

From what I can tell, if people use the default name colour, it uses the default arrow colour?
If so, it might be useful in organised races with safety/course cars to be able to enable the arrow colours. Racers would start their name with the default colour & have the default arrow colours, and course cars would pick up the custom colours. This means racers can easily see where the course cars are.

Quote from Scawen :

The SBTV car football event is coming up soon and I thought, with the new mini map at LA1, it would be nice if the car arrows had the team's colour. I'm not sure if it might help with situational awareness, but I'm sure it's better than all the arrows being the same colour.

Will be interesting to see how that goes

Quote from Scawen :

So when lap timing is not available, I've coloured the arrows the same as the first character in the player's name. I think it works for football. It also affects cruise servers. The mini map is now quite colourful. I think this might be quite useful, but is it too colourful?

Not sure how good it would be for chases on cruise servers, as it will make it even easier for police to follow where a car is going on the map. Given the highly competitive nature, it would change the balance a bit.

Quote from Scawen :

The other new feature is a long requested one: the redline speed for each gear is displayed in the setup screen.

Nice, especially now GRC/VHPA seems to have problems saving setups correctly these days.
Would it be simple to also mark where the shift point (ie when the shift light comes on) is for each gear? Maybe some kind of marker on the sliders?

Quote from michal 1279 :

I got to ask one question regarding the concrete objects:

Is it possible to make them procedural/parametric? So the users could select own length/height/possibly radius and other geometric parameters instead of relying on few predetermined sizes and shapes the editor currently offers. Making a long straight eats up so many 16m wall objects and creation of a smooth curve with many short walls also cuts deep into the object count limit. I got into replicating some real life street tracks recently and this became a huge bottleneck in what can be made.

Or would that require complete overhaul of the layout editor system for this kind of object?

To add to this and throwing it out there for the potential future overhaul:

I've been thinking for a while that it'd be really handy to have parametric objects, especially for anything linear like the armco/barriers. Being able to have (somewhat) arbitrary length & curve radius would be really handy.
Also adding a request for 3-high armco (ie F1 armco walls) while I'm here

Quote from Scawen :

I've adjusted the code so I can generate at different sizes.

So here is a zip file showing the current versions of:

South City (4096)
Fairfield Test Centre (4096)
Bancroft Autodrome (2048)

https://www.lfs.net/file_lfs.php?name=SO_FA_BA_bitmaps.zip

Bonus top down comparison:
https://imx.tc-g.uk/20th/38

Quote from Scawen :

Eric has sent me a daytime version of the same South City view (attached).

Thanks

https://imx.tc-g.uk/20th/37

Quote from RacingSOUL :

Btw, has anyone been able to make LFS work with full motion rigs?

Several, LFS has had support for a very long time and as I understand it, some major studios have even borrowed LFS OutSim protocol.

Quote from Eclipsed :

17 years - if I can read from version history correctly,South city was released 17. july 2003 (ver 0.3A) while seems the current state of South City has been released 25. june 2005 (ver 0.5P).
People around here correct me if I wrote something wrong.

There was another South City refresh since 2005 (added a couple of new configs as well iirc), but I forget exactly when.

Edit: Test patches started Dec 2007

Last edited by Degats, Sat, 20 Aug 2022 16:52.