#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.

I'll have a look but I don't think there is any way to remove hardware acceleration from a Godot app (it is a game engine first and foremost, after all), but the OpenGL version should have better compatibility. I added it to the latest release, direct link here if you prefer.
If this still doesn't work though, I'm not sure I can do anything else.

Weird, never seen that kind of garbled UI with Godot apps. What GPU do you have?
In any case, I just added an OpenGL version (instead of Vulkan) to the v0.2 release, can you give it a try?

This thread contains observations, questions (to Scawen and anyone else who can answer), and test results about my fiddling around with PTH files.

I've been working on my telemetry tool for a while now, and got to a point where I need OutSim's indexed distance to display meaningful data (as telemetry is typically plotted against distance along the track, and we need a consistent distance from lap to lap). This works just fine with official layouts, as they do provide this metric, however custom layouts do not. This is a problem as plotting against lap distance can result in variations of several tens of meters from lap to lap, and causes issues such as braking points, among others, to be completely out of sync on my charts.

I decided to have a go at using an already recorded lap to generate my own PTH file, and use it to compute a "corrected distance" that would try to match the indexed distance. Before generating my own files though, I used an existing one to check my calculations. See Figure 1 for an example lap around SO6R with the XRG, with the official indexed distance and my own version. It looks pretty good already, but is shifted slightly. From my observations, the PTH file for SO6R reports node 355 (of 356 total nodes) as the finish line, however when reading the file, it clearly appears that node 18 is closer. After applying a correction for this shifting issue, the two curves line up nicely, but we're not done yet!


Figure 2 shows the difference between my corrected distance and the indexed distance. While the average error is in the order of 20mm, there are several parts where the curve trends away from zero, and sometimes diverges somewhat with a growing amplitude and alternating positive and negative values. We also have 3 very large spikes where the error goes from roughly -0.4m all the way to +0.4m.


So far, I have an explanation for the average error, assuming the more obvious deviations are somewhat symmetrical: when fixing the node offset visible in Figure 1, I chose to set the first data point to a corrected distance of zero. Why? Because I have no way of knowing the proper value here: as I mentioned above, the finish line is closer to node 18 than it is to node 355, and even if the proper node was used, I've read somewhere on this forum that the node is not always (or even not that often) precisely located at the finish line. Note that I haven't checked this for myself, although I could, using the node's coordinates.

The other deviations are more of a problem, and that's where I would like to have Scawen's input, or anyone who can help me here. My corrected distance is computed in a somewhat naive way:

• For each point of my recorded lap, I look for the PTH node closest to the point's coordinates (right now I loop through all nodes, ideally I should use a quadtree or something).
  
• I then check the dot product between (next node - closest node) and (current position - closest node); if it is positive, I project the current position onto the line going through the closest node and the next node, otherwise I project it on (previous node - closest node).
  
• The final step is to get the path distance from the finish line up to the closest node (if dot product is positive, otherwise previous node), and add the distance from that node to the projected position.
  
• Bonus step: I then apply the correction mentioned above, shifting the data to fix the "reset" partway through the lap and setting the first point to zero.
  

@Scawen Is this how you compute the indexed distance? I assume there must be some difference that would explain the error in my output, e.g. maybe skipping the Z coordinate? Anyway I'll need to have another look at this.



Now we can look at the parts where errors appear in more detail, with annotations on Figure 3 above:

• 3-8s: First turn and dip, starting right after crossing the tramway tracks. There is some "noise" here, but also a clear trend moving up then down, maybe related to elevation?
  
• 12-18s: Turn 2, somewhat tight left hander. Noise only here, nodes are more dense in this area, and my line is slightly to the inside of the PTH line.
  
• 25-33s: The worst offender, chicane + uphill right hander. Extreme spikes (rough location annotated on Figure 3), not sure if 29-31s is just noise or an actual negative error.
  
• 34-45s: Long wide left hander and highway ramp. Noise as always, but also a clear trend, same as Turn 1, may be related to elevation or deviating from the PTH line.
  
• 54-57s: The dip, no noise at all here, pure trend error, likely related to elevation.
  
• 59-65s: Left hairpin, pure noise here.
  
• 73-77s: Last right turn, pure noise as well.
  

The noisy parts may be related to a problem with my calculations, I'll have another look, maybe try to ignore elevation. Not so sure about the non-noisy bits, though.



Alright, now I'd like to take a tangent and talk about custom PTH files. Being able to measure the length of a track or custom layout is a very good reason to want a PTH file, since (in my understanding so far) this is how LFS does it for official layouts. To mention just some of the races I took part in, GT2C this year had a custom layout for KY3 and WE2Y, and all E-Challenge races are built on LA1. We need PTH files for track measurement, and I need them for telemetry (still track measurement).
Using my Godot InSim library, I generated a simple square layout on LA1, following the roads (see Figure 4 above). I named that file LA1.pth and put it in the smx folder. I then recorded a lap and plotted the indexed distance and my corrected distance:


Here, the indexed distance goes up, then down (!), then up again. It clearly seems to follow the Y axis coordinate of the car, and it also appears that zero corresponds to the nodes' minimum Y value (-2000 to -1000 in my case, which translates to 0 to 1000). My corrected distance, however, is what I was hoping to obtain, so at least I can get usable data.
@Scawen Would there be any way to allow custom PTH files to be loaded, even just by replacing existing ones in the smx folder?

Going on another tangent here, AI: I know the subject has been tackled before, but I was also hoping to get some AI running on LA1 with the PTH file. However they do not care about it and immediately kill the engine. I also tested a custom PTH file on Blackwood, removing the .knw files while doing so, but the newly generated AI path was the original one, so they just went about the normal track and ignored my custom path.
Is AI path generation not (only) related to .pth and .knw files?

Last edited by Bokujishin, Tue, 14 May 2024 08:56.

Woops, didn't notice as it displayed fine on my end, fixed the URL, thanks for letting me know.