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

Hi Mohammed

> I am getting this message:
> linuxModLoad: ...  /home/lib/torcs/drivers/cylos1/cylos1.so: cannot 
> open shared object file: No such file or directory
> Pb with loading /home/lib/torcs/drivers/cylos1/cylos1.so driver
> No driver for that race...
>  
> I already had one of the robot packages - TORCS-1.2.2-src-robots-berniw.tgz 
> installed. When I observed the error, it was looking for a cylos1 folder,
> which was not present . Hence, I downloaded the optional robot package 
> TORCS-1.2.2-src-robots-base.tgz 

Perhaps you did not change the default start list of the race, so there
were robots selected which are not installed?

Bye, Bernhard.

-- 

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

Hi,

 I am having problems executing TORCS.
 
I am getting this message:
linuxModLoad: ...  /home/lib/torcs/drivers/cylos1/cylos1.so: cannot 
open shared object file: No such file or directory
Pb with loading /home/lib/torcs/drivers/cylos1/cylos1.so driver
No driver for that race...
 
I already had one of the robot packages - TORCS-1.2.2-src-robots-berniw.tgz 
installed. When I observed the error, it was looking for a cylos1 folder,
which was not present . Hence, I downloaded the optional robot package 
TORCS-1.2.2-src-robots-base.tgz 
 
I extracted the robot package in the home/lib/torcs/drivers
I got the cylos1 folder in there but there is no cylos1.so 
file there. There are different files like cylos1.cpp
cylos1.xml, there is also a make file in there, but it 
doesn't work.
 
Please suggest what I need to do.
 
I will appreciate any help.
 
- Mustafa

		
---------------------------------
Do you Yahoo!?
 Send a seasonal email greeting and help others. Do good.

OK, it seems that it is in initTrack()
...

    static int	firstTime = 1; /* for persistent implementations ???
*/

    if (firstTime) {
	ssgInit();
	firstTime = 0;
    }
...

in 1.53 this was removed and I re-introduced it in 1.54.
Eric commited the fix as 'ssgInit'. So now ssgInit() should not be
called anymore??

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

Hm, I was trying to run it with valgrind but have had problems getting
it to work when the race was on... too many interrupts probably.

I still have a strange bug, which basically goes like this:

1. Start a race.
2. Exit it (in any way).
3. Do something in the interface, such us changing the player, or the
graphics config.
4. Start a new race.
5. Observe crash as soon as the loading sequence starts.

I mentioned this before, 1-2 months ago. I think it has something to
do with glut.

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

Hi all

Just for fun the first leak report I have generated with valgind and my 
inofficial TORCS 1.2.3 candidate (practise 1 lap with berniw 1 around 
mixed 1):

==8851== LEAK SUMMARY:
==8851==    definitely lost: 71249 bytes in 2145 blocks.
==8851==    possibly lost:   2068180 bytes in 259 blocks.
==8851==    still reachable: 10951727 bytes in 429118 blocks.
==8851==         suppressed: 0 bytes in 0 blocks.
==8851== Reachable blocks (those to which a pointer was found) are not 
shown.

I hope to be able to drop it a bit... bye the way, the most curious bug 
I have found so far is that the "digital" font does not support blanks, 
this was tough to find.

Bye, Bernhard.


-- 

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

Hi all

Yesterday night I had a dream, I must share that with you immediately:-) 
It was a nightmare, so be warned...

I woke up and the TORCS CVS was in a very different state. All commits 
where well commented in the logs, just files have been commited which 
really had changed and the developers were careful to not reintroduce 
bugs or to delete version info.

At that point I woke up drenched in sweat... what a nightmare! How 
boring would life be if people would not reitroduce bugs, writing log 
entries and so on.

So I really appreciate it if you put some puzzles into the CVS to make 
my boring life more interesting. Thank you very much for that, keep up 
this cool work, bye

Bernhard.


ps: The reason for my pleading is that I prepare an inofficial 1.2.3...


-- 

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

>
> Hmm, comes the problem from the original bt parts (do you still use the
> "lookahead" distance)?

OK, I will be looking into that to see how I can fix it without doing
any learning. Certainly the steering learning bit helps, but it takes
20-30 laps to converge to a good solution. I actually thought that
the question 'how much should I steer so that I follow this
trajectory' was really hard.. what solution do you have in mind?
Something like what you're using in berniw?


> SNIPPED SEGMENT STUFF
>

Ok, I'll remove the segment stuff and use an exponential decay for
adjusting all previous segment radi (much as I am doing for the
steering and accident probability calculations) and see if that
works/..

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

I put some new sounds in there, also modified relevant .xml files.
I still have not decided where to use the unknown engine-1,2... etc
files. I used the lamborghinidiablo sound for porsche-gt1 as it seemed
to fit. For porsche-gt3rs I used the sound of an electric mixer (yay),
suitably processed.

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

Hi all

I fiddled a bit on the F1 car in the CVS, fixes:
- Broken normals.
- Broken texture coordinates (could still be much better).
- Broken geometry (which stopped accc from working).
- Generated a real acc file, so the env and light maps work now.
- Added the fixed ac file.
- Preformance data in the XML file.
- Added a gauge for 20000 1/min.

Bye, Bernhard.

-- 

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

Hi Christos

I have not looked into your code yet, but here some guesses.

> 1. On some tracks the car initially turns to the inside of the curve
> far too much. It later learns how to avoid doing that, but it would
> have been better if it started off better. This happens mostly in
> tracks with very tight corners light e-track-2 and the dirt tracks.

Hmm, comes the problem from the original bt parts (do you still use the 
"lookahead" distance)? Perhaps the distance is too big. Of course this 
one cannot fit for all kinds of turns, it is just to keep the tutorial 
simple and is fitted to work acceptable with most of the tracks. 
Basically it should be possible to precompute a good lookahead for every 
turn. Especially if you eventually moved the target point inwards it is 
perfectly reasonable that the current lookahead is too big.

> 2. On s-curves, if the car goes so fast that it skids out of the first
> curve, it ends up on the inside of the second curve, which seems OK to
> the current logic. I don't know how to detect that something like this
> is hapenning.

That could come from bt as well, the best example is the slow "S" (90/90 
Degrees) on e-track-2 before the straight. This is caused by my simple 
learning approach, perhaps it hepls when you simply disable it.

The problem is that this approach can just learn in the segement 
(warning, not TORCS segments, logical track segments -> turn and 
straights are joint together if of the same type) where an incident 
happens, and does not correct the learned values in the previous 
segments. This sould be trivial to improve (perhaps 3 lines of code or 
so, take into account the distance to the segment start where the 
incident happend, if it is too small (braking distance) modify as well 
the previous segment).

Bye, Bernhard.


-- 

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

One more update for olethros, includes a lot of limits to fix the
stability, including:

- calculate estimated time until exiting the track given the current
trajectory on both sides no matter what the type of curve is.

- reduce estimates of curve radius according to offset, no matter if
alone or not.

- adjust planned trajectory for consecutive curves of same type so
that smaller radius curves are more important.

- backpropagate a negative radius adjustment when having had an
accident.

There are currently two problems:

1. On some tracks the car initially turns to the inside of the curve
far too much. It later learns how to avoid doing that, but it would
have been better if it started off better. This happens mostly in
tracks with very tight corners light e-track-2 and the dirt tracks.

2. On s-curves, if the car goes so fast that it skids out of the first
curve, it ends up on the inside of the second curve, which seems OK to
the current logic. I don't know how to detect that something like this
is hapenning.

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

I basically changed aero.cpp so that the full aerodynamic effect of
slipstreaming is only encountered when the angle is 0, otherwise it
linearly goes down to 0 when the angle becomes angle_max (which is 10
degrees currently). This makes driving behind other cars much
smoother, because you don't suddenly have no downforce at all. It is
more gradual and you have ample warning. This also means the car does
not jerk suddenly when this happens.

In olethros, I fixed a couple of issues, now the car does not have
strange behaviour any more apart from that which is expected (i.e.
learning to turn wrongly after being involved in an accident - I still
need a way to reliably differentiate between 'normal' driving and 'I
am just going to have / just had an accident')

Overtaking is now much smoother.

I fixed the utterly broken pitstop strategy by replacing it with a
formally defined probabilistic method. Now it works as intended,
with the car not going in for a pitstop if it thinks there is a chance
of losing a place in the final standings if it does so. The Doxygen
documentation explains the probabilistic approach I took. It is simple
to alter by just replacing the distributions I assume with something
else (possibly more complicated).

Olethros now has .brain files, one for each track. These are used as
follows:

1) At the beginning of each practice session, the learning starts from
scratch, disregarding any .brain files.

2) At the end of each practice or qualifying session, the learned
parameters are saved in the .brain file.

3) At the beginning of each qualifying/race session, the learning
starts from the parameters that have been saved in the .brain file.

This way, race sessions don't affect future race events and robots
can be reset by starting a practice session (has to be done for each
track).


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

Hi Christos

> I have had some strange problems when running bt together with
> olethros. Sometimes, but not always, and probably depending on the

Ah, interesting...

> loading order of the bots, olethros starts behaving weirdly in that
> situation  [like not braking at all before turns].

The loading order is given by the starting order in your test I guess,
so could it be possible that the starting order makes the difference?

> I thought that would be either a case of
> 1) me writing sloppy code, which has a pretty high chance

:-)

> 2) there is a linking problem
> 
>  Given that olethros has exactly the same structure as bt, I thought
> 2) was a possibility. To test this I added a namespace around my code
> and the problem seems to disappear. Since the only difference is the

Be careful when testing, I sometimes forget to do "make install" or edit
the wrong file and wonder then why nothing happens and all such funny
stuff...

> mangled names used in the object files, my guess right now is that it
> is indeed a linking problem.

That should not be possible IMHO, because the ".so" is linked in the
robot directory and the only exported thing is the "register" function
(you know, the entry point, "berniw", "bt" , "olethos", ...).

> However when looking at the dlopen() calls, they are all made with
> RTLD_LAZY and not RTLD_GLOBAL, so I don't think this can happen at
> all, namespace or no namespace..

It would not hurt with global as well, because the module entry point is
the only explicitely exported one I think.

> Am I completely wrong-headed in searching for a link problem?

I think it should not be a linking problem, its for sure no dynamic
linking problem (all happens inside the module, TORCS calls just the
registered functions). In case you screwed up the makefiles or so it
could be a static linkage problem.

Make sure that you have changed all references to bt (I think you have
done anyway otherwise it would not even load I guess).

Bye, Bernhard.

-- 

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

I have had some strange problems when running bt together with
olethros. Sometimes, but not always, and probably depending on the
loading order of the bots, olethros starts behaving weirdly in that
situation  [like not braking at all before turns].

I thought that would be either a case of
1) me writing sloppy code, which has a pretty high chance
2) there is a linking problem

 Given that olethros has exactly the same structure as bt, I thought
2) was a possibility. To test this I added a namespace around my code
and the problem seems to disappear. Since the only difference is the
mangled names used in the object files, my guess right now is that it
is indeed a linking problem.

However when looking at the dlopen() calls, they are all made with
RTLD_LAZY and not RTLD_GLOBAL, so I don't think this can happen at
all, namespace or no namespace..

Am I completely wrong-headed in searching for a link problem?

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

On Sun, 5 Dec 2004, Geoff Reidy wrote:

> Hi all,
>
> After latest cvs update I get a make install error. Make completed ok.
>

It seems I forgot to put the add the practice/ race/ qualifying/
directories to CVS. Checked that for the rest of the drivers and now
should all be OK.

> Regards,
> Geoff
>
> make[5]: Leaving directory
> `/usr/local/src/torcs-cvs/torcs/src/drivers/olethros/1/race'
>   /usr/bin/install -c -m 644 default.xml
> /usr/local/share/games/torcs/drivers/olethros/1/default.xml
>   /usr/bin/install -c -m 644 cg-nascar-rwd.rgb
> /usr/local/share/games/torcs/drivers/olethros/1/cg-nascar-rwd.rgb
> make[4]: Leaving directory
> `/usr/local/src/torcs-cvs/torcs/src/drivers/olethros/1'
> make[4]: Entering directory
> `/usr/local/src/torcs-cvs/torcs/src/drivers/olethros/2'
> make: *** practice: No such file or directory.  Stop.
> make: Entering an unknown directorymake: Leaving an unknown
> directorymake[4]: *** [installdirs] Error 1
> make[4]: Leaving directory
> `/usr/local/src/torcs-cvs/torcs/src/drivers/olethros/2'
> make[3]: *** [installdirs] Error 1
> make[3]: Leaving directory
> `/usr/local/src/torcs-cvs/torcs/src/drivers/olethros'
> make[2]: *** [installdirs] Error 1
> make[2]: Leaving directory `/usr/local/src/torcs-cvs/torcs/src/drivers'
> make[1]: *** [installdirs] Error 1
> make[1]: Leaving directory `/usr/local/src/torcs-cvs/torcs/src'
> make: *** [installdirs] Error 1
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Torcs-devel mailing list
> Tor...@li...
> https://lists.sourceforge.net/lists/listinfo/torcs-devel
>

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

Hi all,

After latest cvs update I get a make install error. Make completed ok.

Regards,
Geoff

make[5]: Leaving directory 
`/usr/local/src/torcs-cvs/torcs/src/drivers/olethros/1/race'
  /usr/bin/install -c -m 644 default.xml 
/usr/local/share/games/torcs/drivers/olethros/1/default.xml
  /usr/bin/install -c -m 644 cg-nascar-rwd.rgb 
/usr/local/share/games/torcs/drivers/olethros/1/cg-nascar-rwd.rgb
make[4]: Leaving directory 
`/usr/local/src/torcs-cvs/torcs/src/drivers/olethros/1'
make[4]: Entering directory 
`/usr/local/src/torcs-cvs/torcs/src/drivers/olethros/2'
make: *** practice: No such file or directory.  Stop.
make: Entering an unknown directorymake: Leaving an unknown 
directorymake[4]: *** [installdirs] Error 1
make[4]: Leaving directory 
`/usr/local/src/torcs-cvs/torcs/src/drivers/olethros/2'
make[3]: *** [installdirs] Error 1
make[3]: Leaving directory 
`/usr/local/src/torcs-cvs/torcs/src/drivers/olethros'
make[2]: *** [installdirs] Error 1
make[2]: Leaving directory `/usr/local/src/torcs-cvs/torcs/src/drivers'
make[1]: *** [installdirs] Error 1
make[1]: Leaving directory `/usr/local/src/torcs-cvs/torcs/src'
make: *** [installdirs] Error 1

I just update the bot with some bug fixes, slightly better
behaviour and more documentation.

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

I saw Bernhard's source comment on changing a static class instance
into a real singleton pattern and so I have taken the design from
alexandrescu's ''modern C++ design'' which implements a set of
policies that help you compose different types of singletons (meyers,
phoenix and singletons with longevity with or without mutex locks).

You can get the code from
http://www.idiap.ch/~dimitrak/downloads/singleton.tar.gz

It has not been tested extensively, however.

Alternatively you could take a look at the Alexandrescu's Loki
library, though I am not sure how easy it will be to extract the
singleton stuff from the rest of the library.

I also put a simple (non-generic programming-based) singleton on the
latest version my driver module - dunno if that's what Bernhard had in
mind to use.

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

My track howto is incomplete. In particular, I have not found a away
to combine both shadows and bump-maps. I tried a couple of different
procedures for combining them with accc but so far the result was just
crashes.

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