torcs-devel Mailing List for TORCS - The Open Racing Car Simulator

Bernhard Wymann wrote:
> Hi Christos
> 
>> In some surfaces, a bump map can be specified.
> 

> 
> I think it does nothing at the moment, does it (I'm not sure without
> looking up the code)?
> 
Apparently the previous version of g-track-2 was using a bump map for
all the textures, visually it appeared it was just blended with the
normal texture..

I remember I could make a track utilising either normal texture + shade
texture, or normal texture + bumpmap with particular combinations of
trackgen and accc utilities; in both cases it looked like it was just
blending, but I thought maybe it's just my card that sucks :)


> 
> [1] http://sourceforge.net/forum/forum.php?thread_id=1366480&forum_id=11281
> 
> 


-- 
Christos Dimitrakakis
Homepage: http://www.idiap.ch/~dimitrak/main.html
Music: http://olethros.dmusic.com

Hi Christos

> In some surfaces, a bump map can be specified.

I think it does nothing at the moment, does it (I'm not sure without looking up 
the code)?

I planned to rework this after 2.0, but somebody stepped up in the forum [1], so 
there might be a update much earlier. There will be in the end possibly the 
following remaining things for some surfaces (not all things are useful everywhere):
- A texture
- A normal map (fake bump maps are not necessary anymore, there is enough 
functionality and performance on quite old GPU's).
- A gloss map.
- A shader program.
- Maybe some more textures for more special effects.

Offtopic: There is a new TORCS related site on http://nirwana.ni.funpic.de/torcs/

Bye, Bernhard.


[1] http://sourceforge.net/forum/forum.php?thread_id=1366480&forum_id=11281


-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In some surfaces, a bump map can be specified.

In which of the following three ways is it used?

a) A bump map
b) A normal map
c) A simple texture that gets blended with the other one

Cheers,
Christos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDVOhVBsQIVGq8N4ERAhkoAKCJO/SkArG77/bn9J/aHMJNqbDJ7gCfRTJH
g2VQDm7hmIWdLuNM7YOJp1Q=
=t+SM
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eugen Treise wrote:
> Hi all,
> 
> I did not know that it's possible to fly in torcs, but olethros 10 showed me this.
> If you setup F1 car with 1 degree front wing and 5 degree rear wing, you can take off when hitting the wall at a high speed. I tried it on michigan and could fly over the entire straight of the track. Seems to be a problem with wing angle values causing too much vertical force in the upper direction in some cases.
> 
In the simuv2 code the wings never produce downforce in the upwards
direction, as far as I can see from the code. In simuv3 it can happen
that you'll have a net upwards pull under certain conditions, but this
will be only temporary, lifting the front of the car and making it spin
in the air. (If the angle of rotation of the car is limited then you are
using simuv2, if the car moves freely, it's simuv3)


I know however that when you crash on a wall, only the lateral speed is
affected. The vertical speed is not. So, if you're on a banked track and
moving out, it means you are also moving upwards at quite some speed.
When you hit the barrier, lateral movement stops but you continue going up:

Since most of the downforce in the F1 car is coming from the ground
effect (which I think has a ridiculously high value in this car), most
of the downforce is lost as soon as the car loses contact with the
ground. You test this theory but using 0 degree for wings and see if the
results are replicated.



> There is also an other problem with olethros driving F1 car on michigan. In the car setup .xml file for this track only 6 gears are defined. When the driver switches to 7th gear, the car drives at a low speed with max revs. He stays in this gear if no collision or something other happens.
> 

I'll check the CVS for that and fix it, thanks for the report.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDVNySBsQIVGq8N4ERAgvNAJ9flAgfW/YK4G04gXncscZP3Xz7+ACeOLcn
SEIrwkT8LV9lYcDiWqLXxeo=
=89iB
-----END PGP SIGNATURE-----

Hi all,

I did not know that it's possible to fly in torcs, but olethros 10 showed me this.
If you setup F1 car with 1 degree front wing and 5 degree rear wing, you can take off when hitting the wall at a high speed. I tried it on michigan and could fly over the entire straight of the track. Seems to be a problem with wing angle values causing too much vertical force in the upper direction in some cases.

There is also an other problem with olethros driving F1 car on michigan. In the car setup .xml file for this track only 6 gears are defined. When the driver switches to 7th gear, the car drives at a low speed with max revs. He stays in this gear if no collision or something other happens.

bye,
Eugen


______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

Hi Eugen

> So there must be somewhere a division by 0 in torcs or in robot code.

Should not matter, that got all fixed in... a long time ago. There can happen 
two things:
- with float n, k, n != 0, k == 0 we do "n/k" -> result is for n > 0 "infinity" 
and for n < 0 "-infinity". A valid result which the FPU can further process, no 
problem (of course the result can be plain wrong in the end, but that is not the 
matter)
- with float n, k, n == k == 0 we do "n/k" -> result undefined, the number is 
set to "Not a Number" (NaN), so all computation which get touched by this result 
are NaN's as well, so e,g "1.0f + NaN" is NaN (btw. if you compare a float with 
itself, e.g. a == a then the result is false (!!!!) if it is a NaN, nice 
portable way to check that -> specification IEEE754).
- All (really all, I have to check the clutch) NaNs in robots are checked and 
overwritten with 0 if NaN, but I will recheck that as well.
- It is quite usual if you change something that you run into such trouble, 
because you may violate implicit (undocumented, grrrr...) assumtions of some 
code. You, somebody else or I will find the problem sooner or later, do not 
loose hope and do not get too frustrated by such accidents:-)

If I got you right this happens with your modifications applied? I will have to 
look into them, I will do that probably within the next three weeks (offtopic: I 
started a new job and did not yet move house, so I spend a lot of time with 
travelling to work, currently ~3 hours a day... I hope the situation will 
normalize within 3-5 months. This is the main reason for the "mickey mouse" TODO 
list for 1.3.0, the only core and intese things are the SDL port and the build 
system, all in all probably just mere 25-40 hours of work).

>>Bernhard, when you updates berniw, let me test it with my code. berniw can't find the assigned pit and waits on a wrong one.

I will update the berniw's within the next 8 weeks with the berniw_2004 code 
from TRB and some minor fixes from the berniw in 1.2.4 (e.g module discovery 
memleak, use tmath classes, pit location derived from bt, ...).

Bye, thank you very much,

Bernhard.


-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

Hi all,

it looks there was already a similar problem, at least the result is the same. I have found a bug report from Bernhard including a screen shot, similar to what i have seen. Look here: http://sourceforge.net/tracker/index.php?func=detail&aid=466637&group_id=3777&atid=103777

So there must be somewhere a division by 0 in torcs or in robot code.

Hope someone can find it.

Thanks,
Eugen


Eugen Treise <et...@we...> schrieb am 11.10.05 23:09:06:
> 
> 
> Hi all,
> 
> Pit sharing is finished, but there are some problems, so i have to test it more.
> I have attached a patch, maybe there is a problem in the code.
> 
> While testing i have noticed a problem, which reason i don't know. I attached a screen shot, that shows what can happen. Before this happens, i see many cars driving through others.
> Under windows torcs freezes, under linux i see a black screen and the frame rate becomes very low. Many cars have a huge damage like Inferno on the screen shot and the speed display is also wrong. All cars disappear from the track, only those in the pits can stil be seen, until they finish and disappear also.
> 
> This problem occurres on Dirt-3 track very early. I have configured about 13 berniw, 10 bt, 8 inferno, 8 olethros and 4 damned cars in this order for a quick race.
> 
> If someone has already experienced such a problem, please point me to the right direction.
> 
> Maybe there is a problem with some driver, that makes wrong access to the pits, i don't know.
> 
> Bernhard, when you updates berniw, let me test it with my code. berniw can't find the assigned pit and waits on a wrong one.
> 
> 
> Thanks,
> Eugen
> 
> 
> 
> be...@bl... schrieb am 06.10.05 20:37:46:
> > 
> > Hi Eugen
> > 
> > > I have started to implement pit sharing inside teams.
> > 
> > Good:-)
> > 
> > > Each team gets at least one pit (if there are enough). The rest is distributed to teams with more than 1 driver.
> > > Teams with many drivers get more pits than teams with less drivers.
> > 
> > I had an implementation in mind where (if not enough pits are available to have 
> > 1 per driver) always n drivers will get a bit, so e.g. if n == 2 and you have 1 
> > inferno and 1 berniw bot that they are thrown at the same pit even if they are 
> > not from the same team.
> > 
> > > While testing i noticed following:
> > > 
> > > 1) Collision code reduces the perfomance when many cars are on the track. On my computer (AthlonXP 2GHz) i can drive with 30 drivers, with 50 it's impossible. Well, maybe 30 cars is enough for us.
> > > In collision code there is a switch to enable caching. When activated the perfomance is much better, but torcs freezes when i crached into an other car.
> > > 
> > > 2) berniw robot (from torcs 1.2.4) computes it's pit position depending on the starting position. This will not work with pit sharing. Other robots like bt and olethros use car->_pit structure and find the correct pit position.
> > 
> > Ok, that will be trivial to fix, no problem.
> > 
> > > 3) There is no collision when a robot is in his pit. I saw 4 olethros sitting in one pit at the same time :)
> > 
> > That is intensional, think of the complications if you crash in a pitted bot. 
> > Its basically to keep things simple. The robots will of course need a bit of 
> > modification, but this is easy as well.
> > 
> > > 4) When pit sharing will be included sometime, robots should use pit state (tTrackOwnPit structure) to see if pit is free.
> > 
> > Is this the state which was already around or a new one (there was a flag for 
> > years, no new one needed)?
> > 
> > > I will make some more tests this weekend and post the patch, if it's usable.
> > 
> > Great:-)
> > 
> > Thank you, bye
> > 
> > Bernhard.
> > 
> > -- 
> > 
> > Visit my homepage http://www.berniw.org
> > Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb
> > 

______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

Hi all,

Pit sharing is finished, but there are some problems, so i have to test it more.
I have attached a patch, maybe there is a problem in the code.

While testing i have noticed a problem, which reason i don't know. I attached a screen shot, that shows what can happen. Before this happens, i see many cars driving through others.
Under windows torcs freezes, under linux i see a black screen and the frame rate becomes very low. Many cars have a huge damage like Inferno on the screen shot and the speed display is also wrong. All cars disappear from the track, only those in the pits can stil be seen, until they finish and disappear also.

This problem occurres on Dirt-3 track very early. I have configured about 13 berniw, 10 bt, 8 inferno, 8 olethros and 4 damned cars in this order for a quick race.

If someone has already experienced such a problem, please point me to the right direction.

Maybe there is a problem with some driver, that makes wrong access to the pits, i don't know.

Bernhard, when you updates berniw, let me test it with my code. berniw can't find the assigned pit and waits on a wrong one.


Thanks,
Eugen



be...@bl... schrieb am 06.10.05 20:37:46:
> 
> Hi Eugen
> 
> > I have started to implement pit sharing inside teams.
> 
> Good:-)
> 
> > Each team gets at least one pit (if there are enough). The rest is distributed to teams with more than 1 driver.
> > Teams with many drivers get more pits than teams with less drivers.
> 
> I had an implementation in mind where (if not enough pits are available to have 
> 1 per driver) always n drivers will get a bit, so e.g. if n == 2 and you have 1 
> inferno and 1 berniw bot that they are thrown at the same pit even if they are 
> not from the same team.
> 
> > While testing i noticed following:
> > 
> > 1) Collision code reduces the perfomance when many cars are on the track. On my computer (AthlonXP 2GHz) i can drive with 30 drivers, with 50 it's impossible. Well, maybe 30 cars is enough for us.
> > In collision code there is a switch to enable caching. When activated the perfomance is much better, but torcs freezes when i crached into an other car.
> > 
> > 2) berniw robot (from torcs 1.2.4) computes it's pit position depending on the starting position. This will not work with pit sharing. Other robots like bt and olethros use car->_pit structure and find the correct pit position.
> 
> Ok, that will be trivial to fix, no problem.
> 
> > 3) There is no collision when a robot is in his pit. I saw 4 olethros sitting in one pit at the same time :)
> 
> That is intensional, think of the complications if you crash in a pitted bot. 
> Its basically to keep things simple. The robots will of course need a bit of 
> modification, but this is easy as well.
> 
> > 4) When pit sharing will be included sometime, robots should use pit state (tTrackOwnPit structure) to see if pit is free.
> 
> Is this the state which was already around or a new one (there was a flag for 
> years, no new one needed)?
> 
> > I will make some more tests this weekend and post the patch, if it's usable.
> 
> Great:-)
> 
> Thank you, bye
> 
> Bernhard.
> 
> -- 
> 
> Visit my homepage http://www.berniw.org
> Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Torcs-devel mailing list
> Tor...@li...
> https://lists.sourceforge.net/lists/listinfo/torcs-devel


______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

Hi Bernhard (and others),

Thanks for your reply.

On Monday 3 October 2005 20:53, Bernhard Wymann wrote:
> Hi all
>
> Without having looked at the patches yet here my thoughts:
>
> - I would like to have more penalties, in a final version configurable via
> xml, later via gui (read below).
>
> - We need a framework for that, and the current penalty system/notification
> is a start.
> 
> - Because 1.9 will shake everything on TORCS I would wait with that till
> 2.0 or later (sorry for this default answer, but the less new bugs we
> introduce and the less code we have, the easier will the transition
> actually work).

That's no problem: I can keep the changes on my computer and repost it later. 
BTW: in this paragraph the version is >= 2.0, in the last paragraph you wrote 
about 1.9. Did you intended 2.0 there?

> - We need to discuss what should happen in which cases (e.g. we could say
> that the car which should let the opponent overlap is responsible and 1.
> give a penalty after a certain time, 2. remove it from the race if this
> does not help).

Or a car can say that he cannot overlap a car, and that car gets a penalty 
(after it is verified). Which penalty can depend of the number of penalties 
he already got for it.

> - In a first iteration I would exclude robots from the rules (some are not
> further developed at the moment, so nobody will add the code for that).

I agree: it is not good if (for example) only 6 of the 20 cars finish the 
race... Maybe it is an option to only use a feature (e.g.: no overlapping if 
there are yellow flags) if all cars in a race have implemented it. 

> Of relevance for the first shot in 1.9 are beside the existing rules:
> - Blue.
> - Yellow (no overtaking).
> - Black somehow, but more as an action (remove the offending opponent).

In the current version, a car has 5 laps to come to the pit to clear the 
penalty. After that, the car is eliminated, so I think something like that 
already exists (but it could be extended).

> - Safety car (is as well yellow).

I think a safety car can only be implemented after the bots implemented yellow 
flags; elsewise it is racing with an extra slow-driving car.

> Bye, thank you for your patch,
>
> Bernhard.

Regards,

Mart

Hello Bernhard,

be...@bl... schrieb am 06.10.05 20:37:46:
> 
> Hi Eugen
> 
> > I have started to implement pit sharing inside teams.
> 
> Good:-)
> 
> > Each team gets at least one pit (if there are enough). The rest is distributed to teams with more than 1 driver.
> > Teams with many drivers get more pits than teams with less drivers.
> 
> I had an implementation in mind where (if not enough pits are available to have 
> 1 per driver) always n drivers will get a bit, so e.g. if n == 2 and you have 1 
> inferno and 1 berniw bot that they are thrown at the same pit even if they are 
> not from the same team.

I think sharing pits between team members is not as simple as your suggestion to implement. This way you can only block your team members from entering pit, not the other robots.
I'll see if i get it to work.

> > 3) There is no collision when a robot is in his pit. I saw 4 olethros sitting in one pit at the same time :)
> 
> That is intensional, think of the complications if you crash in a pitted bot. 
> Its basically to keep things simple. The robots will of course need a bit of 
> modification, but this is easy as well.
> 
OK

> > 4) When pit sharing will be included sometime, robots should use pit state (tTrackOwnPit structure) to see if pit is free.
> 
> Is this the state which was already around or a new one (there was a flag for 
> years, no new one needed)?

Yes, the state was already in the structure for future use. It can be free, asked and used. This should be enough.


bye,
Eugen


______________________________________________________________________
XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club!		
Jetzt gratis testen! http://freemail.web.de/home/landingpad/?mc=021130

Hi Eugen

> I have started to implement pit sharing inside teams.

Good:-)

> Each team gets at least one pit (if there are enough). The rest is distributed to teams with more than 1 driver.
> Teams with many drivers get more pits than teams with less drivers.

I had an implementation in mind where (if not enough pits are available to have 
1 per driver) always n drivers will get a bit, so e.g. if n == 2 and you have 1 
inferno and 1 berniw bot that they are thrown at the same pit even if they are 
not from the same team.

> While testing i noticed following:
> 
> 1) Collision code reduces the perfomance when many cars are on the track. On my computer (AthlonXP 2GHz) i can drive with 30 drivers, with 50 it's impossible. Well, maybe 30 cars is enough for us.
> In collision code there is a switch to enable caching. When activated the perfomance is much better, but torcs freezes when i crached into an other car.
> 
> 2) berniw robot (from torcs 1.2.4) computes it's pit position depending on the starting position. This will not work with pit sharing. Other robots like bt and olethros use car->_pit structure and find the correct pit position.

Ok, that will be trivial to fix, no problem.

> 3) There is no collision when a robot is in his pit. I saw 4 olethros sitting in one pit at the same time :)

That is intensional, think of the complications if you crash in a pitted bot. 
Its basically to keep things simple. The robots will of course need a bit of 
modification, but this is easy as well.

> 4) When pit sharing will be included sometime, robots should use pit state (tTrackOwnPit structure) to see if pit is free.

Is this the state which was already around or a new one (there was a flag for 
years, no new one needed)?

> I will make some more tests this weekend and post the patch, if it's usable.

Great:-)

Thank you, bye

Bernhard.

-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

Sounds great.
>
> 1) Collision code reduces the perfomance when many cars are on the track. On my computer (AthlonXP 2GHz) i can drive with 30 drivers, with 50 it's impossible. Well, maybe 30 cars is enough for us.
> In collision code there is a switch to enable caching. When activated the perfomance is much better, but torcs freezes when i crached into an other car.
>

Hm, I guess collision code tests n^2 cars, but I didn't expect so much 
overhead, really.

> 3) There is no collision when a robot is in his pit. I saw 4 
> olethros sitting in one pit at the same time :)
>

The car enters a particular state, during which it's not simulated at 
all.

> 4) When pit sharing will be included sometime, robots should use pit 
> state (tTrackOwnPit structure) to see if pit is free.
>

Hm, there is a 'Can Pit' flag that currently appears at the human 
player's window. Maybe that can be used(?).



-- 
Christos Dimitrakakis
IDIAP (http://www.idiap.ch/~dimitrak/main.html)

Hi all,

I have started to implement pit sharing inside teams.
Each team gets at least one pit (if there are enough). The rest is distributed to teams with more than 1 driver.
Teams with many drivers get more pits than teams with less drivers.

While testing i noticed following:

1) Collision code reduces the perfomance when many cars are on the track. On my computer (AthlonXP 2GHz) i can drive with 30 drivers, with 50 it's impossible. Well, maybe 30 cars is enough for us.
In collision code there is a switch to enable caching. When activated the perfomance is much better, but torcs freezes when i crached into an other car.

2) berniw robot (from torcs 1.2.4) computes it's pit position depending on the starting position. This will not work with pit sharing. Other robots like bt and olethros use car->_pit structure and find the correct pit position.

3) There is no collision when a robot is in his pit. I saw 4 olethros sitting in one pit at the same time :)

4) When pit sharing will be included sometime, robots should use pit state (tTrackOwnPit structure) to see if pit is free.

I will make some more tests this weekend and post the patch, if it's usable.


Greetings,
Eugen


______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

Hi, as I've previously told Bernard, there was an warning issue when
compiling tools/trackgen/track.cpp which looked like this:

g++ -I/tmp/buildd/torcs-1.2.4/build-tree/torcs-1.2.4/export/include
-I/tmp/buildd/torcs-1.2.4/build-tree/torcs-1.2.4 -g -Wall -O2 -Wall
-fPIC -O2 -DUSE_RANDR_EXT -DGL_GLEXT_PROTOTYPES -Wall -fPIC -O2
-DUSE_RANDR_EXT -DGL_GLEXT_PROTOTYPES  -D_SVID_SOURCE -D_BSD_SOURCE
-DSHM -DHAVE_CONFIG_H  -c track.cpp
track.cpp: In function 'int InitScene(tTrack*, void*, int)':
track.cpp:466: warning: operation on 'nbvert' may be undefined
track.cpp:467: warning: operation on 'nbvert' may be undefined
track.cpp:482: warning: operation on 'nbvert' may be undefined
track.cpp:487: warning: operation on 'nbvert' may be undefined

and many more warnings (like 100). I looked at the code and after a
bit of checking I've found that it's probably this issue [0], so I did
some changes and warnings went away.

http://www.eskimo.com/~scs/C-faq/q3.9.html

As I'm not that familiar with this piece of code, I'd like you to let
me know if my patch is correct, so I can happyly include it in the
Debian package I've almost ready for 1.2.4

thanks,
Rudy

-- 
Rudy Godoy | 0x3433BD21 | http://stone-head.org               ,''`.
http://www.apesol.org  -  http://www.debian.org              : :' :
GPG FP: 0D12 8537 607E 2DF5 4EFB  35A7 550F 1A00 3433 BD21   `. `'
                                                               `-

Hi Christos

> updated alpine-1.xml (added cameras)

Thank you very much, I will have a look at it on the week end.

Bye, Bernhard.

-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

Hi all

Without having looked at the patches yet here my thoughts:

- I would like to have more penalties, in a final version configurable via xml, 
later via gui (read below).

- We need a framework for that, and the current penalty system/notification is a 
start.

- Because 1.9 will shake everything on TORCS I would wait with that till 2.0 or 
later (sorry for this default answer, but the less new bugs we introduce and the 
less code we have, the easier will the transition actually work).

- We need to discuss what should happen in which cases (e.g. we could say that 
the car which should let the opponent overlap is responsible and 1. give a 
penalty after a certain time, 2. remove it from the race if this does not help).

- In a first iteration I would exclude robots from the rules (some are not 
further developed at the moment, so nobody will add the code for that).

Of relevance for the first shot in 1.9 are beside the existing rules:
- Blue.
- Yellow (no overtaking).
- Black somehow, but more as an action (remove the offending opponent).
- Safety car (is as well yellow).

Bye, thank you for your patch,

Bernhard.


-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

Hi Christos (and others),

Thanks for your reply.

On Monday 3 October 2005 01:30, Christos Dimitrakakis wrote:
> Thanks for your patch.
>
> So, I have some comments before we decide on whether to apply it, before
> or after modifications:
>
> a) The robots can very easily look at the list of cars and see if any
> of them are lapping them and are close, so there is no need to add
> more things to the structures (unless I don't understand what you did
> correctly).

I think there is a difference in distance measured in meters and seconds. On a 
dirt track where the speed is around 30 m/s (for example), 30 meters means 
one second, and on a oval where the speed is around 90m/s, 30 meters means a 
third of a second.

Of course, if robots have no problem spotting overlapping cars, it can just be 
replaced by a "char" (and maybe also in another place).

> b) As far as I can remember, the blue flag means: ''get out of the way,
> overlapping opponent.'' - A question is whether there is going to be a
> penalty for failing to obey and when the penalty should take place. This
> leads us to the following:

I think a blue flags warn a driver that a faster car is behind and that he 
must give space when the car tries to overtake him. A car may definitely not 
block him. A penalty for blocking the overlapping opponent would be great, 
but how to determine if someone is blocking? A problem with it is that you 
can't assume that drivers drive a constant lap time, as human players 
probably won't.

> c) There are already some other penalties implemented, for violating the
> pit lane rules. I have not looked at how everything is implemented in
> these cases, but I imagine there is some sort of notification taking
> place. It would be better if we somehow integrated this blue flag with
> the penalty notifications.

AFAIK, that also is a list (I used it to look how lists are created and 
updated).

Talking about that structure: I free the information that is left after the 
race in ReRaceCleanDrivers; the reason is that otherwise memory is leaked if 
someone has a flag after the race has ended. I don't see that code for the 
penalty list, so maybe that data is leaked (the size of the leak is quite 
small).

> d) There could be other flags: yellow, red, etc.. So we need a framework
> for all of these. I don't think this is something planned for a definite
> point in the future..

I think this is a good example to see possible problems: a blue flag is for a 
driver, a yellow flag for a track-segment and a red flag for the whole track. 
But of course this can be solved.

Maybe e) How to visualise: I made a simple flag, but I don't know where it is 
the best place to locate it, or another visualisation is better.

> So, in conclusion, I'd be OK with the patch as long as a) is addressed
> and after we decided whether we need to do any major changes to the
> flags/penalties code or not.
>
> Bye, thanks again,
>
> Christos

Regards,

Mart

Thanks for your patch.

So, I have some comments before we decide on whether to apply it, before
or after modifications:

a) The robots can very easily look at the list of cars and see if any
of them are lapping them and are close, so there is no need to add
more things to the structures (unless I don't understand what you did
correctly).

b) As far as I can remember, the blue flag means: ''get out of the way,
overlapping opponent.'' - A question is whether there is going to be a
penalty for failing to obey and when the penalty should take place. This
leads us to the following:

c) There are already some other penalties implemented, for violating the
pit lane rules. I have not looked at how everything is implemented in
these cases, but I imagine there is some sort of notification taking
place. It would be better if we somehow integrated this blue flag with
the penalty notifications.

d) There could be other flags: yellow, red, etc.. So we need a framework
for all of these. I don't think this is something planned for a definite
point in the future..

So, in conclusion, I'd be OK with the patch as long as a) is addressed
and after we decided whether we need to do any major changes to the
flags/penalties code or not.

Bye, thanks again,

Christos

Hi all,

I tried to implement blue flags in TORCS. I attached the result.

I tried to achieve it with the following goals in mind:
* Low CPU power, especially it isn't necessary to run it every timeframe.
* Flags must also be usefull for bots.

I use the following algorithm; the algorithm is called ones a second:
If a car x gets a blue flag then there exists another car y which is:
a. in front of car x;
b. the place on the track is between the place were car x was 3 seconds ago 
and the place where car x is now.

For getting the results to the bots, I added a list to the car structure with 
the cars (and if it is less then one second behind) that are overlapping the 
car.

For humans, I made a simple function that displays something that looks (a 
bit) like a flag.

Regards,

Mart

updated alpine-1.xml (added cameras)