As soon as this patch is released, people want to drive the most idiotic combinations. It's impossible to keep up with PTH filez with that.
I already know some team members who are stretching fingers to get wild with that object editor
PTH is sugar on the cake, let the community decide after some week(s?) what is good and make PTH files for it (however, some good combo's you can guess). I think they do not want to be able to set WR's immediately but just race.
It's a bit unpredictable what will happen though (besides cruise servers going crazy)
The actual layout name for AS8 would be AS2X_AS8_Sprint1. The reversed configuration would be called AS2Y_AS8R_Sprint1_Reversed. So the names are still 4 char. Unless you mean Airio wouldn't print out the AS13R correctly? Wouldn't that be an easy fix?
A last resort for a positions list is actually already around. If you just have a tracker for each server, and then use an insim to read the tracker and deliver it into LFS in the same way it looks now. This was initially going to be used during streams, but it could be used for this purpose too.
Hmm, well, isn't for example the _Reversed part of the layout name extraneous? After all, that Y in track name says it already.
Mostly, I think we'll see in time what is possible, because I'm not sure what you mean by "a tracker that delivers it into LFS". Maybe you mean an intermediate InSim application that will connect directly to LFS and that will process the open layout tracks in a special way, adding node/position data into standard LFS packets, sending them then over to TV Director or anything else?
I guess that would be possible, but I suspect you'll need new 4-char track codes to have the new tracks "properly" recognized. My guess is TV Director would accept ASAR as a track name, while it will not understand what AS13R is. In fact this will not be even communicable. But that's only a guess, I have no idea what info the TV Director uses and how flexible it is in recognizing new tracks.
Airio/AIRW are very flexible in this thing, but they expect 4 chars max as a track name. Hence my suggestion of using letters instead of numbers for the new layout tracks. 4 chars is a LFS standard for tracks, just as 3 chars are standard for car names. I think we should stick to the standards to make it all as much transparent as possible.
Instead of using the long red pit lane, you could use the short pitlan in the middle of the track, by having barriers that make a 180° turn at the upper part of it, they would bring people on the outside of the corner, far from the racing line.
Yes it is, but I thought it might help the "newer" people out. Can never have enough of a description IMO.
A tracker like this, but of course more simplistic. It would read the data from each split and each time the car crosses the finish line. This would then be read by an app similar to this so that you could extract the positions list from the tracker into LFS. Sure it would only update everytime you pass a split, but you don't need to know your position every millisecond and like I said it is better than nothing "last resort".
I realize TV Director will not work without nodes, unless someone can recreate it using XY coordinates. I still don't understand what you mean about the 4 chars max. Wouldn't it be reading "AS2X"?
I understand that LFS only uses the 4 char in track names, but it also only uses numbers. What we could do is just combine both of our ideas so AS13R can simply be changed to A13R. Since LFS tracks don't have overlapping first letters (B, S, F, K, W, A), we can simply just identify the enviroment with it, while identifying the configuration with a number (08 - 21 for Aston).
We can obviously keep AS1-AS7 because those are developer created, while we could have user created be A08 - A21 etc.
Well, I'm not sure. I feel we could attempt to create new "standard" tracks, and it seems logical to me they need to have codes/names compatible with LFS (4 chars). But of course the actual layout name can be anything.
Hm, well, yes, I see. But there can be even better solutions, probably, using the "intermediate" InSim application idea I wrote about before plus the custom node map. Sure, it would require thinking and development, but generally it should be possible to feed to any existing InSim application slightly modified data about the layout race in progress and about the layout tract itself. That would be a highly transparent solution.
Well, AS2X is no track, as I see it. It is an open site that may contain many custom tracks.
Hahaha, yes, sure, that's also an option. I could only suggest the custom layout track names to start at number 10, so that KY4, KY5, AS8, AS9 are open for developers in case they one day decide to make some of the custom tracks official.
Correct, AS2X is the track, but it would also be the layout name. For example if I made a layout on AS5 right now, the beginning is automatically the track code, so it would be "AS5_BlahRace". So for each configuration now it would be "AS2X_A10_Blah" or AS2Y_A10R_Blah". In the end it is still only 4 chars because it would be AS2X and AS2Y. Unless you want it to read further into the layout name, then I would understand.
Well, yes, I understand. My point is that it would be great to have these X and Y layouts appear as completely new LFS tracks, not as layouts. So that if e.g. AIRW is used to store/display unofficial online WRs on these new tracks, it would receive/show only e.g. A11R or K20 as the track name. The same for storing PBs locally e.g. in Airio, for !sb and !pb and !tm and other commands. It will be a new track, not some layout on the open X or Y sites. I'm not sure if I can explain this properly.
Well, I've been already hinting about a possible way to achieve this, incl. positions in race. But only outside LFS itself, meaning for InSim applications. It could go like this: There'll be a small intermediate InSim application with just a few functions. The main InSim (Director, Airio, etc.) will connect not to LFS, but to this intermediate application.
The intermediate application will just forward most of the packets received to the main InSim, but it will slightly modify some info. Based on layout detected (and using some layout checks) this app will report a new custom track (4 chars) in packets where track name appears. It will also process car locations (X,Y,Z) and using a custom-created PTH file (see one of my previous post with image appended) it will determine car nodes and also positions in race. Tricky, but possible, I think.
Based on these calculations it will slightly modify e.g. the MCI packets, so that node number and race position is included there for each car. In theory, that could make Director fully operational. Hopefully.
Still, race positions will not be available through LFS itself, but if the modified data are fed e.g. into Aonio, which features multi-purpose race position list, it should again work just as if LFS itself was supplying the data.
To answer my own question, likely to be BL1X/BL1Y.
Anyway. Still think it would be useful if you could put it in - I'm thinking that if new sets are made for the tracks (and they will be; don't see BL1 or BL2 set working very well on something like BL5 or BL6) it would be useful way to remember what's what.
For instance RB4 on BL6, would likely save as RB4_BL1X.set normally, but I'd like to get into habit of trying to remember RB4_BL1X_BL5.set or RB4_BL1X_BL6.set.
To aid that, would it be possible to put all the various track configs (including existing) onto 1 image per track?
I'd like to keep copy of them on my pc or print out, so I have a rough idea of where I'm going when I join a server and get out on track, and when I'm naming sets.
I guess the release is very near now. As a test I created two more PTH files for two more tracks. Now there is AS21 and AS22 (these were easy to make, because they're just combinations of the existing AS2 and AS3). Also KY31 is now prepared (and it was not so easy, because of two completely new turns). Pictures are appended, the nodes could be used in an intermediate InSim applications for evaluating race positions, wrong way driving, etc. Anybody knows a fast algorithm to find out using X and Y location coordinates to what node (very small sector) they belong?
as I have the source files of those trackmaps that have been edited in the first posts, it would be possible for me to make less photoshopped looking maps with corner numbers for the most popular combinations. My plan was to make K31, one FE and two AS maps as my time is restricted but more can always be possible. So, just post your wish here or send a PM, I will try to finish the first during the next days.