General AI bug on mod track - stalling after race restart

[eg01st]

Title explains the problem.

I found on older posts that this was old AC bug that got fixed, but I get it anyway. I'm working on my second mod track, and did not have problem like this on my first one.
This happens with mod cars as well as with Kunos cars. After I load the scene, race goes fine, but if I restart the race (Esc > Restart) 2 or 3 cars stay on the grid. After next restart - the same cars.

I have AI spline and Pit spline recorded. I re-recorded AI spline but it did not fix the issue. I changed AC_START height from ground but nothing changed.


EDIT: After more testing - ONLY the cars that RETIRE and get spawn into pits get this bug. So, when they stand in the pits during race and I restart the race, they keep standing on the grid.

 

[Ghoults]

How does your ai line look at the s/f line? How do your side csv files look at the s/f line?

 

[eg01st]

Where do I find side csv? Is it something I have to make or convert from AI spline?

 

[Ghoults]

The sides are called side_l.csv and side_r.csv and they go into the main data folder or the data folders of your layouts. You can make them with blender or use one of the apps.
https://assettocorsamods.net/threads/how-can-i-make-ai-path.234/
https://www.racedepartment.com/threads/ai-line-helper.137572/

In your image one of the sides that ac autogenerates from the ai line goes all the way to the outer edge of pits which is probably your cause of issues.

 

[eg01st]

The sides are called side_l.csv and side_r.csv and they go into the main data folder or the data folders of your layouts. You can make them with blender or use one of the apps.
https://assettocorsamods.net/threads/how-can-i-make-ai-path.234/
https://www.racedepartment.com/threads/ai-line-helper.137572/

In your image one of the sides that ac autogenerates from the ai line goes all the way to the outer edge of pits which is probably your cause of issues.

Thanks, I'm splitting the tarmac in the middle to make a CONCRETE layer between track and pits. Maybe that will help.

 

[eg01st]

I reworked the mesh, the splines now look like this. But cars still stay on the grid.

 

[Fat-Alfie]

Do you by chance have duplicate AC_START objects in the same grid spots? It seems strange that only a couple of AI cars are struggling to pull away.

 

[Ghoults]

How does your surfaces.ini and object names look on that straight? Isvalid=1 for those road objects? Does the pit physical surface extend to track in that spot? Physical road faces all pointing up and no holes? Have you looked the fbx road surface at those spots?

 

[eg01st]

How does your surfaces.ini and object names look on that straight? Isvalid=1 for those road objects? Does the pit physical surface extend to track in that spot? Physical road faces all pointing up and no holes? Have you looked the fbx road surface at those spots?

Racing part is visual (0TARMAC) and physical (1TARMAC) mesh. Pitlane is 1 mesh (1TARMAC visual), in between is a patch of 1CONCRETE, where the walls at separating start from pitlane.

This is my 2nd track mod, didn't have this problem with first. This bug appears only when I restart race. First time it's ok.

 

[eg01st]

Do you by chance have duplicate AC_START objects in the same grid spots? It seems strange that only a couple of AI cars are struggling to pull away.

I did everything like on my first track, more or less. I had some problems with AC_START pivots, but I solved them. As I edited the thread, only retiring cars have this bug.

 

[Fat-Alfie]

Doesn't AC see any mesh as physical if its name starts with a number, including 0? I might be wrong as I have never tested it, but I name all my visual meshes objects V-objects-01 (for example). Maybe try renaming for visual objects to rule that out?

EDIT - I was wrong; 0wall-test is not detected as a physical mesh

 

[eg01st]

Doesn't AC see any mesh as physical if its name starts with a number, including 0? I might be wrong as I have never tested it, but I name all my visual meshes objects V-objects-01 (for example). Maybe try renaming for visual objects to rule that out?

No. If objects start with 0, it means it has no collision. If 1, it's a drivable surface or a wall. I think no number is just the same as 0. But to be sure I name visual walls 0WALL, collision walls 1WALL, visual tarmac 0TARMAC, and actual physical mesh 1TARMAC, 1CONCRETE etc. Because I'm not sure how visibility culling works with walls.

 

[Fat-Alfie]

How about spacing out your AC_START objects? Maybe try the standard 16m between start positions? Yours look very close together...

 

[eg01st]

How about spacing out your AC_START objects? Maybe try the standard 16m between start positions? Yours look very close together...

It's 7.5 meters between each position right now.

 

[Fat-Alfie]

Yeah, maybe try double that:

F1 Sporting regulations:
35.4 The grid will be in a staggered 1 x 1 formation and the rows on the grid will be separated by 16 metres

Your rows look 7.5m apart, but the individual positions would be half that - that's pretty tight.

Even so, I'm not sure that would cause some cars to simply refuse to move.

I am happy to test it out and try and help, if you're happy to send me a copy (in private, of course)

 

[eg01st]

Yeah, maybe try double that:

F1 Sporting regulations:
35.4 The grid will be in a staggered 1 x 1 formation and the rows on the grid will be separated by 16 metres

Your rows look 7.5m apart, but the individual positions would be half that - that's pretty tight.

Even so, I'm not sure that would cause some cars to simply refuse to move.

I am happy to test it out and try and help, if you're happy to send me a copy (in private, of course)

Distance between cars in F1 is the same - 8 meters. I just fixed it to 8 meters.

EDIT: Tested, retiring cars still standing...

 

[Ghoults]

Racing part is visual (0TARMAC) and physical (1TARMAC) mesh. Pitlane is 1 mesh (1TARMAC visual), in between is a patch of 1CONCRETE, where the walls at separating start from pitlane.

This is my 2nd track mod, didn't have this problem with first. This bug appears only when I restart race. First time it's ok.

I don't think it is good idea to use names that start with numbers for visual-only meshes. I'd try changing all your visual mesh names so they don't start with numbers and change all your physical meshes so they start with numbers. I use the common practice myself which is that physical meshes start with numbers (01KERB, 17ROAD, 66SLIMETRAP, 02CONCRETE) and visual meshes start with VIS prefix (VISOAD1, VIS01KERB). Of course in some cases like with kerbs your object is both visual and physical.

I think your problem could be that you have effectively two physical meshes on top of each other. Pitlane physical object surface also needs to be its own object (like 01PITLANE). Visual can be anything with not a number in front. Pits also needs ispitlane=1 or true in surfaces.ini.

No. If objects start with 0, it means it has no collision. If 1, it's a drivable surface or a wall.

I don't think so. Number at the beginning means it is a physical drivable mesh. If it is **WALL then it is a collidable wall.

 

[eg01st]

I don't think it is good idea to use names that start with numbers for visual-only meshes. I'd try changing all your visual mesh names so they don't start with numbers and change all your physical meshes so they start with numbers. I use the common practice myself which is that physical meshes start with numbers (01KERB, 17ROAD, 66SLIMETRAP, 02CONCRETE) and visual meshes start with VIS prefix (VISOAD1, VIS01KERB). Of course in some cases like with kerbs your object is both visual and physical.

I think your problem could be that you have effectively two physical meshes on top of each other. Pitlane physical object surface also needs to be its own object (like 01PITLANE). Visual can be anything with not a number in front. Pits also needs ispitlane=1 or true in surfaces.ini.


I don't think so. Number at the beginning means it is a physical drivable mesh. If it is **WALL then it is a collidable wall.

1A: Naming convention:
The AC physics engine takes into account the naming of your tracks objects/meshes in order to give them physical properties. Syntax is as follows:

<ID><name><optional_suffix>, where :
ID – is a number greater than 0, if you'd like it to have some physical properties
name – is the name of your object/mesh
optional_suffix – as the name says, you can use it if it helps, but has no impact on the properties

The <ID> parameter has to be greater than 0, if you'd like your object/mesh to have physical properties. Otherwise it can be 0, or missing, and your mesh will be only a graphical asset.

The <name> parameter is very important and deserves some more explanation, as it will be used to define both the collision mesh and the rolling surfaces. In that purpose, there are a few pre-defined keywords that you can use. These are:

WALL, mandatory to be used for the collision mesh

Define collisions mesh:
- While it is possible to quickly define an object as an obstacle (fence, building, pole, barrier, …) just by naming that object using <ID>+WALL+<optional_suffix>, where ID is any number greater than 0 (e.g 1WALL_fence, 1WALL_building, 2WALL_pole, etc) here's the right way:
- model and name your objects as you see fit, and then add an invisible and as-simple-as-possible mesh around them. Call this mesh 1WALL, or 2WALL, or any number greater than 0. This will assure the best behavior.

 

[Ghoults]

I don't think that is correct. Wall colliders iirc stop working if you add stuff after it. Like 17WALL works, 17WALL_abc does not.

I'm not so sure about "greater than 0" either. I think that just means to use 01ROAD, 02ROAD and so forth because that's the naming convention. This is easy to test and prove me wrong though. Just name your 0TARMAC to VIS0TARMAC and tell me how it goes. .

edit see below.

 

[Fat-Alfie]

Just tested this and 0 prefix makes it non-physical mesh. Any suffix after WALL makes no difference either.