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. 😁