Hi Ted
The 1.2.4 installer is quite outdated, it requires Rosetta to run (was
available in Mac OS X up to 10.6 IIRC, see
http://en.wikipedia.org/wiki/Rosetta_%28software%29.
I do not know about a newer installer, but you can build an 1.3.1 or
1.3.6 form sources if you know xcode:
- 1.3.1: Get the 1.3.1 Mac OS X patch from
http://github.com/camillol/MacTorcs to 1.3.1 and the TORCS 1.3.1 all in
one source package, follow the instructions of the patch
- 1.3.6: Follow this post here:
http://www.berniw.org/trb/forum/showthread.php?topicid=3968, have a look
at the 5th and the following posts
Kind regards
Bernhard
On 02/21/2015 05:59 PM, Theodore Murphy wrote:
> Hello all,
> I have never used a mailing list before, so here goes. I found this interesting open source game, but after extraction of the .gz file, and running of the .dmg installer, the program refuses to open at all. I am going to try running on my MacBook Pro, which is running OS X 6. Short of that, I think I'll try some distro of Linux, but I'm not sure how the mileage is for Linux on Apple machines?
> Thanks for any help from anyone.
>
> -Ted
> Sent from my iPhone
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Torcs-users mailing list
> Torcs-users@...
> https://lists.sourceforge.net/lists/listinfo/torcs-users
>

Hello all,
I have never used a mailing list before, so here goes. I found this interesting open source game, but after extraction of the .gz file, and running of the .dmg installer, the program refuses to open at all. I am going to try running on my MacBook Pro, which is running OS X 6. Short of that, I think I'll try some distro of Linux, but I'm not sure how the mileage is for Linux on Apple machines?
Thanks for any help from anyone.
-Ted
Sent from my iPhone

Hi
> Thanks for the help. Unfortunately, the old buildings seem to be beyond
> repair. So one step forward, several steps back. Second, the use of
> single-sided surfaces produces weird results, namely a building
> wall/roof/door (also fences and walls of different kinds) that's
> single-sided looks completely transparent from the other side, apparent
> in the F4 view in the game when I check the created building(s). That's
Yes, that is called back-face culling, IIRC I mention that in the car
creation video. It is very easy to handle:
- First model the object from outside (e.g. car rooftop in the car tutorial)
- Then copy the object and flip the normals
This has the advantage that the front and back sides are correctly lit,
if you use 2 sided surfaces the lighting is just right for one side,
because the lighting is just calculated once per vertex.
A second advantage relevant for some cases is the the front and backside
can have different textures assigned.
The disadvantage is of course the higher load due to duplicated geometry.
Important (maybe you are aware of it, just to make sure): If you do not
take special care during modeling, you have to adjust the surface
normals at some point (such that they all point to the outside for a
closed shape). In ac3d (and all other modeling tools) you can switch on
the visualization of the normals. If you work with single sided surfaces
form the beginning you immediately see when a surface is the wrong way
round, because it is simply transparent.
> of course unwanted, and forces me to switch them back to a two-sided
> surface. I don't know what that's all about. So far, the two-sided
> buildings, the dull, uninspiring boxes I've added, haven't had the same
> light problems as the earlier experiments. I guess I have to steer clear
> of those and stick with basic structures for now, much as it clashes
> with my mindset.
Don't give up, if you master to get a correct lit/shaded box you know
enough to master more complex objects.
> About the tutorial pages, I wonder if the elevation and relief files are
> absolutely necessary for a functional track. I remember reading about
No, they just help controlling the generation of the terrain. Relief
files allow you to preset contour lines for the terrain (so the mesh
generator generates the mesh using the points on the contour lines).
Elevation files help you to control the height of the terrain.
> those a long time ago, but haven't created any for the previous versions
> (both .ac and .acc), and haven't noticed any graphical issues there. The
Yes, they are not required, they just help to get closer to the desired
terrain right out of the generator without manual modeling.
> whole shadow map business went over my head. For my tracks, I've either
> had a simple blank image (some hue of white like #f4f4f4) or used the
> track outline as the basis of the shadow map, tried and erred in the
> shadow2.rgb file until the track's/shadow's position has been accurate.
> Understandably, that might not be particularly realistic, but when all
> else fails, there's only experimentation.
Yes, that is tricky, in the track tutorial by Vicente he explains how to
do it with Blender:
http://www.berniw.org/aboutme/publications/build_your_trocs_track_in_20_minutes_v2.odt
I explain it here how I do it with povray:
http://www.berniw.org/trb/forum/showthread.php?topicid=163
> There will be instructions on the website for any volunteers who know
> their way around these objects (and obstacles). Useful contributions
> would probably speed up this whole development process, but I'm not
An open license like the GPL/FAL would make it easier to work together
and to share, but of course this is your choice. I think free licenses
are really beneficial at the point where the original author loses the
interest, so other people can continue the work even if the original
author cannot be contacted anymore.
> holding my breath (It's the instant gratification age after all). The
> (dozens of) tracks themselves are diverse, raceable, interesting, often
> quirky and difficult enough. Who knows when they're ready for release.
Kind regards
Bernhard

Thanks for the help. Unfortunately, the old buildings seem to be beyond
repair. So one step forward, several steps back. Second, the use of
single-sided surfaces produces weird results, namely a building
wall/roof/door (also fences and walls of different kinds) that's
single-sided looks completely transparent from the other side, apparent
in the F4 view in the game when I check the created building(s). That's
of course unwanted, and forces me to switch them back to a two-sided
surface. I don't know what that's all about. So far, the two-sided
buildings, the dull, uninspiring boxes I've added, haven't had the same
light problems as the earlier experiments. I guess I have to steer clear
of those and stick with basic structures for now, much as it clashes
with my mindset.
About the tutorial pages, I wonder if the elevation and relief files are
absolutely necessary for a functional track. I remember reading about
those a long time ago, but haven't created any for the previous versions
(both .ac and .acc), and haven't noticed any graphical issues there. The
whole shadow map business went over my head. For my tracks, I've either
had a simple blank image (some hue of white like #f4f4f4) or used the
track outline as the basis of the shadow map, tried and erred in the
shadow2.rgb file until the track's/shadow's position has been accurate.
Understandably, that might not be particularly realistic, but when all
else fails, there's only experimentation.
There will be instructions on the website for any volunteers who know
their way around these objects (and obstacles). Useful contributions
would probably speed up this whole development process, but I'm not
holding my breath (It's the instant gratification age after all). The
(dozens of) tracks themselves are diverse, raceable, interesting, often
quirky and difficult enough. Who knows when they're ready for release.
Sincerely,
stockroom staff
ST Creative Designs
http://stcreativedesigns.fhero.net/

Hi
> This is a recurring problem that seems to have ruined the already
> onerous task of adding 3D objects to tracks. It would be great(ly
> appreciated) if somebody could suggest a viable solution, so I wouldn't
> have to bulldoze all the gazillion buildings created or pull the plug on
> this fruitless exercise.
>
> Here's an example screenshot from one of the tracks:
> http://stcreativedesigns.fhero.net/img/stcd-build00.png
Ok, first take a deep breath, as you can see from several examples, it
is possible to add objects which get lit properly, and I try to figure
this out together with you.
> The red arrow points at the weird discoloration/brightness that appears
> on just about every building created on lots of tracks. Does anybody
> know what's causing that, and is there anything to fix? That happens
> with buildings of various shapes and sizes. As a hopeless experimenter,
> it's difficult to say what went wrong there. I tried "Optimize vertices"
> and "Optimize surfaces" for the whole building (group), no change. I
> also thought it might be caused by the stupid crease 45.000000 lines
> that always get added to the .ac file after you edit the track, but now
> that I went and removed all of that extra junk from one track.ac file,
> it turned out the same graphical BS (as seen in the example image)
> remained there. I've edited the various light settings (amb, emi, spec,
> shi) at the top of the .ac file and returned to the track, but nothing's
> worked.
Basically a lot can go wrong when doing modeling, before we look into
your case some general infos/posts:
- Car modeling tutorial, basically the splitting and lighting part
applies for all objects in TORCS, see http://youtu.be/JFaWNe8jcMc
- http://www.berniw.org/trb/forum/showthread.php?topicid=163
-
http://torcs.cvs.sourceforge.net/viewvc/torcs/torcs/torcs/doc/tutorials/track/index.html?revision=1.2&pathrev=r1-3-1
For TORCS you have to:
- Set ac3d crease angle to 180 in the preferences (then the rendering in
ac3d is as close to the rendering in TORCS as it can get)
- Use only one material
- Take care when extruding that you are not leaving "inner surfaces"
behind (confuses the lighting/shading)
- Use only single sided smooth shaded surfaces
- And some more, have a look into the car tutorial linked above
Ok, now lets have a look into your screenshot, it looks very confusing,
I could imagine that it is a combination of weird surface subdivision,
wrong surface types and normals and "inner leftovers" and broken object
organization.
> So now, after these predictable failures, I'm looking for useful advice
> from more experienced 3D manipulators. This is not a graphics
> card/graphics settings issue: tracks without those 3D objects added
> don't exhibit that discoloration. Section "Graphic" in the track.xml
> file shouldn't be at fault, either: editing the light values there made
> no difference. And this only affects buildings, not for example
> grandstands or billboards.
>
> I wonder if the surface manipulation of a building could somehow have
> messed it up: selecting a surface/surfaces, often using "Divide" to get
> smaller areas of the surface, then "Cut away object" (to be able to add
> a door or window), then naming that object and choosing some specific
Yes, that is the way to go.
> texture (mainly door or window). But if this method produces those
> graphical anomalies, how are you supposed to add doors and windows to a
> building? A separate rectangle placed in front of another object, like a
> door before a building, often caused ridiculous and disturbing
> flickering. Furthermore, there are buildings on these tracks with doors
Yes, thats Z-fighting, you should not do this. Depending on the viewing
distance it can be appropriate in some cases to just paint the door on
the texture though.
> and windows added like described, and they, for some reason, don't have
> that bright discoloration. So confusing, so frustrating, so tiresome to
> bang your head against that wall.
>
> More relevant info can be provided if needed. The .ac files, however,
> won't be distributed.
Hmm, too bad, so you will never release the tracks in any form (acc is
just a combination of multiple ac files, it is not rocket science to
convert it back)?
Kind regards
Bernhard

This is a recurring problem that seems to have ruined the already
onerous task of adding 3D objects to tracks. It would be great(ly
appreciated) if somebody could suggest a viable solution, so I wouldn't
have to bulldoze all the gazillion buildings created or pull the plug on
this fruitless exercise.
Here's an example screenshot from one of the tracks:
http://stcreativedesigns.fhero.net/img/stcd-build00.png
The red arrow points at the weird discoloration/brightness that appears
on just about every building created on lots of tracks. Does anybody
know what's causing that, and is there anything to fix? That happens
with buildings of various shapes and sizes. As a hopeless experimenter,
it's difficult to say what went wrong there. I tried "Optimize vertices"
and "Optimize surfaces" for the whole building (group), no change. I
also thought it might be caused by the stupid crease 45.000000 lines
that always get added to the .ac file after you edit the track, but now
that I went and removed all of that extra junk from one track.ac file,
it turned out the same graphical BS (as seen in the example image)
remained there. I've edited the various light settings (amb, emi, spec,
shi) at the top of the .ac file and returned to the track, but nothing's
worked.
So now, after these predictable failures, I'm looking for useful advice
from more experienced 3D manipulators. This is not a graphics
card/graphics settings issue: tracks without those 3D objects added
don't exhibit that discoloration. Section "Graphic" in the track.xml
file shouldn't be at fault, either: editing the light values there made
no difference. And this only affects buildings, not for example
grandstands or billboards.
I wonder if the surface manipulation of a building could somehow have
messed it up: selecting a surface/surfaces, often using "Divide" to get
smaller areas of the surface, then "Cut away object" (to be able to add
a door or window), then naming that object and choosing some specific
texture (mainly door or window). But if this method produces those
graphical anomalies, how are you supposed to add doors and windows to a
building? A separate rectangle placed in front of another object, like a
door before a building, often caused ridiculous and disturbing
flickering. Furthermore, there are buildings on these tracks with doors
and windows added like described, and they, for some reason, don't have
that bright discoloration. So confusing, so frustrating, so tiresome to
bang your head against that wall.
More relevant info can be provided if needed. The .ac files, however,
won't be distributed.
Sincerely,
stockroom staff
ST Creative Designs
http://stcreativedesigns.fhero.net/

----- Bernhard Wymann wrote:
> Hi David
>
> You might looking for adjusting the inertia of the car, the cg hight,
> roll centers and the tire properties. I created a video regarding this
> some time ago, maybe you already know it:
> http://youtu.be/H75kZ37j9o4
>
> Kind regards
>
> Bernhard
>
Thank you. The video was very informative; I viewed all of it.
I recommend these videos for anyone who wants to understand
TORCS code and functionality. These videos are the
"TORCS Reference Manual."
Maybe the 'next thing' in 'open source' is 'theory of operation videos'!
Sincerely,
David Savinkoff

Hi David
You might looking for adjusting the inertia of the car, the cg hight,
roll centers and the tire properties. I created a video regarding this
some time ago, maybe you already know it:
http://youtu.be/H75kZ37j9o4
Kind regards
Bernhard
On 01/01/2015 10:06 PM, David Savinkoff wrote:
> Hi Bernhard,
>
> After seeing your explanation, I agree with you. However
> I do have some opinions.
>
> I submitted the patch because, at first glance, it looked
> like x and y may have been swapped... and the car
> actually drives better (especially drifting, and dirt tracks).
>
> I attempted to make sense of my patch. Here are some
> possibilities:
>
> * Swapping the x and y axis may subtract some rotation from
> car and make it more driveable ( what a hack!).
>
> * I changed the code to the following, and the car still
> drives OK.
> car->corner[i].vel.ax = 0.0; //- car->DynGC.vel.az * y;
> car->corner[i].vel.ay = 0.0; //car->DynGC.vel.az * x;
>
> When I drift torcs, it feels like too much energy goes into
> rotating the car, and not enough into going forward. As if
> the bumper is plowing the ground. I actually had an old
> Cadillac that would plow the sawdust I drove in. When the
> pile got over the bumper, the car would simply dig in
> (it could not rotate).
>
> If you could point me to the right part of torcs, maybe I'll
> find what I'm looking for. Thanks.
>
> Sincerely,
> David Savinkoff
>
> ----- Bernhard Wymann wrote:
>> Hi David
>>
>> I reviewed the suggested change, but I think it is wrong (I think the
>> original code is right).
>>
>> Simply assume a "1-d car" (a simple line from top), with one corner at
>> (x,y) as (1,0) and an angular velocity around the z-Axis := vz.
>>
>> So the speed of the corner relative to the rotation center is in y
>> direction r*vz, where r=x=1. I cannot see a flaw in this.
>>
>> With your change you would get a movement in x direction although the
>> radius in y direction is 0, that does not make any sense to me.
>>
>> Other thoughts, other opinions?
>>
>> Kind regards
>>
>> Bernhard
>>
>>
>> On 12/18/2014 02:31 AM, David Savinkoff wrote:
>>> Hi,
>>>
>>> TORCS was fueling my high velocity entertainment when road rage set in
>>> and I had to glare at the source code to calm down.
>>>
>>> I think I found a bug.
>>>
>>> The car drives much better now.
>>>
>>> Sincerely,
>>> David Savinkoff
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>>
>>>
>>>
>>> _______________________________________________
>>> Torcs-users mailing list
>>> Torcs-users@...
>>> https://lists.sourceforge.net/lists/listinfo/torcs-users
>>>
>>
>
>

Hi Bernhard,
After seeing your explanation, I agree with you. However
I do have some opinions.
I submitted the patch because, at first glance, it looked
like x and y may have been swapped... and the car
actually drives better (especially drifting, and dirt tracks).
I attempted to make sense of my patch. Here are some
possibilities:
* Swapping the x and y axis may subtract some rotation from
car and make it more driveable ( what a hack!).
* I changed the code to the following, and the car still
drives OK.
car->corner[i].vel.ax = 0.0; //- car->DynGC.vel.az * y;
car->corner[i].vel.ay = 0.0; //car->DynGC.vel.az * x;
When I drift torcs, it feels like too much energy goes into
rotating the car, and not enough into going forward. As if
the bumper is plowing the ground. I actually had an old
Cadillac that would plow the sawdust I drove in. When the
pile got over the bumper, the car would simply dig in
(it could not rotate).
If you could point me to the right part of torcs, maybe I'll
find what I'm looking for. Thanks.
Sincerely,
David Savinkoff
----- Bernhard Wymann wrote:
> Hi David
>
> I reviewed the suggested change, but I think it is wrong (I think the
> original code is right).
>
> Simply assume a "1-d car" (a simple line from top), with one corner at
> (x,y) as (1,0) and an angular velocity around the z-Axis := vz.
>
> So the speed of the corner relative to the rotation center is in y
> direction r*vz, where r=x=1. I cannot see a flaw in this.
>
> With your change you would get a movement in x direction although the
> radius in y direction is 0, that does not make any sense to me.
>
> Other thoughts, other opinions?
>
> Kind regards
>
> Bernhard
>
>
> On 12/18/2014 02:31 AM, David Savinkoff wrote:
> > Hi,
> >
> > TORCS was fueling my high velocity entertainment when road rage set in
> > and I had to glare at the source code to calm down.
> >
> > I think I found a bug.
> >
> > The car drives much better now.
> >
> > Sincerely,
> > David Savinkoff
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> > with Interactivity, Sharing, Native Excel Exports, App Integration & more
> > Get technology previously reserved for billion-dollar corporations, FREE
> > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> >
> >
> >
> > _______________________________________________
> > Torcs-users mailing list
> > Torcs-users@...
> > https://lists.sourceforge.net/lists/listinfo/torcs-users
> >
>

Hi David
I reviewed the suggested change, but I think it is wrong (I think the
original code is right).
Simply assume a "1-d car" (a simple line from top), with one corner at
(x,y) as (1,0) and an angular velocity around the z-Axis := vz.
So the speed of the corner relative to the rotation center is in y
direction r*vz, where r=x=1. I cannot see a flaw in this.
With your change you would get a movement in x direction although the
radius in y direction is 0, that does not make any sense to me.
Other thoughts, other opinions?
Kind regards
Bernhard
On 12/18/2014 02:31 AM, David Savinkoff wrote:
> Hi,
>
> TORCS was fueling my high velocity entertainment when road rage set in
> and I had to glare at the source code to calm down.
>
> I think I found a bug.
>
> The car drives much better now.
>
> Sincerely,
> David Savinkoff
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Torcs-users mailing list
> Torcs-users@...
> https://lists.sourceforge.net/lists/listinfo/torcs-users
>

Hi,
TORCS was fueling my high velocity entertainment when road rage set in
and I had to glare at the source code to calm down.
I think I found a bug.
The car drives much better now.
Sincerely,
David Savinkoff

Hello Joey
Yes. As you are speaking from Makefiles I guess you are working in
GUN/Linux. An example for using an additional lib in a robot is
"olethros", have a look at this line in its Makefile:
LIBS = -L${EXPORTBASE}/lib -llearning
From gcc man page (read original page for full description):
-Ldir
Add directory dir to the list of directories to be searched for -l.
-l library
Search the library named library when linking. (The second alternative
with the library as a separate argument is only for POSIX compliance and
is not recommended.)
So basically you can link any library with this. If you have the library
only in binary form it might be pretty tricky though, because the
alignment and name mangling might differ (e.g. if the library was
complied using some other c++ compiler, or with different alignment
options).
So in the worst case you have pack the library in a wrapper or dock onto
it with an adapter or some other way, in the best case you can simply
link it. If you compile the library by yourself, you will be able to
simply link it.
Additionally you have eventually to take care about memory management,
if the library is in binary form only it might bring its own heap
manager, so it is important that you construct/destruct objects always
with the same heap manager.
Btw. there is a change which is not yet mentioned in the tutorial:
http://www.berniw.org/trb/forum/showthread.php?topicid=3508
Hope this helps
Bernhard
On 12/02/2014 08:28 AM, Joey Andres wrote:
> Hello,
>
> I just discovered Torcs and robotics and its giving me loads of ideas. I
> just read Berni's tutorial and already started building my AI agent. I
> have a huge c++ library of AI that contains all kinds of learning
> algorithms and data structures and would like to integrate these in
> Torcs. I'm wondering, where in Makefile do I place these libraries and
> headers? Also, is it possible to compile these with -std=c++14? I'd be
> very glad if someone can give me information with these stuff. I've
> googled all possible things with respect to this topic and can't find any.
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Torcs-users mailing list
> Torcs-users@...
> https://lists.sourceforge.net/lists/listinfo/torcs-users
>

Hello,
I just discovered Torcs and robotics and its giving me loads of ideas. I
just read Berni's tutorial and already started building my AI agent. I
have a huge c++ library of AI that contains all kinds of learning
algorithms and data structures and would like to integrate these in
Torcs. I'm wondering, where in Makefile do I place these libraries and
headers? Also, is it possible to compile these with -std=c++14? I'd be
very glad if someone can give me information with these stuff. I've
googled all possible things with respect to this topic and can't find any.

Hi Carlos
> I found on Internet that i've got to edit my .bashrc file (that it's a
> hidden file),and when i open it's empty! That's normal?
It depends on the distro and how you created your user account, it can
be empty or not exist at all. I do not know if this is "normal" for your
case, but I would not worry about it.
I have my TORCS sources in ~/torcs_src/torcs/torcs, my settings are:
# TORCS settings
export TORCS_BASE=$HOME/torcs_src/torcs/torcs
export MAKE_DEFAULT=$TORCS_BASE/Make-default.mk
I install the build usually as well in home, my configure statement:
./configure --prefix=/home/berni/torcs_bin
Kind regards
Bernhard

Hi Carlos
I think this is an easy one: Some environment is set by the top level
makefile, if you just call you "local makefile" (which makes perfectly
sense) you need to set 2 environment variables, see here:
http://www.berniw.org/tutorials/robot/tutorial.html
For you just those are important (adapt it to your version and directory):
export TORCS_BASE=/usr/src/torcs/torcs-1.2.4
export MAKE_DEFAULT=$TORCS_BASE/Make-default.mk
Kind regards
Bernhard
On 09/26/2014 12:29 PM, Carlos Otero wrote:
> Good morning.
>
> I've got a problema with the make command when i want to set my car into
> the game.
> I'm in the folder:
>
> reaper@...:~/TORCS/torcs-1.3.6/src/drivers/BI0006-BI0038$
>
> And the elements in the folders are:
>
> BI0006-BI0038.cpp BI0006-BI0038.dsp logo.rgb pw-evoviwrc.rgb
> BI0006-BI0038.def BI0006-BI0038.xml Makefile
>
> So, when i want to compile with make or make install i've got this error.
>
> make: *** no targets. Stop.
> make *** no rule to make target. Stop.
>
> I'm using Ubuntu 14.04 TLS with TORCS' version 1.3.6.
>
> I've installed all the components and programs to run the game,also it
> works perfectly! But i don't know how to solve the problem. Maybe,it
> could be the C++ compiler?
>
> Thank your for your time and your attention.
>
> Reaper.
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Torcs-users mailing list
> Torcs-users@...
> https://lists.sourceforge.net/lists/listinfo/torcs-users
>

Good morning.
I've got a problema with the make command when i want to set my car into the game.
I'm in the folder:
reaper@...:~/TORCS/torcs-1.3.6/src/drivers/BI0006-BI0038$
And the elements in the folders are:
BI0006-BI0038.cpp BI0006-BI0038.dsp logo.rgb pw-evoviwrc.rgb
BI0006-BI0038.def BI0006-BI0038.xml Makefile
So, when i want to compile with make or make install i've got this error.
make: *** no targets. Stop.
make *** no rule to make target. Stop.
I'm using Ubuntu 14.04 TLS with TORCS' version 1.3.6.
I've installed all the components and programs to run the game,also it works perfectly! But i don't know how to solve the problem. Maybe,it could be the C++ compiler?
Thank your for your time and your attention.
Reaper.

I do not track this, so I cannot tell. But usually it is not a major
issue to install TORCS, just ask if you need help.
Kind regards
Bernhard
On 08/27/2014 05:34 PM, Rafael Hrasko wrote:
> Does anyone have a prepared distribution with TORCS installed? It would
> help us a ton
>
> Thanks for your attention
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/
>
>
>
> _______________________________________________
> Torcs-users mailing list
> Torcs-users@...
> https://lists.sourceforge.net/lists/listinfo/torcs-users
>