Simple question but I couldn't find the answer.

Is there a program for it? What are the steps?

No tool as far as I know.

However why would you want to create a PTH file? LFS won't read your PTH file, thus not reporting back the node numbers.

There is no tool to do it but the pth spec is a publicly disclosed format so one could be written.

EQ_Worry may have a reader, don't know if his modifications are made by hand or into a program he made.

Quote from GeForz :

However why would you want to create a PTH file? LFS won't read your PTH file, thus not reporting back the node numbers.

LFS doesn't but an InSim is capable of it.

Quote from Whiskey :

EQ_Worry may have a reader, don't know if his modifications are made by hand or into a program he made.

The 'trouble' he currently has, tells me that there is no easy way to create custom PTH files. I was wondering something was overlooked but it seems there are readers but no programs to write one

Quote from Dygear :

There is no tool to do it but the pth spec is a publicly disclosed format so one could be written.

I'm afraid I do not understand it at all ..

Any idea why the provided PTH files only show binary data with a basic text editor?

I understand thats not the way to it but what is...

Because they're binary files designed to be read by programs, not by humans. You would need to write some code that reads the values, or alternatively you can open it in a hex editor.

I was just about to my php-script, when I remembered, Dygear already submitted his one: http://www.lfsforum.net/showthread.php?t=71343

Quote from cargame.nl :

LFS doesn't but an InSim is capable of it.

Sure. just wondering why you would need to create a custom one as I have no idea for which application one would need a custom pth.

The only vague idea would be to use well-known pth-visualizer to visualize custom layouts. But that's a one time which could be done in photoshop etc., too...

Custom PTH can help checking lane on cruise servers for example.

Quote from avetere :

I was just about to my php-script, when I remembered, Dygear already submitted his one: http://www.lfsforum.net/showthread.php?t=71343

Thank you, I was wondering if anyone was going to use it. It even ships with PRISM, but no one notices that really .

Quote from DarkTimes :

or alternatively you can open it in a hex editor.

I did, but it didn't bring me much further.

Quote from GeForz :

Sure. just wondering why you would need to create a custom one as I have no idea for which application one would need a custom pth.

Custom (open track!) layouts needs custom PTH's.

Airio and PRISM use them to detect off path cars, cars driving in the wrong direction and so on.

Quote from Dygear :

It even ships with PRISM, but no one notices that really .

I did, I did!

But it's a reader, it doesn't write.

And even if it did, I have no clue to do that properly and even more important; fast and efficient. So before I really focus on this I wanted to search if the community came up with something already.

Ah okay.
I'm just wondering as there is no node-information sent by LFS on open configs but only position in MCI's...

I would have to take a look at the pth files on each of the tracks. I'm pretty sure that for the most part the same values are used over and over, so while we can't "write" PTH files we can however copy attributes from the other ones and move them over to our own PTH files. This will ensure that the values are correct.

It's been quite a while since I actualy checked it, but if I remember it correctly, there are some minor differences between some parts on different configs. Mostly this concerns the orientation - most obviously at the "deviation points" of course - but sometimes also around other areas (I'm not quite sure about those ones though, would have to look it up again).
What is definitely different ist node numbering, but this is no real problem.

There shouldn't even be a real problem to fit some old pth together for new configs. There will on the other hand be at least a minor problem for those areas, where at the moment no nodes exist, as here we would have to "invent" them.

But actually I thought, the "big quest" was to generate the pth-files directly out of the layout-files. THAT is, where I see the real problem ...

Quote from Dygear :

Thank you, I was wondering if anyone was going to use it. It even ships with PRISM, but no one notices that really .

*gg* Well, I did notice, but honestly didn't ever use it, because you released it, after I did my own one. But I did have a look at it and I find it quite nice (I still have to push myself towards all that object-oriented stuff :schwitz

I was thinking about that, and I think that two of the best ways to do this is:

1. From an (web) application that displays the course image. From there, we draw some polygons onto the screen where each node is from each file. From there you can select the track config you want to use, and start clicking on nodes to select them. When you get to a point where nodes for one track no longer work, you swap over to another track config that has to have atleast one node overlapping the other config, and continue selecting nodes from there, and just continue doing that until your back to your start / finish line.
   
2. The second option is to have a InSim plugin connect to the server, from there the user selects a track they want to use and enter the config they want. From there they move past the start finish line, and tell the InSim program to start tracking nodes. They continue on until they reach a point where they can no longer continue on that node path. From there they switch configs to a track that allows them to continue to where they left off. They load that track and drive to where they where before, and after they reach that point they tell the InSim again to start tracking their nodes. This way their nodes are a direct copy of the game nodes and we can so get direction details all in one go. Then then go around to the finish line and tell the InSim app to stop.

After both of these are done, the application or InSim plugin asks what to save the PTH file as. After that's done they should be able to use them path files for any race.

I had quite a similar idea ...

however, I did a little check (just on AS for the moment) and in fact I did remember it correctly ... there are some differences, so nodes are not just copied between configs as you can see in the attached pic. Those bars are the distinct nodes and each color represents one of the configs (not reversed, only "normal").

Obviously, for some of the potential new configs, one would have to create new nodes even, where they normally exist, as the corresponding turn isn't present (take the junctions for AS24 as an example) (the node has to be (almost) perpendicular (is that spelled correctly?!?!?) to the track/line which here is obviously not the case).
So, here a whole bunch of manual fitting should be needed. Another issue that we should consider is: the point given by the node-coordinates represents the ideal-line (see http://cl.racemore.de/mpres/images/tracks/AS3_1000.svg as an example: green is the path described by the node-points, black is the corresponding road, grey is total drivable area (which corresponds to the bars given in the attachment)). Thus, if we consider making our own pth-files, we should (at least this is my opinion) keep this up and define an ideal-line. But this would complicate things even further, as it would render any copying of nodes from existing pth-files quite useless ...

PS: I had to zip it, because svg isn't allowed as an attachment

Yeah, interesting. It's not going to be enough the simply reuse some of them, we are going to have to make whole new nodes as well.

I'm just a noob on this area, but here I go!

Aren't the nodes separed by about 0.2 seconds? (I think this appear on some documentation)
Why can't you drive some laps, and then select the one you followed the better route trhough the track. Then just read the coordinates at 0.2 seconds interval and then adjust width and all those things manually.

Disclaimer: if that's too stupid you can just ingnore it or call me..whatever you want

Some interesting ideas going on here.

Just to float some ideas; The paths that avetere shows in his SVG image seem to differ in position only, and may be from the relative velocities of the vehicle that possibly recorded them. Would a matching algorithm work for finding the nearest node in the direction of travel work? Dygear's 2nd suggestion could be combined with this to reuse the most appropriate path for any given configuration.

I'm not sure how the ideal line is generated, but it isn't just a spline fit. I'm guessing the velocity/mass of the vehicle is also fitted to this curve.

[Edit]
Whiskey makes a point that backs up my observation.

Quote from Whiskey :

Aren't the nodes separed by about 0.2 seconds? (I think this appear on some documentation)

The difference in positions - take the northernmost bend for example - seem to indicate they were "sampled" at regular intervals. At the apex the speed would be about the same for all 3 regular configurations that use that bend, and they all pretty much overlap. Where they stretch out may be down to the setup of the recording vehicle (different gear ratios?) if that is indeed how they were generated.
Like Whiskey, my observations need a disclaimer too.
[/edit]

Quote from Whiskey :

Aren't the nodes separed by about 0.2 seconds? (I think this appear on some documentation)

The question becomes, 0.2 seconds for what vehicle? 0.2 Seconds for a UF1 is different from that of a BF1. Do you use the lowest vehicle's time as it offers the greatest fidelity to all vehicles?

Quote from Whiskey :

Why can't you drive some laps, and then select the one you followed the better route trhough the track.

Might be able to do this pretty easily. You would have to load each PTH file to find out if the players point was in the poly, but other then that should be ok. This does assume that every part of the track as a node for it, and that it's node does in fact connect to every other node without overlapping each one.

Quote from Squelch :

Would a matching algorithm work for finding the nearest node in the direction of travel work?

I don't think it will help for when there is a transition between layouts. For example going from AS3 to AS5 might have a small gap between the nodes, or it might have two nodes over lapping. This would be a huge issue as a player can't be in two nodes at once. We would have to make our own node set from scratch!

Quote from Squelch :

I'm not sure how the ideal line is generated, but it isn't just a spline fit.

That's a very good point. I have no idea how this is generated. I have no idea if the line moves as per each car on the track, or if it's just correct for your car type, or if it's just the same for all cars.

Quote from Dygear :

The question becomes, 0.2 seconds for what vehicle? 0.2 Seconds for a UF1 is different from that of a BF1. Do you use the lowest vehicle's time as it offers the greatest fidelity to all vehicles?

That is a good question. If for example the path is recorded using a UF1, then because of the lower speeds, the resolution would be higher. This by implication would mean all faster cars would be able to use this path.

Quote :

Might be able to do this pretty easily. You would have to load each PTH file to find out if the players point was in the poly, but other then that should be ok. This does assume that every part of the track as a node for it, and that it's node does in fact connect to every other node without overlapping each one.

I'm testing that theory right now. There is an entry under options/misc - Update path Off/User Car/All Cars that I don't quite understand. Does this mean the path is dynamic? Anyway I have an AI with a bad setup driving Aston right now. Assuming the AI tries to drive the ideal line whenever possible, I'm letting it do its thing, and do not see any obvious change in ideal line - yet. The bad setup means it cannot keep a good line, and my hope is once done, and a restart performed, There will be a different ideal line, and by implication, an updated path. I'll compare screen shots of a few corners at different points and between the sessions, as well as run a diff on the files to look for changes.

Quote :

I don't think it will help for when there is a transition between layouts. For example going from AS3 to AS5 might have a small gap between the nodes, or it might have two nodes over lapping. This would be a huge issue as a player can't be in two nodes at once. We would have to make our own node set from scratch!

I see what you mean now. However, I have this feeling, and from various comments Scawen has made over the years about his use of AI drivers, that the paths could generated dynamically from a reference AI car. If the track was driven once, or a standard set of path nodes generated automatically, then letting the AI learn and record a new path seems plausible don't you think?

Quote :

That's a very good point. I have no idea how this is generated. I have no idea if the line moves as per each car on the track, or if it's just correct for your car type, or if it's just the same for all cars.

I was wondering that, and perhaps my experiment will show something up along these lines. It may well be that the ideal line is a shortest path bounded by the track limits and a best fit between along the path nodes.

Quote from Squelch :

There is an entry under options/misc - Update path Off/User Car/All Cars that I don't quite understand. Does this mean the path is dynamic?

That could be the rubber on the most used area? So if you choose only your own car there are less layers of rubber.

I don't know which car should be used to creat those 0.2 intervals, of course not the fastest one, but I doubt if the UF1 is right or maybe a FXO is better. I leave that matter to devs/programmers


EDIT:
I knew I have read that somewhere hehe

Quote from Scawen :

Path nodes are approximately as long as 0.2 seconds of time when driving a car.

That is because the original path nodes are created by driving a car smoothly around the track, then connecting the resulting path as a loop. A path node is created 5 times per second, with the position and direction of the car.

But that depends which car was used, so that's why the 0.2 seconds is just a rough guide. Anyway this means the path nodes are more spread out at higher speed sections of track.

Quote from Scawen :

[...]

Their length is not constant but there is approximately 0.2 seconds of time between passing one node and the next, when you are driving at a reasonable speed.

Quote from Whiskey :

That could be the rubber on the most used area? So if you choose only your own car there are less layers of rubber.

I believe you are correct. I thought about it after I read back what I said before.

Quote :

I knew I have read that somewhere hehe

Good find! That sort of backs up the theory that a car was used to set the initial paths, but as you say, which one? The spreading out of the nodes in avetere's svg also suggests that they were placed/recorded at different speeds too, so the reasonable speed may have just been different for each configuration.

Quote from Scawen :

Path nodes are approximately as long as 0.2 seconds of time when driving a car.

That is because the original path nodes are created by driving a car smoothly around the track, then connecting the resulting path as a loop. A path node is created 5 times per second, with the position and direction of the car.

But that depends which car was used, so that's why the 0.2 seconds is just a rough guide. Anyway this means the path nodes are more spread out at higher speed sections of track.

That quote just about confirms it.

So, now to find the secret sauce that allows recording/updating paths. I'm still running my empirical test just to see if something crops up and some correlation can be made.