January 23, 2018, 07:41:34 AM
bigger smaller reset 800px Wide width Full width Reset * *

NRTracks

 
Welcome, Guest. Please login or register.

Login with username, password and session length
« previous next »
Pages: [1] Go Down Print
Author Topic: ai...WHAT'S THE TROUBLE, WHAT'S POSSIBLE, HOW TO DO IT  (Read 19925 times)
fortine_oo
Legacy
Sr. Member
*****
Posts: 188



« on: July 29, 2011, 10:49:41 PM »

ai...
WHAT'S THE TROUBLE, WHAT'S POSSIBLE, HOW TO DO IT

Questions are continually being asked about the ai, how to get them to do the things they're supposed to do and how to get them to do things you want them to do.
The answers to these questions are then discussed and debated. Some of the answers are correct and deliver the desired results, some not. Some of the answers achieve results that are debatable, some make claims that are unsubstantiated.
I offer here a little self help. Rather than a "fix" to a particular set of circumstances at one specific track, this should provide a general course of action to address almost any problem or special request. If nothing else, it will help you to figure out what it is you want and if it's possible to achieve. It should also help you to more precisely phrase the question so the answers you receive will come quicker and bring better solutions for a positive outcome.

Mission statement:
Successful ai are made up of a gazillion properly executed little details rather than some bright idea demon tweak or radical notion that's going to turn the whole simworld upside down and set fire to it in the bargain. (Or maybe set it on fire first and then turn it upside down.)        [...with apology to BS Levy.]

***************         ***************          ***************
If you have any comments or questions, please post them in the General Discussion forum,
here Having ai trouble? - http://nrtracks.com/nrtracks_board/index.php?topic=226.0,
or start a new topic.

***************         ***************          ***************

Admonitions
or
What are the odds that the answer or solution to my request will be successful.

 First and foremost, there is NO ONE MAGIC BULLET track.ini solution to get the ai to react/race in any specific way.
   There is a baseline from which to start, but each track is specific, and each track.ini solution is specific to a specific set of race.lp and secondary lp's. (That's a lot of specificity.)
   All the forum posts claiming to have the magic track.ini values that will make the the ai perform in some astounding way at every track is bunk.
1. Interactions, or "How the Game/Sim Works" (simplified)
   a) The exe runs the show. *
   b) The papy_ai.ini defines the parameters for a host of operations. *
   c) The race.lp tells the ai the path to run. The exe, interprets the information from the recorded race.lp lap, then imparts driving instructions to the ai. **
   d) The rest of the lp's allow and/or restrict where the ai vary from the race.lp. **
   e) The track.ini defines track properties and allows fine tuning of some ai properties as they relate to the specific track conditions and race.lp. **
            [ track ] & [ ai_track ] are for "cup", [ track_(series) ] & [ ai_track_(series) ] are for the series or mod designated
            [ track ] & [ track_(series) ] are for the player & ai, [ ai_track ] & [ ai_track_(series) ] are for the ai only
   f) The ai ratings determine how well an ai can implement the properties of the track. *
      * affects all tracks
    ** affects one specific track

2. Tracks less than 1/2 mile
   This is a special category as far as ai is concerned.
   (If the question/request is for a <1/2 mile track, PLEASE state that in the post, it'll speed up the process of looking for a solution.)
   What the ai are able to do on these tracks is dependent on the construction of the track. The ai work flawlessly at some and marginally at others.
   Other factors are also dependent on the construction of the track. Pitting/pitroad errors/penalties are prevalent, some fixable, some not.

3. Before asking for help, do some searching on your own. Google (or other brand name search engine) is the best place to start. Specific sim forums searches generally yield too many results that are unrelated.
   If the search doesn't yield a specific solution, it may help to hone your question and evoke more effective answers.

4. When asking for help, include PLEASE :
   A. track name (preferably the downland name) and specific version, track type [oval, roadcourse, less than 1/2 mile], series and/or mod (if mod, what exe - cup, cts, gns, pta), track.ini (original to the track version or altered), ai ratings, ai opponent strength setting, papy_ai.ini (papy original or altered)
   B. if there's a problem, a detailed description of what happens as specific as possible__ frequency of the occurrence, where on the track does this happen, what happened right before the trouble started, when does it happen (anytime, just before pit stops, just after pit stops, first lap, etc.), usual number of ai involved, ai only or exacerbated by the player,
   C. If you've received responses, post your final results and/or findings so others may benefit from what worked or avoid what didn't

                 **********                 **********                 **********                 **********                 **********

DISCLAIMER/WARNING: Every statement regarding ai actions/reactions must be prefaced/viewed/understood with the following qualifications in mind:
   1) Any statement of ai actions/reactions is not a description (by any definition) of a human-like action/reaction, but a predisposed implementation
       of rules/directions contained in NR2003.exe.
   2) Any statement of normalcy/regularity regarding the exe's predilection to control and/or have the ai perform in any specific manner is only an educated
       prediction based on experience from past performance. There are so many variables, both adjustable (via the lp's, track.ini, fast.(series).sim, ai ratings,
       papy_ai.ini) and inherent (exe's interpretation/execution of the variables as they relate to the ai's track position and NR2003's physics engine), there is
       no absolute answer/guarantee for any modification of any variable.
   3) NR2003 was developed more as a "Nascar" simulation than a video game, and at a specific moment in time (2003), it can't be modified to be everything
       to anybody's whim in 2015.
   4) If you forget or ignore most every other warning, remember this, all variables are interactive, a modification to one variable is capable of producing an
       unforeseen/unwanted consequence elsewhere (some correctable, some not).
« Last Edit: August 25, 2015, 09:39:11 AM by fortine_oo » Logged
fortine_oo
Legacy
Sr. Member
*****
Posts: 188



« Reply #1 on: July 29, 2011, 11:05:03 PM »

LINKS to detailed information on the track.ini, lp's and reflap

ai Development Tutorial - Track.ini Adjustments

LP files - HowTo

ai Ratings Tutorial - Make a Custom Roster

Reflap (NR2003 lp Creation Tool) "How To" @NRTracks

How To Develop ai (a SHORT COURSE) @NRTracks

Pitroad, Pitstalls, and Pit lp's HOW TO @NRTracks

Grip level value for NR2003


« Last Edit: August 01, 2013, 08:18:29 PM by fortine_oo » Logged
fortine_oo
Legacy
Sr. Member
*****
Posts: 188



« Reply #2 on: July 29, 2011, 11:54:01 PM »

 Huh?
I can't make lp's... I'm not smart enough... I'm a noob... etc., etc.:
----------------
For the sake of family viewing, BALONEY.
If you're asking a question, requesting help or a solution, you must be using the sim. You've type a sentence or two. You can drive and you're familiar with a keyboard, you're able and qualified.

[To start and use reflap: Reflap (NR2003 lp Creation Tool) "How To" @NRTracks]
 
WHAT IT'S ALL ABOUT
Lp's are track specific, created on the track on which they are to be used, and they are S/F line and distance dependent.
    [If you change the S/F line, the track will still load but the race.lp follows it's original dlong/dlat path, making it unusable. If the total distance is changed, the old lp's will not allow the track to load. (You might get away with few meters difference, but I wouldn't count on it.]

For most tracks there are 10 lp's_ race, raceline, minrace, maxrace, minpanic, maxpanic, pit0, minpit0, maxpit0, and limp.
(If there are two rows of pitstalls, you also need pit1, minpit1, and maxpit1.)
Only the race.lp interprets the speed, steering input, throttle response, and braking applied that was used while recording the lap in reflap. The rest of the lp's only record the path, you can drive as fast or slow as you like, it doesn't matter.
Because the race.lp is speed (throttle) sensitive, the best strategy (to hit the save keys) is to pick a section of track that is straight and you are on full throttle. The other lp's are not speed sensitive, so you can slow or even stop to save the lap. You don't have to stop recording to save, in fact, I would recommend you don't. You don't have to save at the start/finish line, you may elect to "save it" at any location as long as you're tracking on the line you've already laid down, i.e. following the line of triangles.
Saving the newly recorded line only saves the line temporarily (for review), you must do this step, ( keys Ctrl + / ), to save the line (as reflap#.lp) to the track folder.

1. The minrace and minpanic are located to the right of the race.lp, always. The maxrace and maxpanic are located to the left of the race.lp, always. The minpit is located to the right of the pit0.lp (or pit1.lp), always. The maxpit is located to the left of the pit0.lp (or pit1.lp), always. The direction of track, CW or CCW,  has no bearing.

2. The minrace and maxrace lp's are the normal extended racing line boundries of the race.lp. The ai race best when these two lp's restrict the ai's path to bonafide alternate racing lines, where the race.lp is the preferred racing line. An actual alternate racing line may cross over the race.lp when you take a corner with a late apex path, or with an early apex path, then the corner exit would have the alternate path cross over the race.lp again; something resembling a crossover pass where one car overtakes on the inside going into the corner and exits wide while the passed car was on the outside and then cuts low to the inside and retakes the position when exiting the corner. That's not to say the minrace and maxrace lp's cross over the race.lp, they just restrict the ai's path from a maximum outside racing line to a maximum inside racing line.

3. The minpanic and maxpanic lp's afford the ai extra maneuver room when squeezed for space by the min/maxrace lp's, so one or two car widths beyond the min/maxrace lp's is all that's normally needed. The ai rarely use this space, but guard against making them too much wider than the min/maxrace as they approach a corner because they're eventually are going to rejoin the racing line and you don't want them crowding in at the corner entry. On the inside line of the corner, the panic line should be a half car width or less from the minrace or maxrace line.

4. After it's made and renamed (from reflap(#).lp), the limp.lp cannot be seen in reflap. You must temporarily rename it raceline.lp, minrace, maxrace, race.lp, or even one of the pit lp's so you can toggle it on for viewing. Just don't use minpanic or maxpanic, as both of those toggle on at the same time and it might get confusing. The ideal path is to run it on the side of the track that the pits are on. Keep it to the edge of the track, and even run it off the racing surface at the corners or other tight spots. It DOESN'T run through the pits, it stays on the track.

5. The pit lp's. At least two pit lp's are needed to have the ai as error free as possible on pitroad. They need to leave the track and run down pitroad and re-enter the track. It's easiest to lay down the pit lp that is the closest to the pitstalls first, then you can lay down the pit0.lp from that. Then, using the pit0.lp as a guide, lay down the pit lp that's closest to the racing surface, and if it's a narrow pitroad, track on the pit0.lp down pitroad and move it off the pit0.lp and toward the track as space allows. The ai on track don't "see" the cars on pitroad, so they are likely to run into cars coming off pitroad, so try to run the pit lp's off the racing line as much as possible until there's an appropiate place where the ai can rejoin the race traffic at the appropiate race speed. That's also the point/value that you'd use for <merge_from_pit_line_dlong>.
   a) pit0.lp: The pace car follows this line for the pace lap and caution laps, so when you make it, try and run the line you would when driving the pace car. This is also the pit line the ai want to be on when they are required to follow the pit lp. It works the best when the pit0.lp is tracking on the race.lp at the dlong value of <merge_to_pit_line_dlong> line. From that point have it move smoothly to the pit road entrance, remembering to leave room (if possible) for the minpit and maxpit lp's. The <merge_to_pit_line_length> is distance added to the <merge_to_pit_line_dlong> value to give the ai some discretion on when they have to commit to the pit lp and pitting. Make sure the total distance doesn't exceed past the point that will allow the ai an easy entrance onto pitroad.
   b) minpit and maxpit: For the majority of the circuit, it doesn't matter where these are. As you get close to the <merge_to_pit_line_dlong> point, make sure the outside pit lp tracks on or beyond the outside m--race lp, and the inside pit lp tracks on or beyond the inside m--race lp. The ai will then be able to capture any pit lp, no matter their current location on the track, to begin their transition to the pits.

6. The race.lp: Okay it's the tough one. Every wheel, throttle, and brake movement is recorded. The exe knows what series exe you used to make the lp, so you can't get away with using gtp at a slower speed thinking it will make the other series faster, it's all relative. It also knows the grip level, so you can't jack up the grip for more control and thinking that you've gone faster so you'll get a faster result with less grip, it's all relative.
   The best advice, no matter the series you run, no matter the grip level, no matter the speed you run the lap, be smooth on the wheel, throttle, and brake (although braking is the most forgiveable). The biggest factor in creating a good race.lp is to use a continuing, increasing throttle as you accelerate out of a corner, and avoid on-again-off-again throttle movement everywhere. If you have to lift due to pushing over oversteering, forget saving that lap, the exe will magnify that action and the ai will slow dramatically exiting that corner. Keep steering to a minimum. Use a pressure lean on the wheel (like steering a bike) when that's all that's required, and by all means, no opposite direction steering, just throw that lap away. When it's necessary to brake, do so a little earlier than you would normally hit the binders; the ai usually end up braking a little later than where you began anyway. Don't slide the car, that action gets magnified by the exe and the ai end up slowing dramatically at that spot. While driving through esses, use as little wheel input as possible.
   Which series to use to make the race.lp?
   1) use the series your most familiar with, you'll probably have a better setup and drive more confidently.
   2) Disregarding #1, drive the series that adhere's to the road better, IMO, gtp, pta, cts, gns, and finally cup. You don't want the car sliding around or breaking loose on acceleration.
   3) If the track has high speed corners, and you don't have to lift in gtp, but you do have to at least lift the throttle in cup, gns, and cts, you're going to need a separate race.lp for gtp, and another race.lp where you lifted for the high speed corner, for the rest. When you use the no lift race.lp in a series that can't take the corner flat out, the exe calculates that a reduction in speed is needed and artificially adds braking when only a throttle lift was needed, consequently the ai really bog down and the player will run into them. If you can navigate the corner with only a lift when making the race.lp, the exe won't require the ai to use the brakes, hence the reason for making a separate stockcar race.lp. I left out pta because sometimes, in this scenario, the gtp race.lp will work for pta and sometimes it won't.

6. The raceline.lp is the line that shows up on the track when you toggle the "R" key, the "ideal racing line". It is customary to use a copy of the race.lp (copy and rename to raceline.lp), but it can be any line you want or make, it's not even required that there be one. It's for the player, it is not used by the ai.


HOW TO MAKE A RACE.LP
The methods:
   a) Full Speed___the best results for racing and adjusting the track.ini, if done correctly.
      No matter the series you're going to use to make the lp, develop a good setup and get good at the track. You have enough to think about, driving smooth, you must know and be able to meticulously handle the conditions of the track and your line flawlessly.
      It's best to drive as fast as you can, so long as you follow the guidelines already described, but don't drive it as a race lap. On a race lap you use too much wheel and too much throttle variation. For corners, follow the old adage "slow in, fast out". It's better to back up the corner entry (start slowing earlier than a race lap), keep some throttle through the corner and accelerate like there's an egg between your foot and the throttle pedal. Ease on the throttle as you pass the middle of the corner and continue increasing until it's mashed to the floor or you reach the maximum speed for that section. If you have to lift the throttle in the acceleration zone, throw away that lap. Smooth throttle control is the most important aspect of getting a good race.lp. Don't slide the car into or out of the corner, use some throttle and/or trailbrake if necessary.
      Keep the car in as straight a line as you can. To transition from one part of the track to another, do it in as smooth a line (or arc) as you can. Take wide corners and esses with as little wheel input as possible.
      You're not going to do it on the first lap. Even when you finally think you've got one, the chances are good you're gonna find there's something about it that you don't like, and you're gonna do another. Save them all, you never know when a particular one that you've discarded is the best one you've done. It's an aggravating process to get one continuous, perfect (or as best-u-can) lap, but it's not impossible.

   b) Moderate Speed___better than acceptable for racing, and if done superbly, it rivals the results of the "full speed" method. However, an average made "moderate speed" lp often requires a little more tinkering with the track.ini, and often requires higher track.ini values (ai_grip_modifier), so the ai may be a little more artificial. If you absolutely can't get a good speed lap, use this method.
      Even though this is not a "fast as you can lap", you still need to develop a good setup and get good at the track. You still need to think about driving smoothly, and you must know and be able to meticulously handle the conditions of the track and your line flawlessly.
      You don't need to be all that fast, but you don't want to dawdle. Drive at a good clip, but easily in control. Good, smooth, ever increasing throttle is paramount with this method. When it's necessary to slow down, if possible, lift the throttle a little early and use little or no brake. If harder braking is required, modulate the brake pedal like you modulate the throttle, with a light touch, progressively harder until that's enough. Get off the brake before turning into the corner, roll the corner, and begin easing on the throttle as soon as you can, ever increasing until you reach the speed you want (maybe half or three quarter throttle), but hold that steady and don't lift until the next slow down area.
      When you try it out with the ai, if the ai get on the gas and brake in the same places you do, and there's no dramatic throttle lifts in the acceleration zones, you probably have a good lp, it's just track.ini tweaking from here to get the ai up to race laptimes and the other stuff.

     -----     -----     -----     -----     -----

About the "Controlled Speed" method:
I have revised my thinking, to some extent, that a very good race.lp made at speed is normally superior to a race.lp made by tooling around the track.
I say very good, because realistically that's about as good as you can get; doing it all right in a single lap at speed is nigh impossible. I believed, assuming that if it was extremely well done, the "moderate speed" race.lp could hope to be as good as a very well done "full speed", certainly not better.
I never considered creating a race.lp where the actual speed was inconsequential.

Now, having made a "Controlled speed" race.lp that out performed my pretty good "full speed" race.lp, I'm considering doing the "Controlled speed" method more often, if not exclusively.

     -----     -----     -----     -----     -----

   c) Controlled Speed___better than acceptable for racing, and if done superbly, it rivals the results of the "full speed" method.  If you absolutely can't get a good speed lap, use this method.
            If you have a track that requires you to drive a line (for a race.lp) that is not the best racing line in order to force the ai to drive the best racing line when the track construction is pulling the ai offline, the "Controlled speed" method seems to net you a better race.lp.
                
    [This method is suited for a RC, where smooth driving and car control is a premium for good race.lp creation and slowing and acceleration occur regularly. Real race speed is not required, technique is critical.]
   Technique:
            1) When acceleration is required, apply the throttle gingerly and keep applying the throttle and gaining speed until it's time to slow for a corner. It's easier to stay in control if you never reach the "actual" top speed for the straight. You may have to reduce the rate of throttle application to keep the speed down. The rate of throttle application isn't paricularly important. What's critical is to continually increase the throttle and continually increase the (car's) speed until it's time to slow down. AVOID on/off/on throttle application, this causes the ai to slow (dramatically) when it occurs in an acceleration zone.
             2) Let off the throttle to reduce to corner speed; you can lift early and coast into the turn. Only apply the brake if necessary (and apply it as gingerly as the throttle). Release the brakes soon as possible and begin to apply the throttle prior to the corner apex, again apply the throttle gingerly and keep applying the throttle until it's time to slow for the next corner. NEVER apply the throttle and then get out the throttle because you've misjudged your speed or lost control of the car, this will only cause the ai to checkup dramatically and lose momentum at race speed.


NOTE 1:
When you use a copy of the race.lp made at full speed for a raceline.lp:
     The ideal racing line will be bright green where full throttle was used and bright red where heavy braking occurred, with lighter shades at the transitions where you're beginning or ending throttle/braking.
When you use a copy of the race.lp made at moderate speed for a raceline.lp:
     The ideal racing line will be mostly a light brownish green everywhere, so it'll show the racing line but it's of little use for braking zones. You could run a race type lap in reflap and save that for the raceline.lp. It's not the race.lp so it doesn't need to be perfect and it won't affect the ai, but it will have the bright colors to help show the braking zones.

NOTE 2: It's a bit tricky to save the reflap for a race.lp, you can't slow down or wander while your saving. I save on a long straight where the throttle is mashed and I'm in a straight line. I also have the save key mapped to my wheel. If you can't map the key to your wheel, you might want to get help and have another person hit the key on your command. If you remember nothing else, when you save the lap you've just laid down, you're only saving it as a temporary file, you have to SAVE IT AGAIN for it to appear in your track folder. Ask anyone that's made any lp's how many times they've forgotten to do the second save. Oh the agony when you figure out you didn't save that precious lap.

NOTE 3: See also: "ai don't run where I want them to" for more information on how the ai "use" the lp's

« Last Edit: January 03, 2018, 05:27:32 PM by fortine_oo » Logged
fortine_oo
Legacy
Sr. Member
*****
Posts: 188



« Reply #3 on: July 30, 2011, 12:07:56 AM »

 lightbulb
Real posts to highlight the reason why explicit information is needed to elicit a qualified response. Names withheld to protect the innocent(?)

Sample question 1

The post:
... ai crash into pit wall   OK this has started to annoy me, I've now got three tracks at which the ai crash into the wall, Portland International, Texas World RC Long and Talladega RC. I'm sure it's an LP issue but I've noticed lines that could remedy this in the ini... does anyone know a fix? Portland's wall is on left, the other two on the right. I'm not so interested in the d_long at which to get the ai to merge onto the pit lp, I understand that line... more the pitting d_lat is confusing me.
-------------
What should have been addressed:

Specify the track name as it can be found for downloading. Be sure to include a version # if there is one.
Include a link for where the track can be downloaded so that anyone willing to help can easily download the track.

Portland International:
No track is listed with that name. The fact that Portland International may be the actual track name doesn't help figure out which track is being referred to. There are two roadcourses, portland_pwf_beta and a Portland_No_Chicane, and an oval, Portland Oval. While the differences (of the two RC's) may only be 3do's/mips and use identical layouts and track.ini and lp's, there's no way to tell without a lot of investigation.

Specify what series (exe).
If a series does not have it's own sections it will use the cup section. If there is no fast setup for a particular series, it will use the fast.cup.sim setup. Pta especially does not execute well using cup values or a cup setup.

Where's does the problem occur?
In this example it doesn't specify whether it's entering or leaving the pitbox, entering onto or exiting from pitroad, or while driving on pitroad while entering or leaving the pits. 

"I'm sure it's an LP issue..."
Did they bother to try different lp's? Why not? This should have been the first step. If that corrected the problem, they could have offered that fix to the rest of the community instead of asking the question.

"... I've noticed lines that could remedy this in the ini..."
What lines? No information can transpire if no information is given.
Did they bother to try different values for these lines?  Why not? This should have been the first step. If that corrected the problem, they could have offered that fix to the rest of the community instead of asking the question.

"I'm not so interested in the d_long at which to get the ai to merge onto the pit lp, I understand that line... more the pitting d_lat is confusing me."
The d_long? Which one? pace_merge_from_pit_line_dlong, pace_merge_to_pit_line_dlong, merge_from_pit_line_dlong, merge_to_pit_line_dlong, pit_lane_end_dlong, pit_lane_start_dlong, stall_exit_goal_dlong_offset, lane_merge_dlong ? I'm not trying to be cute, this just exemplifies how hard, nay impossible, it is to discern what someone is referring to.
The pitting d_lat? Well, at least there are only two of those, slow_pit_line_dlat_offset and stall_exit_goal_dlat_offset for the ai, although there's pacestall_exit_goal_dlong_offset and pacestall_exit_goal_dlat_offset (for the pace car), and pit0_entrance_point0_dlat and pit0_entrance_point1_dlat in the [ AppRuleEnterPits ], but those are for penalties only and don't physically alter the ai behavior.

This poster is intimating he(she) has some knowledge of "the process", did they research for possible fixes? Do a Google search? Search the forums? Search the various (though few) ai/track.ini information databases for possible avenues to a remedy? Why not, or why didn't they attempt to apply what they found out?
These should have been the first steps. If that corrected the problem, they could have offered that fix to the rest of the community instead of asking the question.

Eventually, the offending Portland track was sussed out, the problem identified, and a specific remedy successfully determined, as well as some possible improvements that could also be applied. The Texas and Talladega tracks didn't exhibit any ai wall collisions, and Talladega doesn't have an outside pit wall (Huh?). ...Some days later, the poster revealed he(she) had made changes to some of the values in the track.ini and changed some lp's, so the problem that was fixed wasn't the solution for the trouble he(she) created.

Pretty much a waste of my time. I'll certainly think twice about offering assistance to this poster again.
______________________________________________________________

Sample question 2

Post Title: track settings
The post: 
ok, so heres what i dont like about how a track i like to race, runs. The cars do great in the corners....but when the AI come out of the corners (turn 2 and 4)....instead of washing up to the outside wall...they just ride down on the inside line all the way down the straightaways...and i hate that. Is there anything i can mess with the get them to wash up to the wall on the str8s and not kill how the AI drives in the corner?
------------
What should have been addressed:
This poster obviously is referring to a specific track, why not identify the track. Someone familiar with this track might have already addressed this issue. If a solution is reached, and the track is named in the post, there is a better chance that others with the same question will run across this post in a subsequent search.
Had the track been identified, someone could have checked the track.ini and lp's to see if they could arrive at reason for the ai action and possibly a fix. Not knowing the track, the only response your going to get is an unsubstantiated guess or a post just to ask, "What track?".
You absolutely, positively have to specifically identify the track in question if you want good answers/results to your question.
______________________________________________________________

PLEASE, when you've got a question or problem, DETAILS, DETAILS, DETAILS.

 thumbsup

Logged
fortine_oo
Legacy
Sr. Member
*****
Posts: 188



« Reply #4 on: July 30, 2011, 12:12:54 AM »

Anyone know any good papy_ai.ini? :

[My opinion Tongue, ascertained from my experience developing ai that race as close to real players as the exe will allow.]

For all practical purpose, the original is just fine. thumbsup
Using the papy_ai.ini as a means to get the ai to race a specific way is overkill. Most, if not all, of the perceived benefits could have been realized using the track.ini and lp's, and there wouldn't be so many requests to fix other tracks because of an altered papy_ai.ini.
A long time ago, I investigated and tried a wide range of values for the lines in the [ driver ] and [ physics ] sections. The results didn't yield much (if any) of a different behavior that was noticeable. Because of the less than spectacular results, and because it may have negative effects on the the ai behavior at some tracks, I chose to not look for fixes there.

 checkeredflag
I don't have any recommendations on which values to look at, it's a long trial and error process. For all the claims of enhanced ai performance with altered papy_ai.ini's, I'd say try it for yourself and decide if it works for you. (If you go with an altered papy_ai.ini, just remember to mention that in future requests for help.)
Logged
fortine_oo
Legacy
Sr. Member
*****
Posts: 188



« Reply #5 on: July 30, 2011, 12:52:37 AM »

HOW TO COAX ai

Questions from forum posts with avenues for possible solutions:
[ Numbered for reference, not for importance. ]


WARNING
"They say...", "I read...":
You shouldn't take "They say..." as gospel. You'll reap the most benefit from supplied information when you discount the claim(s) and test the hypothesis
   yourself, observe the results, then reach your own conclusions.


Part 1:


#1
it didn't do that before:
If the ai trouble started recently, i.e. you can't recall the trouble occurring at said tracks before, but now it does, you've more than likely:
1. installed an altered papy_ai.ini (from Revamped Reloaded perhaps), or made individual changes yourself. (Revert to an original papy_ai.ini, still trouble?)
2. changed to a different track.ini or altered some value(s)
3. switched to a different version of the track
4. changed the ai roster or ai ratings

#2
what happens if I use this value:
Use a little effort. Try it and see what happens. If you're not willing to do that, why expect someone to expend the effort to respond to your question? C'mon.
If it achieves results that you find useful or interesting, then post your findings. That'll make you a contributor. Congratulations.

#3
ai are inherently bad/out of control:
1. The ai weren't developed for this track specifically
   a) the race.lp doesn't reflect a real racing line
   b) the race.lp wasn't driven in a manner that allows the exe to translate it properly to the ai, i.e.  uneven/erratic throttle, oversteering and sliding, funky braking
   c) there are no secondary lp's (min/maxrace, min/maxpanic) or they are copies of, minrace=minpanic and maxrace=maxpanic
   d) one or more of the secondary lp's are on the wrong side of the race.lp (misnamed)
   e) there is only a pit0.lp, and minpit0 and maxpit0 are copies of pit0 (note: pit lp's must run through the pits)
   f) the track.ini was copied from another track and no adjustments were made to accommodate the properties of this track or lp's
   g) In the track.ini, any line and value that is in <[ track ]> and <[ ai_track ]>, the "cup" sections, will automatically be applied to every series in the track.ini, unless that other series section has the same line and it's own value. If you want different attributes for each series, add each "cup" track.ini line to each series and apply the appropriate value.
   h) the track.ini doesn't contain sections developed for the series (exe) you're running, (The ai will use the cup sections of the track.ini if the specific series sections are not in the track.ini, and the ai will use the fast.cup.sim setup if there is no fast.(series exe).sim setup available.)
   i) using a modified papy_ai.ini

#4
Ai wreck a lot:
1. ai_wall_offset = 20; at 100 there's full, instantaneous ai to ai contact; at anything less than 100 there is some morphing (increasing as you get to zero where the ai can drive through each other with no contact) so it gets progressively harder to make serious contact. I find 20 looks like normal contact when it occurs, but reduces (not eliminates) incidents.
2. ai_drafting_distance = 1.07 and/or ai_dlat_pad = 0.7; average cup values; pta and gtp can use slightly lower values; increase these values in 0.05 increments, but if you get to 1.85 and 0.85 and the trouble continues, the problem lies elsewhere.
3. ai ratings; higher maximum ratings in the "drivers" section, especially "track type" ability. On tracks that exhibit a lot of close racing (short tracks, plate tracks), if an ai has a minimum rating of 50 or less for Vehicle/Chassis, Driver/Track-type, Driver/Consistency, an ai will have a good chance of initiating a collision.
4. minrace/maxrace lp's; needs wider spacing from the race.lp and/or wider spacing between the two min/max lp's
5. minpanic/maxpanic lp's; needs wider spacing from the min/maxrace.lp's
6. using a modified papy_ai.ini

Special consideration for "Plate" tracks (or a track where you (and the ai) drive flat out, i.e. you never lift the throttle for a corner):
1. ai_wall_offset = 8 - 20; at 8 there is some visible morphing, maybe a fender width or a little more. I didn't find less than 8 to significantly yield any less accidents to justify the visual morphing.
2. ai_drafting_distance = 1.10 - 1.5 and/or ai_dlat_pad = 0.85 - 1.5
   Be aware, the higher the value for either line will reduce the ai's ability to pass. You can never completely eliminate accidents unless you want to have a "follow the leader" scenario.
   a) Start with the lower values for each line. Run a race. If the accidents have subsided, you can stop there or you can try and lower the values just a bit to encourage better passing. Run a race, etc.  
   b) If more adjustments are needed, work with the ai_dlat_pad value first. Increase the value in 0.10 increments. If you can achieve the results you're seeking with a value 1.5 or less, stop here.
   c) If more adjustments are needed, work with the ai_drafting_distance value.  Increase the value in 0.10 increments. If you can achieve the results you're seeking with a value 1.5 or less, stop here.
   d) If more adjustments are needed, you might want reconsider how few accidents you're willing to accept. Further increases will adversely affect the ai's ability to achieve any passing. If you continue, try to confine any further increases to the ai_dlat_pad. Combine the higher ai_dlat_pad values with wider minrace and maxrace lp's spacing (and min/max panic lp's, to stay beyond the min/maxrace lp's, if necessary). [I would not normally suggest that the minrace and maxrace lp's be spaced more than 2 or 3 car widths either side of the race.lp, but if a relatively high ai_dlat_pad value is used, wider spacing is the only way to allow for some "wiggle room" to encourage/allow ai passing.]
   e) The ai ratings determine how well an ai can implement the properties of the track. If an ai has a minimum Vehicle/Chassis rating less than 60 and/or a Driver/Track-type rating less than 60, this ai will have a good chance of initiating a collision at least once during every race when the exe has randomly selected a ratings value below 60. This is (next to) an absolute certainty for tracks that exhibit "pack-racing", such as plate tracks.

#5
ai don't wreck enough:
The occurrence of collisions is somewhat dependent on the track itself. A track with well done lp's and track.ini will normally have less incidents. Plate tracks, or similar "flat out" tracks, will have more accidents due the close proximity, nose to tail and side by side.
1. Reduce the ai ratings. If only the minimum value is reduced, the ai will be more prone to lesser ability ( or bad driving, if you will) when the random selection favors the low end of the ratings. If the random selection favors the high end, the ai will wreck less (or not at all). Lowering the minimum and maximum values should increase the chance of collisions at any race. Use the lower ratings in these categories: 1) Vehicle/ Chassis, 2) Driver/ Track type (ability), 3) Driver/ Consistency. Try a value of 45 or less as a minimum value.
2. [ ai_track ] (or [ ai_track_(series) ] ai_wall_offset = 100, 100 = full-contact AI collision detection
3. Decrease [ ai_track ] (or [ ai_track_(series) ] ai_drafting_distance
4. Decrease [ ai_track ] (or [ ai_track_(series) ] ai_dlat_pad
5. Increase [ ai_track ] (or [ ai_track_(series) ] ai_squeeze_pcnt. Increase judiciously, 0.05 increments (or less).

#6
ai never wreck when hit:
1. ai_inverse_slipcurve_k ; reduce the value until the ai break loose as easily when you bump them as you get loose when the ai bump you; it has the added benefit that the ai won't have a superior cornering ability over the player (assuming the player has some cornering skill)

#7
ai spin out for no reason:
1. ai_inverse_slipcurve_k = has too low a value
2. less than optimal fast.(series).sim setup
3. Mismatched race.lp line (incorrectly driven/saved)
4. When it occurs just before or along the pits, bad track.ini value(s) as it relates to pitting. Also may be related to bad pit lp's, alone or in conjunction with the track.ini.
5. Seldom the problem, but_ bad track segment, track section, x section

#8
ai rollover:
1. Track grip level too high (track_asphalt_grip, track_concrete_grip, track_paint_grip, etc.)
2. Curb too high or too steep of an angle
3. Combination of #1 & #2

#9
ai jumping cars:
1. When the ai are placed on a track by the system, they are "dropped" onto a designated location, either the pitstall or starting grid. When more than one car (including the player) is designated to occupy the same location, those car(s) will pop, explode, fly off (or whatever term you like) when the second car is "dropped" onto the occupied space. Check the track.ini for like or similar (within 3m) pitstall or starting grid locations and rectify with new values.
2. Track grip level too high (track_asphalt_grip, track_concrete_grip, track_paint_grip)
3. Combination of high grip level and an anomaly of the track. I have only once seen someone identify the reason for the anomaly at one track (a particular 3do I think, I don't recall the specific track), all the other's retain their mystery. Their is a work-a-round, but it's time consuming to achieve and the raceability is marginal.

#10
ai don't pass enough:
Passing (on any track) is hard to do if cars have equal ability, even top rated cars may take several laps to get by a second tier car. If a top rated car can't get past a backmarker in less than two laps, you've definitely got issues.
1. ai ratings; be sure to verify that the ai have decent ratings for all of the track types
2. ai_drafting_distance = 1.07 and/or ai_dlat_pad = 0.7  (average starting points), decreasing will help passing (possibly at the recurrence of more collisions, use <ai_wall_offset = 20-30> for less incidents)
3. ai_squeeze_pcnt = 0.05 - 0.30 (the trouble could be poor lp's, but this is easier to try first); Starting range, too high (above 1.5- 2.0) causes the ai to wander aimlessly, especially off the track. If raising to 0.30 doesn't show significant results, go for new lp's.
4. minrace/maxrace lp's; min/maxrace lp's that encompass legitimate secondary racing lines; to help avoid incidents, min/maxpanic lp's that allow escape lanes, especially where the preferred racing lines are narrow or converge to a preferred narrower racing line (e.g. the transition from a wide straight to a corner or esses)
5. ai_panic_decel = 7.5; too high a value could cause early checkup by the car behind, even when there's no problem ahead)
More extreme:
6. If #2 & #4 have been implemented with less than desired results, try ai_squeeze_pcnt = > 0.30
7. ai_line_modifier = 1.01-1.05; increasing this line communicates to the ai that they have more grip than they actually do, which allows them to go faster than what the exe says is the ideal speed for the actual grip available. Increasing this value not only makes the ai racier, it will make them quicker through the corners and that will lower their laptimes, so to maintain the same laptimes the <ai_grip_modifier> or opponent strength will have to be lowered as well.

#11
ai don't pass where I want them to:
1. new minrace and maxrace lp's
2. all the solutions for "ai don't pass enough"
 
#12
ai pass too much:
Passing is competition, and I tend to believe that's the reason for racing. However, I've seen this asked for numerous times. One could try doing the opposite of "ai don't pass enough", and narrow the distance between the race.lp and the minrace and maxrace lp's.

#13
ai don't run where I want them to:
1. make new lp's [the min lp is always on the right (relative to the race.lp or pit0.lp), the max lp is always on the left; the direction of track, CW or CCW, has no bearing]
        Place the location of the lp's to allow the ai   to run where you want, and to restrict the ai from running where you don't.
   a) ai run on the race.lp 99% of the time *; you need, at least, a different race.lp.
   b) to pass, the ai run up to, and as far out as the wheels will remain in contact with the minrace and maxrace lp's **
   c) under duress or crowding, the ai will run out to the minpanic and maxpanic lp's ***
   d) at least two pit lp's are needed to have the ai as error free as possible on pitroad; the minpit0.lp or maxpit0.lp (whichever is closer to the pitstalls) should be a lane close to the pitstalls (i.e. within one car width), the pit0.lp should be 1 to 1 1/2 car widths from that; while on the pitroad where the pitstalls are, the ai rarely (if ever) use the pit lp closest to the track, however, they may use that pit lp when leaving the racing surface for the pits or re-entering the track from the pits.
   e) Use the track.ini to control when the ai must follow the pit lp's; [ pit_lane_0 ]merge_from_pit_line_dlong, merge_to_pit_line_dlong, merge_to_pit_line_length, lane_merge_dlong
   f) during the pace lap, the two lines of ai follow the minrace.lp and the maxrace.lp, most of the time. However, when the maxrace.lp (for example) is close to the race.lp and the minrace.lp is not, the pacing line will follow the maxrace.lp and the minrace.lp pacing line will move toward the race.lp.

* There's always a preferred racing line on a track. Since NR2003 doesn't allow for changing track conditions, that line will always be the same. As far as the ai are concerned, the preferred/optimal racing line is the race.lp. The ai will follow that line unless overriding instructions allow them to vary from it. The overriding instructions can be from the track.ini, lp's, or ai ratings.
         There are a couple of exceptions that I know of:
                   1) When the exe determines the speed and grip are at a tenable level, the ai will shorten the distance between point A and B even if the race.lp swings wide, and conversely, if the race.lp pinches the angle, the ai will swing a little wider to maintain speed.   +>
                       +> Exception for "Plate" tracks (or a track where you (and the ai) drive flat out, i.e. you never lift the throttle for a corner):
        What you have here is an application of exception #1. The exe determines that the speed and grip are acceptable for a more direct path than the race.lp, so the ai will tend to stay on the most direct route through the corner(s), which is the maxrace.lp (on CCW oval), especially if there are other ai around and on the race.lp. However, there's always that overriding rule to follow the race.lp, so as soon as there's enough clearance, the ai will tend to go back to the race.lp as the track straightens.
                   2) When the track centerline (used to construct the track) is not actually in contact with the racing surface, the ai can be pulled toward  (or repelled from) the track centerline as far as the minrace.lp or maxrace.lp (depending on the location of track centerline and the direction of travel, CW or CCW) will allow.
** Excluding "rim-riding" (not particularly easy, nigh impossible, to accomplish for the ai in NR2003), there are really only two bonafide "secondary" racing lines. One would be on or outside of the preferred line and drive a little deeper into the corner and use a late apex and a corner exit below or up to the preferred line. The other would be on or inside of the preferred line and take the corner with an early apex and a corner exit back out to or beyond the preferred line. Having minrace and maxrace lp's wider than one lane beyond these alternate racing lines is unnecessary, and decrease the distance of the inside mxxrace.lp (maxrace on CCW oval) from the race.lp as they approach a corner to lessen the two cars into one space syndrome.
*** Wider minpanic and maxpanic lp's will handle the "running out of room" problem, until you get to a corner. The ai rarely use this space, only for "panic" situations when braking space is insufficient and for accident avoidance. However, guard against making them too much wider than the min/maxrace as they approach a corner because they eventually are going to rejoin the racing line and you don't want them crowding in at the corner entry. On the inside line of the corner, the panic line should be a half car width or less from the mxxrace.lp (maxrace on CCW oval) line.

#14
I want ai ... passing on the inside... passing on the outside... single file:
The action you want is evidently not the action the track creator was looking for.
The ai will (more or less) always follow the race.lp unless they are looking to pass.
Passing on the outside, i.e. the outside line is the dominate line, is nigh impossible. For the ai in NR2003, the fastest way around an oval is on a racing line
   as close as possible to the inside of the track. The ai will try and run this line anytime the location of the lp's will allow it, regardless of the grip level. It
   doesn't matter how much greater the grip level of the outside line is, the ai will still use the inside line if the lp's will allow it. On a track with an inside line
   grip level of 0.80 (a grip level the Player will perceive as ice) and an outsine line grip level of 3.50 (a grip level the Player will perceive as being on a rail),
   the ai will "choose" the inside line if the lp's will allow it. The reason the ai will "choose" an 0.80 grip level over a 3.5 grip level is because the ai and the
   Player operate with a different physic's model.
In simulation mode (without Driver's Aids), the Player is constrained to real world physics (more or less).
The ai are held in check by the exe. The ai are designed to stay on the track and go forward. They don't drift, at maximum lateral G's they simply become
   unglued and usually slide off the track surface. They sometimes re-acquire grip, but at a big loss to momentum before regaining speed.

 
end part 1
« Last Edit: January 02, 2018, 04:45:49 PM by fortine_oo » Logged
fortine_oo
Legacy
Sr. Member
*****
Posts: 188



« Reply #6 on: July 30, 2011, 12:56:50 AM »

HOW TO COAX ai

Questions from forum posts and avenues for possible solutions:
[ Numbered for reference, not for importance. ]


WARNING
"They say...", "I read...":
You shouldn't take "They say..." as gospel. You'll reap the most benefit from supplied information when you discount the claim(s) and test the hypothesis
   yourself, observe the results, then reach your own conclusions.


Part 2:



#15
ai speed... too fast, too slow:
The ai's speed is determined by the race.lp, track.ini, and ai ratings.
The ai's speed does not vary from a particular mod or carset model when the exe is cup, gns, cts, or pta.
    Modified exe's (aka illegal exe's) will yield different results. As an example, the Gen6 model will perform the same as the original cup model, but the cars
    using owr05 (modified exe) will perform differently than the cars using owr07 (pta exe) while using the same race.lp, track.ini, and ai ratings.

Regardless of the reason for the need to slow or speed up the ai, you can dial in the ai laptimes via the track.ini line:
[ ai_track ] or [ ai_track_(series) ]
ai_grip_modifier ; Adjust this value to control the ai's laptimes.
    Decrease the value to increase the ai's laptime, adjust to four decimal places if necessary.
    You'll want to verify/adjust the ai_accel_modifier and the ai_drag_modifier before the final
       ai_grip_modifier value.
ai_drag_modifier ; Only adjust this value when the ai have a different top speed (in non-drafting situation) than the player
    on the longest straight, it is not the parameter used to slow or speed up the ai's laptime.
    Increase the value to reduce the ai's top speed.
    While you're checking the ai's top speed, also check their acceleration. You'll want to verify/adjust this value before modifying the ai_drag_modifier.
    Take a mph reading at a particular spot a fair distance from a corner but well before they reach top speed and compare that to your speed at that point.
       The ai's speed may be 1-2 mph faster than yours and still be okay.
ai_accel_modifier ; Only adjust this value when the ai accelerate faster or slower than the Player, it is not the parameter used
    to slow or speed up the ai's laptime.
    Increase the value to have the ai accelerate faster. This line is for acceleration from corners and does not have a significant effect on starts/restarts.
    You'll want to verify/adjust this value before modifying the ai_drag_modifier.
    Take a mph reading at a particular spot a fair distance from a corner but well before they reach top speed and compare that to your speed at that point.
       The ai's speed may be 1-2 mph faster than yours and still be okay.
ai_decel_modifier ; Only adjust this value when the ai brake sooner or later than the Player.
    Decrease the value to have the ai brake sooner. This line does not have a big effect on laptimes.

#16
ai qualifying:
An assumption to the fact an adjustment is needed... the ai are running laptimes within the range of the Player. The Player needs to adjust the "Computer Opponents / Strength %" before determining that the ai are too fast or too slow.
[ ai_track ] or [ ai_track_(series) ] ai_qual_modifier = 1.00   1.00 should yield a qualifying result that is +/- the best laptime an ai is capable of running with no draft assistance. A value greater than 1.00 will lower the laptime, a value less than 1.00 will increase the laptime. "ai_qual_modifier" is fairly sensitive to change, try modifying in 0.01-0.05 increments.

On ovals a special qualifying setup may be employed by the Player that actually produces a faster laptime than is readily attained with a race setup. A value greater than 1.00 is usually called for.
On RC's the setup is compromised for many track variables and a qualifying setup is usually nothing more than slightly increased tire pressures and a tick less wing. A qualifying laptime is quite often higher than a racing lap, so a value less than 1.00 is more likely needed.  

#17
ai run into the back of me:
1. First, you have to exhibit some driving/braking ability. If the ai are "rear ending" when you're closer to the middle of the corner (rather than as you approach the corner), you need to release the brake sooner, roll through the corner and accelerate sooner than you were. (As a bonus, this will also reduce your laptimes.)
2. You say the ai "rear end" you in the braking zone. Do you "rear end" the ai in the braking zone? Begin the adjustment process by getting the ai to slow at close to the same rate as you. They should start braking at about the same time, but usually they'll start a tick or two later (remember, they're robots and very consistent). With the same priority as hitting the brakes, you want them to get off the brakes and roll the corner at roughly the same place. Adjust this scenario by adjusting the ai_decel_modifier value (raising the value reduces the time the ai are braking) and get it to where you're not having to brake before you want to (not including the stack ups on the first couple of laps). That's as good as it gets by only adjusting with the track.ini.
3. At some tracks with a long fast straight leading to a relatively slow corner, the ai seem to be able to brake in a shorter distance than the player. If you adjust the ai_decel_modifier for that long straight-corner, you'll be running into the back of the ai at every other corner. So, adjust the ai_decel_modifier for the rest of the track, then you'll have to modify the ptf to help on the long straight-corner. Create a track section(s) that about covers the braking zone, but end just short of the turn in point. Assign a track surface different than the normal racing surface. If the racing surface is "asphalt" (the ptf designation, not the mip visual), make the braking zone "concrete", or vice versa. Whatever the racing surface grip value is, add 0.05 to that for the braking surface value. You can also use paint for the braking surface, but a slightly higher value will be needed, probably 0.10 higher than the racing surface. The player will be able to begin braking a little later and slow at a faster rate than before, but the ai will show negligible (if any) improvement.
4. NOT A SOLUTION: ai_dlongpad_scale.
   The given definition: This pads the braking of the AI so that they don't suddenly stop when going into a turn or trying to pit. The smaller the number, the more scaling that takes place.
         With a value above 0.30, the ai will brake more and/or sooner than the race.lp would indicate as appropiate. With a value less than 0.30, there seems to be no effect. Hence, I use 0.30.
   If you try and use this line to control the long fast straight leading to a relatively slow corner problem, you'll be running into the back of the ai at every (other) corner.

NOTE: At some tracks with a very long fast straight leading to a relatively slow corner (Lemans Sarthe, for instance, at the end of Mulsanne straight). If there is enough of a gap between the ai at the corner and the ai approaching the corner, the approaching ai will not see the car(s ahead and will begin braking at the normal, clear track distance, and run into you and/or other ai as if you weren't there. I have yet to find a fix for this. The best you can do is use a higher ai_panic_decel value, a higher ai_squeeze_pcnt, and generously wide minpanic and maxpanic lp's and hope the ai see the traffic soon enough and take avoidance action. You can also use ai_wall_offset = 0.00, but I find total morphing objectionable.
Aug 2012 UPDATE: "wiggling" the race.lp on the approach to the corner reduces/eliminates the consequences of this "blindness".

#18
ai cars just blindly pile into a wreck:
There are two different scenarios to consider, (re)actions that can be helped and (re)actions that can't be overcome (or not completely).
1. Things that can be done:
        a) ai_panic_decel = 5 - 20 ; This will cause the ai to react sooner and with more intensity to the cars ahead. The ai will slow and/or
               change lanes. Too high a value can cause early checkup by the car behind, even when there's no problem ahead.
        b) ai_squeeze_pcnt = 0.05 - 0.50 ; ai_squeeze_pcnt allows the ai to deviate from the ususal constraints of the Race.lp (they'll change
               racing lines easier).
            Too high a value (or any value > 0.00) can be detrimental to the racing because it can cause the ai to take an alternate racing even
               when there is no viable passing opportunity available.
            Too high a value causes the ai to wander aimlessly, even off the track.
2. When the "pile up" essentially blocks the racing surface, there's not much of a chance of avoiding the "piling on" effect, especially when the
       ai are in a pack.
    Then you have the situation where the ai blindly pile into a wreck that has occurred "well in front" of them. This has more to do with the exe
       than anything else, IMO. This seemingly "blind to the cars ahead" scenario is a re-occurring problem on tracks where there is a long top speed
       straight leading into a very slow corner. The ai have no trouble slowing properly for the corner by themselves or in a pack, i.e. the ai begin
       braking soon enough and reduce speed effectively to navigate the turn. The trouble lies in the cars some seconds behind. Those ai approach
       the corner as if there are no cars in front of them and brake for the corner using "normal", un-obstructed track braking procedure. It's as if
       the ai ahead are not recognized as being there, consequently, the ai ram right into the traffic ahead because they did not start slowing soon
       enough. There is currently no known fix for this problem.
       (Aug 2012 UPDATE: "wiggling" the race.lp on the approach to the corner reduces/eliminates the consequences of this "blindness".)
    Things you can try:
        a) By the placement the minpanic.lp and maxpanic.lp, provide enough extra panic space for the ai to use for avoidance.
        b) ai_squeeze_pcnt = 0.05 - 0.50 ; ai_squeeze_pcnt allows the ai to deviate from the ususal constraints of the Race.lp (they'll change racing
               lines easier).
            Too high a value (or any value > 0.00) can be detrimental to the racing because it can cause the ai to take an alternate racing even when
               there is no viable passing opportunity available.
            Too high a value causes the ai to wander aimlessly, even off the track.
        c) ai_panic_decel = 5 - 20 ; This will cause the ai to react sooner and with more intensity to the cars ahead. The ai will slow and/or change
               lanes. Too high a value can cause early checkup by the car behind, even when there's no problem ahead.

#19
ai slow/checkup entering the corner:
The reason:
   1) A poorly made race.lp is the usual cause.
       There was an unnecessary throttle lift during the lp creation.
       There is a wiggle or misalignment in the race.lp.
       The lp location is less than optimal for negotiating the corner.
       The lp location tracks on a surface designation that has a reduced grip value or the ai_inverse_slipcurve_k value is too low.
   2) Too high an ai_dlongpad_scale value is the other cause.  ai_dlongpad_scale = 0.3 is the only value I use.
       While the definition of the properties of this parameter, "This pads the braking of the AI so that they don't suddenly stop when going into a
          turn or trying to pit. The smaller the number, the more scaling that takes place
", "pad" and "scaling" is not defined. The common belief seems to
          be that a high value is beneficial, but the greater the value the more the ai is likely to checkup. I have not found any practical use for a high value (there
          are other ways to get the ai to slow up if necessary).
          ai_dlongpad_scale = 0.03 keeps the ai from checking up unnecessarily, and a lower value doesn't appear to have an additional effect.
   3) Too low a value for ai_decel_modifier, especially if combined with a ai_dlongpad_scale value greater than 0.30.

#20
"I make LP's to make the AI run my style...", "Now I... want... to make the AI run more realistic":
You may have competing wishes, your style vs. realistic ai.
Realistic ai would mirror real racing, and the object of racing is to get around the track as quickly as possible. Your racing line or style may not be the quickest
   way around. Only when you're knowledgeable about racing lines, braking, throttle control, and optimal setups, can you begin to run the quickest laps. Once
   the "best" racing line is established, the race.lp, you then determine the secondary racing lines, the line inside and/or outside of the preferred racing line.
   Once you have determined these secondary racing lines you create the minrace and maxrace lp's which will restrain the ai to these extreme inside or outside
   boundaries.
Your style may vary. You can either continue running "your style" or adapt to a possibly faster line and/or driving style.

The shortest way around any oval, the inside line, is the fastest way. This is a fact in the real world and in NR2003. However, there is a problem inherent in the
   properties of NR2003. In the real world, certain track/car conditions may yield a faster lap when running a higher racing line. In NR2003, with a track configured
   to have better grip in a higher line, the Player may run faster on that higher line than they can on a lower line. Rather than get into a long explanation, suffice it
   to say the ai don't run with the same properties as the Player. The ai are enhanced to stay in control, so they can maintain car control with less grip than the
   Player. If they are allowed (by the lp placement) to hug the inside line, they will, and therefore be faster than a higher line with superior grip.
On a superspeedway (or any track where there is no throttle lift) the outside line will never dominate. On non-SS tracks this is still mostly the case, but with
   extremely low grip values (unrealistic for the Player's use) on the inside line, the higher line may be faster. However, the ai will still try to run the inside line when
   it's deemed okay by the exe, they will become loose, lose momentum, and eventually return to the higher line, not very realistic.

#21
ai crash entering the pits:
1. make new pit lp's
2. adjust the track.ini values to control when the ai must follow the pit lp's; [ pit_lane_0 ]merge_from_pit_line_dlong, merge_to_pit_line_dlong, merge_to_pit_line_length, lane_merge_dlong
3. In the track.ini, use slower pit speed limit, [ pit_lane_0 ] speed_limit_MPH = xx

#22
ai crash exiting the pits:
1. make new pit lp's
2. adjust the track.ini values to control when the ai must follow the pit lp's; [ pit_lane_0 ]merge_from_pit_line_dlong, merge_to_pit_line_dlong, merge_to_pit_line_length, lane_merge_dlong
3. In the track.ini, use slower pit speed limit, [ pit_lane_0 ] speed_limit_MPH = xx

#23
pit penalties enter:
1. Incorrect [ AppRuleEnterPits ] values in the track.ini
   a) apply correct values
   b) deleting this section of the track.ini should remove any pit entry penalties
2. adjust the track.ini values to control when the ai must follow the pit lp's; [ pit_lane_0 ] merge_to_pit_line_dlong, merge_to_pit_line_length

#24
pit penalties exit:
1. adjust the track.ini values to control when the ai must follow the pit lp's; [ pit_lane_0 ] merge_from_pit_line_dlong (must be at least as far down the track as lane_merge_dlong), lane_merge_dlong (ai must stay on "apron" subsurface until this distance is reached), deleting this line will remove the pit exit penalty

#25
pit penalties speeding:
1. pit speed must be maintained from just before the first pitstall on pitroad to just after the last pitstall on pitroad. (deleting [ pit_lane_0 ] speed_limit_MPH in the track.ini will remove pit speeding penalties)
2. Sometimes the construction of the track skews the dlong values. By noting where the ai slow to pit speed, and then viewing the dlong values in the ptf (opened in sandbox), by trial and error adjust the location of the start of pitroad by placing a line, cone, etc., to mark the correct location for the player.
3. Due to the construction method, tracks shorter than 1/2 mile may exhibit pit speed application and verification anomalies which cannot be corrected.

#26
ai pit under caution on 1st lap:
Ai pitting under caution after only one lap is a NR2003 shortcoming. There is really nothing that can be done to overcome it.
The ai pitting strategy takes a lot of trial and error just to get the ai to pit in a window commensurate with the Player.
Trying to get the ai to pit differently for cautions is even more difficult and not all cars will conform even then. Plus, it tends to screw up regular pitting strategies.
Trying to get the ai to buck the game's tendencies when it comes to pitting under caution is an exercise in futility.

  
end Part 2
« Last Edit: January 02, 2018, 04:44:49 PM by fortine_oo » Logged
fortine_oo
Legacy
Sr. Member
*****
Posts: 188



« Reply #7 on: July 28, 2013, 11:17:53 AM »

Questions from forum posts and avenues for possible solutions:
[ Numbered for reference, not for importance. ]


WARNING
"They say...", "I read...":
You shouldn't take "They say..." as gospel. You'll reap the most benefit from supplied information when you discount the claim(s) and test the hypothesis
   yourself, observe the results, then reach your own conclusions.


Part 3:



#27
ai cars_game won't load the full roster:
1) On the "Single Race" page, be sure you have selected a roster with enough cars, "Computer Opponents/Roster:" .
2) On the "Single Race" page, be sure you have selected the quantity of cars desired, "Computer Opponents/Number:" .
    NR2003 will only allow the quantity of ai cars per the track.ini, [ track ] max_starters = XX (minus one for the Player).
3) On the initial "Nascar Racing Page", select "Opponent Manager". Select a Roster. Be sure "Total Drivers" and "Active" (drivers) contain the required number of cars.
    Note: NR2003 will only load one car per number. If there are cars with duplicate car #'s, go to the section on the right, Driver/#, change
       the car number so each car has a number not assigned to any other car. The number may be up to three digits.


#28
how do you do a standing start:
Standing start method, NORMAL:
1_
Apply track.ini changes to <[ starting_grid_0 ]> (full pace). This leaves one pace lap in a normal configuration.
The ai appear to start a normal pace lap, but as the pace car crosses half track distance, the green flag order is given. There's a very short lag (less than 1 second) before the ai take off racing, but the player can just mash it as soon as you see the ai move.
WARNING:
The NR2003.exe considers the polesitter to be on the inside of the track and does not allow passing on the inside before the S/F line. On a CW track, the inside is the right side, on a CCW track, the inside is the left side. If you are in the pole-side line, you cannot pass any car in your line on the "inside" (as described), but you can pass anyone in the other line on the "inside". If you are in the other line, you cannot pass anyone on the "inside" (as described).

2_
The pace car cannot start beyond the half way point from the S/F line. One meter less than half usually works.
<stall_pace = xxx.00(half distance - 1) x.00 x.00>
I've never had the field catch the pace car on the track using realistic (normal) pace speeds on a RC track up to 6 miles long.  
3_
[ ai_track ]
pace_merge_to_pit_line_dlong = xxx.00       Arbitrarily, 100 meters less than half.
I never had a problem with this value being farther down the track until Monaco F1. Having a value less than half track length commits the pace car to "pit in" when it starts, so it releases the field to a start condition (I guess).
4_
<[ starting_grid_0 ]> or <[ starting_grid_1 ]>
<stall_0 = xxx.00 x.00 0.00>
<stall_1 = xxx.00 x.00 0.00>
etc.
Align grid close to the S/F line. Allow a 8 - 10 meter clearance from the S/F line as a cushion so no ai cross the S/F line before the green flag flies.

Standing start method, INSTANTANEOUS:
1_
Apply track.ini changes to <[ track ]> <starter_decision = XX00 XX01>. Add an arbitrary value, say 1500, to the actual track length and use the new value as the "starter_decision".
The ai race (and spotter yells green flag) as soon as the pace car starts. The ai still do that twist turn as they start, so you only advantage to this method is the fraction of a second it takes to actually see (or hear from the spotter) a green flag.
The drawback to this method is you lose the option to have a different (full or short) pace lap.
WARNING:
The NR2003.exe considers the polesitter to be on the inside of the track and does not allow passing on the inside before the S/F line. On a CW track, the inside is the right side, on a CCW track, the inside is the left side. If you are in the pole-side line, you cannot pass any car in your line on the "inside" (as described), but you can pass anyone in the other line on the "inside". If you are in the other line, you cannot pass anyone on the "inside" (as described).

2_ same as NORMAL
3_ same as NORMAL
4_ You can have the starting grid anywhere you want (with either version), but you can't pass on the "inside" until the S/F line, and you don't want the ai to catch the pace car before it gets to pit road because they'll slow to stay behind the pace car.


#29
pace.lp:
There is no such lp recognized by the exe in NR2003. The pace car uses the pit0.lp (or pit1.lp). Furthermore, the pit0.lp is not speed (nor steering, nor throttle, nor braking) sensitive during the reflap process. In other words, it doesn't matter how its driven, 100mph or at a crawl, only that you lay down at least a lap (as for all the lp's), drive through the pits, and that the ends are pretty close in line when you save it.

#30
ai path on pace lap and yellows:
As mentioned elsewhere, during the pace lap, the two lines of ai follow the minrace.lp and the maxrace.lp, more or less. It depends on how far apart the minrace.lp and maxrace.lp are, and the location of the race.lp. The ai will usually track on the m__race.lp that's closest to the race.lp, and the other line will be 4m - 8m away. If the minrace.lp and maxrace.lp aren't there, both lines will try and occupy the race.lp. If the minrace and the maxrace lp's are named incorrectly, i.e. the minrace is on the left and the maxrace is on the right, after the pace lap begins, the ai will start swapping to the opposite sides of the track (and creating mayhem) in order to follow the correct lp (that's now on the other side of the race.lp). Also, misnamed (misplaced) min/maxrace lp's generally cause the ai to stay anchored to the race.lp.

#31
ai_pacing_distance & ai_bunching_distance:
If the ai ai_pacing_distance and ai_bunching_distance have the same value, the ai will start the race pretty even and ready to race. When the two lines use different values and a full 43 car field, and the ai_bunching_distance is a greater value than the ai_pacing_distance, the ai will still be trying to get to bunching distance when the green flag flies unless there's a pretty long straight before the S/F line.


That's all for now.
 checkeredflag
« Last Edit: January 02, 2018, 04:44:13 PM by fortine_oo » Logged
Pages: [1] Go Up Print 
« previous next »
Jump to:  

Powered by SMF 1.1.15 | SMF © 2006-2008, Simple Machines
Leviathan design by Bloc | XHTML | CSS