Problem with IA in btb tracks.
- Thread starter ElWeon18
- Start date
Make sure its properties are 'collide' and not 'drivable'. If you're using a new material (or one from an XPack) make sure its using one of the standard material names from the 'rFactor material names' menu.
You should also check your corridor widths; make sure the green lines do not extend beyond the wall, otherwise the AI will think they can drive there.
You should also check your corridor widths; make sure the green lines do not extend beyond the wall, otherwise the AI will think they can drive there.
Hi ElWeon18,
Have you checked the wall's properties in BTB? Note the "Collision" checkbox in the screen grab below:
If this box is not selected, the wall will not be seen by A.I. as "solid".
You can also check the wall's entry in the "trk" file (using a text editor like Notepad) to verify that it is a "CollTarget"; see below:
If you have 3DSimED, the wall's properties can be verified graphically:
Your problem may be related to the wall's assigned "Material"; depending upon the track's "tdf" file; it should have a Material named "twal, cem, wall, cmwall" in order for rFactor to understand that it is made of something solid.
If necessary, I may be able to assist further if you forward your project's "trk" file.
Have you checked the wall's properties in BTB? Note the "Collision" checkbox in the screen grab below:
If this box is not selected, the wall will not be seen by A.I. as "solid".
You can also check the wall's entry in the "trk" file (using a text editor like Notepad) to verify that it is a "CollTarget"; see below:
If you have 3DSimED, the wall's properties can be verified graphically:
Your problem may be related to the wall's assigned "Material"; depending upon the track's "tdf" file; it should have a Material named "twal, cem, wall, cmwall" in order for rFactor to understand that it is made of something solid.
If necessary, I may be able to assist further if you forward your project's "trk" file.
Last edited:
Hi ElWeon18,
Your issues appear to pertain to "material" names;
wall5_s0
wall6_s0
wall7_s0
wall13_s0
wall18_s0
wall31_s0
wall32_s0
wall34_s0
wall35_s0
wall37_s0
wall38_s0
wall39_s0
wall40_s0
wall41_s0
are assigned materials named;
rmbl249
rmbl250
rmbl278
I simply renamed rmbl249 to wall_rmbl249, rmbl250 to wall_rmbl250 and rmbl278 to wall_rmbl278. I then loaded your track in rFactor and verified that no cars passed through any wall.
I suggest that if you wish a wall to react as a rumble strip; either modify the track's ".tdf" file or create another surface (with material named "wall") behind the "rmbl" surface. The simplest solution may be to name said surfaces as "twall".
Good luck,sir. Your track is beautiful!
Your issues appear to pertain to "material" names;
wall5_s0
wall6_s0
wall7_s0
wall13_s0
wall18_s0
wall31_s0
wall32_s0
wall34_s0
wall35_s0
wall37_s0
wall38_s0
wall39_s0
wall40_s0
wall41_s0
are assigned materials named;
rmbl249
rmbl250
rmbl278
I simply renamed rmbl249 to wall_rmbl249, rmbl250 to wall_rmbl250 and rmbl278 to wall_rmbl278. I then loaded your track in rFactor and verified that no cars passed through any wall.
I suggest that if you wish a wall to react as a rumble strip; either modify the track's ".tdf" file or create another surface (with material named "wall") behind the "rmbl" surface. The simplest solution may be to name said surfaces as "twall".
Good luck,sir. Your track is beautiful!
Last edited:
For a "quick & dirty" solution, you can overwrite the "SAFER" materials definition by pasting the following text in your track's TDF file:
// SAFER Walls (spring/damper = 0 for immovable objects)
[FEEDBACK]
Legal=false Spring=0.0 Damper=0.0 CollFrict=0.11 Sparks=0 Scraping=1 Wallskids=1 Sound=guardrail
Materials=safer,rmbl249,rmbl250,rmbl278
R Soul's is a more proper method, however.
// SAFER Walls (spring/damper = 0 for immovable objects)
[FEEDBACK]
Legal=false Spring=0.0 Damper=0.0 CollFrict=0.11 Sparks=0 Scraping=1 Wallskids=1 Sound=guardrail
Materials=safer,rmbl249,rmbl250,rmbl278
R Soul's is a more proper method, however.
Hi! I go to that option, but the materials have that name. What I have to do?The easiest thing to do is go into BTB and go to the materials section (). Find the materials used for those walls and edit their 'rFactor material name' property and change it from rmbl to wall
Hello everyone!
I know the post is old, but the problem reported here is current... after all, ElWeon18 has always continued to produce circuits with the same problem: AIs keep going through walls. They're solid for drivers, but not for AI. I don't believe it's a personal problem of ElWeon18, but rather a bug produced by BTB, because after the emergence of this program and the various tracks produced by various modelers the result is always the same: AI does not collide with walls.
I did the procedures indicated by Gwaldock and I am surprised that he had a positive result because this did not happen to me. And I'm sure it didn't work well for ElWeon18 either, because, as I said, their work always had the same problem. It would, however, be interesting if Gwaldock, if he solved the problem so simply, to post this same track with the collision walls so that we can test this, it would be of great value to all of us who suffer from this problem and perhaps we would actually learn to solve the numerous circuits that always present this.
I'm sure the problem is generated by BTB because I have several circuits produced before 2008, when the infamous BTB (so good because it's a facilitator for the production of circuits and so bad because I can't stand to see so many circuits equal in aesthetics and on top of that with this unbearable bug!) was released. These pre-2008 circuits do not feature a single collision-free wall; I call them pre-BTB and I have incredible admiration for these circuits, from the simplest to the most elaborate, because, in addition to being functional they are very original – there were no terrible xpacks that today make practically all circuits look the same, except for creative modelers who apply their own ideas, as is the case with the LFT-ElWeon18 circuits.
Oh yes, as a curiosity, I say that when I converted these circuits generated by the BTB from RF to F1C what happened was exactly the opposite of what happens with RF: the AIs collided with the walls and I didn't... Curious, isn't it?!
Well, then, I propose a new discussion on the subject, because there has been more than a decade of a problem that until then no one really comes forward to actually solve or, even if I didn't want to give the solution, please, at least post the repaired circuits.
Thank you
I know the post is old, but the problem reported here is current... after all, ElWeon18 has always continued to produce circuits with the same problem: AIs keep going through walls. They're solid for drivers, but not for AI. I don't believe it's a personal problem of ElWeon18, but rather a bug produced by BTB, because after the emergence of this program and the various tracks produced by various modelers the result is always the same: AI does not collide with walls.
I did the procedures indicated by Gwaldock and I am surprised that he had a positive result because this did not happen to me. And I'm sure it didn't work well for ElWeon18 either, because, as I said, their work always had the same problem. It would, however, be interesting if Gwaldock, if he solved the problem so simply, to post this same track with the collision walls so that we can test this, it would be of great value to all of us who suffer from this problem and perhaps we would actually learn to solve the numerous circuits that always present this.
I'm sure the problem is generated by BTB because I have several circuits produced before 2008, when the infamous BTB (so good because it's a facilitator for the production of circuits and so bad because I can't stand to see so many circuits equal in aesthetics and on top of that with this unbearable bug!) was released. These pre-2008 circuits do not feature a single collision-free wall; I call them pre-BTB and I have incredible admiration for these circuits, from the simplest to the most elaborate, because, in addition to being functional they are very original – there were no terrible xpacks that today make practically all circuits look the same, except for creative modelers who apply their own ideas, as is the case with the LFT-ElWeon18 circuits.
Oh yes, as a curiosity, I say that when I converted these circuits generated by the BTB from RF to F1C what happened was exactly the opposite of what happens with RF: the AIs collided with the walls and I didn't... Curious, isn't it?!
Well, then, I propose a new discussion on the subject, because there has been more than a decade of a problem that until then no one really comes forward to actually solve or, even if I didn't want to give the solution, please, at least post the repaired circuits.
Thank you
So on my track DOCKLANDS i was getting this problem on three specific corners, where the AI would run slightly wide and go through the walls, which, for a street circuit kind of ruined the whole concept. It took the following steps to resolve it.
1. First ensured corridors didn't overlap the wall.
2. Created an invisible collision wall that was several metres high and extended below the ground by several metres.
3. Obviously ensured the barriers/armco/walls were collision objects.
4. Double sided the barriers/armco/walls textures
5. Ensure the texture is named CMWL. (for concrete wall) or GRDR (for armco barrier)
Following all those steps the AI stopped going through walls and will now collide with them if they run wide.
I've implemented the same steps on another street circuit (Marston Gate yet to be released) and the AI do not pass through walls.
As I'm writing this I've had the thought I've never seen AI pass through tyrewalls. So an easy solution would be to place a tyrewall.sobj in the same location as the wall, and set the tyrewall to be invisible. You'd get the physical barrier of the tyrewall with the desired visual barrier of the concrete wall.
1. First ensured corridors didn't overlap the wall.
2. Created an invisible collision wall that was several metres high and extended below the ground by several metres.
3. Obviously ensured the barriers/armco/walls were collision objects.
4. Double sided the barriers/armco/walls textures
5. Ensure the texture is named CMWL. (for concrete wall) or GRDR (for armco barrier)
Following all those steps the AI stopped going through walls and will now collide with them if they run wide.
I've implemented the same steps on another street circuit (Marston Gate yet to be released) and the AI do not pass through walls.
As I'm writing this I've had the thought I've never seen AI pass through tyrewalls. So an easy solution would be to place a tyrewall.sobj in the same location as the wall, and set the tyrewall to be invisible. You'd get the physical barrier of the tyrewall with the desired visual barrier of the concrete wall.
Last edited:
Hi, Caribstu!
Here we are again; Thanks for responding!
When I talk about these walls, I get nervous... It's one of the only things, unfortunately, that I really can't come up with... and, in fact, I didn't even want to give a solution, at least not on the basis of effort, but rather that the circuits could be produced the way they have to be produced, all coming out of the "factory" (BTB) working perfectly the way it has to be.
When you say you've never seen AI go through tires I'm surprised, because the problem is also the same with tire barriers, regardless of whether the settings in the SCN or TDF are correct, it's enough to be a BTB product that the problems are the same...
In fact, what amazes me the most is that I can take an object that is solid in a given circuit (not BTB) and put it in a BTB circuit and that object ceases to be solid in that circuit (BTB).
I've tried to apply invisible collision barriers by naming the material correctly according to the TDF and with the correct configuration in the SCN, but nothing worked...
Out of curiosity, could you, for example, do this work on the track that ElWeaon18 posted above and post it here again with the positive result you get? It would be nice to see it with my own eyes... Just as it would be interesting to see the result of the track that Gwaldock produced... It would be really amazing to solve the problem just by renaming the name of the materials, but since I didn't get the same result as him, I only believe by seeing... Just as I could do what you propose, but let's recognize that the work is much bigger and in the end I could have a bad result... So, if you are sure it works, please offer us this; It would be very important for us to learn this from someone who knows how to do it! In fact, of all that you enumerated I did and achieved nothing... Maybe I'm missing something and you can teach it in practice... Can it be?
Thank you!
Hugs
Last edited:
Anyway, I downloaded your track, Docklands, even though it's not for RF, in order to study some of what you did on it; you may be out of time to do the task I asked for earlier, with the ElWeaon18 e-prix, and suddenly I understand something I've been looking for for a long time... If I get something positive, I'll let you know.
Dude, I'm not even thinking about walls anymore, a subject that annoys me a lot... I watched the video of Docklands, as well as I was able to see it in 3dsimedV3 (in V1 and V2 it causes CTD... and I'm not very familiar with the V3, so I can't study much on it) and the circuit is amazing! Congratulations on that; Great job! Have you considered converting to RF? It would be a very well-received job, for sure!
Well, thank you for downloading the track (eprix) and, if it's not going to give you too much work, I thank you in advance for the willingness, regardless of the result, at least you're a guy who is willing to help and that's worth a lot!
Thanks again!
Hugs
