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.)
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.
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?
[Edit]
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. [/edit]
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
And the full quote giving an explanation just for reference
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.
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.
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!
/me searches for every post made my EQ Worry.
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 might be what Cargame refers to.
[Edit]
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.
[/edit]
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. The difference between them is pretty huge, at least header, can't be sure about node data blocks.
Most of EQ Worry's posts about the .pth files are in this thread.
A picture. Another. Last one.
And maybe another useful post.
A picture. Another. Last one.
And maybe another useful post.
Thanks, I updated my post just as you wrote that by the looks of it. A schoolboy error methinks.
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.
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.
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.
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 ...
Thanks for the clarification.
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.
An 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
I guessed right then, and started brushing up on my python fu to parse the files and get something similar.
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?
[Edit]
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.
To successfully parse a layout file for objects affecting the intended path, this unification needs to happen.
[/edit]
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.
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.
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 ...
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.
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
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
avetere, we are in like a mind meld right now!
1
2
How to create PTH files
(44 posts, started )
FGED GREDG RDFGDR GSFDG