RaceDepartment Store

Would you rather have:

  • Alien speed in online races

    Votes: 60 33.7%
  • Super expensive high-end hardware

    Votes: 118 66.3%

Upcoming Events

AC events on Simracing.GP ACC events on Simracing.GP R3E events on Simracing.GP Weekly rFactor 2 events Join TCR Virtual today!

Tutorial on making 2-way traffic (or other) AI lines and layouts

First step for making the 2-way lines is checking out the road and surfaces.ini for impending problems with the side lines. One way for that is to load the track with some layout that already has AI lines and have a look at those. May require disabling of "Origin shift" in CSP settings > "Graphic adjustments". If the red sides follow exactly the border between the asphalt and the green or brown stuff then most probably you will have the same side lines automatically generated from the game after your attempt.
Clipboard01.jpg


Another way of checking is to confirm the names of the objects that are physics. Those have number for first symbol in the names (0 doesn't count). 1ROAD next to 1SAND when the surface "SAND" has "IS_VALID_TRACK=0" tag in "..\AssettoCorsa\system\data\surfaces.ini" or in the layout's "surfaces.ini" means the side line will be created on that border.
Clipboard02.jpg
Clipboard03.jpg


When the objects for physics are correct you need to prepare the new layout's structure. In Windows Explorer open the track's folder (fastest way - right-click or use the three dots next to the track's name in Content Manager). In there create new folder (i.e. "2way") and while empty - copy that into "ui". Then from "ui" or some of the other track's layouts select and copy the three .png and the "ui_track.json" into the empty "..ui\2way\" folder. Edit the contents of "ui_track.json" to reflect the changes in this layout. Avoid putting the new name entirely different than the other names of the track's layouts but add few words after the old name. When done editing that re-open CM and see if the new layout shows up for selecting.
Clipboard04.jpg
Clipboard05.jpg


Then proceed to creating the file structure - copy the "data" folder and map.png from some of the existing layouts and paste those into "..\<track name>\2way\". Make a copy from some of the other "models_***.ini" for that track or if there are none you need to create new in the track's folder ("..\<track name>\") and name it "models_2way.ini" to match the name of the layout's folder. If you are making new - open it and create a paragraph

[MODEL_0]
FILE=euphoria_hillside_park.kn5 ;the actual name of the kn5 model in the track's folder;
POSITION=0,0,0
ROTATION=0,0,0
Clipboard10.jpg


After that load the new traffic layout in "Practice" mode. When all of the necessary models are present the car will be functioning and positioned correctly and you will be ready for drawing the fast_lane. Notes on the car choice - large cars with longer wheelbase are more stable but the lines drawn with those have longer segments and in tight turns that sometimes becomes too obvious later with the AI cars. Drawing the line at racing pace is not necessary and two lines drawn with different cars at different pace work the same provided the lines have the same geometry. So choose a car that has small enough turning circle, smooth and broad torque band, big enough suspension travel and gripping tires to give you the best traction and stability and then drive it like a grownup. Choosing a car with weak engine allows for relaxing your feet by flooring it for long enough during the drive and that matters a lot when it takes more than 1 hour for driving the line on a long road.

Next on the list - choosing the actual route. The simpler - the better. Avoid as much as possible: overlapping the line by driving again in the same lane; crossing the paths of the AI; narrow passages between walls or near obstacles.
Find the best places for the U-turns with road tagged as "IS_VALID_TRACK=1" wide enough to accommodate the turning circle of most cars in the "street" class. On a long road or large road grid use the "map.png" file to actually draw into it the arrows to guide you where to turn and color-code those if it's multi-lane and you need to make another parallel loop. So your first stab at making the traffic is a drawing over the "map.png" and then practice run on which you confirm on track where and how to turn.

Settings of CSP and other for the time of driving the new lines - the entire "New AI behavior" module should be turned off, "Origin shift" in CSP settings > "Graphic adjustments" should be disabled. Deactivate all Python apps except Sol controls.

When all of the above is done and you feel there's enough energy left for the long haul - start the engine. By that I mean choose the starting point of the line on some straight bit with distinct object next to the side which you take as reference. YOU NEED TO STOP THE RECORDING AT THE END OF THE DRIVE JUST BEFORE YOU REACH THE STARTING POINT. This method doesn't need the first timing gate to form a "start line" and to begin and close the recording there. I use "start pits" to record the line from anywhere I fancy to anywhere I decide to stop.
Clipboard06.jpg

On multi-lane traffic it simply is the only way for creating the parallel lines. On A2B hill-climbs it's the easiest way to make the AI cross the finish line. The drawback - after completing the drive and renaming the "pit_lane.ai.candidate" to "fast_lane.ai" the game takes it's time to evaluate it upon loading which takes as long as the time to actually render the line upon exiting the session. So if the rendering needs 2 hours it will take twice that when making the line from "pit_lane.ai.candidate" and you need to interact in the middle of that wait. In conclusion - to save time you may consider the option to start the 2-way just before the timing gate as long as you don't need to pass through it again in the same direction for making another round. In that case using the standard "start recording" in the "AI" app will spare you the wait for loading the raw line and the rendering will be done upon exit of the same session. To see the location of the timing gate you have no other option but to use 3DSimED to load the relevant track's models prior to the attempt.
Clipboard12.jpg

*To make things more interesting the author in this example had the track encrypted and for that the wire-frame view is necessary. The positioning of these two gate objects would prevent making of the traffic that I've done using the "start pits".

The timing gate may not be on the map, may not be in the place that the map says it will be, or it may not be present at all. If any of this and without checking - you will waste a lot of time blindly driving around just to find out that timing doesn't work and the recording of the traffic you want is never going to happen. In case you need the gate to be somewhere else or if it simply is missing in the track you can create it by placing by the sides of the road two primitives in 3DSimED. Boxes with 1m sides are fine and the names should be "AC_TIME_0_L" and "AC_TIME_0_R" for the left and right side respectively. "Plugin Export" that as "gate.kn5" and make it load by adding a paragraph into "models_2way.ini". Now, if the track already has those objects there is a big difference whether you put the new "gate.kn5" model last in the queue or first. Put it before all others as [MODEL_0] to make it work and observe the proper sequential numbering of the next models.

But if you are like me and want to get straight to it - use the "start pits" and just drive the route that you want. Just remember the place of the start and on the second approach to it click "recording" to stop the process before you reach the starting point. After exiting that session you will find a single "pit_lane.ai.candidate" in "..\<track name>\2way\ai\" folder.
Clipboard07.jpg

Rename it to "fast_lane.ai" and load another "Practice" session. This time loading will be slowed down by the raw line that you want to render. Be patient and don't terminate "acs.exe". If you like to have the PC available for other tasks use "Alt+Tab" or "Ctrl+Alt+Del" to make the "Desktop Manager" of Windows re-gain control over the screen.

After the loading is complete you need to use "start pits" again and depending if you intend to actually use the "pit_lane.ai" or a duplicate of the "fast_lane.ai" you may want to drive the good short guiding line into and out of the pits. When that is done click "recording" to stop the process and exit the session. That's when the actual usable lines are made by the game. The good result is two new .candidate files which need to be renamed by removing the ".candidate' from the names. The initial "fast_lane.ai" needs to get out of the way and for safekeeping you may pack it into a zip.

There are two scenarios for "pit_lane.ai": 1. using the short line that only covers the pit area or 2. making a copy of "fast_lane.ai" and renaming that copy to "pit_lane.ai". That gives the opportunity to scatter the pits along the route and make the AI join more naturally for a street driving. But when you have all cars starting from the pits using the duplicate "fast_lane" has no benefits.

If you think that's all - it's not. For most of the AI to work with the line there has to be some track-specific hints. A simple template for creating such "..\content\tracks\<track name>\2way\data\ai_hints.ini" file is

[HINT_0]
START=0.001
END=0.999
VALUE=0.8

[BRAKEHINT_0]
START=0.001
END=0.999
VALUE=0.9

[MAXSPEED_0]
START=0.001
END=0.999
VALUE=160

[DANGER_0]
START=0.001
END=0.999
LEFT=0.6
RIGHT=0.6

From those paragraphs most likely [HINT_**] and [MAXSPEED_**] would be of use, the first telling the AI that each corner radius is shorter than the look-ahead estimate (i.e. factor of 0.8) and the second - not to exceed the defined speed. Hints can work in combination and be multiple of the same kind. The numbering is [HINT_0], [HINT_1], [HINT_2], etc. and the "START=***" and "END=***" determine the points on the spline in form of percentage length from the starting point. It is displayed on the "AI" app but with a long splines you might want to use the "DRS zones" app instead to avoid CPU overload.
Clipboard09.jpg

The way I find most effective for tuning the hints is to load a well-developed car in "Hotlap" mode and enable the AI (Ctrl+G and Ctrl+C) so I can watch and listen for problems. If the AI resembles human driver then that part of the course is ok. If not I take note of the positions and edit the hints. Testing of the line is not complete without a Track day with AI flood. Before judging that some line is good or bad consider this: some AI cars experience difficulties with new AI flood when spawned at speed in the highest gear and have to downshift fast without any hesitation. Instead of doing it as expected many AI just can't engage the clutch. Here's what solves this issue: unpacking of car's data and enabling the unpacked data as default by renaming "data.acd" to "data.acd1", then edit of "drivetrain.ini" to have [AUTOCLUTCH]
MIN_RPM=100
Provided there's no other problems with the car's physics that makes it go without a hiccup. Additional benefit of using the unpacked data is the option to train that AI better so it doesn't hit the walls due to cutting corners or missing the turn.

Not essential but nice to have are F3 track-side cameras. The positions and directions of those are tied to the spline length and you can't simply use the old "cameras.ini" from another layout. For making the F3 cams I'm using the "Custom Shaders Patch debug app Advanced"
Again by enabling AI and setting [MAXSPEED_0] low enough I'm able to go round the course and in one lap to position all the cameras so the cars remain in frame later on. For making the cams I usually let AI drive some wide car with less body roll - like a Hummer in case of wide roads, so with F5 and some rotation I can reach over or near the edge of the road. Thanks to LeBluem aka @Please Stop This for making the useful tool.
Additional note on the cams - since v0.99k the app offers "new auto cams" mode of recording and it works very well for making huge sets for long lines when some conditions are met: the timing gate "0" should be present and at the exact spot where the line begins, you set "min_z=0" and "max_z=1", in CSP settings disable "New AI behavior" module and disable "Use double precision physics", in "Hotlap" or "Track day" session position the cams by selecting F5 and looking at the rear quarter close to the road edge without going into some buildings and other obstructions, at height of more than 2 m above ground. To add variety to the set you can change the "IN" and "OUT" while the AI does the driving. For wide and long straight roads - bigger distances between cams, for narrows and twisties - shorter distances. If the AI speed is limited that also calls for shortening the "IN" and "OUT". If "IN" is bigger than "OUT" cams show more the front of the cars approaching, if "OUT" is bigger - more of the rears is in the shots.

Let me know if splitting the opposite lanes is interesting for you and I will add more info. And don't hold back if you see the results of the attempts exceed your expectations - share the layouts with us!
 
Last edited:
But if neither are present then another approach of conjoining the road borders (non-manifold edges) will be needed. Any ideas on that?
If the road mesh edge was clean and smooth, extruding it into a vertical wall and then solidifying that wall mesh with half the lane width should work.

If the road changes width, different sections can be made separately. An edge that's slightly zigzag but with clean topology can be smoothed. If there are large sharp angles (common in city tracks) or dirty topology, I don't see any easy way to do it.
 
Last edited:
"Sometimes the car appears without a wheel or without a tire, so it barely drives and stops all the flow" said @RN4 today.

The problem you've described is seen with AI flood because of the way it is designed. You may check it in replay while observing each of the AI cars. The flood spawns them above the road and then they fall onto the surface. Some cars suspensions are strong enough to handle the drop and others break. I recommend opening the file "C:\Users\*******\Documents\Assetto Corsa\cfg\extension\new_behaviour.ini" and in there paste and save
Code:
[AI_FLOOD]
PUSH_FORCE=150000
SHUFFLE_BEHAVIOUR=ALWAYS
MIN_TRACK_LENGTH=2000
Y_OFFSET=-0.35
PUSH_SPEED=90
SPAWN_MIN_DISTANCE_TO_PLAYER=240, 120
SPAWN_DISTANCE=260, 180
SPAWN_RANGE=220, 160
SPAWN_DESPAWN=300, 140

[AI_RACE_RETIREMENT]
REJOIN=1

[AI_SPLINES]
CACHE_GRID=0

Notice the "Y_OFFSET=-0.35" line. It instructs CSP to spawn the cars 0.35 m lower so the drop is minimal. Hopefully that will solve the broken AI cars that you get sometimes.
 
Last edited:
If the road mesh edge was clean and smooth, extruding it into a vertical wall and then solidifying that wall mesh with half the lane width should work.

If the road changes width, different sections can be made separately. An edge that's slightly zigzag but with clean topology can be smoothed. If there are large sharp angles (common in city tracks) or dirty topology, I don't see any easy way to do it.
Actually with the help of both your scripts and the Blender add-on there is a relatively easy and universal way of doing this on any track. First I get to isolating the loop that is one of the road edges (whichever has cleaner topology). That works regardless of the complexity of the mesh since I start with join and decimate. Then I merge all vertices by distance 1 m and select non-manifold edges. Invert selection and delete edges so only the non-manifold edges are left. Clean the remaining bridging edges between the two loops untill "Alt+LMB" results in selecting only one of the loops. Space the vertices evenly with the "Loop tools'. Voila - there are both the lines we need for each of the directions. Then to spare myself further headache I go through convert to curve (Bezier) and to mesh again and quickly check for broken linking between the vertices with select linked. Clean the problems, smooth vertices if necessary, apply the rotation (that comes from 3DSimED export in the beginning) and export the selected loop as csv. Then make from it "fast_lane.ai". For some reason it gets 20 m offset on the side lines... No problemo, there it goes under the other script and the borders are clamped at 1.5 m on both sides of the original road border :) So we take that side line that now sits at 1.5 m distance from the road edge,

Clipboard01.jpg
move all vertices 0.55 m over the road and make it work as "fast_lane.ai" by going through export csv > csv to ai > setting the actual borders as we want them to work in the layout.

I just wish there was a faster way of rendering the result. 50 km line takes 4 hours for initializing and another 4 hours for saving. Whether it is by ksEditor or by loading a practice session doesn't make a difference.

PS. - the trick with using one of the side lines for something different also helps when you want to move the "fast_lane.ai" in some other lane. Say, you have a 1-way loop for time attack and want to have your favorite fast AI racing along on the narrow road. Then the misplaced side line can serve as target for the shrinkwrap (nearest vertex) modifier on the "fast_lane.ai". It works well on the rendered "fast_lane.ai" too and the exported from Blender "fast_lane.ai" loads as fast as usual but with the changes you've made.
 
Last edited:
Sometimes another problem arises. When I drive up to other cars, some of them may become invisible for a second or more. As far as I understand, the problem is in the fashion itself, but there may be a way to fix this situation, because many people on the video have exactly the same cars and everything is fine with them.
 
When I drive up to other cars, some of them may become invisible for a second or more.
:O_o: ???
Can you post a link to a small video to demonstrate that? It could be many things - wrong "lods.ini", AI flood settings, borked CSP install... What cars are glitching - mods or official? Does the problem persist when you switch CSP off?
 
This happens with mods.
It seems that you are on "Deutchlandring" and loaded the traffic car pack of the "colliders disabled" variety. I don't have it and can't vouch for the reason of the quirk but it appears to be an intentional setting of "lods.ini"

[LOD_0]
FILE=********.kn5
IN=1
OUT=****
on each of the traffic cars. That "IN=1" probably was done to compensate for going through a car with disabled collider without seeing it's hollowed insides. Like in 0.49 on the video. You can load the non-encrypted track with CSP disabled and do the same drive in Track day after waiting some minutes for the AI to move out. I'm pretty sure it will act the same way. But if it acts normal without CSP - reset the "Graphic Adjustments" module of CSP settings.
 
Last edited:
Last edited:
  • Like
Reactions: RN4
The traffic vehicles pack also has a collision-enabled version: https://drive.google.com/file/d/1PbYGD61LFi0DNcw7f2o68xBwdJ80pZfl/view . Some vehicles have bad collision volumes though.
I'm keen on adding a small tutorial on making colliders in Blender. I just got the very same pack last night and intend to go adding cars one-at-a-time with checks in CM and Test pad. When I reach that truck "X" with collider from a hatchback I' ll post the steps for making the collider. It's really easy and a fine way to get people accustomed to Blender and ksEditor. And that way the guys like @RN4 can turn the cars from the non-collidable to normal without waiting for the 1.5 GB alternative pack to arrive and with some wrong colliders in it.
 
Last edited:
  • Like
Reactions: RN4
on each of the traffic cars. That "IN=1" probably was done to compensate for going through a car with disabled collider without seeing it's hollowed insides. Like in 0.49 on the video. You can load the non-encrypted track with CSP disabled and do the same drive in Track day after waiting some minutes for the AI to move out. I'm pretty sure it will act the same way. But if it acts normal without CSP - reset the "Graphic Adjustments" module of CSP settings.
Unfortunately it didn't help :(
 
Last edited:
I'm keen on adding a small tutorial on making colliders in Blender. I just got the very same pack last night and intend to go adding cars one-at-a-time with checks in CM and Test pad. When I reach that truck "X" with collider from a hatchback I' ll post the steps for making the collider. It's really easy and a fine way to get people accustomed to Blender and ksEditor. And that way the guys like @RN4 can turn the cars from the non-collidable to normal without waiting for the 1.5 GB alternative pack to arrive and with some wrong colliders in it.
Oooh, that would be great. I'm really looking forward to it)
 
Last edited:
I just wish there was a faster way of rendering the result. 50 km line takes 4 hours for initializing and another 4 hours for saving. Whether it is by ksEditor or by loading a practice session doesn't make a difference.
Did you mean 4 minutes or 4 hours? I just tested the 20.7km Kunos Nordschleife line which has 13k samples. Generating AI file from geometry as-is and re-saving the file in ksEditor took 13min on my system. If I decimate the geometry down to fewer than 1k samples then resample it to 10k in ksEditor, the whole process would only take 5min.

Loading/saving time increases dramatically when AI line length goes beyond a certain point. See #40.
 
Last edited:
Did you mean 4 minutes or 4 hours? I just tested the 20.7km Kunos Nordschleife line which has 13k samples. Generating AI file from geometry as-is and re-saving the file in ksEditor took 13min on my system. If I decimate the geometry down to fewer than 1k samples then resample it to 10k in ksEditor, the whole process would only take 5min.
No typos there. Fresh AI line from geometry takes same as rendering the line drawn with a car the usual way. Anything less results in saving an incomplete "fast_lane.ai" that later takes massive amount of time to initialize on start of each session. File sizes give the first clue. The final line has ~1 MB per kilometer so if your line on the Nordschleife is lot less than 20 MB then it is not ready.
 
While testing for rendering times I also found out that trucks with colliders and correct dimensions in "car.ini" need ~1.8 m on each side of the fast_lane.ai to work correctly.
trucks on Arona.jpg
 
decimate the geometry down to fewer than 1k samples then resample it to 10k in ksEditor
That trick has a big side effect - the new line moves closer to the road edge on apexes. While it may be beneficial for race and hotlap it messes up the traffic flow. One quick way around that is to apply shrinkwrap (nearest vertex) for the new smoothed line and point to the old traffic line as target.
 
Unfortunately it didn't help :(
intentional setting of "lods.ini"

[LOD_0]
FILE=********.kn5
IN=1
OUT=****
on each of the traffic cars.
If you are still wondering how to deal with the matter of cars disappearing and if I guessed correctly the reason for it - you need to open each "data" folder of each problematic traffic car and edit each "lods.ini" to have "IN=0" instead of "IN=1". Test that for one car first to see if that solves the problem.
 
No typos there. Fresh AI line from geometry takes same as rendering the line drawn with a car the usual way. Anything less results in saving an incomplete "fast_lane.ai" that later takes massive amount of time to initialize on start of each session. File sizes give the first clue. The final line has ~1 MB per kilometer so if your line on the Nordschleife is lot less than 20 MB then it is not ready.
My 5min line does work. The file size is correct. In-game loading time is normal. There are some graphical glitches when showing the ideal line (no acceleration/brake colour, some small sections are missing or misplaced), but AIs can finish the whole Nordschleife lap without any strange behavior.

I made a change to the csv_to_line script to reduce sampling density according to the local curvature of the line. Tight corners have higher density than straight lines. This keeps ksEditor loading time low without shifting the line too much during resampling. Shrink wrapping is still recommended.

The script now accepts two additional numeric values. The first one is the maximum lateral offset allowed when deleting a sample (default to 0.5m). I'm computing using linear interpolation, ksEditor uses spline, so the actual offset is typically much smaller. The first one is resampling density which defaults to 1.6m per sample, similar to lines recorded in-game. The second is border distance (default to 1.75m).

Code:
acai_csv_to_line.py input.csv output.ai 1.6 1.75
acai_line_to_csv.py           output.ai
acai_calc_speed.py            output.ai
 

Attachments

  • acai_csv_to_line.py.txt
    6 KB · Views: 13
  • acai_line_to_csv.py.txt
    16.9 KB · Views: 9
  • acai_calc_speed.py.txt
    7.9 KB · Views: 15
Last edited:
Turns out my Nordschleife test line was just not long enough. I made a 72km Targa Florio line yesterday. Loading the 3k-sample line and resampling to 36k took over 1.5h. Saving the resampled line took so long I went to sleep. This morning the new line was saved and found to be functional in-game.

This line is so massive ideal line rendering refuse to work. Ctrl+I doesn't do anything. The AI Dev app however can show the line and its borders correctly. Interestingly the SRP traffic line is even longer and it does render partially on my system.
 
Last edited:
Top