How to create PTH files

[cargame.nl]

Simple question but I couldn't find the answer.

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

[GeForz]

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.

[Dygear]

There is no tool to do it but the pth spec is a publicly disclosed format (http://www.lfs.net/file_lfs.php?name=SMX_PTH_S2Y.zip) so one could be written.

[Whiskey]

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

[cargame.nl]

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.


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 :shrug:

[cargame.nl]

There is no tool to do it but the pth spec is a publicly disclosed format (http://www.lfs.net/file_lfs.php?name=SMX_PTH_S2Y.zip) 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...

[DarkTimes]

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.

[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

[GeForz]

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

[misiek08]

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

[Dygear]

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 :).

[cargame.nl]

or alternatively you can open it in a hex editor.
I did, but it didn't bring me much further.

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.

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.

[GeForz]

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

[Dygear]

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.

[avetere]

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

[avetere]

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:) ;)

[Dygear]

I was thinking about that, and I think that two of the best ways to do this is:
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.
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.

[avetere]

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 ;)

[Dygear]

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. :(

[Whiskey]

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

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 :nod:

[Squelch]

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.


Whiskey makes a point that backs up my observation.
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.

[Dygear]

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?

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.

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!

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.

[Squelch]

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.

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.

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?

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.

[Whiskey]

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 :schwitz:


EDIT:
I knew I have read that somewhere hehe
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.

[...]

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.

[Squelch]

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.
I knew I have read that somewhere heheGood 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.
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.

[Dygear]

We can get around the whole track with the pit limiter on. We could just use that, taking MCI snapshots of our X, Y, Z every 0.2 seconds (200ms) that should give very even results that can be use inter-portably between different layouts. But we still need a way of knowing the width of the track, but again for that you might be able to use the current node data, I would expect that to be the same (I hope anyway.)

[Squelch]

We can get around the whole track with the pit limiter on. We could just use that, taking MCI snapshots of our X, Y, Z every 0.2 seconds (200ms) that should give very even results that can be use inter-portably between different layouts.
Very good idea. I was just thinking about layouts. There would need to be a valid/verified pth for each and every layout wouldn't there? I'm guessing that Scawen has never released, or intended to release a path editor because the paths for the official configurations were all that were needed. Any autocross layout - as I imagine was originally intended for only autox - would have been beyond the original scope. That has all changed now if open configs are here to stay.

But we still need a way of knowing the width of the track, but again for that you might be able to use the current node data, I would expect that to be the same (I hope anyway.)Yes the existing node data should still be relevant, it should only differ in its direction and where they fall in between existing nodes, they could be interpolated. As far as track width is concerned, can't this be extracted from the smx files?


I just had a horrible thought.

Cruise servers would like to be able to drive both ways on a section of track. If the existing nodes widths (not inter node distance) are used, there would be a conflict. This is also true for rally style layouts that may use the same bit of track, so some method of defining the width would be needed too. Not something that is too pressing right now, as the paths - any paths - need to be created first, but worth bearing in mind.

[Dygear]

As it turns out, you can get this from the PTH->Nodes->Limit, it gives the left and right limit of the track given as a float.

[Squelch]

As it turns out, you can get this from the PTH->Nodes->Limit, it gives the left and right limit of the track given as a float.
You beat me to it :)
NODE BLOCK :

1 int 0 centre X : fp
1 int 4 centre Y : fp
1 int 8 centre Z : fp
1 float 12 dir X : float
1 float 16 dir Y : float
1 float 20 dir Z : float
1 float 24 limit left : outer limit
1 float 28 limit right : outer limit
1 float 32 drive left : road limit
1 float 36 drive right : road limit

And the full quote giving an explanation just for reference
Path nodes are described in the PTH documentation found on this page :

http://www.liveforspeed.net/?page=coderfiles

And here's a description of them, I'll write on the spot :

They are a series of points with direction and width that describe the track that you drive along. LFS uses it to watch your progress along the track, decides if you are driving in reverse. They provide the data for the echoes and the lightmaps, hold information about which objects you can see from that point, define the left and right boundaries for the AI drivers and are also used in yellow and blue flag systems, the position list, timing and some other things.

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.
I'm guessing avetere generated his svg using that data, and using interpolation a new path could be written out. Another thing that strikes me, is will an open config layout even attempt to read a path file? The existing ones are all named per existing track configuration, and we only have the [x,y] suffix which does not indicate a particular route. It would also need to depend on the layout file for which there has never been a path association.

[Dygear]

I think LFS is programmed to load those pth files, and only those pth files. I don't think we would ever be able to test our work unless Scawen allows for it.

[cargame.nl]

Another thing that strikes me, is will an open config layout even attempt to read a path file?
Yes.

I don't know how EQ Worry did it but custom PTH files are succesfully used. I already have some custom PTH files from 'merged tracks'. I have to ask how he did that. But it is a tremendous amount of work to create PTH files for tracks with new corners in it. (He said that somewhere here on the forum).

So I look for a way to ease that a bit because it greatly limits the power of open track layouts. Off path detection is needed to invalidate lap timing for example.

And I'm just interested myself in the logic behind it. Great discussion!

[Dygear]

I don't know how EQ Worry did it but custom PTH files are succesfully used. [...] (He said that somewhere here on the forum).

/me searches for every post made my EQ Worry (http://www.lfsforum.net/search.php?searchid=4416261).

[Squelch]

I don't know how EQ Worry did it but custom PTH files are succesfully used. I already have some custom PTH files from 'merged tracks'. I have to ask how he did that. But it is a tremendous amount of work to create PTH files for tracks with new corners in it. (He said that somewhere here on the forum).

So I look for a way to ease that a bit because it greatly limits the power of open track layouts. Off path detection is needed to invalidate lap timing for example.

And I'm just interested myself in the logic behind it. Great discussion!I've searched for possible merged pth files and found non. Did Eq Worry send them to you off forum? Would you care to share?

I've been looking at the .pth files and I'm having trouble already. Firstly there only appear to be 11 in the pth folder. AS1-7, KY1-3, and WE1.The pth.txt published for patch Y doesn't seem to describe what I'm seeing. Anyone know if its valid for the current format? According to the header, offsets 6 and 7 contain the version and revision respectively, but I see 00 and fa. That's ok, but pth.txt says "0 - do not read file if > 0" for both entries. Also the node count at offset 8 is zero. I'm thoroughly confused by it now. Any tips would be welcomed.

Dygear, I think this (http://www.lfsforum.net/showthread.php?p=1590528#post1590528) might be what Cargame refers to.


Doh!
I'm looking at the pth folder, and I guess they are compiled. Offset 0 should read "LFSPTH" not "SRPATH" Look at the .pth files in SMX_PTH_S2Y.zip instead. In other words ignore my previous comments.

A sample merged .pth file would be nice to work with though.

[E.Reiljans]

I've been looking at the .pth files and I'm having trouble already. Firstly there only appear to be 11 in the pth folder. AS1-7, KY1-3, and WE1.The pth.txt published for patch Y doesn't seem to describe what I'm seeing. Anyone know if its valid for the current format? According to the header, offsets 6 and 7 contain the version and revision respectively, but I see 00 and fa. That's ok, but pth.txt says "0 - do not read file if > 0" for both entries. Also the node count at offset 8 is zero. I'm thoroughly confused by it now. Any tips would be welcomed.There are 2 different types of PTH files - ones that are used by LFS, and one that's used in .pth's in this archive (http://www.lfs.net/file_lfs.php?name=SMX_PTH_S2Y.zip). The difference between them is pretty huge, at least header, can't be sure about node data blocks.

[PMD9409]

Most of EQ Worry's posts about the .pth files are in this (http://www.lfsforum.net/showthread.php?t=73903) thread.

A picture (http://www.lfsforum.net/attachment.php?attachmentid=113345&d=1302889185). Another (http://www.lfsforum.net/attachment.php?attachmentid=113446&d=1303494298). Last one (http://www.lfsforum.net/attachment.php?attachmentid=113447&d=1303494298).

And maybe another useful post (http://www.lfsforum.net/showthread.php?p=1580573#post1580573).

[Squelch]

There are 2 different types of PTH files - ones that are used by LFS, and one that's used in .pth's in this archive (http://www.lfs.net/file_lfs.php?name=SMX_PTH_S2Y.zip). The difference between them is pretty huge, at least header, can't be sure about node data blocks.Thanks, I updated my post just as you wrote that by the looks of it. A schoolboy error methinks.

Most of EQ Worry's posts about the .pth files are in this (http://www.lfsforum.net/showthread.php?t=73903) thread.

A picture (http://www.lfsforum.net/attachment.php?attachmentid=113345&d=1302889185). Another (http://www.lfsforum.net/attachment.php?attachmentid=113446&d=1303494298). Last one (http://www.lfsforum.net/attachment.php?attachmentid=113447&d=1303494298).

And maybe another useful post (http://www.lfsforum.net/showthread.php?p=1580573#post1580573).Very interesting. I was reading through that thread, and somehow missed EQ Worry's "useful post"

My experiment has finished, and the ideal line seems to be set in stone (read pth) I cannot detect any differences either between the visible ideal lines for AI with different setups, nor different cars. The only file updated is the .trs in the knw folder.

I surmise that the ideal line is probably a best fit curve for the shortest path between intersections of path nodes and road limits, plus some other factor that accounts for velocity perhaps, or even between the node centre and road limit on the shortest path.

How did you generate the ideal line in your images PMD9409? Are they a merge of the originals? It looks like they get a bit wobbly where the different configurations join.

[PMD9409]

Oh sorry, those are EQ Worry's pictures that were in the thread. I just collected them so you guys could get a general ideal of what he was doing.

Most of the paths he did was just merging of path files. However he has created many new turns, and how he has created those nodes and ideal lines is beyond me. I've wanted to know this stuff as well, as I have driven on his "updated Airio" that used the pth files, and they worked fantastic. However, I don't have the slightest idea of what to do really, I'm just a patience and curious spectator hoping to add any help that is possible.

Fantastic discussion btw, with the idea bouncing you guys are doing you are sure to hit the jackpot soon.


Bedtime now. :D

[avetere]

I'm guessing avetere generated his svg using that data

Yes, that is basically, how I did them.

For the track-width-issue dygear mentioned:
It should be quite easy to get the information out of existing pth where nodes exist but I don't think that would be the right way of doing it, as we are talking about manually generated layouts where - at different points/junctions/etc. there will defeinitely be new "handplaced" barriers (or worse: chicanes) that will effectively limit the track in relation to the real one.
So, I'm afraid, we would have to come up with a two-step aproach:

1: Generate a path (ideal line) consisting of coordinates (x,y and don't forget z!!!) and direction
2: manually and visually shorten those node-lines corresponding to a) trackimage b) set layout

The main problem I see for auto-generation is a lack of intelligence in layout files to decide where the track actually is ...

[Squelch]

Oh sorry, those are EQ Worry's pictures that were in the thread. I just collected them so you guys could get a general ideal of what he was doing.
Thanks for the clarification.

Most of the paths he did was just merging of path files. However he has created many new turns, and how he has created those nodes and ideal lines is beyond me. I've wanted to know this stuff as well, as I have driven on his "updated Airio" that used the pth files, and they worked fantastic. However, I don't have the slightest idea of what to do really, I'm just a patience and curious spectator hoping to add any help that is possible.I must admit that I only skimmed through your thread, and very interesting it is too. My worry is that those new pth files appear to only work with Airio, and PROS at that. For the lowly single users like me, using your "official" open tracks will be out of bounds unless he decides to open up the new app to work with the the free version, or better still a standalone.

Fantastic discussion btw, with the idea bouncing you guys are doing you are sure to hit the jackpot soon.
Bedtime now. :DAn open source pth generator/editor is my aim here, and having not really participated on the forums for a while, I'm deliberately learning from scratch so I don't miss anything.

And yes, I completely missed my bedtime too :D

Yes, that is basically, how I did them.I guessed right then, and started brushing up on my python fu to parse the files and get something similar.

For the track-width-issue dygear mentioned:
It should be quite easy to get the information out of existing pth where nodes exist but I don't think that would be the right way of doing it, as we are talking about manually generated layouts where - at different points/junctions/etc. there will defeinitely be new "handplaced" barriers (or worse: chicanes) that will effectively limit the track in relation to the real one.
So, I'm afraid, we would have to come up with a two-step aproach:

1: Generate a path (ideal line) consisting of coordinates (x,y and don't forget z!!!) and direction
2: manually and visually shorten those node-lines corresponding to a) trackimage b) set layout

The main problem I see for auto-generation is a lack of intelligence in layout files to decide where the track actually is ...Where a junction is concerned, I think it might be possible to use a moving window - say 16 nodes maybe more - to firstly detect where a junction exists between two track configurations, and secondly to create an aggregate or mean road width value taken from the node data within the window. From your generated svg, does the ideal line pass through the node centres? If so, this makes life a little easier.

As for hand placement of barriers affecting the road width, would parsing the lyt file for objects placed around the track co-ordinates at the nodes help? If we know the object type and orientation, the limits of the intended track can be found. This should work even for places where the intended path deviates from the physical track. Of course this makes it much more complex, but would allow pth files for any layout. I envisage some kind of post processing after the layout has been created, and then maybe refined by driving the track to update places where the autogen might have failed. Having just said that, driving the layout at "reasonable speed" as Scawen has said how he does the originals may be all that is required. I do have the same concerns as you over the number of possible variations though.

This still leaves the question. How to make LFS read the new pth file. Does Airio inject the data via Insim, or is the file a compatible lookup table for use during detection and subsequent Insim commands?


Regarding the parsing of lyt files. Scawen has mentioned several times in the Z3x patch thread about unifying AutoX objects. There is also this entry in the lyt format information.

NOTE3 :
-------
Object index varies by track, so it's not easy to
list them in a reliable way. In future we may
provide an autocross object file that is shared
between all tracks.

To successfully parse a layout file for objects affecting the intended path, this unification needs to happen.

[Whiskey]

To successfully parse a layout file for objects affecting the intended path, this unification needs to happen.

Not necesary, but helps a lot. Some programs (LYT editor) has a table with the corresponding ID for each track. Luckyly enough the unification is taking place so programers can avoid that mess.

[avetere]

From your generated svg, does the ideal line pass through the node centres? If so, this makes life a little easier.
No, it does not. That's what I wanted to show you on that linked image above (http://cl.racemore.de/mpres/images/tracks/AS3_1000.svg) the green line is the path given by the "node-points".
Another example: http://jallasnails.de/uploads/as3_nodes.svg
This is, what there really is inside the pth:
- yellow dots: node-points
- green bars: road-limits
- red bars: drivable limits (before open config, you were out of bounds if you crossed those for what reason ever)
- blue line: finish-line
(I broadened the lines a bit in order to make them more visible ...)
You can easily see, that the nodepoint is - in most cases - not the center and not even near it. It resembles more the ideal line. So track boundaries will have to be implemented manually I'm afraid.

As for hand placement of barriers affecting the road width, would parsing the lyt file for objects placed around the track co-ordinates at the nodes help? If we know the object type and orientation, the limits of the intended track can be found.You could do that of course - I even thought of that myself - but that should actually require a high amount of processing power (that's just a guess here). Because you would - for each single node - need to check, whether it intersects with any of the given layout objects. You would also have to consider type and orientation of the object, to decide, whether this is a track boundary or a mere obstacle and so on.
Also, You might create problems, if for example you don't put barriers close to one another, but with a little gap in between. If the "node-line" hits that gap, You get another problem.
So for a fully automated task - correct me if I'm wrong - you would ideally have to:
- create a node path (an array of node points)
- create an inner and an outer track path (being the boundaries of the road)
- create an inner and an outer "world path" (which area is drivable apart from the road)
- create one or more "object paths" that create the boundaries set by the objects, even in case they are not set one onto the other
- find the smallest portion of track, set by those boundaries (this should represent the new nodes)

Actually a quite comlex task to to it automatically



EDIT:
TO complicate things even more: All you see on those pictures is only the projection on the x-y-plane. One would also need to implement z-coordinate (height) and vertical (or is that horizontal?!? I really can't decide between them) distortion/orientation. So, we would actually need height-profiles of the tracks I'm afraid ...

[Dygear]

Best way to gat that data is to drive around in the MRT or something while hitting the edge of the track to it's it's boundies. I did this once to get the pit in and pit out point's position so that I could give automatically penalized to people who cut that line in the SimFIA races. But I'll have a longer think about this and see what I can come up with.

[avetere]

I think, the best way would actually be the non-automatic one.

1: create the path as you just said: Do a nice lap in something like MRT. Then I'd think it best to start from finish-line (which we get out of an old pth or in case of autocross-start from lyt) and create nodepoints from the new insim-packets

2: for track/drive boundaries we should do a visual approach:
- take those large tif-images scawen posted a while ago as background
- overlay a visualization of the layout (to create those it would of course be clever to wait for the unified system)
- overlay the nodes
- shorten them manually according to track/layout

Maybe we could use something in the style of that one for this:
http://www.lfsforum.net/showthread.php?t=73923

[Dygear]

avetere, we are in like a mind meld right now!