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

Hi Remi,

Rémi Coulom wrote:
> Hi,
> 
> I am preparing a paper for the ACG conference 
> http://www.cs.unimaas.nl/icga/acg10/
> This event gathers programmers of artificial intelligence applied to games, 
> and I thought it might be a good idea to make a presentation of RARS and 
> TORCS there. The audience will consist mostly of typical computer geeks like 
> us. I hope it will motivate some of them to participate.

Great !

> 
> I am writing an overview paper that presents the current state of the art in 
> the field of AI applied to simulated car races. Right now, I'd like to 
> request your assistance/opinion/suggestions. Mainly, I would appreciate if 
> you could provide me with some information about the following topics:
>  
> - How do bots compare to human drivers? I guess the best bots are unbeatable 
> in RARS. What about TORCS?

Depends on the track, on some tracks robots are beatable, but on some tracks
it is more difficult.
In general, robots win on the distance and humans are generally best for
overlapping.
IMHO a robot with a car perfectly set-up and using good trajectories
should be unbeatable.

> 
> - How does commercial software work? I guess few use realistic simulation, 
> although some do. Considering AI, I guess they all cheat, by recording human
> trajectories or using such techniques. Do you have more information about 
> this?
> 
> - How does your car work? I have collected some old posts of the RARS mailing 
> list. I have just put them on the RARS site, if you'd like to check. If you'd 
> like to add your own message to this collection, then please go ahead. I have 
> taken a look at the source code of some bots, but I will not be able to make 
> a completely comprehensive report of all the techniques used, since there are 
> so many cars.

Hum, trying to follow the middle line an anticipate the turns, that's the
way my robots work. That's far from the best trajectories.

> 
> I hope I will have a readable draft by thursday, and I will make it available 
> publicly, so that you can suggest things to improve/add.
> 
> Thanks for your feedback,
> 
> Rémi
> 

Bye,
Eric.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
                        TORCS
             The Open Racing Car Simulator
         AKA The Other Release Coming Soon (Skin'r)
                  http://torcs.org
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

Hi,

I am preparing a paper for the ACG conference=20
http://www.cs.unimaas.nl/icga/acg10/
This event gathers programmers of artificial intelligence applied to game=
s,=20
and I thought it might be a good idea to make a presentation of RARS and=20
TORCS there. The audience will consist mostly of typical computer geeks l=
ike=20
us. I hope it will motivate some of them to participate.

I am writing an overview paper that presents the current state of the art=
 in=20
the field of AI applied to simulated car races. Right now, I'd like to=20
request your assistance/opinion/suggestions. Mainly, I would appreciate i=
f=20
you could provide me with some information about the following topics:
=20
- How do bots compare to human drivers? I guess the best bots are unbeata=
ble=20
in RARS. What about TORCS?

- How does commercial software work? I guess few use realistic simulation=
,=20
although some do. Considering AI, I guess they all cheat, by recording hu=
man
trajectories or using such techniques. Do you have more information about=
=20
this?

- How does your car work? I have collected some old posts of the RARS mai=
ling=20
list. I have just put them on the RARS site, if you'd like to check. If y=
ou'd=20
like to add your own message to this collection, then please go ahead. I =
have=20
taken a look at the source code of some bots, but I will not be able to m=
ake=20
a completely comprehensive report of all the techniques used, since there=
 are=20
so many cars.

I hope I will have a readable draft by thursday, and I will make it avail=
able=20
publicly, so that you can suggest things to improve/add.

Thanks for your feedback,

R=E9mi

> One other point to discuss is the Linux packaging,
> particularly the files location.
> 
> The 1.2.0 version files location is:
> $HOME/.torcs  Configuration and result files for the general
>               options and the player.
> 
> /usr/bin/                for the main command
> /usr/share/games/torcs   all the "runtime" directory

i think that's ok, but i would like still to be able to install below 
/usr/local (usually that works with ./configure).

> The problem raised by packagers is that /usr/share is
> dedicated to architecture-independent data.

yes, that's why i was a bit surprised about that:-)

> For the future versions (after the 1.2.1), the files can be located
> in:
> 
> /usr/bin/                for the main command
> /usr/games/torcs/        for the binaries
> /usr/lib/torcs/          for the shared libs (or may be /usr/lib ?)
> /usr/share/games/torcs   for the data

i would prefer /usr/lib/torcs, so one knows where all the stuff is.

> One problem is the robots.
> 
> The robots are dynamicaly "discovered" by the program
> at runtime. they are located in specific directories
> and are composed of a shared lib and data files that
> can be modified/created by the robot code. so /usr
> is not a good target directory for the robots as
> /usr is Read-Only for users.
> 
> As robots can be provided by everyone, some points
> have to be discussed.
> 
> So where to store the robots part ?

One could put the "defult" robots below /usr/lib/torcs/drivers (i think 
none of the packaged robots are doing write acceses? if not one could 
implement "copy on write"). the robot developed by the user could reside 
below ~/.torcs/drivers/robotname (and TORCS could also look into that 
directory to load it). what i think is an important point is that 
whereever we put the robots that the structure is independent of the 
location (so that one has not to reorganize the datafiles all the time).

> A robot development environment have to be created too
> for robot developpers.

i think for that we need a little package with the needed header files, 
makefiles and to adapt the scritpt to generate the skeleton. i don't 
know if it would be possible to write kind of a "plugin" for kdevelop 
and vc++ so that one could choose a "TORCS robot" project and it would 
do everything automatically. another question is also if it's worth the 
trouble, because i suspect that the people writing robots can live quite 
good with shells and makefiles.

perhaps one should setup a poll on the TORCS site and ask the users what 
they finally need to be able to develop a robot (because for me it was 
ok to start with 0.0.19;-)).

bye, bernhard.


-- 

visit my homepage http://n.ethz.ch/student/hwymann

Hi all,

A new development version is available here
<http://torcs.org/www/tmp/TORCS-1.2.1a-src.tgz>
(the version number remains 1.2.1)

the modifications are:

- Keyboard steering: the steer returns quickly to
   center when releasing the key (easier to drive
   thanks Dietrich for the hint)

- Smokes: less smoke at reduced speed (enhance the
   frame rate and the realism)

- The mouse does not center anymore at the race start
   if it is not used for steering.

Bye,
Eric.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
                        TORCS
             The Open Racing Car Simulator
                  http://torcs.org
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

On Sat, 12 Apr 2003, Eric Espie wrote:

> One other point to discuss is the Linux packaging,
> particularly the files location.

> For the future versions (after the 1.2.1), the files can be located
> in:
>
> /usr/bin/                for the main command

I'm installing the launcher as /usr/games/torcs because
/usr/games is encouraged for games binaries and launchers
on my system.

> /usr/games/torcs/        for the binaries

It has been done this way in earlyer releases of my system,
until it was decided that binaries used for games should
be put into the hierachy know by GNU tools as libexec,
means binaries and libraries to run the main command.

An example for this was /usr/bin/locate (script) with
binaries in /usr/lib/libexec (or where you define it).

Now I have been told that libexec is just /usr/lib in
todays FHS/LSB recommendations with e.g. /usr/lib/perl
for the perl binaries and other binary data.

/usr/lib/perl is actually quite an interesting example
because it also includes architecture agnostic scripts
and as it's own hiearchy for arch-dependant stuff.

> /usr/lib/torcs/          for the shared libs (or may be /usr/lib ?)

Yep, this would be such libexec-style directory for
libraries only used by a particular app.

FHS seesm to suggest a /usr/lib/games hierarchy for
additional game data(and possibly game libs):

http://www.pathname.com/fhs/2.2/fhs-4.11.html

Similarly, a /usr/lib/games hierarchy may be used in addition
to the /usr/share/games hierarchy if the distributor wishes
to place some game data there.

> /usr/share/games/torcs   for the data

Yes, if I summarize, I would use this set:

/usr/games/torcs         for the game launcher
/usr/lib/games/torcs/    for the binaries and shared libs
/usr/share/games/torcs/  for the data

> One problem is the robots.
>
> The robots are dynamicaly "discovered" by the program
> at runtime. they are located in specific directories
> and are composed of a shared lib and data files that
> can be modified/created by the robot code. so /usr
> is not a good target directory for the robots as
> /usr is Read-Only for users.
>
> As robots can be provided by everyone, some points
> have to be discussed.
>
> So where to store the robots part ?
>
> For security reasons, the drivers/ tree could be copied
> into the users $HOME/.torcs directory so the robots
> could access to the data files in R/W mode and as the
> robots are executed with the user's privileges, the risks of
> system corruption is limited.

My idea is that $HOME/.torcs can be used to override all
system torcs files and I'd like to have as less as possible
copied and use a copy-on-write mechanism if torcs changes
a setting locally for a user.

May it could be done by a check if opening the system file
for write worked and try to write a local file then.

I also would like to switch quickly between torcs config
by just switching between different $HOME/.torcs directories
or between different directories within $HOME/.torcs.

I could call the laucher using an option, e.g. I'd use
torcs -l train to use $HOME/.torcs/train when I'm in the
train and have no joystick or wheel around and don't want
loud sounds and use the default directory with full sound
and wheel at home.

The ultimate comfort would then be an automatic menu in
case there have been different config sets created - for
choosing them on start.

Of course these are just long-term ideas,
Bernhard

PS: Bernhard Wymann wrote:
> > thank you for the info... and for the t-shirt;-)
Same from me, thank you for the t-shirt! :-)

Bernhard Wymann wrote:
> Hi all
> 
> now after 1.2.0 made it to the release i would like to know a bit about 
> the future. what are the plans for the next release, who does what, what 
> is already in progress and so on...
> 
> possible tasks:
> ---------------
> - robot tutorial (will be done till 9.2003)

Your tutorial is very good :-)

> - track tutorial

Christophe ?

> - organizing an "official" robot racing season (rules, infrastructure, 
> time)

Any volunteers ?

> - network play

My current task, I'm heavily thinking about that, I begin
to structure the code for that.

> - race rules
> - safety car

I thought about it a few months ago... it is sure that it
should be done, I'll think about it after the network, and sound.

> - animated scenery (helicopter with camera?, water, sky/clouds)
> - transparent car windows, driver inside
> - shadow mapping or other shadow algorithm
 > - cockpit inside view with mirrors and cockpit

The graphic part is relatively independant and can be worked
separately, it's heavily based on PLIB scenegraph and Christophe
AC3D file format enhancements.

> - better sound

The second task I wanted to work on after the network play.

> - general improvments
> - track editor

... a lot of projects started but none were finished.

> 
> thank you for the info... and for the t-shirt;-)
> 
> bye, bernhard.
> 
>

One other point to discuss is the Linux packaging,
particularly the files location.

The 1.2.0 version files location is:
$HOME/.torcs  Configuration and result files for the general
               options and the player.

/usr/bin/                for the main command
/usr/share/games/torcs   all the "runtime" directory

The problem raised by packagers is that /usr/share is
dedicated to architecture-independent data.

For the future versions (after the 1.2.1), the files can be located
in:

/usr/bin/                for the main command
/usr/games/torcs/        for the binaries
/usr/lib/torcs/          for the shared libs (or may be /usr/lib ?)
/usr/share/games/torcs   for the data

One problem is the robots.

The robots are dynamicaly "discovered" by the program
at runtime. they are located in specific directories
and are composed of a shared lib and data files that
can be modified/created by the robot code. so /usr
is not a good target directory for the robots as
/usr is Read-Only for users.

As robots can be provided by everyone, some points
have to be discussed.

So where to store the robots part ?

For security reasons, the drivers/ tree could be copied
into the users $HOME/.torcs directory so the robots
could access to the data files in R/W mode and as the
robots are executed with the user's privileges, the risks of
system corruption is limited.

A robot development environment have to be created too
for robot developpers.

I'd be glad to have the specialists point of view
on the subject.

Thanks,
Eric.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
                        TORCS
             The Open Racing Car Simulator
                  http://torcs.org
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

Hi all

now after 1.2.0 made it to the release i would like to know a bit about 
the future. what are the plans for the next release, who does what, what 
is already in progress and so on...

possible tasks:
---------------
- robot tutorial (will be done till 9.2003)
- track tutorial
- organizing an "official" robot racing season (rules, infrastructure, time)
- network play
- race rules
- safety car
- animated scenery (helicopter with camera?, water, sky/clouds)
- transparent car windows, driver inside
- shadow mapping or other shadow algorithm
- better sound
- cockpit inside view with mirrors and cockpit
- general improvments
- track editor

thank you for the info... and for the t-shirt;-)

bye, bernhard.


-- 

visit my homepage http://n.ethz.ch/student/hwymann

Hi All,

If someone is interested in testing the long awaited
keyboard steering feature, it's available under
<http://torcs.org/tmp>
You can get only the source packages, but I changed
a little the data packages content to have something
usable with only the mandatory torcs-data package.

The steering sensitivity is modifiable in the
"Mouse/Keyboard/Pad" configuration screen.

you can choose to drive either with keyboard,
joystick buttons (Pad) or mouse.

The current steering law is linear (fct of time)
but may be changed to something more progressive
if necessary.

I'd be happy to have your comments on that.

Bye,
Eric.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
                        TORCS
             The Open Racing Car Simulator
                  http://torcs.org
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=