17-09-2008, 10:35 PM
Aqui fica mais um tidbid do "Kaemmer's corner".
http://members.iracing.com/iforum/thread.j...61&tstart=0
Julgo que o futuro blog onde os devs da iRacing escreverão será público, portanto vou fazer paste aqui para já enquanto não está pronto.
ArrayRace Control. In the years B.C. (Before Computers), it would take a large team of people to handle race control at an actual event: flaggers at each corner station, a chief steward at start/finish, pit and garage-area officials, an army of timers and scorers (sometimes two for each car on track, for redundancy), and a truck load of radios. Mistakes and controversy were commonplace. Now, we have transponders and computerized timing and scoring, which considerably simplifies life for the timers and scorers (most of whom now just get to watch), and there are many fewer mistakes and less controversy (at least as regards timing and scoring). In the simulation, not only is the timing and scoring handled by the iRacing servers, but so is the work of all the officials, flaggers and chief steward. That considerably simplifies life for everyone. Everyone except Grant Reeve. Hes the software engineer at iRacing who gets to implement most of this.
I had a brief chat with Grant today in which I picked his brain about iRacings race control system. While we are able to use some of the existing race-control code from the Nascar 2003 simulation, it turns out that much of it needs to be modified to handle our new track representation. We needed a new data representation for our tracks in order to be able to handle multiple paths around a circuit, such as when a circuit has multiple configurations (VIR), or when it has either multiple pitlanes or a pitlane that doesnt follow the track path exactly. With our old representation, a circuit could only have one closed path, and it was fairly straightforward to determine how far along that path each car had travelled. Much of race control in Nascar 2003 depended on this fact, and it was more straightforward to determine the order of cars along this single path when making decisions such as who was ahead of whom, or if a driver had completed a lap without shortcutting the course. Now, we need to keep track of several possible paths and which path each car is currently on, and we use checkpoints (a line segment which we can test for car crossings) extensively to determine when and where cars are and what they appear to be doing (entering/exiting pits, racing, blowing through chicanes all the usual race-driver habits).
Grant is currently working on the code that will handle full course cautions. Just to give you a small sense of what this entails, imagine all the possible reasons that would cause a car to be removed from the pace order, allowing all the cars behind to pass it with impunity. I can think of: entering the pits (are they entering properly?), losing control (how is that determined?), driving too slowly (what speed is too slow?depends on the track, and even where on the track). In which of those situations would a car be allowed to rejoin the pace field in his/her original spot? How should instructions from race control be communicated to the driver? These are only a few of a huge number of questions that need to be addressed in order to properly handle a field of cars pacing under yellow.
Keep in mind that the information that the iRacing server has about the location and velocity of each car comes from slightly differing times, since there is varying communications latency to each drivers computer, and in some cases the information is missing if there have been dropped communications packets, or if the driver disconnected and reconnected. All of this has to be taken into account throughout race control. Mistakes and controversy on track are inevitable in racing, but Grants working hard to keep a tight lid on that!
Dave[/quote]
http://members.iracing.com/iforum/thread.j...61&tstart=0
Julgo que o futuro blog onde os devs da iRacing escreverão será público, portanto vou fazer paste aqui para já enquanto não está pronto.
ArrayRace Control. In the years B.C. (Before Computers), it would take a large team of people to handle race control at an actual event: flaggers at each corner station, a chief steward at start/finish, pit and garage-area officials, an army of timers and scorers (sometimes two for each car on track, for redundancy), and a truck load of radios. Mistakes and controversy were commonplace. Now, we have transponders and computerized timing and scoring, which considerably simplifies life for the timers and scorers (most of whom now just get to watch), and there are many fewer mistakes and less controversy (at least as regards timing and scoring). In the simulation, not only is the timing and scoring handled by the iRacing servers, but so is the work of all the officials, flaggers and chief steward. That considerably simplifies life for everyone. Everyone except Grant Reeve. Hes the software engineer at iRacing who gets to implement most of this.
I had a brief chat with Grant today in which I picked his brain about iRacings race control system. While we are able to use some of the existing race-control code from the Nascar 2003 simulation, it turns out that much of it needs to be modified to handle our new track representation. We needed a new data representation for our tracks in order to be able to handle multiple paths around a circuit, such as when a circuit has multiple configurations (VIR), or when it has either multiple pitlanes or a pitlane that doesnt follow the track path exactly. With our old representation, a circuit could only have one closed path, and it was fairly straightforward to determine how far along that path each car had travelled. Much of race control in Nascar 2003 depended on this fact, and it was more straightforward to determine the order of cars along this single path when making decisions such as who was ahead of whom, or if a driver had completed a lap without shortcutting the course. Now, we need to keep track of several possible paths and which path each car is currently on, and we use checkpoints (a line segment which we can test for car crossings) extensively to determine when and where cars are and what they appear to be doing (entering/exiting pits, racing, blowing through chicanes all the usual race-driver habits).
Grant is currently working on the code that will handle full course cautions. Just to give you a small sense of what this entails, imagine all the possible reasons that would cause a car to be removed from the pace order, allowing all the cars behind to pass it with impunity. I can think of: entering the pits (are they entering properly?), losing control (how is that determined?), driving too slowly (what speed is too slow?depends on the track, and even where on the track). In which of those situations would a car be allowed to rejoin the pace field in his/her original spot? How should instructions from race control be communicated to the driver? These are only a few of a huge number of questions that need to be addressed in order to properly handle a field of cars pacing under yellow.
Keep in mind that the information that the iRacing server has about the location and velocity of each car comes from slightly differing times, since there is varying communications latency to each drivers computer, and in some cases the information is missing if there have been dropped communications packets, or if the driver disconnected and reconnected. All of this has to be taken into account throughout race control. Mistakes and controversy on track are inevitable in racing, but Grants working hard to keep a tight lid on that!
Dave[/quote]