DumbAIMisc 1.1.2

[Tetri]

.

I made a simple try and nothing has crashed so I suppose it may work without extended physics activated. The app has grown to a lot of code, it is hard to be sure of everything without extensive testing. The best thing is to try it and report it there if you see a crash in the log, I'd have a look.

I think the apis are unrelated because you can't access physics apis thru an lua app and cannot access lua apis thru a physics lua (a sentence that needs to be read multiple times😅).

I discovered that while trying to force turbo values on cars via aiwhisp - which couldn't be done, whereas integrating a script directly in the car data worked flawlessly.

It makes sense to separate both - preventing cheating or exploiting physics thru a third party soft. And it allows cars on a server to have 100% match on their physics.

Hence why i 'm confident "extended physics" has absolutly no parts/conflicts in your lua app. The lua Apis are working fully with them on or off.

Therefore should be exclusively reserved for cars developped with extended physics.

And apart from the AI being slower - probably due to some tyre contact improvment - the player is usually barely noticing them on cars developped without.

 

[Gabriele]

I've never used extended physics (I don't know if the "DRM Revival" mod I'm using requires it). I'll run a race with extended physics disabled and tell you what happened. 😁

 

[Tetri]

I've never used extended physics (I don't know if the "DRM Revival" mod I'm using requires it). I'll run a race with extended physics disabled and tell you what happened. 😁

Have a look at general graphics as well - extended physics covers a wild range of improvments that can be related to lightings, shaders, materials etc.

Your best call, apart from reading the latest DRM's release log, is probably to look for an extension.ini file and read what's inside. Can't remember, but it looks like "extendedsettings = -2" or some stuff like that and a bunch of edited values.

I have a niche mod that needs extended physics strictly for its mirrors for example😂.
The Alfa Romeo TZ2 is using extended physics for its external engine sound , with a dedicated script. Turning ext phys off with this car would create a lua bug detection ingame in the luadebug.

In my opinion, for offline, look at pace. If it's slower with ext phys, turn it off.

 

[Gabriele]

Have a look at general graphics as well - extended physics covers a wild range of improvments that can be related to lightings, shaders, materials etc.

Your best call, apart from reading the latest DRM's release log, is probably to look for an extension.ini file and read what's inside. Can't remember, but it looks like "extendedsettings = -2" or some stuff like that and a bunch of edited values.

I have a niche mod that needs extended physics strictly for its mirrors for example😂.
The Alfa Romeo TZ2 is using extended physics for its external engine sound , with a dedicated script. Turning ext phys off with this car would create a lua bug detection ingame in the luadebug.

In my opinion, for offline, look at pace. If it's slower with ext phys, turn it off.

I'm not an expert at reading and interpreting the values in the various files... If the AI is much slower than me, should I disable extended physics? I'll use an AI value of 95%.

 

[Tetri]

I'm not an expert at reading and interpreting the values in the various files... If the AI is much slower than me, should I disable extended physics? I'll use an AI value of 95%.

I always use ai @100% /30% aggression. Make them do 5 laps, watch their times, test without extended physics next and compare

 

[Gabriele]

Track: Daytona (reboot team 1.3.1)
Cars: Drm Mod and Légion's Porsche 935/80
Laps: 36
I've had issues with both "extended physics" enabled and disabled:
Cars retiring and rejoining the race.
Cars entering the pits and unable to exit. The car attempts to exit but is automatically returned to the pits.
P.S.: Could the app conflict with Nuzzi's apps?

 

[ancient_3]

No, not a conflict with another app, nor a car problem: I just tested and had some bug using Kunos F488 GT3 on the same track.

For me it happened only in a week-end session, not in quick race. The bots go to pits right at start and then mess around without being able to pit.

This is really a strange bug: I first thought of a pitlane problem, but during qualifying, bots are able to go out and go back to pits several times without issues.

 

[Gabriele]

No, not a conflict with another app, nor a car problem: I just tested and had some bug using Kunos F488 GT3 on the same track.

For me it happened only in a week-end session, not in quick race. The bots go to pits right at start and then mess around without being able to pit.

This is really a strange bug: I first thought of a pitlane problem, but during qualifying, bots are able to go out and go back to pits several times without issues.

Is it a circuit issue, then? I'm using it for a custom championship with race weekends, and this bug is distorting the results

 

[ancient_3]

Is it a circuit issue, then? I'm using it for a custom championship with race weekends, and this bug is distorting the results

No it is a DumbAI issue becauseif you remove the app, the start is proceeding as usual.

It is related to pitlane in someway: if you remove pitlane.ai in the ai folder, then the start is OK even with DumbAI.

So there is something in DumbAI code that is related to the start procedure which is misinterpreted by the app: makes them go to pit from start but eventually do not allow them to pit once near their pit box

I'll try to find a fix !

 

[Gabriele]

No it is a DumbAI issue becauseif you remove the app, the start is proceeding as usual.

It is related to pitlane in someway: if you remove pitlane.ai in the ai folder, then the start is OK even with DumbAI.

So there is something in DumbAI code that is related to the start procedure which is misinterpreted by the app: makes them go to pit from start but eventually do not allow them to pit once near their pit box

I'll try to find a fix !

I had a race weekend, qualifying was fine, but the problems were in the race. Do you think if I delete "pitlane.ai" I could use the circuit without problems? 🙂

 

[ancient_3]

ancient_3 updated DumbAI with a new update entry:

new feature and some fixes

changelog:

- new feature: human player automatically gets tyre compound and AI computed fuel level from DumbAI default behavior in its setup menu, as a default choice

- corrected a bug where AI would always have full tank at start in no refuel scenarios

- fixed a bug display in race engineer (same time gap displayed for car +1 and car +2)

- fixed cases where AI would put wet tyres at start of dry races

- fixed issue when CSP is not able to generate rain tyres

- fixed...

Read the rest of this update entry...

 

[ancient_3]

I had a race weekend, qualifying was fine, but the problems were in the race. Do you think if I delete "pitlane.ai" I could use the circuit without problems? 🙂

Just test the new release, I think I found a fix for your problem

 

[Gabriele]

Just test the new release, I think I found a fix for your problem

I'll try it and let you know. 😁
Thank you so much.😁

 

[Tetri]

So there is something in DumbAI code that is related to the start procedure which is misinterpreted by the app: makes them go to pit from start but eventually do not allow them to pit once near their pit box

I'll try to find a fix !

Wait wait wait you apparently found the issue. What was it? I 've been having random issues with pits for ever, and i'm familiar with those AIs going rogue at start after a qual session. Tell me everything😂

 

[ancient_3]

Wait wait wait you apparently found the issue. What was it? I 've been having random issues with pits for ever, and i'm familiar with those AIs going rogue at start after a qual session. Tell me everything😂

This is what I observed :

=> the bug happened only if there was a pitlane.ai file
=> the bug happened only when fuel multiplier was set to 0
=> the bug happened only when DumbAI was active

When fuel multiplier is set to 0, DumbAI sets the fuel level to a very small amount of fuel (10 Liters). I suspected this fuel level was too low and triggered the native AC pitstop behavior for refuel. I suspected it happened only in this particular track because you start at a position where it is still possible to go to the pits. Whatever , once native AC has sent it wanted to go to pit even only one time, you can't override it with lua later.

But DumbAI was still spamming that it did not want to pit, using setAIPitStopRequest(i,false). If you send this signal while car has also received a pitstop order from native AC while in the pitlane, the car is usually confused and misses the pit box (and usually starts messing around until he finds in the pitlane a wall to crash and rest lol)

So if my diagnostic was correct, the solution in the new update was to send setAIPitStopRequest(i,false) just once, but right after the creation of the bot, so that native AC would not have the time to trigger its one, thanks to the 100ms delay added by x4fab in preview 212.

Here it worked with the 488GT3 on the same track. Let's see if @Gabriele confirms it works with his mod.

 

[Gabriele]

This is what I observed :

=> the bug happened only if there was a pitlane.ai file
=> the bug happened only when fuel multiplier was set to 0
=> the bug happened only when DumbAI was active

When fuel multiplier is set to 0, DumbAI sets the fuel level to a very small amount of fuel (10 Liters). I suspected this fuel level was too low and triggered the native AC pitstop behavior for refuel. I suspected it happened only in this particular track because you start at a position where it is still possible to go to the pits. Whatever , once native AC has sent it wanted to go to pit even only one time, you can't override it with lua later.

But DumbAI was still spamming that it did not want to pit, using setAIPitStopRequest(i,false). If you send this signal while car has also received a pitstop order from native AC while in the pitlane, the car is usually confused and misses the pit box (and usually starts messing around until he finds in the pitlane a wall to crash and rest lol)

So if my diagnostic was correct, the solution in the new update was to send setAIPitStopRequest(i,false) just once, but right after the creation of the bot, so that native AC would not have the time to trigger its one, thanks to the 100ms delay added by x4fab in preview 212.

Here it worked with the 488GT3 on the same track. Let's see if @Gabriele confirms it works with his mod.

I re-ran the race, and everything worked 100%. 😁
The only strange behavior was the cars that retired due to an accident: after a while, they restart. 🤷‍♂️
Sometimes the lapped cars don't move, and accidents happen. 😅🤷‍♂️
Anyway, the app works very well, thank you very much. I'll do more championship races and keep you updated. 😁

 

[ancient_3]

Hi Gabriele,
thanks for the feedback

The only strange behavior was the cars that retired due to an accident: after a while, they restart. 🤷‍♂️

For this one, are you sure you have un-checked "get back to the race after going to pits" option in CSP/AI new behaviour/AI retirement settings ? I did and never saw a retired car go back to race with DumbAI

Sometimes the lapped cars don't move, and accidents happen. 😅🤷‍♂️

For this one, it may happen that lapped cars don't make the lateral move in specific part of tracks where the ai line is narrow. But they should still be moving , while slower. This is a thing I want to improve in the near future, now that the DumbAI basis is stronger.

Could you tell me in which situation you observed it ?

 

[Gabriele]

Hi Gabriele,
thanks for the feedback

For this one, are you sure you have un-checked "get back to the race after going to pits" option in CSP/AI new behaviour/AI retirement settings ? I did and never saw a retired car go back to race with DumbAI

For this one, it may happen that lapped cars don't make the lateral move in specific part of tracks where the ai line is narrow. But they should still be moving , while slower. This is a thing I want to improve in the near future, now that the DumbAI basis is stronger.

Could you tell me in which situation you observed it ?

Honestly, I don't know...😅😂
I'll check if I disabled the "get back to the race after going to the pits" option. I disabled "new AI behavior." 🤔
The lapped drivers issue occurred in the slow section of the circuit, perhaps because the track is narrow.
But the app still worked perfectly. 😁

 

[Thockard]

Hi Gabriele,
thanks for the feedback

For this one, are you sure you have un-checked "get back to the race after going to pits" option in CSP/AI new behaviour/AI retirement settings ? I did and never saw a retired car go back to race with DumbAI

For this one, it may happen that lapped cars don't make the lateral move in specific part of tracks where the ai line is narrow. But they should still be moving , while slower. This is a thing I want to improve in the near future, now that the DumbAI basis is stronger.

Could you tell me in which situation you observed it ?

Hi ancient_3,
Man you are making a great job with this app. That is really a game changer for me.

I've made some tests on my side because I observed the same problem as Gabriele regarding the retired cars.
They are teleported to the pits and restart at low speed, creating crashes with other cars.

It happens either New AI behavior be activated or not.
I always play with the "get back to the race after going to pits" option deactivated.
AIWhisperer was also running.

I uninstalled DumbAI and the problem disappeared. Any retired cars teleported to the pits stayed in pits.

BUT I also made another test by installing RARE (DumbAI still unistalled) and forcing cars to go to pits (with DumbAI always uninstalled)
I'm sure I've seen cars exiting the pits after crashing but :
1 - they were running normally, at full speed
2 - unfortunately I forgot to check if they were teleported or rejoined the pits by themselves.
So I have to redo the test to get accurate conclusions but I think it could be interesting to have in mind that it could possibly happen with the use of RARE.

 

[ancient_3]

Could you provide me a detailed combo so that I can redo it myself on my computer? like 1 track, 1 car, the CSP version, how you made the cars go to pit and what are the other app that are running ? I only run DumbAI and Pure over CSP so it is hard to guess how it would interact with other app.

I made plenty of >10 lap races where some AI went teleported early in the race due to crash at start for example and never saw one get back on track so I don't know how to help but curious to see how it happens for you

 

[Thockard]

Could you provide me a detailed combo so that I can redo it myself on my computer? like 1 track, 1 car, the CSP version, how you made the cars go to pit and what are the other app that are running ? I only run DumbAI and Pure over CSP so it is hard to guess how it would interact with other app.

I made plenty of >10 lap races where some AI went teleported early in the race due to crash at start for example and never saw one get back on track so I don't know how to help but curious to see how it happens for you

I am currently using ASR f1 1991.
20 cars on track is enough.
Race of 22 laps.
I drove Ferrari or Williams.
Extended physics activated/deactivated changes nothing.

Track Adelaide 92 by Shi.
With RARE, I forced the tire wear to 96-98% for example. In general Ai adapt their tyre to avoid a pit stop so they generally use hard or medium compounds.
With DumbAI, I used the default ini file but also used a modified file (changed the default compound to B (medium) and pitting with tyre change and refueling))

I am using CSP 0.3.0 preview 338
Other apps running : AIWhisperer
Installed but not running when playing : AIHint reader, Ai spline editor, Fastlane editor, JumpAIline

 

[Thockard]

Could you provide me a detailed combo so that I can redo it myself on my computer? like 1 track, 1 car, the CSP version, how you made the cars go to pit and what are the other app that are running ? I only run DumbAI and Pure over CSP so it is hard to guess how it would interact with other app.

I made plenty of >10 lap races where some AI went teleported early in the race due to crash at start for example and never saw one get back on track so I don't know how to help but curious to see how it happens for you

Ok, I've made more tests, here are the results :

Ref cases are numbers 15 and 16, with cars staying in pits when teleported in pits after a crash.
A different result compard to these cases means something has changed.

A cross in a cell means the parameter/result is activated/observed.
Just a remark, I've previously said that sometimes cars were exiting pits at low speed, it was a result of the blue flags defined in DumbAI, no issue here.
I add @Tetri here, that could interest him also as it appears AIW seems to alter something too.

Note : If you want to make the same tests as mine with Adelaide 92, use a ai_hints file.ini with :the following lines to enforce crashes at the hairpin :
[BRAKEHINT_0]
START=0.670
END=0.750
VALUE=1.1

 

[Tetri]

Ok, I've made more tests, here are the results :

View attachment 1524906

Ref cases are numbers 15 and 16, with cars staying in pits when teleported in pits after a crash.
A different result compard to these cases means something has changed.

A cross in a cell means the parameter/result is activated/observed.
Just a remark, I've previously said that sometimes cars were exiting pits at low speed, it was a result of the blue flags defined in DumbAI, no issue here.
I add @Tetri here, that could interest him also as it appears AIW seems to alter something too.

Note : If you want to make the same tests as mine with Adelaide 92, use a ai_hints file.ini with :the following lines to enforce crashes at the hairpin :
[BRAKEHINT_0]
START=0.670
END=0.750
VALUE=1.1

I have no doubt aiwhisp can be involved. If you're using a beta version like 0.82+, it's even worse because i NEEDED that stupid pit state to stay quiet and overrode the whole system for the gas/brake/offset inputs to be shut down before/in pits.

So far i have a pit state debug active in the debug of aiwhisp (thru luadebug). But i also have a teleport automation for cars that are crashed or moving at less than 50 km/h for more than 10 secs... I might have gotten rid of it on v0.83, but it's pretty easy to spot.

So, for ancient_3 to follow on my approach : pitlane and pitstop are automatically an aiwhisperer shutdown(all logics).

If a "aiisgoingtopits" command is triggered, either thru dumbaAI or vanilla AC, aiwhisp is shut down passing 80% of track progress.

If a session is restarted, switched (ie quals to race), or if any session flag is triggered, ac.state is restarted and untouched for 10 seconds.


Yet, in very particular and obviously superastonishingly annoying occurences, the pit state is not reset, and stays set for either a whole race or until next pit stop (isinpitlane triggered true even if running middle track, go figure).

So, although i have no clue why some AIs go stupid while everyone else seems fine, i wonder if aiwhisp (or DumbAI) wouldn't, sometimes, mix up the pitstate/pitstop/goingtopits states and conflict with AC's first call.

And i'm also pretty sure CSP new ai behavior is also to blame, since it gives very various results depending on csp version, especially from 2.11 to 3+.

Latest build was super stable for me.

Last tip : in experimental in CSP, there's a checkbox to "force csp physics to all cars". And i don't like some AI behaviors when this is checked.

To push things forward for @Thockard, the ferrari 643 AI on Adelaide is going 1.10 with latest csp version. I still don't understand why we don't get the same results, but i get 3 different lap times with the latest 3 CSP versions, so i'm inclined to think CSP is responsible for most of latest AI bugs.

I am saddly in the middle of a work crunch atm and can't experiment as much as i wish with AC, so i'll let you giys figure it out until i'm back at it