No it isn't - apart from the info already available - as setup information is encrypted.

Quote from Dygear :

I'm tempted to submit this as a bug, so we can at least get a reason why this happened.

Yeah, I was about ask that too, especially since nodes aren't shared between configs (which would at least have been an explanation).

Quote from Dygear :

Nodes are boxes laid out on the track that tell information about the track. For example, it gives information about direction, ensuring that the client is going the correct direction, and position. Node numbers get higher the further into the lap you get, this allows the LFS engine a very quick way to keep track of who is in front while on the same lap. As a higher number means they are further into the lap, it also means that the highest number has compleated that lap the most. In the case of a person being on the lead lap, and then having the highest node number, that person is in first. It's actually a very simple sorting algorithm to implement.

Just for clarification:
This is absolutely true in itself, but You'll have to consider that finishline usually is not the first node of the track.
In Westhill e.g. the finishline is around node 600 plus some spare nodes out of about 650 (more or less).

So, if the finishline was e.g. node 627 out of 647, then a higher nodenumber while being on the same lap would only mean further progress, if the higher one was less than 627 or the lower one was above 627

In insim ISP_NLP

Node corresponds with the nodenumber inside pth

Quote from delta13 :

I would like to know if its possible not to verouillier the layout by the creator but to ensure that the name of the creator can not be changed

There is no information on who created a layout inside the file, that could be preserved ... (and I don't see a real reason, why there schould be, honestly)

Quote from Scawen :

EDIT : It turned out too important to do the slider bar, so I have done that now. Thanks for the feedback.

Well, actually, as you did this slider-thing:
You might want to consider to do the same thing on all occasions (is that spelled correctly?!)

This might be a nice thing e.g. for one- or two-shot qualifications in leagues

Haven't tried it actually, since I've been "at work"

Hello and welcome.

I certainly don't want to spoil your first post, but:
- why rapidshare? you can upload lyt-files as an attachment directly into this forum (see "additional options" underneath the message-text-area)
- wrong place ... actually the right place would be here: http://www.lfsforum.net/forumdisplay.php?f=27


Nevertheless: Welcome and have fun

Do you need the whole picture (which I don't have) or do you only need the track? In the latter case serve yourself with a svg-file:
http://cl.racemore.de/mpres/im ... L1_0.5Z28_km_all_1000.svg (1000 can be replaced the desired size, the other tracks are loaded the same way)
In case you don't want the "unselected configs" remove "_all" ... you can also replace km by mi ...
(At the moment tracknames are case sensitive, so please use uppercase only)

Last edited by avetere, Wed 7 May 2014, 18:48.

You will be able to watch pre Z35-replays (should be down to Y or even X30, if I'm not mistaken) even with the new version

Quote from denis-takumi :

LFS version plz

It's z33

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

Quote from Squelch :

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.

Quote :

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

Last edited by avetere, Mon 16 May 2011, 09:48.

Quote from Squelch :

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

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

Last edited by avetere, Sun 15 May 2011, 21:40.

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

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

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

You see, opening that part of SO would simply enable another unfinished area. So that comes in the category of something that really needs to be updated with a real track update.

OK. That's quite understandable for the unfinished part (though I obviously hoped for another outcome), but now at least, this issue has been cleared for the moment

But how about the two barriers around that "bridgehead" (see first pic on the right) to enable the other way round up to the highway? that one seems perfectly finished and usable to me ...

No need to comment on that though, I'm perfectly willing to get the anwser as a surprise

Just as a reminder:
Could we get rid of those few objects at SO (around highway-passage)?

Quote from Scawen :

It will be multiplayer incompatible

I reckon this means mpr-format will be altered?
If so, would it be possible, you let me/us know, in what way (e.g. which packets are affected)?

Quote from nesrulz :

btw2, ideal line (4) is probably hard to put it in this configuration?

Actually not possible and what is perhaps even more important: Totally senseless. Any ideal-line is dependant on where you are going and this information is simply not there ...


@wrong-way: As you are totally free to go where you want, how on earth should lfs know or decide, whether you are going the wrong way on any specific part of the track?!? That would be . as above - totally senseless ...

You might also want to take a look at this one:
http://www.lfsforum.net/showthread.php?p=1180856#post1180856

Quote from Scawen :

I don't know what you mean about the autocross lights, they seem to work ok. Maybe you are talking about the sequence of the lights? I can't change that easily, Eric did it how he wanted it, and it is stored in the lights object.

I think he meant the way, the traffic lights switch to green, when you manually set a starting-point. Unlike the usual way, there is a 3 second countdown that makes the starting-procedure very predictable ...
So maybe give it a randomizer and keep the countdown "silent" ?!

type=cars