The TORCS Racing Board
Username: Password: Remember Me?
Lost Password Register
Author: phi | Created: 2017-06-01 22:17:13
Subject: Penalties
Hi all

First of all I would like to thanks everyone for their work directly or indirectly related to TORCS and all the projects that surround it.

I have two questions/observations extracted from robot racings:

1) In races where there are penalties it is frequent to find situations of this type:

. rank: 10 / time: +29 laps / penaltytime: 0:21.043
. rank: 11 / time: +4 laps / penaltytime: 0:00.576
. rank: 12 / time. +7 laps / penaltytime: 0:06.315
(also, in this example driver 10 was eliminated from race)

Does this make any sense? I tried to check the code, but it seems all ok...

2) Car A makes a 'drive through penalty' at the pit exit. After unsuccessfully trying to pay the penalty for 4 or 5 laps, he gives up and goes on to make his normal laps until... indefinitely, that is, TORCS does not put him out of the race when he reaches the legal limit of laps to pay the penalty. If a car does not try to pay its penalty the TORCS will eliminate it from the race after 5 laps, but this does not happen with cars like the previous example. Is this situation expected, or is there an error?

Thanks in advance
Last Edited: 2017-06-01 22:17:13 by phi
    Author: berniw | Created: 2017-06-01 22:30:41
    Subject: Re: Penalties

    Regarding the implemented algorithm it makes sense, yes, see:
    Around line 90, ReApplyRaceTimePenalties. Basically you run a virtual race against averaged laptimes as long as you have a penalty pending. Just clear it and you are fine.

    There is an issue though if the car is taken out of the race for another reason than damage (e.g. running out of fuel). This will be improved in the next version.

    If this is the case it could be a bug actually, but I am not sure without looking into it. Could it be the case that it tries to clear it, and just gets a new penalty on exit every time? Then it would be ok, because the new penalty has another 5 laps to clear and so on.

    Kind regards

    Last Edited: 2017-06-01 23:45:11 by berniw
      Author: phi | Created: 2017-06-02 00:22:21
      Subject: Re: Penalties
      Yes, this is the code I checked and it seemed to me to be correct. However, in the final result of this example who won was who had fewer turns and got a higher penalty, not to mention that the TORCS eliminated it. In this case it compensated not to clear the penalty, all the more so that this car ended below the other two (I refer to the classification in-race), and in the final result rose in the ranking.

      PS: Sorry, in my reading I missed the second paragraph of item 1. The car in question was eliminated because it was locked into the rails.

      Yes, he tries to clear but gets a new one. When he stops trying to clear (I do not know how, but there is a moment when he stops trying, while the TORCS continues to give the message that there is a penalty), the penalty still exists and he gives more than 5 normal laps without TORCS eliminating him. I feel compelled to offer more specific data for a possible replication: Mouse (TORCS Endurance Test Races 2017) in E-Road, with car7-trb1 and standard setups.

      Last Edited: 2017-06-02 00:32:34 by phi
        Author: timfoden | Created: 2017-06-02 09:15:50
        Subject: Re: Penalties
        I'd like to make a couple of observations:

        Its not easy for a watcher of a race to determine of the car still has a pit related penalty (drive through or stop and go), as the the blue message informing the user of this stays even after the penalty has been served. It can be really easy to miss whether the car has actually earned another pit penalty or not when the penalty message and the cleared message happen very close together, as will be happening in this case with Mouse. The reason Mouse is picking up these penalties is that it is starting to accelerate too early at the end of the pit lane and goes over the pit speed limit just before exiting. Thus the penatly gained and penalty cleared messages are almost simultaneous.

        Picking up these penalties can be trivially fixed by changing the line in PitPath::MakePath() that calculates the ending segment of the pit for applying the speed limit to include an extra one.

        e.g. From this section of code:

        CalcMaxSpeeds( cm );

        idx0 = (m_pTrack->IndexFromPos(m_pitStartPos) + NSEG - 8) % NSEG;
        idx1 = (m_pTrack->IndexFromPos(m_pitEndPos) + 1) % NSEG;
        double spd = MN(m_pPath[idx0].spd, pPitInfo->speedLimit - 2);
        m_pPath[idx0].maxSpd = m_pPath[idx0].spd = spd;
        {for( int i = idx0; i != idx1; i = (i + 1) % NSEG )
        spd = MN(m_pPath[i].spd, pPitInfo->speedLimit - 0.5);
        m_pPath[i].maxSpd = m_pPath[i].spd = spd;


        idx1 = (m_pTrack->IndexFromPos(m_pitEndPos) + 1) % NSEG;


        idx1 = (m_pTrack->IndexFromPos(m_pitEndPos) + 2) % NSEG;

        It's possible for the car to pick up penalty points that don't require it to pit. These are when the car cuts the course (too far off the track on the inside of a corner), and the time for the penalty is added on at the end of the race.

        Thus I would ask: Are you sure that the car still had a pit related penalty pending at the end of the race?

        Cheers, Tim.
        Last Edited: 2017-06-02 09:15:50 by timfoden
          Author: phi | Created: 2017-06-02 17:46:28
          Subject: Re: Penalties
          I was hesitant to mention the robot from where I could observe the question precisely because it is a question of the TORCS, not a matter of some robot. Mouse is here only because it reveals a problem at the level of the simulator: it tries to pay the penalty without being able to, and this could be done with any other robot (I think). If all robots work well the consequence is to hide a problem at the level of the simulator, a problem that may well emerge at some point and affect a whole simulation. Obviously we should correct the robots, but it is also obvious that we should do about the simulator.

          I run two E-Road races (56 laps), specifically attentive to the question, and following Mouse 1:

          1) [TORCS is ok, here]
          . lap 10 - pit (Drive Through Penalty)
          . laps 11-48 - clear/get penalty
          . end of race (penalty pending)

          2) [TORCS does not eliminate the car, here]
          . lap 22 - pit (Drive Through Penalty)
          . laps 23-39 - clear/get penalty
          . laps 40-50 - normal laps (Drive Through Penalty still exist)
          . lap 51 - pit (end of race) (penalty pending)

          Why clear/get penalty? Because I can not imagine another explanation for what happened in these races.

          Last Edited: 2017-06-02 17:46:28 by phi
            Author: berniw | Created: 2017-06-02 18:30:08
            Subject: Re: Penalties
            How do you determine if there is still a penalty? Tim said " the the blue message informing the user of this stays even after the penalty has been served...", so is it eventually just a display bug? Or did you inspect/print the internal state of TORCS?

            I will have a look into it tomorrow, does the problem appear as well without pit sharing?

            Last Edited: 2017-06-02 18:30:08 by berniw
              Author: phi | Created: 2017-06-02 19:07:37
              Subject: Re: Penalties
              I rely only on what is visible (display) and on the alleged recurrence of the infringement. I do not sufficiently master the TORCS for a more careful observation at the internal level.

              Perhaps is just a display bug, I dont know...

              I do not tried without pit sharing. All the races are with pit sharing.

              PS: I must say that in race 2 Mouse 2 (a few meters in front of Mouse 1) entered in pits to pay his penalty, precisely at lap 40, back from which Mouse 1 began its normal laps. I do not know if this data will be of any interest...
              Last Edited: 2017-06-02 19:22:53 by phi
              Author: phi | Created: 2017-06-03 19:30:21
              Subject: Re: Penalties
              What Tim said intrigates me a bit in a good sense, and put me to think a little about it. In my system (windows; TORCS 1.3.8-test1) this never happened: during the development of my robot I always relied on these messages, sometimes revealing two or more penalties in succession, and the goal was always its elimination: I've never been stuck to a permanent message, which would eventually happen (I suppose) in case of bad information from TORCS. Whenever there was a penalty payment, the corresponding message disappeared.

              So, I ask myself now: Is Tim's remark referring (in the sense of the true target problem) not to a display error, but to something else? That is, can we still think about the possibility of a simple display error?
              Last Edited: 2017-06-03 19:30:21 by phi
                Author: phi | Created: 2017-06-04 20:21:02
                Subject: Re: Penalties
                I noticed that my robots do 'memset(&car->ctrl, 0, sizeof(tCarCtrl));' at every step, and the Mouse (like many others) does not do it. Now I understand why what Tim said was not happening to me, so much so that in ReRaceRules() everything seems to indicate the permanence of a wrong message (When all penalties are paid). When I have availability I will test again, adding that memory cleaning to the Mouse.
                Last Edited: 2017-06-04 20:21:02 by phi
                  Author: phi | Created: 2017-06-04 22:11:03
                  Subject: Re: Penalties
                  Such cleaning does not work very well with the Mouse, at least without reviewing his pit stop process. In any case, I realized that at some point, after countless attempts, the Mouse can effectively pay its penalty: the blue message disappears (it appears to be only a residual effect).

                  So it seems that the display bug is the only one, and I believe it can be solved - at least on this subject - with an 'else' clause in ReRaceRules():

                  penalty = GF_TAILQ_FIRST(&(car->_penaltyList));
                  if (penalty) {
                  } else {
                  *(car->ctrl.msg[3]) = 0;

                  I do not know exactly if only this will suffice, or whether it will be satisfactorily correct. In any case, my doubts about this issue seem to be resolved.
                  Last Edited: 2017-06-04 22:11:03 by phi
                    Author: berniw | Created: 2017-06-05 23:41:08
                    Subject: Re: Penalties
                    Cool, thank you for the investigation:-)
                    Last Edited: 2017-06-05 23:41:08 by berniw