#42 reporting for duty.

BTW I think you meant September 26th.

GodotInSim v1.3 is now available on GitHub.
It introduces more format customization for GISUtils time strings, the default grey color for LFSText, as well as fixes for LFSText (some characters in the extended characters of the Latin code page were not being converted properly), and a few other minor additions or quality of life improvements.

Also, while I haven't had as much time as I would like to work on actual projects using this tool, here are a couple sneak peeks:

• Multi-class standings and live gaps, each class can be configured with arbitrary cars, and a "hidden/ignored" class can be used for safety car and other utility vehicles if necessary.
  
• Live delta, displaying the time delta to the best recorded lap of the session, and colored arrows showing the derivative (current improvement (or lack thereof) over the best lap, that's the rate of change of the delta). Also displays final deltas for each sector.
  

Sadly I did just check, and I'm getting the same value for all tyres, even non-existing ones (e.g. 0 (R1) for "all 4" tyres of the Reaper X1 bike, or 5 (road normal) for the 3-wheeler Hadraplan). At least that's what I get with the default setups.

I haven't checked the values, but the IS_NPL packet gives you the tyre compounds for "all 4" wheels - maybe 2 of those values are equal to TYRE_NUM, which would indicate a motorcycle?

#42 will be racing.

As gu3st said, the DDoS situation certainly hasn't helped with Scawen's ability to make progress; he's been quiet on the forums in the last month though, let's hope this means he's able to focus on the the new physics without too much distraction.

It would be great to get a few new sneak-peek screenshots from Eric's side as well, I'm not sure whether he is working on the new tracks we saw in the 20th anniversary news post, or improving existing ones (South City being the main one I believe, maybe Fern Bay?).

Entry number : 42
Entry team Name : Yes We Kan
Car: Protech 92
Entered driver (Ingame name / LFSW name / Country) : (Cyk / Bokujishin / France)

Maybe not a bug but rather a design decision, but in hotlap mode, crossing the start/finish line for the first time (starting the first hotlap) does not send an IS_LAP packet, which means we have no way of knowing when this lap starts. This can be an issue for many possible reasons: triggering a new telemetry dataset, starting custom timing or delta time, etc.
Following IS_SPX and IS_LAP packets are properly sent, starting with split 1.

Given Flame's screenshots, it looks like you should only need to change the mapping so 10-160 maps to 16-255.
Checking a couple values by taking similar screenshots with diffuse lighting only would ensure it is correct.

GodotInSim v1.2 is now available on GitHub.
I forgot to announce v1.1 last weekend, which added the new IPB packet in LFS 0.7F.

v1.2 goes back to using the "standard" plid syntax instead of player_id, which is a breaking change. It also fixes MST packets not interpreting messages starting with a slash a commands.

I'm also working on a more advanced tool as a demo, which will display race standings and driver statistics as well as a minimap showing blue/yellow flags and coloring cars by car/category/lapped/etc.
The goal is to allow preparing a race by specifying categories (e.g. P2/GT3), separating safety car/rescue vehicles in a dedicated category, and showing standings by category.

FWIW, I had a look at the colors corresponding to 10-10-10 and 160-160-160, they are respectively 12-12-12 (0c0c0c) and 200-200-200 (c8c8c8).
However, I believe mapping 10-160 to 0-255 is the way to go, as limiting to 200 would definitely wash colors away.

Hi Scawen, thanks for the update! I have a question related to the new ISP_IPB packet: its size is 8 + numB * 4, and there's BanIPs [IPB_MAX_BANS], of type in_addr which is not documented. It seems quite logical that in_addr is size 4, and this makes me think that each of those bytes represents one part of an IPv4 address; does this mean that IPv6 addresses are not supported here?

Short answer: yes to 2) and no to 1) and 3). The editor allows you to create complete vehicles, as well as edit any existing one to your liking. There is also a "Test in LFS" button for local testing, and there is no obligation to publish mods.

As far as engine tweaks are concerned, I'm not sure 10k hp is possible, as values are based on physical parameters; you can definitely go over 1,000hp though. Also keep in mind that engine mass is calculated automatically, a more powerful engine will be heavier.

I would suggest going through some of the editor tutorials to see what and how you can tweak things, I believe you will find them in the vehicle mods forum.

While catchfencing may require some additional work, I definitely agree kerbs should be a rather easy addition that shouldn't require the new graphics and physics, plus they should not affect object count too much (at least in places where other objects were used instead). I hope they can be included in the next InSim incompatible update (at the very least 0.7F will have some InSim changes, so maybe this could be an opportunity to update object index data?)
Those additional sausage kerbs from the new year screenshots would be a welcome addition at the same time.

If the preferred way to tackle this would be to improve the layout editor first, it will also have an impact on InSim, as it will need to take the additional features into account. The most obvious change would be in the ObjectInfo struct, I think; it would need to increase in size from 8 bytes to whatever is needed for higher precision placement of objects (especially along Z axis and heading), and this could also affect other packets that have parameters using the same format as ObjectInfo (JRR, UCO and AXM use ObjectInfo directly, OBH uses same format for XYZ and index).

With that said, and following what thegamer23 said, I think it could be nice to have grass/gravel/asphalt (and any other type of surface, really) as a flag in what are currently concrete blocks only. That way, combined with higher precision placement, you could make proper terrain within the layout editor. It would most certainly require 2 things, though: a higher object count, which is already an issue for more advanced layout, and as a nice-to-have bonus, a layer system, so the entire layout wouldn't become a cluttered mess from "terrain blocks".

As far as InSim is concerned, the increased ObjectInfo size, plus the increased object count limit, would require more bandwidth, but some clever grouping of values could help alleviate this (this is already the case for some data across InSim).

Hi, glad you got it working! Did you simply delete all files related to the app? I believe that as long as you download version 0.2.1, and follow along the above video, everything should be working (I just checked again on an old Windows PC and it works fine). Feel free to tell me if you have any other issue.

Did you download the latest version? (hotfix for file names) Recording would fail on Windows before that.
I just checked on a Windows 10 install I have lying around, and it works as intended there. Check the video I posted for @superlame a few posts back if needed.
If you still cannot get recordings to work, could you please try and launch the tool from cmd or PowerShell, and post the log here after recording and trying to load data?

FR: Je ne vois pas forcément de quels tracés tu parles, mais oui, l'éditeur intégré demande du temps pour créer quelque chose de propre. Le seul logiciel externe dont j'ai entendu parler est l'éditeur pour Blender, peut-être qu'il facilite certaines choses, mais il n'y a pas de solution magique, il faut être prêt à investir du temps.

EN: I don't know what layouts you're talking about, but yeah, LFS's layout editor does require some work to get good-looking layouts. The only (recent) external tool I've heard of is the Blender layout editor, this may help things a bit, but there is no magic solution here, you need to put in the work.

Thank you Scawen, this is working just fine now

#21

OK, that was my bad, I forgot Windows was picky about file names (can't have : in the names).
Here's a link to the fixed version.

Here you go: https://youtu.be/sj53MN9EkpA
I recorded this on Linux (I only have a Windows virtual machine and nothing really works on it), but it should otherwise work exactly the same.
As long as your cfg.txt is set up properly, you have InSim running in LFS, and the recording tab shows "Connected", you should be able to record and then load data (I renamed the tlm folder so the app would create a new one before recording).

From your last screenshot, nothing seems to be out of the ordinary, so maybe it's something in your cfg.txt? You can also try to run the Telemetry from cmd/powershell, you should see some debug info; maybe something goes wrong when you try to load a lap, if you have laps recorded at all.

Edit: Also, make sure that LFS is not running when you edit the cfg.txt file, as LFS will only read it on startup, and write to it again on shutdown, so it will ignore your changes and then erase them.

Last edited by Bokujishin, Wed 15 May 2024, 18:25.

Ah yes, apologies, I did not explain how to use the tool at all, will add that to the first post.

Right now telemetry does not display in real time, you first record a session, and then display it in the telemetry tab by loading a tlm file ( a file is created when you start recording and each time you cross the finish line).

You should not need to run as administrator, tlm files are recorded by default to %appdata%\Godot\app_userdata\LFSTelemetry\tlm, and the file dialog should open there when you try to load a file.

Small gotcha if you record a hotlap replay: crossing the finish line to start the first hotlap does not trigger a new lap event from InSim, so if you start recording "too early", the line will jump across the entire chart. I suggest either waiting for the lap to start (losing a few data points in the process) or slowing the replay down to catch the start of the lap, then resuming normal speed (you can even record in fast forward with no issue as long as your computer manages).

Good to hear you got the visual glitch resolved. By the way, you can leave everything empty in the recording section, it defaults to those values anyway.
The data is recorded through OutSim (and OutGauge for ABS/TC), but unfortunately OutSim only outputs data when you are in cockpit view or custom view, so outside views will result in holes in the data.

Okay, had another go with a different approach: I am now looking for the position of each point within a quadrilateral formed by the left and rights limits defined by the next and previous nodes. Using a nice formula I found online, the figure below plots the previous error (in blue), and the new one (in orange):

This is much better! I'm honestly okay with this result, as the largest deviations are still smaller than the previous "normal" ones, and there are no more large spikes. It's also much more consistent, the noiseless deviations are no more.
I will still need to compare more laps and different tracks, but I am much more confident in this result.

The only problem now, I guess, is that custom .pth files will need to have proper limits for each node, to ensure all quadrilaterals are convex.