DumbAIMisc 1.0

[ancient_3]

ancient_3 updated DumbAI with a new update entry:

new blue flag behavior

Change log:

- 3 new UI options for blue flag: "None" is AC/CSP vanilla behavior, "Secure" is blue flag behavior from Dumb AI 0.3 and "Enhanced / Dangerous" is a new experimental blue flag behavior

- new UI slider for AI Caution: if "Enhanced / Dangerous" is selected, gives the value of caution that AI should use to overtake during outlap event (0.5 the more agressive up to 1.0 "vanilla" AI caution ; 0.6 as default)

- new option "Enhanced /...

Read the rest of this update entry...

 

[snibedysnab]

Just a curiosity, is this mod compatible with AI Whisperer?

 

[ancient_3]

Just a curiosity, is this mod compatible with AI Whisperer?

Yes for sure if you disable the Blue Flag behavior.

If you keep it enabled, DumbAI mod only modifies the AICaution for outlapping bot and puts a maximum speed value for the AI outlapped bot with a lateral move aside of the main AI spline, only at specific time of the race (when the bot is outlapped) so it depends on what AI Whisperer is doing at the same time for these same bots. One problem I think may be that my mod would restore AICaution to 1 after the bot has finished to outlap so it then depends on how AI Whisperer would manage AI Caution values. @Tetri should know better than me about this

 

[Tetri]

Just a curiosity, is this mod compatible with AI Whisperer?

Saw the notification from @ancient_3

Both are perfectly compatible, apart from the AICaution mods from aiwhisperer. In the next update i'm gonna use SPlineOffset as well, so that would be 2 conflicts, but nothing really noticeable, AICaution would be the one really missing.

That's only if you use elasticaution from the behaviors tweak or have made modifications to the AICautionlevel.

In this case, DumbAI would need a small modification in its code.

The part where

if oneOfThemIsOutLappingMe == 0 then
physics.setAISplineOffset(i, 0, false)
physics.setAICaution(this.ac_id, 1)
end

Unless i missed a condition, this makes the AICaution and SplineOffset always reset on every frame, overwriting whisperer (which updates at 10hz)

i 'm not sure this is needed, it could be called once at the end of the blueflag situations ?


That would fix any conflict (and optimise perfs a little, preventing repeated calls on default values every frames), since Dumb AI would take priority with its faster script update.

What do you think @ancient_3 ?



Something like :

--in the variables :
was_outlapping_previous = false


--then in apply_behavior

function this.apply_behavior()
local sum = 0
for key, value in pairs(this.is_outlapping) do
sum = sum + value
end

if sum > 0 then
physics.setAICaution(this.ac_id, this.ai_caution)
this.was_outlapping_previous = true
else
if this.was_outlapping_previous then --RESET
physics.setAICaution(this.ac_id, 1)
this.was_outlapping_previous = false
end
end
end

I guess you could apply the same logic to detectblueflag and checkisslowrunner so that they don't apply any mods until the situation is detected

(Quickly done with the quick resume of Dumbai from my chatbot, so probably to be checked and tweaked properly, but you get the idea)

 

[ancient_3]

ancient_3 updated DumbAI with a new update entry:

AI Whisperer compatibility & minor improvements

Change log:

- Compatibility with AI Whisperer app from Tetri: setAICaution & SetAISplineOffset are only modified during Blue Flag events so that AI Whisperer can retake hands on these variables just after the event.

- minor improvement: Removed the functionnality to change line if outlapping process was taking too long as it created sometimes collisions in beginning part of some straights where outlapper would try to overtake just after the turn while...

Read the rest of this update entry...

 

[ancient_3]

Saw the notification from @ancient_3

Both are perfectly compatible, apart from the AICaution mods from aiwhisperer. In the next update i'm gonna use SPlineOffset as well, so that would be 2 conflicts, but nothing really noticeable, AICaution would be the one really missing.

That's only if you use elasticaution from the behaviors tweak or have made modifications to the AICautionlevel.

In this case, DumbAI would need a small modification in its code.

The part where

if oneOfThemIsOutLappingMe == 0 then
physics.setAISplineOffset(i, 0, false)
physics.setAICaution(this.ac_id, 1)
end

Unless i missed a condition, this makes the AICaution and SplineOffset always reset on every frame, overwriting whisperer (which updates at 10hz)

i 'm not sure this is needed, it could be called once at the end of the blueflag situations ?


That would fix any conflict (and optimise perfs a little, preventing repeated calls on default values every frames), since Dumb AI would take priority with its faster script update.

What do you think @ancient_3 ?



Something like :

--in the variables :
was_outlapping_previous = false


--then in apply_behavior

function this.apply_behavior()
local sum = 0
for key, value in pairs(this.is_outlapping) do
sum = sum + value
end

if sum > 0 then
physics.setAICaution(this.ac_id, this.ai_caution)
this.was_outlapping_previous = true
else
if this.was_outlapping_previous then --RESET
physics.setAICaution(this.ac_id, 1)
this.was_outlapping_previous = false
end
end
end

I guess you could apply the same logic to detectblueflag and checkisslowrunner so that they don't apply any mods until the situation is detected

(Quickly done with the quick resume of Dumbai from my chatbot, so probably to be checked and tweaked properly, but you get the idea)

I got the idea and made an update. If you can try it and tell me

This trick won't be perfect as even if you're on 10Hz , if the outlap process takes too long, AI Whisperer will inject its modifications while DumbAI is still putting its ones...

In the end, when you're ready with a new complete AI behavior , these apps should be merged , so that you would benefit of the "strategy" parts of DumbAI while integrating its Blue Flag behavior directly into you AI modifications : much cleaner way to solve the problem

 

[Tetri]

Definitly something i wanted to do at some point. Looked into it, should not be too hard🤟.

I'm still trying absolute nonsensical lunatic changes to see if i can finally make that AI up its game (i miss free time), so for now let's have them separated, your blue flag seems to be "clean", which is absolutly not the case with AIwhisperer😂

 

[Philip00]

Hey @ancient_3

First of all, let me say again that the app is absolutely amazing and works really well.

I’ve encountered one issue, which seems to be related to AC AI behavior rather than the app itself. I’m having trouble finding a solution when one AI car is trying to lap another. Even when the lapped car moves off the racing line and there is plenty of space, the lapping car still gets stuck behind it.

Example:


Using the same mod, I don’t experience this issue on the F1 1992 Kyalami track. This makes me think the problem may also be related to the 1998 Suzuka track by Shin, which appears to be narrower than Kyalami.

I would like to ask whether you could advise on any possible solutions for this. For example, I was thinking about increasing the throttle limit for lapped cars in the app settings.

I also wanted to ask @Tetri whether AI Whisperer could help in this situation.

I understand that this may not be directly related to the app, but I wanted to ask for your opinion or suggestions, and I hope that’s okay.

Thank you so muich for this amaizing app,

Philip

 

[Tetri]

Hey @ancient_3

First of all, let me say again that the app is absolutely amazing and works really well.

I’ve encountered one issue, which seems to be related to AC AI behavior rather than the app itself. I’m having trouble finding a solution when one AI car is trying to lap another. Even when the lapped car moves off the racing line and there is plenty of space, the lapping car still gets stuck behind it.

Example:


Using the same mod, I don’t experience this issue on the F1 1992 Kyalami track. This makes me think the problem may also be related to the 1998 Suzuka track by Shin, which appears to be narrower than Kyalami.

I would like to ask whether you could advise on any possible solutions for this. For example, I was thinking about increasing the throttle limit for lapped cars in the app settings.

I also wanted to ask @Tetri whether AI Whisperer could help in this situation.

I understand that this may not be directly related to the app, but I wanted to ask for your opinion or suggestions, and I hope that’s okay.

Thank you so muich for this amaizing app,

Philip

Hey,

yup, AI whisperer can fix this. You need AIHintsReader as well.

The idea is that the AI calculates whether it can overtake or not on those straight, and usually if it's too narrow, safeguards prevent some cars from overtaking properly.

Also, if it's a Shi track, there might be a little AI app running. I 've seen him integrating this lately, maybe with the car you're using it 's giving bad results. you can check for that AI lua app in the extension folder of the track, rename it to something different and see if it fixes your issue.


Otherwise, what you need are overtaking zones. Using AIHintsreader, you can create new aihints called "ZONE1". Once created, you can then apply specific settings for those zones in AIwhisperer (higher aggression/lower aicaution), overwriting the safe settings from AC.


It sounds a little overcomplicated at first but it is actually pretty easy to setup, 5 mins max. Then you save the settings and it's automatically called for everytime you would launch that car/track combo.

 

[ancient_3]

Hey @ancient_3

First of all, let me say again that the app is absolutely amazing and works really well.

I’ve encountered one issue, which seems to be related to AC AI behavior rather than the app itself. I’m having trouble finding a solution when one AI car is trying to lap another. Even when the lapped car moves off the racing line and there is plenty of space, the lapping car still gets stuck behind it.

Example:


Using the same mod, I don’t experience this issue on the F1 1992 Kyalami track. This makes me think the problem may also be related to the 1998 Suzuka track by Shin, which appears to be narrower than Kyalami.

I would like to ask whether you could advise on any possible solutions for this. For example, I was thinking about increasing the throttle limit for lapped cars in the app settings.

I also wanted to ask @Tetri whether AI Whisperer could help in this situation.

I understand that this may not be directly related to the app, but I wanted to ask for your opinion or suggestions, and I hope that’s okay.

Thank you so muich for this amaizing app,

Philip

Hi Philip,
Yes I'd say it is a mean DumbAI blue flag situation Native AC AI is always balancing between changing line for overtaking or keeping the normal AI spline and it seems it heavily depends on how the other bot is located aside the AI spline and the track limits. I suppose there is also collider computation and speed differential assessment, with most probably a computation to avoid cars that have suddenly crashed

So even if Dumb AI modifies caution value, depending on where you are in the track layout, this is not always sufficient to provide a smooth quick overtaking.

There is no good combination for every track but here are some elements that may enhance this situation:

- change the bots AI Agression in CM: I use between 20 & 30 values which seem to be ok without creating too much incidents. Aggression of 50 gives very strong outlapping results but also some crashes. Depends on the other bots values as well I believe

- lower the max speed limit when outlapped in Dumb AI: it can help some times but also it can make leader being stuck behind at a lower speed, losing more time. Heavily depends on the track layout, works best to enhance overtake in straights and in strong braking at the end of straigths but may have reverse effects on tracks such as Monaco or Hungary

- increase the blue flag situation detection distance in Dumb AI: which is 100m by default, I made some tries but not extensive , I'm not yet sure how much it impacts. Makes the AI bot detect the situation earlier so max speed and spline offset are launched earlier, this may help to decide the leader bot to overtake, but depends really how AC manage this overtaking decision with changing lines or not, how much meters in front of the overtaking car are used to compute the overtake decision etc...

I'm definitely interested about experiments about this but unfortunately, I lack a bit of time to make extensive tries. Also overtaking decision is a task that @Tetri is investigating I think so we may find some progress one day in this area.

 

[ancient_3]

@icey and others users, I made a small instruction manual in the second post of the thread, here: https://www.gtplanet.net/forum/threads/dumbai.434461/post-14517365

Just let me know if anything remains unclear

 

[Philip00]

Hi Philip,
Yes I'd say it is a mean DumbAI blue flag situation Native AC AI is always balancing between changing line for overtaking or keeping the normal AI spline and it seems it heavily depends on how the other bot is located aside the AI spline and the track limits. I suppose there is also collider computation and speed differential assessment, with most probably a computation to avoid cars that have suddenly crashed

So even if Dumb AI modifies caution value, depending on where you are in the track layout, this is not always sufficient to provide a smooth quick overtaking.

There is no good combination for every track but here are some elements that may enhance this situation:

- change the bots AI Agression in CM: I use between 20 & 30 values which seem to be ok without creating too much incidents. Aggression of 50 gives very strong outlapping results but also some crashes. Depends on the other bots values as well I believe

- lower the max speed limit when outlapped in Dumb AI: it can help some times but also it can make leader being stuck behind at a lower speed, losing more time. Heavily depends on the track layout, works best to enhance overtake in straights and in strong braking at the end of straigths but may have reverse effects on tracks such as Monaco or Hungary

- increase the blue flag situation detection distance in Dumb AI: which is 100m by default, I made some tries but not extensive , I'm not yet sure how much it impacts. Makes the AI bot detect the situation earlier so max speed and spline offset are launched earlier, this may help to decide the leader bot to overtake, but depends really how AC manage this overtaking decision with changing lines or not, how much meters in front of the overtaking car are used to compute the overtake decision etc...

I'm definitely interested about experiments about this but unfortunately, I lack a bit of time to make extensive tries. Also overtaking decision is a task that @Tetri is investigating I think so we may find some progress one day in this area.

Thanks @ancient_3 !

Right now my settings are the following:

AI agression: 20-30, I even tried with 50-60
Max speed limit: 120, I can try to reduce this but this seems like already pretty slow.
Blue Flag situation detectiod: 100M, I can try to increase this.

I will try out to play wtih these settings.


cheers,
Philip

 

[snibedysnab]

Infinite thanks to both of you for taking the suggestion to heart. Cheers

 

[Philip00]

Hey @ancient_3

I have a quick question regarding DumbAI and blue flag behavior.

I’ve noticed that even though I set the maximum speed when being lapped to 120 km/h, the lapped AI still limits its speed to around 40–50 km/h during blue flag situations.

Is there a way to make them reach the configured speed limit?

Thanks in advance,
Philip

 

[ancient_3]

Hey @ancient_3

I have a quick question regarding DumbAI and blue flag behavior.

I’ve noticed that even though I set the maximum speed when being lapped to 120 km/h, the lapped AI still limits its speed to around 40–50 km/h during blue flag situations.

Is there a way to make them reach the configured speed limit?

Thanks in advance,

I suspect it may be linked to the bug where low AI have difficulties to manage throttle pedal when driving at too low speed. I think CSP proposes something to deal with it in new AI behavior options but maybe is not sufficient in our case.
I'll try to find some workaround with other lua commands.

Thanks for the bug report !

 

[ancient_3]

I suspect it may be linked to the bug where low AI have difficulties to manage throttle pedal when driving at too low speed. I think CSP proposes something to deal with it in new AI behavior options but maybe is not sufficient in our case.
I'll try to find some workaround with other lua commands.

Thanks for the bug report !

@Philip00 So while some low AI have really this issue, it was not the cause of the bug: I simply had a variable name change that did not follow through the app to the inner bot code and it was simply putting a undefined value as max speed limit when outlapped, whatever you changed in the UI. Sorry for this stupid thing.

I just made a corrective that I tried with 120 km/h max and observed 122 km/h in the replay of the outlapped bot in a straight, so should work now, hopefully.

A good Christmas surprise is that the new CSP 0.3.0 preview 212 brought the changes that were necessary to override native AC AI pit stop strategy, so next DumbAI update will rewrite all pit stop management (tyre / fuel / damage) including fuel management so that we have a normal behavior where AI pits before it runs out of fuel (will try to manage running out of gas issue when pit stop to refuel not allowed) and/or out of tyres and then new pit strategies with fuel only, tyres only and mixed fuel and tyres pit stops

 

[ancient_3]

Uploaded file had mistakes, version deleted, please download the version in the next post

 

[ancient_3]

ancient_3 updated DumbAI with a new update entry:

bug correction for max speed limit when outlapped

Change log:
As the title says, a correction for a small but important bug reported by @Philip00: where the value given in the UI for max speed limit when outlapped was not forwarded to the bot. Thank you Philip !

Read the rest of this update entry...

 

[Philip00]

@Philip00 So while some low AI have really this issue, it was not the cause of the bug: I simply had a variable name change that did not follow through the app to the inner bot code and it was simply putting a undefined value as max speed limit when outlapped, whatever you changed in the UI. Sorry for this stupid thing.

I just made a corrective that I tried with 120 km/h max and observed 122 km/h in the replay of the outlapped bot in a straight, so should work now, hopefully.

A good Christmas surprise is that the new CSP 0.3.0 preview 212 brought the changes that were necessary to override native AC AI pit stop strategy, so next DumbAI update will rewrite all pit stop management (tyre / fuel / damage) including fuel management so that we have a normal behavior where AI pits before it runs out of fuel (will try to manage running out of gas issue when pit stop to refuel not allowed) and/or out of tyres and then new pit strategies with fuel only, tyres only and mixed fuel and tyres pit stops

Thanks so much Im gonna try this out now. Do you recommend to use the CSP 0.3.0 preview 212 over 0.3.0-preview140?

OMG regarding the fuel and tyre stops I cant wait to try it out, if you need any help let me know!

Thanks for the fix I am gonna give you an update soon.

Best regards,
Philip

 

[ancient_3]

Thanks so much Im gonna try this out now. Do you recommend to use the CSP 0.3.0 preview 212 over 0.3.0-preview140?

OMG regarding the fuel and tyre stops I cant wait to try it out, if you need any help let me know!

Thanks for the fix I am gonna give you an update soon.

Best regards,
Philip

For the speed limit debug, I think it should work with preview140.

For the next update, we will need preview 212 as there is in it a new lua function that allows to override AC pit stop.

In fact, I have almost finished and debugged an adaptative tyre & fuel strategy that would work with preview212. Everything look OK, bots pit either for refuel or for tyre wear.

Unfortunately, it seems that the lua function setCarFuel does not work, so it is not possible to add the correct amount (and weight) of fuel in the car during the pitstop, the car keeps the fuel level of before the pitstop and so impossible to make the AI do adaptative multiple pitstops for refuel.

I could workaround this by computing a static strategy where the bot computes the laps to stop at the start of the race, as vanilla AC/CSP does, but it would not be realistic for physics as in this case, the bot would run most of the race with 0 fuel (but still would stop to refuel at a definite lap and spend there the correct amount of time for refuel)

I have contacted x4fab to learn how he sees this setCarFuel potential bug, let's see what will happen ....

 

[Philip00]

For the speed limit debug, I think it should work with preview140.

For the next update, we will need preview 212 as there is in it a new lua function that allows to override AC pit stop.

In fact, I have almost finished and debugged an adaptative tyre & fuel strategy that would work with preview212. Everything look OK, bots pit either for refuel or for tyre wear.

Unfortunately, it seems that the lua function setCarFuel does not work, so it is not possible to add the correct amount (and weight) of fuel in the car during the pitstop, the car keeps the fuel level of before the pitstop and so impossible to make the AI do adaptative multiple pitstops for refuel.

I could workaround this by computing a static strategy where the bot computes the laps to stop at the start of the race, as vanilla AC/CSP does, but it would not be realistic for physics as in this case, the bot would run most of the race with 0 fuel (but still would stop to refuel at a definite lap and spend there the correct amount of time for refuel)

I have contacted x4fab to learn how he sees this setCarFuel potential bug, let's see what will happen ....

I just tried out the fix, and it worked flawlessly. Thank you so much again.

I’m really cheering that you found a solution for the fuel strategy, as that would be a huge game changer—but this app is already a huge game changer, to be honest.

If you need me to test anything, just let me know.

Thanks again,
Philip

 

[Chapman2424]

Quick question - how does this app interact with CSP "Adaptive AI" setting ? Do you recommend not activating it with you app initialized?

 

[ancient_3]

I just tried out the fix, and it worked flawlessly. Thank you so much again.

I’m really cheering that you found a solution for the fuel strategy, as that would be a huge game changer—but this app is already a huge game changer, to be honest.

If you need me to test anything, just let me know.

Thanks again,
Philip

Any test or feedback interest me so feel free There are probably many issues in the app as it is hard to test for everything. Especially fuel is quite long to test even with x5 multiplier , still have to wait for 8 or 9 laps to check for bots going to pits etc...

I'll try to add the fuel strategy "fixed lap" soon, so that I can go further to a definitive version of DumbAI, even not completely accurate for physics due to real fuel amount in the car.

If I find a way to use the setCarFuel (or if it is a CSP bug that is corrected), it then should be easier to add the adaptative fuel management.

Thanks for the interest in the app

 

[ancient_3]

Quick question - how does this app interact with CSP "Adaptive AI" setting ? Do you recommend not activating it with you app initialized?

I do not know I have new AI behavior activated in CSP but don't have this specific option activated so I did not test it with DumbAI (but I will try it now that you mention it !). Just let me know if you make some tests with this CSP setting and DumbAI both running and find some issues, it will help me, as mentionned above, unfortunately, I lack time for testing the app extensively so any feedback is much appreciated.

Overall, I do not know how the AI are modified by CSP and thus don't know how my lua app would override CSP behavior or not. DumbAI basically only modifies the AI caution values of the outlapper, and the spline offset & max speed limit of the outlapped, in the context of a blue flag situation, so it should not interact often with other AI behaviors ?

I expect to work later a bit on AI behavior under blue flag situation , when I have finished the DumbAI pit stop strategies computation and once I have a stable DumbAI 1.0 (which aim was initially in october just "having the softest tyres when AI pit after rain has dried on the track" haha )

 

[ancient_3]

ancient_3 updated DumbAI with a new update entry:

DumbAI first complete version

Hi !

Here is a first complete version of DumbAI with a mix of new and older features selected from past versions

New features:
- automatic computing of pit stop strategy of bots at the start of the race (fuel & tyres)

- adaptative pit stop strategy during race according to tyre wear, fuel consumption and damages, taking into account fuel and tyre multipliers

Features from older version:

- blue flag behavior for outlapped and outlapping bots

- possibility to...

Read the rest of this update entry...

 

[Philip00]

Hey @ancient_3

First of all, I’d like to say that I really enjoy version 1.0, and I’ve spent a lot of time racing with it.

That said, I’m wondering whether this could open the door to fuel-based strategies for the AI, similar to the era when refuelling was allowed between 1994 and 2009.

At the moment, it seems that the AI always starts the race with a full fuel tank. I’m curious whether it would be possible to create fuel-dependent stint strategies for them. For example, 60% of the AI could complete the race with a one-stop strategy, while the remaining 40% use a two-stop strategy.

During the 1994–2006 period, fuel strategy was the primary factor, with tyre strategy playing a secondary role. Do you think it would be possible to simulate that kind of strategic variation somehow?

The tyre wear strategy would still remain an option for the pre-1994 and post-2010 eras.

Do you think if something liek this possible to simualte those strategies somehow?
Philip

 

[ancient_3]

Hi Philip,

At the moment, it seems that the AI always starts the race with a full fuel tank.

No it should not, except the special case where the fuel amount computed for race lenght matches almost exactly the fuel tank capacity, so not likely to happen often.

The fuel computation first assess if the fuel tank capacity is enough for the race length (taking into account fuel multiplier), using the fuel_cons.ini to obtain the number of kilometers than can be done by the car per 1 L of fuel. If there is no fuel_cons.ini, it takes a default value of 1.5 Km/L .

If the global amount of needed fuel is under the fuel tank capacity, then just fill it with this amount. If it is over, then divide it by the number of stints needed to obtain a mean amount of fuel needed for each stint.

For example, if tank capacity is 120L and fuel amount needed for the race is 200L, then DumbAI will fill the tank with 100L and make a pitstop at half the race to add another 100L of fuel.

You can check it by yourself by removing the -- comment at line 261 of bot.lua file in the structures folder of DumbAI app, just before : ac.log(ac_name.." real car fuel = "..ac.getCar(this.ac_id).fuel) . The bots will then spam their fuel amount in the log of the app at each update(dt) (easier to look at it with only one opponent :-D) .

Remember the fuel management only works with CSP 0.3.0 preview 212 as x4fab added the necessary lua functions to override the fuel behavior of vanilla AC/CSP.

Hey @ancient_3



That said, I’m wondering whether this could open the door to fuel-based strategies for the AI, similar to the era when refuelling was allowed between 1994 and 2009.

At the moment, it seems that the AI always starts the race with a full fuel tank. I’m curious whether it would be possible to create fuel-dependent stint strategies for them. For example, 60% of the AI could complete the race with a one-stop strategy, while the remaining 40% use a two-stop strategy.

During the 1994–2006 period, fuel strategy was the primary factor, with tyre strategy playing a secondary role. Do you think it would be possible to simulate that kind of strategic variation somehow?

The tyre wear strategy would still remain an option for the pre-1994 and post-2010 eras.

Do you think if something liek this possible to simualte those strategies somehow?
Philip

Yes I think, at least I'm looking at it for the mixed compound pitstop strategy. In DumbAI 1.0, with this strategy, AI only checks for tyre compounds but I will also add a change in fuel management. For example, if one pit stop is needed in the race, and the AI put harder tyre compound, we could make AI start with the maximum fuel tank capacity for its first stint with hard tyres, to ensure a better probability that the first stint will be optimal and AI has a second stint with its softer tyres with much less fuel than in the first one.

But it is not easy to have it full dynamic, because it is a bit difficult to predict tyre wear, especially if you have different multipliers between fuel consumption and tyre wear. One solution could be to register tyre wear per lap, as it is done with fuel by AC and try to have a dynamic adjusments after 2-3 laps of the race , to have a mean value of tyre wear per lap and then cross it with fuel consumption per lap assessment, to better anticipate next pitstop.

Once we are at modifying the fuel consumption assessment, we can force AI to have 2 pitstops with less fuel rather than one. So yes definitely possible, but needs to be sure that significant differences can be made between strategies, according to race conditions. With tyre wear multiplier at 1.0 and fuel at 1.0, if cars are very close and fuel weight makes significant differences in lap times for this type of cars, a very hard compound that would last the whole race could make fuel strategy significant for example.

 

[Philip00]

Hi Philip,


No it should not, except the special case where the fuel amount computed for race lenght matches almost exactly the fuel tank capacity, so not likely to happen often.

The fuel computation first assess if the fuel tank capacity is enough for the race length (taking into account fuel multiplier), using the fuel_cons.ini to obtain the number of kilometers than can be done by the car per 1 L of fuel. If there is no fuel_cons.ini, it takes a default value of 1.5 Km/L .

If the global amount of needed fuel is under the fuel tank capacity, then just fill it with this amount. If it is over, then divide it by the number of stints needed to obtain a mean amount of fuel needed for each stint.

For example, if tank capacity is 120L and fuel amount needed for the race is 200L, then DumbAI will fill the tank with 100L and make a pitstop at half the race to add another 100L of fuel.

You can check it by yourself by removing the -- comment at line 261 of bot.lua file in the structures folder of DumbAI app, just before : ac.log(ac_name.." real car fuel = "..ac.getCar(this.ac_id).fuel) . The bots will then spam their fuel amount in the log of the app at each update(dt) (easier to look at it with only one opponent :-D) .

Remember the fuel management only works with CSP 0.3.0 preview 212 as x4fab added the necessary lua functions to override the fuel behavior of vanilla AC/CSP.

Yes I think, at least I'm looking at it for the mixed compound pitstop strategy. In DumbAI 1.0, with this strategy, AI only checks for tyre compounds but I will also add a change in fuel management. For example, if one pit stop is needed in the race, and the AI put harder tyre compound, we could make AI start with the maximum fuel tank capacity for its first stint with hard tyres, to ensure a better probability that the first stint will be optimal and AI has a second stint with its softer tyres with much less fuel than in the first one.

But it is not easy to have it full dynamic, because it is a bit difficult to predict tyre wear, especially if you have different multipliers between fuel consumption and tyre wear. One solution could be to register tyre wear per lap, as it is done with fuel by AC and try to have a dynamic adjusments after 2-3 laps of the race , to have a mean value of tyre wear per lap and then cross it with fuel consumption per lap assessment, to better anticipate next pitstop.

Once we are at modifying the fuel consumption assessment, we can force AI to have 2 pitstops with less fuel rather than one. So yes definitely possible, but needs to be sure that significant differences can be made between strategies, according to race conditions. With tyre wear multiplier at 1.0 and fuel at 1.0, if cars are very close and fuel weight makes significant differences in lap times for this type of cars, a very hard compound that would last the whole race could make fuel strategy significant for example

So, if the fuel tank capacity is high enough to finish the race, the AI won’t make pit stops based on fuel. However, if the capacity is lower than what’s required to complete the race, they will split the race into stints. Please let me know if I’ve misunderstood you.

"Yes I think, at least I'm looking at it for the mixed compound pitstop strategy. In DumbAI 1.0, with this strategy, AI only checks for tyre compounds but I will also add a change in fuel management. For example, if one pit stop is needed in the race, and the AI put harder tyre compound, we could make AI start with the maximum fuel tank capacity for its first stint with hard tyres, to ensure a better probability that the first stint will be optimal and AI has a second stint with its softer tyres with much less fuel than in the first one."
That would be awesome for races set in the 2007–2009 period, when multiple compounds had to be used during the race and refuelling was still allowed.

As for the 1994–2006 era, drivers had to choose a single compound to use for the entire race, meaning compound changes were forbidden at the time. Do you think it would be possible to simulate this as a strategic option as well?

 

[ancient_3]

So, if the fuel tank capacity is high enough to finish the race, the AI won’t make pit stops based on fuel. However, if the capacity is lower than what’s required to complete the race, they will split the race into stints. Please let me know if I’ve misunderstood you.

Yes exactly.

Some examples with Dumb AI version 1.0 , with a fuel tank max capacity of 120L :
If fuel needed to complete the race = 60 => AI starts with 60L and does not pit
if fuel needed to complete the race = 120 => AI starts with 120L and does not pit
if fuel needed = 200 => AI starts with 100L and pits at mid race to refuel up to 100L
if fuel needed = 330 => AI starts with 110 L and pits at 1/3 and 2/3 of the race to refuel 110L

Beyond the debugging of the native AC pitstop strategy, the differences of DumbAI is that where vanilla AC would compute a definite lap when AI should pit, whatever the real fuel consumption, DumbAI checks its fuel level in "real time", therefore is able to pit earlier if the bot consumed more fuel than expected and also when pitting for refuel, it recomputes how many laps are left and how many fuel is needed to complete the race and therefore is able to put less fuel if the bot consumed less fuel than expected instead of putting the pre computed amount of fuel at start of the race.

In the next version, I'll try to make this fuel adjustement using a variable that is computed by AC (fuelConsumed per lap) so that if the car has no fuel_cons.ini and the default value of 1.5 km / L is used, it can be corrected with real data during the race.

That would be awesome for races set in the 2007–2009 period, when multiple compounds had to be used during the race and refuelling was still allowed.

As for the 1994–2006 era, drivers had to choose a single compound to use for the entire race, meaning compound changes were forbidden at the time. Do you think it would be possible to simulate this as a strategic option as well?

Yes sure, I will try to add in the next version: "refuel allowed but not tyres change" and "tyre change allowed but not refuel". Were they allowed to change tyres but not change tyres compound during the race ? this would be a third option I think.

Now that there is a decent 1.0 version, I think we have a good basis to play with race strategies

 

[Philip00]

Yes sure, I will try to add in the next version: "refuel allowed but not tyres change" and "tyre change allowed but not refuel". Were they allowed to change tyres but not change tyres compound during the race ? this would be a third option I think.
Actually, this was the situation from 1994 to 2006.

Let me be more precise:

1994–2004: Refuelling was allowed, and drivers could change tyres during pit stops, but not the compound.

2005: Refuelling was allowed, but changing tyre compounds during the race was forbidden. Tyre changes were only permitted if the tyres were damaged and close to puncture (though this would have been very difficult to enforce—feel free to correct me if I’m wrong. Therefore, it should be sufficient to allow refuelling while preventing tyre changes).

2006: Refuelling was allowed, and drivers could again change tyres during pit stops, but not the compound (same rules as 1994–2004).

2007–2009: Refuelling was allowed, and drivers were required to change tyre compounds at least once during the race.

1994–2004 and 2006: Fuel load largely determined pit-stop strategy, as tyres were much more durable than they are today. At the time, only soft and hard tyres were available. Drivers had to choose between these compounds before the qualifying session and were then required to use the same compound in both qualifying and the race.

The choice of compound was highly track-dependent. Occasionally, a driver would wear the tyres excessively and be forced to pit earlier than planned, but this was relatively rare. In most cases, drivers pitted because they were running low on fuel, resulting in one-, two-, or three-stop strategies during the race.

Let me know if you needm ore information and let me know if I can help you with anything.

And again thank you for this amaizing app and cannot appriciate it enough.

Philip