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

On Thu, May 23, 2013, at 06:25 AM, Bernhard Wymann wrote:
...

> Ok, I cannot see an option which helps you without using a 3d-modeler 
> tool. But possible "hacks" would be:
> - using -B with an outside line far below the horizon: but for this you 
> require a 3d-modeler to setup the 3d model of the outside line, I guess 
> this is not what you are looking for
> - Using a height map which puts the outside terrain on a very low level, 
> such that you cannot see it with the normal cameras
> - Hacking trackgen: in src/tools/trackgen/easymesh.cpp, around line 
> 2270, look for exterior/interior, just comment out the undesired part
> 
> >   shows the problem area in yellow). Are there any other tricks to help
> > me get rid of the unwanted terrain so this track wouldn't look
> > absolutely ridiculous? Please don't point to the masterpiece also known
> > as Blender. In my desperation, I tried opening the -msh.ac file there
> 
> You can use ac3d, but this is not free...
> 
...

Nothing worked here. I went to the /src/tools/trackgen/easymesh.cpp file
and found line 2270 with those interior/exterior variables, and then
tried to comment out the line, first with # and then with /*  */ , saved
and ran "make", only to read another error that stopped the entire
process. Without any coding skills, I can't know what went wrong there.
(Clarification: on the first failed attempt, I used # on that line; on
the second, /* */)

I then undid those changes and tried manipulating the "Terrain
Generation" section in the track.xml, using all sorts of negative values
for "border height" and "maximum altitude" and "minimum altitude" and
kept re-creating the track with the terrain, but it always appeared on
the right side (outside) of the track, and in F7 view, you could see the
terrain being ridiculously thick, as a result of those negative values
like -10000000000. Many times trackgen also crashed, unsatisfied with
the values I tried in that section. So no progress on this front, and I
haven't had a chance to try any 3D model manipulation yet. 

st
http://stdesigns.orgfree.com/

-- 
http://www.fastmail.fm - One of many happy users:
  http://www.fastmail.fm/help/overview_quotes.html

On Thu, May 23, 2013, at 06:09 AM, Bernhard Wymann wrote:
...
> Lets see...
> find . -name "*.cpp" -exec grep -H -i cursor {} \;
> 
> -> so src/libs/tgfclient/gui.cpp looks interesting, maybe
> "GfuiMouseShow"?
> 
> Then google:
> https://www.google.com/search?q=glut+mouse+cursor+positioning
> 
> -> glutWarpPointer could do the trick
> 
> Looking for this in TORCS:
> find . -name "*.cpp" -exec grep -H -i Pointer {} \;
> 
> -> src/libs/tgfclient/gui.cpp -> glutWarpPointer, GfuiMouseSetPos, this 
> could be your thing:-)
> 
> Maybe you need to dig a tad further, but I guess this is a major hint 
> for your solution, the next step would be to look up the places where
> GfuiMouseSetPos is used.
> 
> But as I pointed out above, I think the main flaw is that you restart 
> TORCS at all, if you just edit an existing track restarting the game 
> session should relaod the track, not even reselection of the track 
> should be required;-)
> 
> Keep us informed about your solution (hacked TORCS or adopted workflow, 
> whatever).
> 
> Best regards
> 
> Bernhard

I found the GfuiMouseSetPos and glutWarpPointer (around l. 390) in
/src/libs/tgfclient/gui.cpp and tried changing it, replacing (x, y) with
many number combinations like (750, 750), (0, 0) and (1024, 768) that
should have pushed the pointer off the middle of the screen, but in
vain. Obviously, after saving the file and running "make" I pasted the
changed library from that source folder to the torcs library folder and
only then ran torcs, but the desktop pointer promptly popped up in the
middle of the screen, crashing the party with impunity. If I added
numbers separated by a comma elsewhere on that line, after the brackets
or the semi-colon, "make" failed and spewed out an error message (which
I didn't copy but which had something to do with operands on either side
of commas not taking effect).

So then this amateur hack had to improvise. I canceled those changes and
moved on, somewhere between lines 220-245, where I saw 

GfuiScreen -> mouseAllowed = 1;

and

GfuiMouseHW = 1;

both of which I changed to 0, saved the file, then ran "make" and pasted
the library like described above. Now the desktop pointer still appeared
in the initial torcs logo screen, but vanished before the game main
screen, so I could then proceed to the track without taking my hands off
the keyboard. That's good enough for me. If I touch the mouse afterward,
a bluish pointer will appear, so it's not like mouse is completely
disabled after those changes. 

As to why I have to quit and re-start the game after any editing of the
track.xml and re-creating the track with trackgen, it would be
impossible or at least incredibly complicated to run the game itself (in
the terminal, with the -s option) in full-screen mode (the only way for
my poor video card) and then use the same terminal and my text editor
for track editing. It's not like I can escape from the game by ALT+TAB
or anything in full-screen mode. 

Thanks for pointing me in the right direction.

st
http://stdesigns.orgfree.com/

-- 
http://www.fastmail.fm - A fast, anti-spam email service.

On Thu, May 23, 2013, at 07:43 AM, Bernhard Wymann wrote:
... 
> Ok, when I find the time I will have a look, but beware, there has even 
> been formula 1 races with just 4 cars hitting the finish line, so in 
> racing it is pretty common that "***t happens". Same applies if you go 
> into an online lobby against human players (with other racing games of 
> course, TORCS is missing that)...
> 
> You can as well adjust the amount of "chaos" by the driver selection, if 
> you take "berniw" offsprings there should be not too much action...
> 

I know contact can't always be avoided, but the problem (one of them)
with these robots is their endless pushing which is totally unnecessary,
for example in turn 1 of a longer race (regardless of track type).
Obviously, no human driver in their right mind would initiate anything
there. In this game, that turn 1 riot is pretty much automatic. I start
my test races at the back of the field (20-25 cars usually), and there's
no point in joining that chaotic rush there because one of those brutes
will undoubtedly push me if I try to race "normally" or pass anybody,
and then some other rager will keep pounding till my car's totaled. If I
give them a 20-second head start, I might still catch some of them by
the end of lap 1.

 
> My experience/opinion with this differs, depending on you opponent 
> selection you can have a very "organized" race or a "chaotic" one, so 
> you have some choice (after discovering the characters of the bots).
> 
> At least for me as human driver it is pretty easy to stay out of trouble 
> in TORCS, compared to racing against other human drivers online with 
> other racing sims.
> 
> I agree with you that the robots could be more clever, they are 
> certainly not optimized for oval racing.
> 

But that happens on all tracks, including road courses, that blind
driving, smashing into cars even when there's room for passing (usually
there is). They have no restraint: they just force their way through
anybody, other robots or a human. That's what really irks me, and very
often ruins my race. And the presence of a human isn't necessary:
they'll exchange blows everywhere, bang into one another for no reason.
Just the other day, I ran one more test race for that as yet unreleased
road course (with the terrain problem), and the leader had a clear,
20-second lead when in the final turn, surrounded by a couple of lapped
cars, one of those brutes rams into the leader's car and sends it into
the pit wall on the front straight, and then comes another one and
bang-bang-bang, wants to drill a hole through the leader's car, sideways
and nose against the pit wall. 10,000 of damage in no time flat, and
race over for the leader, 150 m from the finish line. The raging
drummers flee the scene as usual.

...
> > 4. the inability of robots to drive smoothly (in a race, NOT on solo
> > runs), on straightaways and in turns. This leads to frequent incidents
> > when some idiot slams on the brakes all of a sudden, leaving a poor
> > human no time to react and swerve (obviously affects other robots too).
> 
> In the berniw offsprings this is the case, this is a relict from the 
> "200MHz CPU area", to save CPU cycles it does not reconsider some 
> decisions. When I am going to hack this, this will be improved.
> 
> > And as always happens upon contact, the human-controlled car is sent
> > into the wall or airborne while the slowpoke offender drives away
> > happily. This behavior is probably related to or a consequence of the
> 
> They probably just react better, if you run "semi pro" you have exactly 
> the same physics, with pro you have more damage and less grip. I do not 
> know how good you "drive", maybe some practise/analysis helps.
> 
> Usually sudden movements end up in problems, e.g. if you lift the 
> accelerator suddenly you can get heavy oversteer because of engine 
> braking, switching gears in the wrong moment can be pretty bad as well, 
> etcetc.
> 

It doesn't matter what I do because of their predictably unpredictable
driving. If I'm driving on the inside, they may smash into my car in
turn entry; if I stay on the outside, they're eager to hand out their
punishment right before exiting the turn; the center of the track in a
turn is a danger zone at all times. I don't know how to assess my
driving: being much faster than the robots, especially on short tracks
(where they can be 2-5 seconds slower than me despite driving lighter
trb1 cars), doesn't say much.

> > blindness and aggression described in 1. This kind of erratic driving
> > also puts the robots at a disadvantage: a human racer, if able to avoid
> > the aggressors and their endless repertoire of tricks, can often lap the
> > field or the majority of them unnaturally soon, not exactly the sign of
> > good racing.
> 
> Yes, this is the case, but this is not that important because of "our" 
> audience:
> 1. I think real race addicts/aces having steering whels etc. are by no 
> means running TORCS, or just out of curiosity, they are using iRacing, 
> LFS, or whatever, so this is not the intended audience.
> 2. People which have no budget and just want to have some fun, they are 
> downloading TORCS and enjoy some laps with the keyboard or maybe a 
> gamepad, but I suppose those not being fast drivers.
> 3. People using TORCS as base for their own research/whatever projects, 
> they can hack the things to make it fit their requirements.
> 
> So I agree that it could be better (e.g. in a future version there will 
> be rubberbanding implemented), but there are more important things to do 
> currently.

...

> > 6. the infuriating bulldoze-through-any-obstacle behavior that causes
> > nothing but trouble on the track. Why can't the robots back up and go
> > around an obstacle (stopped car) cleanly instead of forcing their way
> > through it? Is it totally inconceivable and impossible to change the
> 
> I explained this here:
> http://sourceforge.net/p/torcs/discussion/11281/thread/948d0e70/
> 

So a robot going in reverse OR avoiding the obstacle well in advance is
impossible, too complicated/time-consuming or completely irrelevant?
It's just that this very "feature" results in lots of wrecks, none of
which should happen, and depletes the field very dramatically. And for a
human, sometimes it's impossible to get away before one of those brutes
closes in and starts drumming away. My car's gone, my engine's cooking,
and unprintable words stream forth. 

> > 7. pit road failures:
 ...
> > in a longer race, never even turning onto pit road for fuel, instead
> > running out of it and crawling along the track, another recipe for
> > disaster and invitation to the rageaholic drummers. The pit road entry
> > point in the "Pits" section is usually far enough for the robots to be
> > able to get off the track in time and turn onto pit road, but for some
> > unknown reason, they don't even try to pit;
> 
> Maybe you have more drivers in the race than pits?

No, like I said, 20-25 cars in the field for me, and my tracks have more
pits (ovals usually with 43 or 44 like on real tracks, road courses with
30+ depending on front straight length and stuff). I don't remember on
which road courses this happens (it's been months since my last test
races there), but of ovals, you may check ac-speedway, dd-speedway,
is-speedway, mi-speedway, mt-speedway, ne-speedway, pp-speedway and
ri-speedway (or its night version) at least. Of those tracks, many have
a curving front stretch (which you told me a long time ago wasn't valid
for pits), but some like dd-speedway and ne-speedway have a front
straight, yet some robots fail to even enter the pits. To reiterate my
point, some robots do come to the pits for fuel on those tracks and
succeed in their pit stop too (I can't remember which ones or if there's
any consistency) while others just keep driving cluelessly until the
tank is empty. 
> 
> 
> Thanks for the input, here my opinion:
> The robots will need improvement, I agree on that, but my priority on 
> the last and as well on the upcoming releases is on TORCS itself. Three 
> planned steps will have a significant impact on the robots, that is why 
> I first want to complete those before adopting the robots. These are:
> 1. Car setup can be changed in the pit under certain conditions
> 2. More racing rules (pace car, etc.)
> 3. Split/Join/Crossing track segments (for city like scenarios in 
> research, but as "side effect" you can do then as well pit lanes on a 
> separate path, maybe ROC like scenarios or track variants).
> 
> Those have a big impact on the bots, so I basically sacrifice robot 
> development currently in favour of IMO more important things.
> 
> Btw. if you want to try other bots you can get them from the TRB events, 
> e.g:
> http://www.berniw.org/trb/events/event_view.php?vieweventid=17
> 
> Beware, for 1.3.4 you need to adopt them:
> http://www.berniw.org/trb/forum/showthread.php?topicid=3508
> 

Okay, I have to check that sometime later. 


> A final thought, about "Now the truth is out there": You should think 
> about if there something like truth outside a mathematical context even 
> exists, because usually the things selled as truth are just point of 
> views/opinions, or even worse beliefs/paradigms. So depending on what 
> you accept as facts and how you weight it, you will come to different 
> conclusions;-)
> 
> And if Einstein is right (nobody could falsify so far the theory of 
> relativity) there does not even exist a globally observable reality, so 
> even in physics your point of view matters regarding what and when you 
> see something;-)
> 
> Best regards
> 
> Bernhard


I know that's my interpretation (the phrase was supposed to be catchy
and semi-amusing after reading through all my aches and pains), but
that's why I encouraged everybody "out there" to run test races (which I
always run several times before any track release), so it's not just
some stranger's word on some mailing list. And it's not like I have any
interest in stirring the pot or trolling, let alone time for such
frivolities. 

Yours truly, (pun intended if accepted)
st

-- 
http://www.fastmail.fm - mmm... Fastmail...

Hi

I guess you need at least to extract the car package with your desired 
car such that it appears under this path or to edit the script. I guess 
nobody hit this problem so far, because people usually start from the 
"all-in-one" package or took the robotgen script from the tutorial 
(which does not work anymore for 1.3.4).

If you look at the robot tutorial, I provide there a custom "robotgen" 
script which fits the paths of the tutorial, but the robotgen script in 
the CVS assumes that everything is there (in the "source").

So you have 2 choices:
- Extract the data in the place robotgen expects it or
- Quickly edit robotgen to fit your installation path

I would just edit robotgen to fit your path, just replace "grep category 
data/cars/models..." with "grep category /fullpath/data/cars/models...", 
where fullpath is the location of the stuff on your system.

Best regards

Bernhard

On 05/24/2013 09:46 AM, Michael Sieben wrote:
> Hi Bernhard,
>
> i run the script from the $TORCS_BASE  directory.
>
> the problem seems to be this:
>
>
> $ bash -x robotgen -n "mcc1" -a "McCriddle" -c "car5-trb1" --gpl
> *snip*
> ++ grep category data/cars/models/car5-trb1/car5-trb1.xml
> grep: data/cars/models/car5-trb1/car5-trb1.xml: Datei oder Verzeichnis
> nicht gefunden
> *snip*
>
>
> but i have no data/..... dirs under my $TORCS_BASE
>
> should i extract any more than the *-src-* - Archives to the $TORCS_BASE
> directory ?
>
> here are the first 2 levels of dirs:
>
> export/drivers/
> export/include/
> export/lib/
> export/modules/
> src/doc/
> src/drivers/
> src/interfaces/
> src/libs/
> src/linux/
> src/modules/
> src/raceman/
> src/tools/
> src/windows/
>
>
> kind regards
> McCriddle
>
>
>
>
>
>
>
> 2013/5/24 Bernhard Wymann <be...@bl... <mailto:be...@bl...>>
>
>     Hi McCriddle
>
>     Did you put it in the same place like the other script, I guess you
>     just run it from the wrong place, do the paths relative to the
>     script exist (here your command works flawlessly)? Does the category
>     in the car5-trb1 directory exist (in the original it does, maybe you
>     have modified it)?
>
>     berni@wytec001:~/torcs_src/__torcs/torcs> ./robotgen -n "mcc1" -a
>     "McCriddle" -c "car5-trb1" --gpl
>     Generation of robot mcc1 author McCriddle
>     Copying car5-trb1.rgb ... and car5-trb1.xcf ... done
>     Copying logo.rgb ... done
>     Generating src/drivers/mcc1/Makefile ... done
>     Generating src/drivers/mcc1/mcc1.xml ... done
>     Generating src/drivers/mcc1/mcc1.cpp ... done
>     Generating src/drivers/mcc1/mcc1.def ... done
>     Generating src/drivers/mcc1/mcc1.dsp ... done
>
>     Here you can see how to execute a script verbose:
>     http://tldp.org/LDP/Bash-__Beginners-Guide/html/sect_02___03.html
>     <http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_03.html>
>
>     Best regards
>
>     Bernhard
>
>
>     On 05/23/2013 04:27 PM, Michael Sieben wrote:
>
>         Hi Bernhard,
>
>         i downloaded the robotgen you linked, but now i get this:
>
>         ./robotgen -n "mcc1" -a "McCriddle" -c "car5-trb1" --gpl
>         grep: data/cars/models/car5-trb1/__car5-trb1.xml: Datei oder
>         Verzeichnis
>         nicht gefunden
>         usage: robotgen -n <name> -a <author> -c <car> [-d description]
>         [--gpl]
>         linadmin@svr110:~/torcs-1.3.4$ torcs -s
>         Visual Properties Report
>         ------------------------
>         Compatibility mode, properties unknown.
>         linadmin@svr110:~/torcs-1.3.4$ ./robotgen -n "mcc1" -a
>         "McCriddle" -c
>         "car5-trb1" --gpl
>         grep: data/cars/models/car5-trb1/__car5-trb1.xml: Datei oder
>         Verzeichnis
>         nicht gefunden
>         usage: robotgen -n <name> -a <author> -c <car> [-d description]
>         [--gpl]
>
>
>         The "Configure Race" now works fine, after i deleted my
>         generated robot
>         from /usr/local/lib/... and /usr/local/share/....
>
>         kind regards
>         McCriddle
>
>
>
>         2013/5/23 Bernhard Wymann <be...@bl...
>         <mailto:be...@bl...> <mailto:be...@bl...
>         <mailto:be...@bl...>>>
>
>
>              Hi McCriddle
>
>              The ultimate reason for this is probable a fixed memory leak in
>              1.3.4. I the CVS you can find a fixed robotgen script:
>         http://torcs.cvs.sourceforge.____net/viewvc/torcs/torcs/torcs/____robotgen?revision=1.4.2.1&____view=markup&pathrev=r1-3-1
>
>
>         <http://torcs.cvs.sourceforge.__net/viewvc/torcs/torcs/torcs/__robotgen?revision=1.4.2.1&__view=markup&pathrev=r1-3-1
>         <http://torcs.cvs.sourceforge.net/viewvc/torcs/torcs/torcs/robotgen?revision=1.4.2.1&view=markup&pathrev=r1-3-1>>
>
>              And have a look at this, this is likely the cause:
>         http://www.berniw.org/trb/____forum/showthread.php?topicid=____3508
>         <http://www.berniw.org/trb/__forum/showthread.php?topicid=__3508>
>
>
>         <http://www.berniw.org/trb/__forum/showthread.php?topicid=__3508
>         <http://www.berniw.org/trb/forum/showthread.php?topicid=3508>>
>
>              Let us know if this helped, usually the solution of such
>         stuff is
>              pretty easy, so keep going.
>
>              Best regards
>
>              Bernhard
>
>
>
>              On 05/23/2013 01:31 PM, Michael Sieben wrote:
>
>                  Hi,
>
>                  i'm trying to setup torcs for robot-dev.
>
>                  I'm running on Ubuntu 13.04 and used the current
>         torcs-1.3.4
>                  sources.
>
>                  Basically i followed the tutorial at
>         http://www.berniw.org/____tutorials/robot/tutorial.html
>         <http://www.berniw.org/__tutorials/robot/tutorial.html>
>
>                  <http://www.berniw.org/__tutorials/robot/tutorial.html
>         <http://www.berniw.org/tutorials/robot/tutorial.html>>
>
>                  After applying a patch ( see
>         http://comments.gmane.org/____gmane.games.torcs.general/1584
>         <http://comments.gmane.org/__gmane.games.torcs.general/1584>
>
>
>         <http://comments.gmane.org/__gmane.games.torcs.general/1584
>         <http://comments.gmane.org/gmane.games.torcs.general/1584>__> ) i
>                  got the
>                  game running and can start race without any problems.
>
>                  Using the robotgen from the tutorial i generated and
>         compiled my
>                  basic
>                  robot and then tried to test it.
>
>                  Unfortunately torcy crashes whenever i try to modify
>         the race
>                  settings (
>                  Configura race ) as soon as i hit "Accept" in the track
>         selection.
>
>                  I hope someone can give me a hint where my environment
>         is lacking.
>
>                  Thanks in advance
>                  McCriddle
>
>
>                  Here is the output from torcs -d :
>
>                  GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
>                  Copyright (C) 2013 Free Software Foundation, Inc.
>                  License GPLv3+: GNU GPL version 3 or later
>                  <http://gnu.org/licenses/gpl.____html
>         <http://gnu.org/licenses/gpl.__html>
>
>                  <http://gnu.org/licenses/gpl.__html
>         <http://gnu.org/licenses/gpl.html>>>
>                  This is free software: you are free to change and
>         redistribute it.
>                  There is NO WARRANTY, to the extent permitted by law.  Type
>                  "show copying"
>                  and "show warranty" for details.
>                  This GDB was configured as "x86_64-linux-gnu".
>                  For bug reporting instructions, please see:
>                  <http://www.gnu.org/software/____gdb/bugs/
>         <http://www.gnu.org/software/__gdb/bugs/>
>                  <http://www.gnu.org/software/__gdb/bugs/
>         <http://www.gnu.org/software/gdb/bugs/>>>...
>                  Reading symbols from
>         /usr/local/lib/torcs/torcs-____bin...done.
>
>                  (gdb) Starting program: /usr/local/lib/torcs/torcs-bin -l
>                  /home/linadmin/.torcs -L /usr/local/lib/torcs -D
>                  /usr/local/share/games/torcs
>                  warning: no loadable sections found in added symbol-file
>                  system-supplied
>                  DSO at 0x7ffff7ffa000
>                  [Thread debugging using libthread_db enabled]
>                  Using host libthread_db library
>                  "/lib/x86_64-linux-gnu/____libthread_db.so.1".
>
>                  Visual Properties Report
>                  ------------------------
>                  Compatibility mode, properties unknown.
>                  [New Thread 0x7fffeee39700 (LWP 20929)]
>                  [New Thread 0x7fffee638700 (LWP 20930)]
>                  [New Thread 0x7fffeb474700 (LWP 20931)]
>                  [Thread 0x7fffeb474700 (LWP 20931) exited]
>                  [New Thread 0x7fffeb474700 (LWP 20932)]
>                  [New Thread 0x7fffe6c72700 (LWP 20933)]
>                  [Thread 0x7fffe6c72700 (LWP 20933) exited]
>                  [Thread 0x7fffeb474700 (LWP 20932) exited]
>                  [Thread 0x7fffee638700 (LWP 20930) exited]
>                  [Thread 0x7fffeee39700 (LWP 20929) exited]
>                  process 20925 is executing new program:
>                  /usr/local/lib/torcs/torcs-bin
>                  [Thread debugging using libthread_db enabled]
>                  Using host libthread_db library
>                  "/lib/x86_64-linux-gnu/____libthread_db.so.1".
>
>                  Visual Properties Report
>                  ------------------------
>                  Compatibility mode, properties unknown.
>                  [New Thread 0x7fffeee39700 (LWP 20934)]
>                  [New Thread 0x7fffee638700 (LWP 20935)]
>                  [New Thread 0x7fffeb474700 (LWP 20936)]
>                  [Thread 0x7fffeb474700 (LWP 20936) exited]
>                  [New Thread 0x7fffeb474700 (LWP 20937)]
>                  [New Thread 0x7fffe6c72700 (LWP 20938)]
>
>                  Program received signal SIGSEGV, Segmentation fault.
>                  0x00007ffff613ac51 in ?? () from
>         /lib/x86_64-linux-gnu/libc.so.____6
>
>                  (gdb) #0  0x00007ffff613ac51 in ?? () from
>                  /lib/x86_64-linux-gnu/libc.so.____6
>
>                  #1  0x00007ffff613a8c6 in strdup () from
>                  /lib/x86_64-linux-gnu/libc.so.____6
>
>                  #2  0x00007ffff4de3389 in RmDriversSelect
>                  (vs=vs@entry=0x7ffff73859c0
>                  <ds>) at driverselect.cpp:360
>                  #3  0x00007ffff717e758 in reConfigRunState () at
>         racemanmenu.cpp:155
>                  #4  0x00007ffff75b0447 in GfuiScreenActivate
>         (screen=0x2839ea0) at
>                  gui.cpp:491
>                  #5  0x00007ffff4de176b in rmtsDeactivate
>         (screen=<optimized out>) at
>                  trackselect.cpp:80
>                  #6  0x00007ffff4de1871 in rmtsSelect () at
>         trackselect.cpp:171
>                  #7  0x00007ffff75b025b in gfuiMouse (y=<optimized out>,
>         x=<optimized
>                  out>, state=1, button=0)
>                        at gui.cpp:423
>                  ---Type <return> to continue, or q <return> to
>         quit---#8  gfuiMouse
>                  (button=0, state=1, x=<optimized out>, y=<optimized
>         out>) at
>                  gui.cpp:398
>                  #9  0x00007ffff6d4c7d8 in glutMainLoopEvent () from
>                  /usr/lib/x86_64-linux-gnu/____libglut.so.3
>
>                  #10 0x00007ffff6d4cd81 in glutMainLoop () from
>                  /usr/lib/x86_64-linux-gnu/____libglut.so.3
>
>                  #11 0x00000000004013b6 in main (argc=8,
>         argv=0x7fffffffe068) at
>                  main.cpp:134
>                  (gdb) quit
>                  A debugging session is active.
>
>                        Inferior 1 [process 20925] will be killed.
>
>                  Quit anyway? (y or n) [answered Y; input not from terminal]
>
>
>
>
>         ------------------------------____----------------------------__--__------------------
>
>                  Try New Relic Now & We'll Send You this Cool Shirt
>                  New Relic is the only SaaS-based application performance
>                  monitoring service
>                  that delivers powerful full stack analytics. Optimize and
>                  monitor your
>                  browser, app, & servers with just a few lines of code.
>         Try New Relic
>                  and get this awesome Nerd Life shirt!
>         http://p.sf.net/sfu/newrelic_____d2d_may
>         <http://p.sf.net/sfu/newrelic___d2d_may>
>                  <http://p.sf.net/sfu/newrelic___d2d_may
>         <http://p.sf.net/sfu/newrelic_d2d_may>>
>
>
>
>                  ___________________________________________________
>                  Torcs-users mailing list
>                  Tor...@li....____net
>                  <mailto:Torcs-users@lists.__sourceforge.net
>         <mailto:Tor...@li...>>
>         https://lists.sourceforge.net/____lists/listinfo/torcs-users
>         <https://lists.sourceforge.net/__lists/listinfo/torcs-users>
>
>         <https://lists.sourceforge.__net/lists/listinfo/torcs-users
>         <https://lists.sourceforge.net/lists/listinfo/torcs-users>__>
>
>
>
>
>

Hi Bernhard,

i now got my first bot generated, compiled and started in a race.

I now used the "For Linux and FreeBSD from "all-in-one" Source Package" and
have the missing folders in my $TORCS_BASE - directory.

kind regards
McCriddle


2013/5/24 Bernhard Wymann <be...@bl...>

> Hi McCriddle
>
> Did you put it in the same place like the other script, I guess you just
> run it from the wrong place, do the paths relative to the script exist
> (here your command works flawlessly)? Does the category in the car5-trb1
> directory exist (in the original it does, maybe you have modified it)?
>
> berni@wytec001:~/torcs_src/**torcs/torcs> ./robotgen -n "mcc1" -a
> "McCriddle" -c "car5-trb1" --gpl
> Generation of robot mcc1 author McCriddle
> Copying car5-trb1.rgb ... and car5-trb1.xcf ... done
> Copying logo.rgb ... done
> Generating src/drivers/mcc1/Makefile ... done
> Generating src/drivers/mcc1/mcc1.xml ... done
> Generating src/drivers/mcc1/mcc1.cpp ... done
> Generating src/drivers/mcc1/mcc1.def ... done
> Generating src/drivers/mcc1/mcc1.dsp ... done
>
> Here you can see how to execute a script verbose:
> http://tldp.org/LDP/Bash-**Beginners-Guide/html/sect_02_**03.html<http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_03.html>
>
> Best regards
>
> Bernhard
>
>
> On 05/23/2013 04:27 PM, Michael Sieben wrote:
>
>> Hi Bernhard,
>>
>> i downloaded the robotgen you linked, but now i get this:
>>
>> ./robotgen -n "mcc1" -a "McCriddle" -c "car5-trb1" --gpl
>> grep: data/cars/models/car5-trb1/**car5-trb1.xml: Datei oder Verzeichnis
>> nicht gefunden
>> usage: robotgen -n <name> -a <author> -c <car> [-d description] [--gpl]
>> linadmin@svr110:~/torcs-1.3.4$ torcs -s
>> Visual Properties Report
>> ------------------------
>> Compatibility mode, properties unknown.
>> linadmin@svr110:~/torcs-1.3.4$ ./robotgen -n "mcc1" -a "McCriddle" -c
>> "car5-trb1" --gpl
>> grep: data/cars/models/car5-trb1/**car5-trb1.xml: Datei oder Verzeichnis
>> nicht gefunden
>> usage: robotgen -n <name> -a <author> -c <car> [-d description] [--gpl]
>>
>>
>> The "Configure Race" now works fine, after i deleted my generated robot
>> from /usr/local/lib/... and /usr/local/share/....
>>
>> kind regards
>> McCriddle
>>
>>
>>
>> 2013/5/23 Bernhard Wymann <be...@bl... <mailto:be...@bl...>>
>>
>>
>>     Hi McCriddle
>>
>>     The ultimate reason for this is probable a fixed memory leak in
>>     1.3.4. I the CVS you can find a fixed robotgen script:
>>     http://torcs.cvs.sourceforge._**_net/viewvc/torcs/torcs/torcs/**
>> __robotgen?revision=1.4.2.1&__**view=markup&pathrev=r1-3-1
>>
>>     <http://torcs.cvs.sourceforge.**net/viewvc/torcs/torcs/torcs/**
>> robotgen?revision=1.4.2.1&**view=markup&pathrev=r1-3-1<http://torcs.cvs.sourceforge.net/viewvc/torcs/torcs/torcs/robotgen?revision=1.4.2.1&view=markup&pathrev=r1-3-1>
>> >
>>
>>     And have a look at this, this is likely the cause:
>>     http://www.berniw.org/trb/__**forum/showthread.php?topicid=_**_3508<http://www.berniw.org/trb/__forum/showthread.php?topicid=__3508>
>>
>>     <http://www.berniw.org/trb/**forum/showthread.php?topicid=**3508<http://www.berniw.org/trb/forum/showthread.php?topicid=3508>
>> >
>>
>>     Let us know if this helped, usually the solution of such stuff is
>>     pretty easy, so keep going.
>>
>>     Best regards
>>
>>     Bernhard
>>
>>
>>
>>     On 05/23/2013 01:31 PM, Michael Sieben wrote:
>>
>>         Hi,
>>
>>         i'm trying to setup torcs for robot-dev.
>>
>>         I'm running on Ubuntu 13.04 and used the current torcs-1.3.4
>>         sources.
>>
>>         Basically i followed the tutorial at
>>         http://www.berniw.org/__**tutorials/robot/tutorial.html<http://www.berniw.org/__tutorials/robot/tutorial.html>
>>
>>         <http://www.berniw.org/**tutorials/robot/tutorial.html<http://www.berniw.org/tutorials/robot/tutorial.html>
>> >
>>
>>         After applying a patch ( see
>>         http://comments.gmane.org/__**gmane.games.torcs.general/1584<http://comments.gmane.org/__gmane.games.torcs.general/1584>
>>
>>         <http://comments.gmane.org/**gmane.games.torcs.general/1584<http://comments.gmane.org/gmane.games.torcs.general/1584>
>> **> ) i
>>         got the
>>         game running and can start race without any problems.
>>
>>         Using the robotgen from the tutorial i generated and compiled my
>>         basic
>>         robot and then tried to test it.
>>
>>         Unfortunately torcy crashes whenever i try to modify the race
>>         settings (
>>         Configura race ) as soon as i hit "Accept" in the track selection.
>>
>>         I hope someone can give me a hint where my environment is lacking.
>>
>>         Thanks in advance
>>         McCriddle
>>
>>
>>         Here is the output from torcs -d :
>>
>>         GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
>>         Copyright (C) 2013 Free Software Foundation, Inc.
>>         License GPLv3+: GNU GPL version 3 or later
>>         <http://gnu.org/licenses/gpl._**_html<http://gnu.org/licenses/gpl.__html>
>>
>>         <http://gnu.org/licenses/gpl.**html<http://gnu.org/licenses/gpl.html>
>> >>
>>         This is free software: you are free to change and redistribute it.
>>         There is NO WARRANTY, to the extent permitted by law.  Type
>>         "show copying"
>>         and "show warranty" for details.
>>         This GDB was configured as "x86_64-linux-gnu".
>>         For bug reporting instructions, please see:
>>         <http://www.gnu.org/software/_**_gdb/bugs/<http://www.gnu.org/software/__gdb/bugs/>
>>         <http://www.gnu.org/software/**gdb/bugs/<http://www.gnu.org/software/gdb/bugs/>
>> >>...
>>         Reading symbols from /usr/local/lib/torcs/torcs-__**bin...done.
>>
>>         (gdb) Starting program: /usr/local/lib/torcs/torcs-bin -l
>>         /home/linadmin/.torcs -L /usr/local/lib/torcs -D
>>         /usr/local/share/games/torcs
>>         warning: no loadable sections found in added symbol-file
>>         system-supplied
>>         DSO at 0x7ffff7ffa000
>>         [Thread debugging using libthread_db enabled]
>>         Using host libthread_db library
>>         "/lib/x86_64-linux-gnu/__**libthread_db.so.1".
>>
>>         Visual Properties Report
>>         ------------------------
>>         Compatibility mode, properties unknown.
>>         [New Thread 0x7fffeee39700 (LWP 20929)]
>>         [New Thread 0x7fffee638700 (LWP 20930)]
>>         [New Thread 0x7fffeb474700 (LWP 20931)]
>>         [Thread 0x7fffeb474700 (LWP 20931) exited]
>>         [New Thread 0x7fffeb474700 (LWP 20932)]
>>         [New Thread 0x7fffe6c72700 (LWP 20933)]
>>         [Thread 0x7fffe6c72700 (LWP 20933) exited]
>>         [Thread 0x7fffeb474700 (LWP 20932) exited]
>>         [Thread 0x7fffee638700 (LWP 20930) exited]
>>         [Thread 0x7fffeee39700 (LWP 20929) exited]
>>         process 20925 is executing new program:
>>         /usr/local/lib/torcs/torcs-bin
>>         [Thread debugging using libthread_db enabled]
>>         Using host libthread_db library
>>         "/lib/x86_64-linux-gnu/__**libthread_db.so.1".
>>
>>         Visual Properties Report
>>         ------------------------
>>         Compatibility mode, properties unknown.
>>         [New Thread 0x7fffeee39700 (LWP 20934)]
>>         [New Thread 0x7fffee638700 (LWP 20935)]
>>         [New Thread 0x7fffeb474700 (LWP 20936)]
>>         [Thread 0x7fffeb474700 (LWP 20936) exited]
>>         [New Thread 0x7fffeb474700 (LWP 20937)]
>>         [New Thread 0x7fffe6c72700 (LWP 20938)]
>>
>>         Program received signal SIGSEGV, Segmentation fault.
>>         0x00007ffff613ac51 in ?? () from /lib/x86_64-linux-gnu/libc.so.**
>> __6
>>
>>         (gdb) #0  0x00007ffff613ac51 in ?? () from
>>         /lib/x86_64-linux-gnu/libc.so.**__6
>>
>>         #1  0x00007ffff613a8c6 in strdup () from
>>         /lib/x86_64-linux-gnu/libc.so.**__6
>>
>>         #2  0x00007ffff4de3389 in RmDriversSelect
>>         (vs=vs@entry=0x7ffff73859c0
>>         <ds>) at driverselect.cpp:360
>>         #3  0x00007ffff717e758 in reConfigRunState () at
>> racemanmenu.cpp:155
>>         #4  0x00007ffff75b0447 in GfuiScreenActivate (screen=0x2839ea0) at
>>         gui.cpp:491
>>         #5  0x00007ffff4de176b in rmtsDeactivate (screen=<optimized out>)
>> at
>>         trackselect.cpp:80
>>         #6  0x00007ffff4de1871 in rmtsSelect () at trackselect.cpp:171
>>         #7  0x00007ffff75b025b in gfuiMouse (y=<optimized out>,
>> x=<optimized
>>         out>, state=1, button=0)
>>               at gui.cpp:423
>>         ---Type <return> to continue, or q <return> to quit---#8
>>  gfuiMouse
>>         (button=0, state=1, x=<optimized out>, y=<optimized out>) at
>>         gui.cpp:398
>>         #9  0x00007ffff6d4c7d8 in glutMainLoopEvent () from
>>         /usr/lib/x86_64-linux-gnu/__**libglut.so.3
>>
>>         #10 0x00007ffff6d4cd81 in glutMainLoop () from
>>         /usr/lib/x86_64-linux-gnu/__**libglut.so.3
>>
>>         #11 0x00000000004013b6 in main (argc=8, argv=0x7fffffffe068) at
>>         main.cpp:134
>>         (gdb) quit
>>         A debugging session is active.
>>
>>               Inferior 1 [process 20925] will be killed.
>>
>>         Quit anyway? (y or n) [answered Y; input not from terminal]
>>
>>
>>
>>         ------------------------------**__----------------------------**
>> --__------------------
>>
>>         Try New Relic Now & We'll Send You this Cool Shirt
>>         New Relic is the only SaaS-based application performance
>>         monitoring service
>>         that delivers powerful full stack analytics. Optimize and
>>         monitor your
>>         browser, app, & servers with just a few lines of code. Try New
>> Relic
>>         and get this awesome Nerd Life shirt!
>>         http://p.sf.net/sfu/newrelic__**_d2d_may<http://p.sf.net/sfu/newrelic___d2d_may>
>>         <http://p.sf.net/sfu/newrelic_**d2d_may<http://p.sf.net/sfu/newrelic_d2d_may>
>> >
>>
>>
>>
>>         ______________________________**___________________
>>         Torcs-users mailing list
>>         Tor...@li....**__net
>>         <mailto:Torcs-users@lists.**sourceforge.net<Tor...@li...>
>> >
>>         https://lists.sourceforge.net/**__lists/listinfo/torcs-users<https://lists.sourceforge.net/__lists/listinfo/torcs-users>
>>         <https://lists.sourceforge.**net/lists/listinfo/torcs-users<https://lists.sourceforge.net/lists/listinfo/torcs-users>
>> **>
>>
>>
>>
>>
>

Hi Bernhard,

i run the script from the $TORCS_BASE  directory.

the problem seems to be this:


$ bash -x robotgen -n "mcc1" -a "McCriddle" -c "car5-trb1" --gpl
*snip*
++ grep category data/cars/models/car5-trb1/car5-trb1.xml
grep: data/cars/models/car5-trb1/car5-trb1.xml: Datei oder Verzeichnis
nicht gefunden
*snip*


but i have no data/..... dirs under my $TORCS_BASE

should i extract any more than the *-src-* - Archives to the $TORCS_BASE
directory ?

here are the first 2 levels of dirs:

export/drivers/
export/include/
export/lib/
export/modules/
src/doc/
src/drivers/
src/interfaces/
src/libs/
src/linux/
src/modules/
src/raceman/
src/tools/
src/windows/


kind regards
McCriddle







2013/5/24 Bernhard Wymann <be...@bl...>

> Hi McCriddle
>
> Did you put it in the same place like the other script, I guess you just
> run it from the wrong place, do the paths relative to the script exist
> (here your command works flawlessly)? Does the category in the car5-trb1
> directory exist (in the original it does, maybe you have modified it)?
>
> berni@wytec001:~/torcs_src/**torcs/torcs> ./robotgen -n "mcc1" -a
> "McCriddle" -c "car5-trb1" --gpl
> Generation of robot mcc1 author McCriddle
> Copying car5-trb1.rgb ... and car5-trb1.xcf ... done
> Copying logo.rgb ... done
> Generating src/drivers/mcc1/Makefile ... done
> Generating src/drivers/mcc1/mcc1.xml ... done
> Generating src/drivers/mcc1/mcc1.cpp ... done
> Generating src/drivers/mcc1/mcc1.def ... done
> Generating src/drivers/mcc1/mcc1.dsp ... done
>
> Here you can see how to execute a script verbose:
> http://tldp.org/LDP/Bash-**Beginners-Guide/html/sect_02_**03.html<http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_03.html>
>
> Best regards
>
> Bernhard
>
>
> On 05/23/2013 04:27 PM, Michael Sieben wrote:
>
>> Hi Bernhard,
>>
>> i downloaded the robotgen you linked, but now i get this:
>>
>> ./robotgen -n "mcc1" -a "McCriddle" -c "car5-trb1" --gpl
>> grep: data/cars/models/car5-trb1/**car5-trb1.xml: Datei oder Verzeichnis
>> nicht gefunden
>> usage: robotgen -n <name> -a <author> -c <car> [-d description] [--gpl]
>> linadmin@svr110:~/torcs-1.3.4$ torcs -s
>> Visual Properties Report
>> ------------------------
>> Compatibility mode, properties unknown.
>> linadmin@svr110:~/torcs-1.3.4$ ./robotgen -n "mcc1" -a "McCriddle" -c
>> "car5-trb1" --gpl
>> grep: data/cars/models/car5-trb1/**car5-trb1.xml: Datei oder Verzeichnis
>> nicht gefunden
>> usage: robotgen -n <name> -a <author> -c <car> [-d description] [--gpl]
>>
>>
>> The "Configure Race" now works fine, after i deleted my generated robot
>> from /usr/local/lib/... and /usr/local/share/....
>>
>> kind regards
>> McCriddle
>>
>>
>>
>> 2013/5/23 Bernhard Wymann <be...@bl... <mailto:be...@bl...>>
>>
>>
>>     Hi McCriddle
>>
>>     The ultimate reason for this is probable a fixed memory leak in
>>     1.3.4. I the CVS you can find a fixed robotgen script:
>>     http://torcs.cvs.sourceforge._**_net/viewvc/torcs/torcs/torcs/**
>> __robotgen?revision=1.4.2.1&__**view=markup&pathrev=r1-3-1
>>
>>     <http://torcs.cvs.sourceforge.**net/viewvc/torcs/torcs/torcs/**
>> robotgen?revision=1.4.2.1&**view=markup&pathrev=r1-3-1<http://torcs.cvs.sourceforge.net/viewvc/torcs/torcs/torcs/robotgen?revision=1.4.2.1&view=markup&pathrev=r1-3-1>
>> >
>>
>>     And have a look at this, this is likely the cause:
>>     http://www.berniw.org/trb/__**forum/showthread.php?topicid=_**_3508<http://www.berniw.org/trb/__forum/showthread.php?topicid=__3508>
>>
>>     <http://www.berniw.org/trb/**forum/showthread.php?topicid=**3508<http://www.berniw.org/trb/forum/showthread.php?topicid=3508>
>> >
>>
>>     Let us know if this helped, usually the solution of such stuff is
>>     pretty easy, so keep going.
>>
>>     Best regards
>>
>>     Bernhard
>>
>>
>>
>>     On 05/23/2013 01:31 PM, Michael Sieben wrote:
>>
>>         Hi,
>>
>>         i'm trying to setup torcs for robot-dev.
>>
>>         I'm running on Ubuntu 13.04 and used the current torcs-1.3.4
>>         sources.
>>
>>         Basically i followed the tutorial at
>>         http://www.berniw.org/__**tutorials/robot/tutorial.html<http://www.berniw.org/__tutorials/robot/tutorial.html>
>>
>>         <http://www.berniw.org/**tutorials/robot/tutorial.html<http://www.berniw.org/tutorials/robot/tutorial.html>
>> >
>>
>>         After applying a patch ( see
>>         http://comments.gmane.org/__**gmane.games.torcs.general/1584<http://comments.gmane.org/__gmane.games.torcs.general/1584>
>>
>>         <http://comments.gmane.org/**gmane.games.torcs.general/1584<http://comments.gmane.org/gmane.games.torcs.general/1584>
>> **> ) i
>>         got the
>>         game running and can start race without any problems.
>>
>>         Using the robotgen from the tutorial i generated and compiled my
>>         basic
>>         robot and then tried to test it.
>>
>>         Unfortunately torcy crashes whenever i try to modify the race
>>         settings (
>>         Configura race ) as soon as i hit "Accept" in the track selection.
>>
>>         I hope someone can give me a hint where my environment is lacking.
>>
>>         Thanks in advance
>>         McCriddle
>>
>>
>>         Here is the output from torcs -d :
>>
>>         GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
>>         Copyright (C) 2013 Free Software Foundation, Inc.
>>         License GPLv3+: GNU GPL version 3 or later
>>         <http://gnu.org/licenses/gpl._**_html<http://gnu.org/licenses/gpl.__html>
>>
>>         <http://gnu.org/licenses/gpl.**html<http://gnu.org/licenses/gpl.html>
>> >>
>>         This is free software: you are free to change and redistribute it.
>>         There is NO WARRANTY, to the extent permitted by law.  Type
>>         "show copying"
>>         and "show warranty" for details.
>>         This GDB was configured as "x86_64-linux-gnu".
>>         For bug reporting instructions, please see:
>>         <http://www.gnu.org/software/_**_gdb/bugs/<http://www.gnu.org/software/__gdb/bugs/>
>>         <http://www.gnu.org/software/**gdb/bugs/<http://www.gnu.org/software/gdb/bugs/>
>> >>...
>>         Reading symbols from /usr/local/lib/torcs/torcs-__**bin...done.
>>
>>         (gdb) Starting program: /usr/local/lib/torcs/torcs-bin -l
>>         /home/linadmin/.torcs -L /usr/local/lib/torcs -D
>>         /usr/local/share/games/torcs
>>         warning: no loadable sections found in added symbol-file
>>         system-supplied
>>         DSO at 0x7ffff7ffa000
>>         [Thread debugging using libthread_db enabled]
>>         Using host libthread_db library
>>         "/lib/x86_64-linux-gnu/__**libthread_db.so.1".
>>
>>         Visual Properties Report
>>         ------------------------
>>         Compatibility mode, properties unknown.
>>         [New Thread 0x7fffeee39700 (LWP 20929)]
>>         [New Thread 0x7fffee638700 (LWP 20930)]
>>         [New Thread 0x7fffeb474700 (LWP 20931)]
>>         [Thread 0x7fffeb474700 (LWP 20931) exited]
>>         [New Thread 0x7fffeb474700 (LWP 20932)]
>>         [New Thread 0x7fffe6c72700 (LWP 20933)]
>>         [Thread 0x7fffe6c72700 (LWP 20933) exited]
>>         [Thread 0x7fffeb474700 (LWP 20932) exited]
>>         [Thread 0x7fffee638700 (LWP 20930) exited]
>>         [Thread 0x7fffeee39700 (LWP 20929) exited]
>>         process 20925 is executing new program:
>>         /usr/local/lib/torcs/torcs-bin
>>         [Thread debugging using libthread_db enabled]
>>         Using host libthread_db library
>>         "/lib/x86_64-linux-gnu/__**libthread_db.so.1".
>>
>>         Visual Properties Report
>>         ------------------------
>>         Compatibility mode, properties unknown.
>>         [New Thread 0x7fffeee39700 (LWP 20934)]
>>         [New Thread 0x7fffee638700 (LWP 20935)]
>>         [New Thread 0x7fffeb474700 (LWP 20936)]
>>         [Thread 0x7fffeb474700 (LWP 20936) exited]
>>         [New Thread 0x7fffeb474700 (LWP 20937)]
>>         [New Thread 0x7fffe6c72700 (LWP 20938)]
>>
>>         Program received signal SIGSEGV, Segmentation fault.
>>         0x00007ffff613ac51 in ?? () from /lib/x86_64-linux-gnu/libc.so.**
>> __6
>>
>>         (gdb) #0  0x00007ffff613ac51 in ?? () from
>>         /lib/x86_64-linux-gnu/libc.so.**__6
>>
>>         #1  0x00007ffff613a8c6 in strdup () from
>>         /lib/x86_64-linux-gnu/libc.so.**__6
>>
>>         #2  0x00007ffff4de3389 in RmDriversSelect
>>         (vs=vs@entry=0x7ffff73859c0
>>         <ds>) at driverselect.cpp:360
>>         #3  0x00007ffff717e758 in reConfigRunState () at
>> racemanmenu.cpp:155
>>         #4  0x00007ffff75b0447 in GfuiScreenActivate (screen=0x2839ea0) at
>>         gui.cpp:491
>>         #5  0x00007ffff4de176b in rmtsDeactivate (screen=<optimized out>)
>> at
>>         trackselect.cpp:80
>>         #6  0x00007ffff4de1871 in rmtsSelect () at trackselect.cpp:171
>>         #7  0x00007ffff75b025b in gfuiMouse (y=<optimized out>,
>> x=<optimized
>>         out>, state=1, button=0)
>>               at gui.cpp:423
>>         ---Type <return> to continue, or q <return> to quit---#8
>>  gfuiMouse
>>         (button=0, state=1, x=<optimized out>, y=<optimized out>) at
>>         gui.cpp:398
>>         #9  0x00007ffff6d4c7d8 in glutMainLoopEvent () from
>>         /usr/lib/x86_64-linux-gnu/__**libglut.so.3
>>
>>         #10 0x00007ffff6d4cd81 in glutMainLoop () from
>>         /usr/lib/x86_64-linux-gnu/__**libglut.so.3
>>
>>         #11 0x00000000004013b6 in main (argc=8, argv=0x7fffffffe068) at
>>         main.cpp:134
>>         (gdb) quit
>>         A debugging session is active.
>>
>>               Inferior 1 [process 20925] will be killed.
>>
>>         Quit anyway? (y or n) [answered Y; input not from terminal]
>>
>>
>>
>>         ------------------------------**__----------------------------**
>> --__------------------
>>
>>         Try New Relic Now & We'll Send You this Cool Shirt
>>         New Relic is the only SaaS-based application performance
>>         monitoring service
>>         that delivers powerful full stack analytics. Optimize and
>>         monitor your
>>         browser, app, & servers with just a few lines of code. Try New
>> Relic
>>         and get this awesome Nerd Life shirt!
>>         http://p.sf.net/sfu/newrelic__**_d2d_may<http://p.sf.net/sfu/newrelic___d2d_may>
>>         <http://p.sf.net/sfu/newrelic_**d2d_may<http://p.sf.net/sfu/newrelic_d2d_may>
>> >
>>
>>
>>
>>         ______________________________**___________________
>>         Torcs-users mailing list
>>         Tor...@li....**__net
>>         <mailto:Torcs-users@lists.**sourceforge.net<Tor...@li...>
>> >
>>         https://lists.sourceforge.net/**__lists/listinfo/torcs-users<https://lists.sourceforge.net/__lists/listinfo/torcs-users>
>>         <https://lists.sourceforge.**net/lists/listinfo/torcs-users<https://lists.sourceforge.net/lists/listinfo/torcs-users>
>> **>
>>
>>
>>
>>
>

Hi McCriddle

Did you put it in the same place like the other script, I guess you just 
run it from the wrong place, do the paths relative to the script exist 
(here your command works flawlessly)? Does the category in the car5-trb1 
directory exist (in the original it does, maybe you have modified it)?

berni@wytec001:~/torcs_src/torcs/torcs> ./robotgen -n "mcc1" -a 
"McCriddle" -c "car5-trb1" --gpl
Generation of robot mcc1 author McCriddle
Copying car5-trb1.rgb ... and car5-trb1.xcf ... done
Copying logo.rgb ... done
Generating src/drivers/mcc1/Makefile ... done
Generating src/drivers/mcc1/mcc1.xml ... done
Generating src/drivers/mcc1/mcc1.cpp ... done
Generating src/drivers/mcc1/mcc1.def ... done
Generating src/drivers/mcc1/mcc1.dsp ... done

Here you can see how to execute a script verbose:
http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_03.html

Best regards

Bernhard

On 05/23/2013 04:27 PM, Michael Sieben wrote:
> Hi Bernhard,
>
> i downloaded the robotgen you linked, but now i get this:
>
> ./robotgen -n "mcc1" -a "McCriddle" -c "car5-trb1" --gpl
> grep: data/cars/models/car5-trb1/car5-trb1.xml: Datei oder Verzeichnis
> nicht gefunden
> usage: robotgen -n <name> -a <author> -c <car> [-d description] [--gpl]
> linadmin@svr110:~/torcs-1.3.4$ torcs -s
> Visual Properties Report
> ------------------------
> Compatibility mode, properties unknown.
> linadmin@svr110:~/torcs-1.3.4$ ./robotgen -n "mcc1" -a "McCriddle" -c
> "car5-trb1" --gpl
> grep: data/cars/models/car5-trb1/car5-trb1.xml: Datei oder Verzeichnis
> nicht gefunden
> usage: robotgen -n <name> -a <author> -c <car> [-d description] [--gpl]
>
>
> The "Configure Race" now works fine, after i deleted my generated robot
> from /usr/local/lib/... and /usr/local/share/....
>
> kind regards
> McCriddle
>
>
>
> 2013/5/23 Bernhard Wymann <be...@bl... <mailto:be...@bl...>>
>
>     Hi McCriddle
>
>     The ultimate reason for this is probable a fixed memory leak in
>     1.3.4. I the CVS you can find a fixed robotgen script:
>     http://torcs.cvs.sourceforge.__net/viewvc/torcs/torcs/torcs/__robotgen?revision=1.4.2.1&__view=markup&pathrev=r1-3-1
>     <http://torcs.cvs.sourceforge.net/viewvc/torcs/torcs/torcs/robotgen?revision=1.4.2.1&view=markup&pathrev=r1-3-1>
>
>     And have a look at this, this is likely the cause:
>     http://www.berniw.org/trb/__forum/showthread.php?topicid=__3508
>     <http://www.berniw.org/trb/forum/showthread.php?topicid=3508>
>
>     Let us know if this helped, usually the solution of such stuff is
>     pretty easy, so keep going.
>
>     Best regards
>
>     Bernhard
>
>
>
>     On 05/23/2013 01:31 PM, Michael Sieben wrote:
>
>         Hi,
>
>         i'm trying to setup torcs for robot-dev.
>
>         I'm running on Ubuntu 13.04 and used the current torcs-1.3.4
>         sources.
>
>         Basically i followed the tutorial at
>         http://www.berniw.org/__tutorials/robot/tutorial.html
>         <http://www.berniw.org/tutorials/robot/tutorial.html>
>
>         After applying a patch ( see
>         http://comments.gmane.org/__gmane.games.torcs.general/1584
>         <http://comments.gmane.org/gmane.games.torcs.general/1584> ) i
>         got the
>         game running and can start race without any problems.
>
>         Using the robotgen from the tutorial i generated and compiled my
>         basic
>         robot and then tried to test it.
>
>         Unfortunately torcy crashes whenever i try to modify the race
>         settings (
>         Configura race ) as soon as i hit "Accept" in the track selection.
>
>         I hope someone can give me a hint where my environment is lacking.
>
>         Thanks in advance
>         McCriddle
>
>
>         Here is the output from torcs -d :
>
>         GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
>         Copyright (C) 2013 Free Software Foundation, Inc.
>         License GPLv3+: GNU GPL version 3 or later
>         <http://gnu.org/licenses/gpl.__html
>         <http://gnu.org/licenses/gpl.html>>
>         This is free software: you are free to change and redistribute it.
>         There is NO WARRANTY, to the extent permitted by law.  Type
>         "show copying"
>         and "show warranty" for details.
>         This GDB was configured as "x86_64-linux-gnu".
>         For bug reporting instructions, please see:
>         <http://www.gnu.org/software/__gdb/bugs/
>         <http://www.gnu.org/software/gdb/bugs/>>...
>         Reading symbols from /usr/local/lib/torcs/torcs-__bin...done.
>         (gdb) Starting program: /usr/local/lib/torcs/torcs-bin -l
>         /home/linadmin/.torcs -L /usr/local/lib/torcs -D
>         /usr/local/share/games/torcs
>         warning: no loadable sections found in added symbol-file
>         system-supplied
>         DSO at 0x7ffff7ffa000
>         [Thread debugging using libthread_db enabled]
>         Using host libthread_db library
>         "/lib/x86_64-linux-gnu/__libthread_db.so.1".
>         Visual Properties Report
>         ------------------------
>         Compatibility mode, properties unknown.
>         [New Thread 0x7fffeee39700 (LWP 20929)]
>         [New Thread 0x7fffee638700 (LWP 20930)]
>         [New Thread 0x7fffeb474700 (LWP 20931)]
>         [Thread 0x7fffeb474700 (LWP 20931) exited]
>         [New Thread 0x7fffeb474700 (LWP 20932)]
>         [New Thread 0x7fffe6c72700 (LWP 20933)]
>         [Thread 0x7fffe6c72700 (LWP 20933) exited]
>         [Thread 0x7fffeb474700 (LWP 20932) exited]
>         [Thread 0x7fffee638700 (LWP 20930) exited]
>         [Thread 0x7fffeee39700 (LWP 20929) exited]
>         process 20925 is executing new program:
>         /usr/local/lib/torcs/torcs-bin
>         [Thread debugging using libthread_db enabled]
>         Using host libthread_db library
>         "/lib/x86_64-linux-gnu/__libthread_db.so.1".
>         Visual Properties Report
>         ------------------------
>         Compatibility mode, properties unknown.
>         [New Thread 0x7fffeee39700 (LWP 20934)]
>         [New Thread 0x7fffee638700 (LWP 20935)]
>         [New Thread 0x7fffeb474700 (LWP 20936)]
>         [Thread 0x7fffeb474700 (LWP 20936) exited]
>         [New Thread 0x7fffeb474700 (LWP 20937)]
>         [New Thread 0x7fffe6c72700 (LWP 20938)]
>
>         Program received signal SIGSEGV, Segmentation fault.
>         0x00007ffff613ac51 in ?? () from /lib/x86_64-linux-gnu/libc.so.__6
>         (gdb) #0  0x00007ffff613ac51 in ?? () from
>         /lib/x86_64-linux-gnu/libc.so.__6
>         #1  0x00007ffff613a8c6 in strdup () from
>         /lib/x86_64-linux-gnu/libc.so.__6
>         #2  0x00007ffff4de3389 in RmDriversSelect
>         (vs=vs@entry=0x7ffff73859c0
>         <ds>) at driverselect.cpp:360
>         #3  0x00007ffff717e758 in reConfigRunState () at racemanmenu.cpp:155
>         #4  0x00007ffff75b0447 in GfuiScreenActivate (screen=0x2839ea0) at
>         gui.cpp:491
>         #5  0x00007ffff4de176b in rmtsDeactivate (screen=<optimized out>) at
>         trackselect.cpp:80
>         #6  0x00007ffff4de1871 in rmtsSelect () at trackselect.cpp:171
>         #7  0x00007ffff75b025b in gfuiMouse (y=<optimized out>, x=<optimized
>         out>, state=1, button=0)
>               at gui.cpp:423
>         ---Type <return> to continue, or q <return> to quit---#8  gfuiMouse
>         (button=0, state=1, x=<optimized out>, y=<optimized out>) at
>         gui.cpp:398
>         #9  0x00007ffff6d4c7d8 in glutMainLoopEvent () from
>         /usr/lib/x86_64-linux-gnu/__libglut.so.3
>         #10 0x00007ffff6d4cd81 in glutMainLoop () from
>         /usr/lib/x86_64-linux-gnu/__libglut.so.3
>         #11 0x00000000004013b6 in main (argc=8, argv=0x7fffffffe068) at
>         main.cpp:134
>         (gdb) quit
>         A debugging session is active.
>
>               Inferior 1 [process 20925] will be killed.
>
>         Quit anyway? (y or n) [answered Y; input not from terminal]
>
>
>
>         ------------------------------__------------------------------__------------------
>         Try New Relic Now & We'll Send You this Cool Shirt
>         New Relic is the only SaaS-based application performance
>         monitoring service
>         that delivers powerful full stack analytics. Optimize and
>         monitor your
>         browser, app, & servers with just a few lines of code. Try New Relic
>         and get this awesome Nerd Life shirt!
>         http://p.sf.net/sfu/newrelic___d2d_may
>         <http://p.sf.net/sfu/newrelic_d2d_may>
>
>
>
>         _________________________________________________
>         Torcs-users mailing list
>         Tor...@li....__net
>         <mailto:Tor...@li...>
>         https://lists.sourceforge.net/__lists/listinfo/torcs-users
>         <https://lists.sourceforge.net/lists/listinfo/torcs-users>
>
>
>

Hi st

> I tried to draw attention to this topic many months ago, to no avail. I

I think I did some test driving and videos then, see:
http://youtu.be/pHQ0KsDLRLU
http://youtu.be/CslDBENMrlM

My conclusion was: Olethros has some "potential" in tight turns, 
bt/berniw are very cooperative...

> don't know if I'm wasting my breath here, but these are my experiences
> and findings and some suggestions too, based on a gazillion test races,
> on the default, on others' and on my own tracks. And when I use the term
> "idiots" in the following, it only refers to the (mis)behavior of the
> robots, not in any way to their creators. If anything, I must be the
> human idiot here, unable to rein in those aggressive brutes and make
> racing more tolerable (to say nothing of enjoyable).
>
> If you doubt any of my observations, pick up some example tracks at
> http://stdesigns.orgfree.com/ttrx/  and run test races to see the
> motorized mayhem and brutality with your own eyes. For longer tracks
> (>1.5 miles), I'd recommend at least 30-50 laps, for short tracks,
> 80-150 laps. 20+ robots in the field, whatever your video card can
> handle (the more robots, the more obvious their failings). Park your car
> on pit road (to get it out of the way) and start watching (F9
> recommended for the best views, PageUp and PageDown to switch between
> cars) things unfold.

Ok, when I find the time I will have a look, but beware, there has even 
been formula 1 races with just 4 cars hitting the finish line, so in 
racing it is pretty common that "***t happens". Same applies if you go 
into an online lobby against human players (with other racing games of 
course, TORCS is missing that)...

You can as well adjust the amount of "chaos" by the driver selection, if 
you take "berniw" offsprings there should be not too much action...

> These are the biggest problems I've witnessed on all tracks, road and
> oval alike.
>
> 1. blind driving, an overly aggressive raceline (left side of this
> example image
> http://www.mojoimage.com/free-image-hosting-view-12.php?id=4768torcs-racel1.png)
> that ALWAYS leads to incidents in turn entry (inside, 1 in image) and
> exit (outside, 2 in image). It's impossible to race like that on an oval
> (at least two lines available), and even on a (narrower) road course,
> such recklessness will breed trouble. The track width is irrelevant:
> most of the ovals are ~15 meters wide, which easily allows 3-wide racing
> (this even happens on the incredibly wide default ovals). Yet the anal
> idiots always come pushing in turns, no matter what, always cut off a
> car on the inside when entering the turn and then push a car on the high
> side into the wall at turn exit. This demolition-derby boneheadedness is
> absolutely infuriating, a death blow to actual racing. Mikey Schumacher
> is a choirboy compared to these single-minded wreckers.

Relax:-)

> A solution (illustrated by the right side of the example image
> http://www.mojoimage.com/free-image-hosting-view-12.php?id=4768torcs-racel1.png):
> changing the robot code so that a robot would stick to ONE line in
> turns, be it on the inside or outside or in the middle of the track.
> Also eliminating the totally unnecessary pushing and hooking in turns
> when there's enough room for passing (true on most tracks). Yes, some
> might claim the latter is part of racing, and maybe in the final laps in
> a battle for the win, but in this game, the same BS happens all the
> time, over and over again, pointless brutality that only detracts from
> the racing.

My experience/opinion with this differs, depending on you opponent 
selection you can have a very "organized" race or a "chaotic" one, so 
you have some choice (after discovering the characters of the bots).

At least for me as human driver it is pretty easy to stay out of trouble 
in TORCS, compared to racing against other human drivers online with 
other racing sims.

I agree with you that the robots could be more clever, they are 
certainly not optimized for oval racing.

> 2. the same aggressive raceline way too close to the inside of the track
> in turns (as approximately shown in the example image), leads to idiotic
> and repetitive collisions with the pit wall on tracks where the wall
> begins in a turn; disrupts the racing itself. A test race on mr-speedway
> or nt-speedway shows this perfectly, though it occurs on numerous other
> ovals too, including tracks where the pit wall is only on the front
> straight, e.g. hm-speedway, ne-speedway; also on road courses where the
> pit wall begins in a turn (Country Club for example).
>
> Two possible solutions: changing the robot code so that the robot
> wouldn't drive so close to the inside in a turn, thus perhaps avoiding
> the wall; or changing the game code to allow the addition of another
> track element ("the apron", asphalt or grass or both) between the "main
> track" and the "left border" (pit wall), a common detail on many tracks
> which would both improve the track appearance (more realistic) and put
> an end to the robots' suicidal head-on crash course with the pit wall.
> Widening the main track itself or creating a "fake" apron (by
> manipulating the track texture) wouldn't make any difference as the
> robots would drive right at the bottom anyway, determined by their
> current code.
>
> 3. the inability of robots to back up after hitting/making contact with
> a wall, their hopeless attempt to bulldoze through the wall instead of
> simply backing up and resuming driving; a frequent occurrence when they
> hit the pit wall; however, some robots also get stuck on the outside
> wall and keep pushing toward it instead of hitting the reverse and
> continuing the race.

Yes, I am aware of this. Beware, my focus in the last releases was not 
on hacking the robots, because I think the main purpose of TORCS is that 
people implement their own ones, so see this more as "demos". I have in 
mind to create a "better" default bot, but there are still more 
important things to do before.

> Solution: there must be something off in the robot code that causes
> this, something a competent and willing coder could correct.
>
> 4. the inability of robots to drive smoothly (in a race, NOT on solo
> runs), on straightaways and in turns. This leads to frequent incidents
> when some idiot slams on the brakes all of a sudden, leaving a poor
> human no time to react and swerve (obviously affects other robots too).

In the berniw offsprings this is the case, this is a relict from the 
"200MHz CPU area", to save CPU cycles it does not reconsider some 
decisions. When I am going to hack this, this will be improved.

> And as always happens upon contact, the human-controlled car is sent
> into the wall or airborne while the slowpoke offender drives away
> happily. This behavior is probably related to or a consequence of the

They probably just react better, if you run "semi pro" you have exactly 
the same physics, with pro you have more damage and less grip. I do not 
know how good you "drive", maybe some practise/analysis helps.

Usually sudden movements end up in problems, e.g. if you lift the 
accelerator suddenly you can get heavy oversteer because of engine 
braking, switching gears in the wrong moment can be pretty bad as well, 
etcetc.

> blindness and aggression described in 1. This kind of erratic driving
> also puts the robots at a disadvantage: a human racer, if able to avoid
> the aggressors and their endless repertoire of tricks, can often lap the
> field or the majority of them unnaturally soon, not exactly the sign of
> good racing.

Yes, this is the case, but this is not that important because of "our" 
audience:
1. I think real race addicts/aces having steering whels etc. are by no 
means running TORCS, or just out of curiosity, they are using iRacing, 
LFS, or whatever, so this is not the intended audience.
2. People which have no budget and just want to have some fun, they are 
downloading TORCS and enjoy some laps with the keyboard or maybe a 
gamepad, but I suppose those not being fast drivers.
3. People using TORCS as base for their own research/whatever projects, 
they can hack the things to make it fit their requirements.

So I agree that it could be better (e.g. in a future version there will 
be rubberbanding implemented), but there are more important things to do 
currently.

> Solution: same as above in 1.
>
> 5. pounding against the pit wall on the front straight/stretch, either
> on the trackside or on pit road, totally inexplicable and absurd. Might
> be related to blindness and aggression, also to their pit road failures
> (see below in 7).

The thing is that no robot actually cares about it, pit wall collision 
detection was introduced after the robots. So this will need adoption.

> 6. the infuriating bulldoze-through-any-obstacle behavior that causes
> nothing but trouble on the track. Why can't the robots back up and go
> around an obstacle (stopped car) cleanly instead of forcing their way
> through it? Is it totally inconceivable and impossible to change the

I explained this here:
http://sourceforge.net/p/torcs/discussion/11281/thread/948d0e70/

> robot code so that they would no longer act like rageaholics behind the
> wheel? Combined with the pit-wall collisions explained in 2, this
> senseless banging effectively takes out most cars in races, with a field
> of 25 very often reduced to ~5 cars. Is this supposed to be a race track
> or some post-Matrix fight club?
>
> 7. pit road failures: going to the pits without finding the right pit
> stall (even with realistic 9-11 meter-long pit stalls) and returning to
> pit road on every lap, only to fail again, a complete waste of energy;
>
> turning onto pit road (usually the left side) only one track segment
> before the beginning of pit road, instead of the actual entry point
> determined in the "Pits" section of a track.xml (very problematic on
> tracks where the last segment before pit road is really short, usually
> because of different, more realistic textures/lines on the left side of
> the track, visible at least on is-speedway, mt-speedway, ri-speedway,
> sb-speedway);
>
> ignoring the pit exit segment in the "Pits" section as well, instead
> merging onto the track in the middle of turn 1, damn the torpedoes;
>
> in a longer race, never even turning onto pit road for fuel, instead
> running out of it and crawling along the track, another recipe for
> disaster and invitation to the rageaholic drummers. The pit road entry
> point in the "Pits" section is usually far enough for the robots to be
> able to get off the track in time and turn onto pit road, but for some
> unknown reason, they don't even try to pit;

Maybe you have more drivers in the race than pits?

> in races where they do go to the pits, the robots usually delay their
> pit stop way too much, with less than 1 liter of fuel in the tank, and
> if they fail to find that pit stall, they drive off and inevitably run
> out of fuel on the next lap. This should be alterable in the robot code
> (right?), the amount of fuel left that causes them to pit;
>
> some robots occasionally stopping on the track on the front
> straight/stretch (right alongside the pit wall) and supposedly trying to
> pit there, completely idiotic and suicidal, with others coming down the
> front straight/stretch at breakneck speed while these morons decide to
> park right there. This may occur on tracks with a curving front stretch
> or a simple front straight too;
>
> olethros-specific issues: this robot acts like a complete psycho on pit
> road, often turning onto it very late, losing control, slapping against
> the wall, then parking in the middle of it in an attempt to pit,
> failing, driving off and pounding continuously against the pit wall on
> the front straight in its rage, finally rushing back in the middle of
> traffic in turn 1. Even when it does find its way to the left side of
> pit road, more often than not it doesn't find the pit stall and keeps
> coming back to pit road as described in the first example of these pit
> road failures.
>
> -----
> I hope everybody understands the intent of this long message is to help
> with the development of this racing (the operative word here) game, not
> to deride the efforts or abilities of unpaid volunteers. I've simply
> tried to honestly and accurately describe the flaws of robots that
> should deserve more attention in the game development. And since I lack
> the skill and understanding of the game code to make any changes myself,
> this lengthy appeal needed writing. Now the truth is out there. Thanks
> for sticking it out, and drive safely.

Thanks for the input, here my opinion:
The robots will need improvement, I agree on that, but my priority on 
the last and as well on the upcoming releases is on TORCS itself. Three 
planned steps will have a significant impact on the robots, that is why 
I first want to complete those before adopting the robots. These are:
1. Car setup can be changed in the pit under certain conditions
2. More racing rules (pace car, etc.)
3. Split/Join/Crossing track segments (for city like scenarios in 
research, but as "side effect" you can do then as well pit lanes on a 
separate path, maybe ROC like scenarios or track variants).

Those have a big impact on the bots, so I basically sacrifice robot 
development currently in favour of IMO more important things.

Btw. if you want to try other bots you can get them from the TRB events, 
e.g:
http://www.berniw.org/trb/events/event_view.php?vieweventid=17

Beware, for 1.3.4 you need to adopt them:
http://www.berniw.org/trb/forum/showthread.php?topicid=3508

A final thought, about "Now the truth is out there": You should think 
about if there something like truth outside a mathematical context even 
exists, because usually the things selled as truth are just point of 
views/opinions, or even worse beliefs/paradigms. So depending on what 
you accept as facts and how you weight it, you will come to different 
conclusions;-)

And if Einstein is right (nobody could falsify so far the theory of 
relativity) there does not even exist a globally observable reality, so 
even in physics your point of view matters regarding what and when you 
see something;-)

Best regards

Bernhard

Hi Bernhard,

i downloaded the robotgen you linked, but now i get this:

./robotgen -n "mcc1" -a "McCriddle" -c "car5-trb1" --gpl
grep: data/cars/models/car5-trb1/car5-trb1.xml: Datei oder Verzeichnis
nicht gefunden
usage: robotgen -n <name> -a <author> -c <car> [-d description] [--gpl]
linadmin@svr110:~/torcs-1.3.4$ torcs -s
Visual Properties Report
------------------------
Compatibility mode, properties unknown.
linadmin@svr110:~/torcs-1.3.4$ ./robotgen -n "mcc1" -a "McCriddle" -c
"car5-trb1" --gpl
grep: data/cars/models/car5-trb1/car5-trb1.xml: Datei oder Verzeichnis
nicht gefunden
usage: robotgen -n <name> -a <author> -c <car> [-d description] [--gpl]


The "Configure Race" now works fine, after i deleted my generated robot
from /usr/local/lib/... and /usr/local/share/....

kind regards
McCriddle



2013/5/23 Bernhard Wymann <be...@bl...>

> Hi McCriddle
>
> The ultimate reason for this is probable a fixed memory leak in 1.3.4. I
> the CVS you can find a fixed robotgen script:
> http://torcs.cvs.sourceforge.**net/viewvc/torcs/torcs/torcs/**
> robotgen?revision=1.4.2.1&**view=markup&pathrev=r1-3-1<http://torcs.cvs.sourceforge.net/viewvc/torcs/torcs/torcs/robotgen?revision=1.4.2.1&view=markup&pathrev=r1-3-1>
>
> And have a look at this, this is likely the cause:
> http://www.berniw.org/trb/**forum/showthread.php?topicid=**3508<http://www.berniw.org/trb/forum/showthread.php?topicid=3508>
>
> Let us know if this helped, usually the solution of such stuff is pretty
> easy, so keep going.
>
> Best regards
>
> Bernhard
>
>
>
> On 05/23/2013 01:31 PM, Michael Sieben wrote:
>
>> Hi,
>>
>> i'm trying to setup torcs for robot-dev.
>>
>> I'm running on Ubuntu 13.04 and used the current torcs-1.3.4 sources.
>>
>> Basically i followed the tutorial at
>> http://www.berniw.org/**tutorials/robot/tutorial.html<http://www.berniw.org/tutorials/robot/tutorial.html>
>>
>> After applying a patch ( see
>> http://comments.gmane.org/**gmane.games.torcs.general/1584<http://comments.gmane.org/gmane.games.torcs.general/1584>) i got the
>> game running and can start race without any problems.
>>
>> Using the robotgen from the tutorial i generated and compiled my basic
>> robot and then tried to test it.
>>
>> Unfortunately torcy crashes whenever i try to modify the race settings (
>> Configura race ) as soon as i hit "Accept" in the track selection.
>>
>> I hope someone can give me a hint where my environment is lacking.
>>
>> Thanks in advance
>> McCriddle
>>
>>
>> Here is the output from torcs -d :
>>
>> GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
>> Copyright (C) 2013 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.**html <http://gnu.org/licenses/gpl.html>>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-linux-gnu".
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/**gdb/bugs/<http://www.gnu.org/software/gdb/bugs/>
>> >...
>> Reading symbols from /usr/local/lib/torcs/torcs-**bin...done.
>> (gdb) Starting program: /usr/local/lib/torcs/torcs-bin -l
>> /home/linadmin/.torcs -L /usr/local/lib/torcs -D
>> /usr/local/share/games/torcs
>> warning: no loadable sections found in added symbol-file system-supplied
>> DSO at 0x7ffff7ffa000
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/**
>> libthread_db.so.1".
>> Visual Properties Report
>> ------------------------
>> Compatibility mode, properties unknown.
>> [New Thread 0x7fffeee39700 (LWP 20929)]
>> [New Thread 0x7fffee638700 (LWP 20930)]
>> [New Thread 0x7fffeb474700 (LWP 20931)]
>> [Thread 0x7fffeb474700 (LWP 20931) exited]
>> [New Thread 0x7fffeb474700 (LWP 20932)]
>> [New Thread 0x7fffe6c72700 (LWP 20933)]
>> [Thread 0x7fffe6c72700 (LWP 20933) exited]
>> [Thread 0x7fffeb474700 (LWP 20932) exited]
>> [Thread 0x7fffee638700 (LWP 20930) exited]
>> [Thread 0x7fffeee39700 (LWP 20929) exited]
>> process 20925 is executing new program: /usr/local/lib/torcs/torcs-bin
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/**
>> libthread_db.so.1".
>> Visual Properties Report
>> ------------------------
>> Compatibility mode, properties unknown.
>> [New Thread 0x7fffeee39700 (LWP 20934)]
>> [New Thread 0x7fffee638700 (LWP 20935)]
>> [New Thread 0x7fffeb474700 (LWP 20936)]
>> [Thread 0x7fffeb474700 (LWP 20936) exited]
>> [New Thread 0x7fffeb474700 (LWP 20937)]
>> [New Thread 0x7fffe6c72700 (LWP 20938)]
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00007ffff613ac51 in ?? () from /lib/x86_64-linux-gnu/libc.so.**6
>> (gdb) #0  0x00007ffff613ac51 in ?? () from /lib/x86_64-linux-gnu/libc.so.
>> **6
>> #1  0x00007ffff613a8c6 in strdup () from /lib/x86_64-linux-gnu/libc.so.**
>> 6
>> #2  0x00007ffff4de3389 in RmDriversSelect (vs=vs@entry=0x7ffff73859c0
>> <ds>) at driverselect.cpp:360
>> #3  0x00007ffff717e758 in reConfigRunState () at racemanmenu.cpp:155
>> #4  0x00007ffff75b0447 in GfuiScreenActivate (screen=0x2839ea0) at
>> gui.cpp:491
>> #5  0x00007ffff4de176b in rmtsDeactivate (screen=<optimized out>) at
>> trackselect.cpp:80
>> #6  0x00007ffff4de1871 in rmtsSelect () at trackselect.cpp:171
>> #7  0x00007ffff75b025b in gfuiMouse (y=<optimized out>, x=<optimized
>> out>, state=1, button=0)
>>      at gui.cpp:423
>> ---Type <return> to continue, or q <return> to quit---#8  gfuiMouse
>> (button=0, state=1, x=<optimized out>, y=<optimized out>) at gui.cpp:398
>> #9  0x00007ffff6d4c7d8 in glutMainLoopEvent () from
>> /usr/lib/x86_64-linux-gnu/**libglut.so.3
>> #10 0x00007ffff6d4cd81 in glutMainLoop () from
>> /usr/lib/x86_64-linux-gnu/**libglut.so.3
>> #11 0x00000000004013b6 in main (argc=8, argv=0x7fffffffe068) at
>> main.cpp:134
>> (gdb) quit
>> A debugging session is active.
>>
>>      Inferior 1 [process 20925] will be killed.
>>
>> Quit anyway? (y or n) [answered Y; input not from terminal]
>>
>>
>>
>> ------------------------------**------------------------------**
>> ------------------
>> Try New Relic Now & We'll Send You this Cool Shirt
>> New Relic is the only SaaS-based application performance monitoring
>> service
>> that delivers powerful full stack analytics. Optimize and monitor your
>> browser, app, & servers with just a few lines of code. Try New Relic
>> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_**
>> d2d_may <http://p.sf.net/sfu/newrelic_d2d_may>
>>
>>
>>
>> ______________________________**_________________
>> Torcs-users mailing list
>> Tor...@li....**net <Tor...@li...>
>> https://lists.sourceforge.net/**lists/listinfo/torcs-users<https://lists.sourceforge.net/lists/listinfo/torcs-users>
>>
>>
>

Hi st

Cool, you seem to be very busy with TORCS, great:-)

> I've created a track supposedly located on the waterfront, an illusion
> more or less supported by the background image. Unfortunately, if I run
> trackgen with the -a option, even when the "border margin" is 0 or a
> negative value, trackgen adds the terrain to the outside of the track to
> form that typical rectangle of terrain. This totally ruins the creative
> intent and the appearance. The track without the terrain at all is
> equally unsatisfactory, as if the track were floating in the air.
>
> I checked trackgen -h and tried the -B option, which removed the outside
> terrain at some parts but not entirely (this example image
> http://www.mojoimage.com/free-image-hosting-view-12.php?id=1295torcs-terrain1.png

I cannot load the image for some reason, but lest have a look...
Ok, I cannot see an option which helps you without using a 3d-modeler 
tool. But possible "hacks" would be:
- using -B with an outside line far below the horizon: but for this you 
require a 3d-modeler to setup the 3d model of the outside line, I guess 
this is not what you are looking for
- Using a height map which puts the outside terrain on a very low level, 
such that you cannot see it with the normal cameras
- Hacking trackgen: in src/tools/trackgen/easymesh.cpp, around line 
2270, look for exterior/interior, just comment out the undesired part

>   shows the problem area in yellow). Are there any other tricks to help
> me get rid of the unwanted terrain so this track wouldn't look
> absolutely ridiculous? Please don't point to the masterpiece also known
> as Blender. In my desperation, I tried opening the -msh.ac file there

You can use ac3d, but this is not free...

> (which did open), but I literally can't do anything in that chaotic
> environment. If there's any other option and maneuver left to try, I'd
> gladly hear about it.

Yes, Blender is as well hard for me, I think for a somebody using it 
often it is great, but just for here and then it is (at least for me) 
not that easy to use.

Best regards

Bernhard

Hi st
> This is a continuous nuisance and a cause for engine overheating, and I

:-)

> hope there is a simple solution. In my track creation and editing
> efforts, I always have to re-start TORCS like a hundred times to see how
> the track looks and what changes are still needed, and the stupid mouse

Why do you restart it, the track list is updated (IIRC) when you enter 
the track selection, and if the track name does not change you just need 
to restart the race to see the modified track (because it is loaded at 
the start of the race)?

> pointer from the desktop is always in the way, right in the middle of
> the screen, the last thing I need before my eyes. And while you might
> consider this totally trivial, it really slows me down a lot, having to
> always reach for the mouse and chase the uninvited pointer off the
> screen before being able to continue to the track. And multiply that by
> a hundred (or whatever), and it really gets annoying.

Ok, yes, such stuff can be annoying...

> Now, is there a way to edit the game code so that the pointer would no
> longer appear in the middle of the screen as described above but
> preferably at the bottom? I know "make" probably needs to be run
> afterward too. If anybody out there could point out the right source
> file where this variable is and how to alter it appropriately, I'd be
> grateful, and the misfiring engine might cool down too.

Lets see...
find . -name "*.cpp" -exec grep -H -i cursor {} \;

-> so src/libs/tgfclient/gui.cpp looks interesting, maybe "GfuiMouseShow"?

Then google:
https://www.google.com/search?q=glut+mouse+cursor+positioning

-> glutWarpPointer could do the trick

Looking for this in TORCS:
find . -name "*.cpp" -exec grep -H -i Pointer {} \;

-> src/libs/tgfclient/gui.cpp -> glutWarpPointer, GfuiMouseSetPos, this 
could be your thing:-)

Maybe you need to dig a tad further, but I guess this is a major hint 
for your solution, the next step would be to look up the places where
GfuiMouseSetPos is used.

But as I pointed out above, I think the main flaw is that you restart 
TORCS at all, if you just edit an existing track restarting the game 
session should relaod the track, not even reselection of the track 
should be required;-)

Keep us informed about your solution (hacked TORCS or adopted workflow, 
whatever).

Best regards

Bernhard

Hi McCriddle

The ultimate reason for this is probable a fixed memory leak in 1.3.4. I 
the CVS you can find a fixed robotgen script:
http://torcs.cvs.sourceforge.net/viewvc/torcs/torcs/torcs/robotgen?revision=1.4.2.1&view=markup&pathrev=r1-3-1

And have a look at this, this is likely the cause:
http://www.berniw.org/trb/forum/showthread.php?topicid=3508

Let us know if this helped, usually the solution of such stuff is pretty 
easy, so keep going.

Best regards

Bernhard


On 05/23/2013 01:31 PM, Michael Sieben wrote:
> Hi,
>
> i'm trying to setup torcs for robot-dev.
>
> I'm running on Ubuntu 13.04 and used the current torcs-1.3.4 sources.
>
> Basically i followed the tutorial at
> http://www.berniw.org/tutorials/robot/tutorial.html
>
> After applying a patch ( see
> http://comments.gmane.org/gmane.games.torcs.general/1584 ) i got the
> game running and can start race without any problems.
>
> Using the robotgen from the tutorial i generated and compiled my basic
> robot and then tried to test it.
>
> Unfortunately torcy crashes whenever i try to modify the race settings (
> Configura race ) as soon as i hit "Accept" in the track selection.
>
> I hope someone can give me a hint where my environment is lacking.
>
> Thanks in advance
> McCriddle
>
>
> Here is the output from torcs -d :
>
> GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/local/lib/torcs/torcs-bin...done.
> (gdb) Starting program: /usr/local/lib/torcs/torcs-bin -l
> /home/linadmin/.torcs -L /usr/local/lib/torcs -D
> /usr/local/share/games/torcs
> warning: no loadable sections found in added symbol-file system-supplied
> DSO at 0x7ffff7ffa000
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Visual Properties Report
> ------------------------
> Compatibility mode, properties unknown.
> [New Thread 0x7fffeee39700 (LWP 20929)]
> [New Thread 0x7fffee638700 (LWP 20930)]
> [New Thread 0x7fffeb474700 (LWP 20931)]
> [Thread 0x7fffeb474700 (LWP 20931) exited]
> [New Thread 0x7fffeb474700 (LWP 20932)]
> [New Thread 0x7fffe6c72700 (LWP 20933)]
> [Thread 0x7fffe6c72700 (LWP 20933) exited]
> [Thread 0x7fffeb474700 (LWP 20932) exited]
> [Thread 0x7fffee638700 (LWP 20930) exited]
> [Thread 0x7fffeee39700 (LWP 20929) exited]
> process 20925 is executing new program: /usr/local/lib/torcs/torcs-bin
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Visual Properties Report
> ------------------------
> Compatibility mode, properties unknown.
> [New Thread 0x7fffeee39700 (LWP 20934)]
> [New Thread 0x7fffee638700 (LWP 20935)]
> [New Thread 0x7fffeb474700 (LWP 20936)]
> [Thread 0x7fffeb474700 (LWP 20936) exited]
> [New Thread 0x7fffeb474700 (LWP 20937)]
> [New Thread 0x7fffe6c72700 (LWP 20938)]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff613ac51 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) #0  0x00007ffff613ac51 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x00007ffff613a8c6 in strdup () from /lib/x86_64-linux-gnu/libc.so.6
> #2  0x00007ffff4de3389 in RmDriversSelect (vs=vs@entry=0x7ffff73859c0
> <ds>) at driverselect.cpp:360
> #3  0x00007ffff717e758 in reConfigRunState () at racemanmenu.cpp:155
> #4  0x00007ffff75b0447 in GfuiScreenActivate (screen=0x2839ea0) at
> gui.cpp:491
> #5  0x00007ffff4de176b in rmtsDeactivate (screen=<optimized out>) at
> trackselect.cpp:80
> #6  0x00007ffff4de1871 in rmtsSelect () at trackselect.cpp:171
> #7  0x00007ffff75b025b in gfuiMouse (y=<optimized out>, x=<optimized
> out>, state=1, button=0)
>      at gui.cpp:423
> ---Type <return> to continue, or q <return> to quit---#8  gfuiMouse
> (button=0, state=1, x=<optimized out>, y=<optimized out>) at gui.cpp:398
> #9  0x00007ffff6d4c7d8 in glutMainLoopEvent () from
> /usr/lib/x86_64-linux-gnu/libglut.so.3
> #10 0x00007ffff6d4cd81 in glutMainLoop () from
> /usr/lib/x86_64-linux-gnu/libglut.so.3
> #11 0x00000000004013b6 in main (argc=8, argv=0x7fffffffe068) at main.cpp:134
> (gdb) quit
> A debugging session is active.
>
>      Inferior 1 [process 20925] will be killed.
>
> Quit anyway? (y or n) [answered Y; input not from terminal]
>
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
>
>
>
> _______________________________________________
> Torcs-users mailing list
> Tor...@li...
> https://lists.sourceforge.net/lists/listinfo/torcs-users
>

Hi,

i'm trying to setup torcs for robot-dev.

I'm running on Ubuntu 13.04 and used the current torcs-1.3.4 sources.

Basically i followed the tutorial at
http://www.berniw.org/tutorials/robot/tutorial.html

After applying a patch ( see
http://comments.gmane.org/gmane.games.torcs.general/1584 ) i got the game
running and can start race without any problems.

Using the robotgen from the tutorial i generated and compiled my basic
robot and then tried to test it.

Unfortunately torcy crashes whenever i try to modify the race settings (
Configura race ) as soon as i hit "Accept" in the track selection.

I hope someone can give me a hint where my environment is lacking.

Thanks in advance
McCriddle


Here is the output from torcs -d :

GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/lib/torcs/torcs-bin...done.
(gdb) Starting program: /usr/local/lib/torcs/torcs-bin -l
/home/linadmin/.torcs -L /usr/local/lib/torcs -D
/usr/local/share/games/torcs
warning: no loadable sections found in added symbol-file system-supplied
DSO at 0x7ffff7ffa000
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Visual Properties Report
------------------------
Compatibility mode, properties unknown.
[New Thread 0x7fffeee39700 (LWP 20929)]
[New Thread 0x7fffee638700 (LWP 20930)]
[New Thread 0x7fffeb474700 (LWP 20931)]
[Thread 0x7fffeb474700 (LWP 20931) exited]
[New Thread 0x7fffeb474700 (LWP 20932)]
[New Thread 0x7fffe6c72700 (LWP 20933)]
[Thread 0x7fffe6c72700 (LWP 20933) exited]
[Thread 0x7fffeb474700 (LWP 20932) exited]
[Thread 0x7fffee638700 (LWP 20930) exited]
[Thread 0x7fffeee39700 (LWP 20929) exited]
process 20925 is executing new program: /usr/local/lib/torcs/torcs-bin
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Visual Properties Report
------------------------
Compatibility mode, properties unknown.
[New Thread 0x7fffeee39700 (LWP 20934)]
[New Thread 0x7fffee638700 (LWP 20935)]
[New Thread 0x7fffeb474700 (LWP 20936)]
[Thread 0x7fffeb474700 (LWP 20936) exited]
[New Thread 0x7fffeb474700 (LWP 20937)]
[New Thread 0x7fffe6c72700 (LWP 20938)]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff613ac51 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) #0  0x00007ffff613ac51 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff613a8c6 in strdup () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff4de3389 in RmDriversSelect (vs=vs@entry=0x7ffff73859c0 <ds>)
at driverselect.cpp:360
#3  0x00007ffff717e758 in reConfigRunState () at racemanmenu.cpp:155
#4  0x00007ffff75b0447 in GfuiScreenActivate (screen=0x2839ea0) at
gui.cpp:491
#5  0x00007ffff4de176b in rmtsDeactivate (screen=<optimized out>) at
trackselect.cpp:80
#6  0x00007ffff4de1871 in rmtsSelect () at trackselect.cpp:171
#7  0x00007ffff75b025b in gfuiMouse (y=<optimized out>, x=<optimized out>,
state=1, button=0)
    at gui.cpp:423
---Type <return> to continue, or q <return> to quit---#8  gfuiMouse
(button=0, state=1, x=<optimized out>, y=<optimized out>) at gui.cpp:398
#9  0x00007ffff6d4c7d8 in glutMainLoopEvent () from
/usr/lib/x86_64-linux-gnu/libglut.so.3
#10 0x00007ffff6d4cd81 in glutMainLoop () from
/usr/lib/x86_64-linux-gnu/libglut.so.3
#11 0x00000000004013b6 in main (argc=8, argv=0x7fffffffe068) at main.cpp:134
(gdb) quit
A debugging session is active.

    Inferior 1 [process 20925] will be killed.

Quit anyway? (y or n) [answered Y; input not from terminal]

I tried to draw attention to this topic many months ago, to no avail. I
don't know if I'm wasting my breath here, but these are my experiences
and findings and some suggestions too, based on a gazillion test races,
on the default, on others' and on my own tracks. And when I use the term
"idiots" in the following, it only refers to the (mis)behavior of the
robots, not in any way to their creators. If anything, I must be the
human idiot here, unable to rein in those aggressive brutes and make
racing more tolerable (to say nothing of enjoyable). 

If you doubt any of my observations, pick up some example tracks at
http://stdesigns.orgfree.com/ttrx/  and run test races to see the
motorized mayhem and brutality with your own eyes. For longer tracks
(>1.5 miles), I'd recommend at least 30-50 laps, for short tracks,
80-150 laps. 20+ robots in the field, whatever your video card can
handle (the more robots, the more obvious their failings). Park your car
on pit road (to get it out of the way) and start watching (F9
recommended for the best views, PageUp and PageDown to switch between
cars) things unfold.

These are the biggest problems I've witnessed on all tracks, road and
oval alike. 

1. blind driving, an overly aggressive raceline (left side of this
example image
http://www.mojoimage.com/free-image-hosting-view-12.php?id=4768torcs-racel1.png)
that ALWAYS leads to incidents in turn entry (inside, 1 in image) and
exit (outside, 2 in image). It's impossible to race like that on an oval
(at least two lines available), and even on a (narrower) road course,
such recklessness will breed trouble. The track width is irrelevant:
most of the ovals are ~15 meters wide, which easily allows 3-wide racing
(this even happens on the incredibly wide default ovals). Yet the anal
idiots always come pushing in turns, no matter what, always cut off a
car on the inside when entering the turn and then push a car on the high
side into the wall at turn exit. This demolition-derby boneheadedness is
absolutely infuriating, a death blow to actual racing. Mikey Schumacher
is a choirboy compared to these single-minded wreckers.

A solution (illustrated by the right side of the example image
http://www.mojoimage.com/free-image-hosting-view-12.php?id=4768torcs-racel1.png):
changing the robot code so that a robot would stick to ONE line in
turns, be it on the inside or outside or in the middle of the track.
Also eliminating the totally unnecessary pushing and hooking in turns
when there's enough room for passing (true on most tracks). Yes, some
might claim the latter is part of racing, and maybe in the final laps in
a battle for the win, but in this game, the same BS happens all the
time, over and over again, pointless brutality that only detracts from
the racing. 

2. the same aggressive raceline way too close to the inside of the track
in turns (as approximately shown in the example image), leads to idiotic
and repetitive collisions with the pit wall on tracks where the wall
begins in a turn; disrupts the racing itself. A test race on mr-speedway
or nt-speedway shows this perfectly, though it occurs on numerous other
ovals too, including tracks where the pit wall is only on the front
straight, e.g. hm-speedway, ne-speedway; also on road courses where the
pit wall begins in a turn (Country Club for example).

Two possible solutions: changing the robot code so that the robot
wouldn't drive so close to the inside in a turn, thus perhaps avoiding
the wall; or changing the game code to allow the addition of another
track element ("the apron", asphalt or grass or both) between the "main
track" and the "left border" (pit wall), a common detail on many tracks
which would both improve the track appearance (more realistic) and put
an end to the robots' suicidal head-on crash course with the pit wall.
Widening the main track itself or creating a "fake" apron (by
manipulating the track texture) wouldn't make any difference as the
robots would drive right at the bottom anyway, determined by their
current code. 

3. the inability of robots to back up after hitting/making contact with
a wall, their hopeless attempt to bulldoze through the wall instead of
simply backing up and resuming driving; a frequent occurrence when they
hit the pit wall; however, some robots also get stuck on the outside
wall and keep pushing toward it instead of hitting the reverse and
continuing the race. 

Solution: there must be something off in the robot code that causes
this, something a competent and willing coder could correct. 

4. the inability of robots to drive smoothly (in a race, NOT on solo
runs), on straightaways and in turns. This leads to frequent incidents
when some idiot slams on the brakes all of a sudden, leaving a poor
human no time to react and swerve (obviously affects other robots too).
And as always happens upon contact, the human-controlled car is sent
into the wall or airborne while the slowpoke offender drives away
happily. This behavior is probably related to or a consequence of the
blindness and aggression described in 1. This kind of erratic driving
also puts the robots at a disadvantage: a human racer, if able to avoid
the aggressors and their endless repertoire of tricks, can often lap the
field or the majority of them unnaturally soon, not exactly the sign of
good racing.

Solution: same as above in 1.

5. pounding against the pit wall on the front straight/stretch, either
on the trackside or on pit road, totally inexplicable and absurd. Might
be related to blindness and aggression, also to their pit road failures
(see below in 7).

6. the infuriating bulldoze-through-any-obstacle behavior that causes
nothing but trouble on the track. Why can't the robots back up and go
around an obstacle (stopped car) cleanly instead of forcing their way
through it? Is it totally inconceivable and impossible to change the
robot code so that they would no longer act like rageaholics behind the
wheel? Combined with the pit-wall collisions explained in 2, this
senseless banging effectively takes out most cars in races, with a field
of 25 very often reduced to ~5 cars. Is this supposed to be a race track
or some post-Matrix fight club?

7. pit road failures: going to the pits without finding the right pit
stall (even with realistic 9-11 meter-long pit stalls) and returning to
pit road on every lap, only to fail again, a complete waste of energy; 

turning onto pit road (usually the left side) only one track segment
before the beginning of pit road, instead of the actual entry point
determined in the "Pits" section of a track.xml (very problematic on
tracks where the last segment before pit road is really short, usually
because of different, more realistic textures/lines on the left side of
the track, visible at least on is-speedway, mt-speedway, ri-speedway,
sb-speedway);

ignoring the pit exit segment in the "Pits" section as well, instead
merging onto the track in the middle of turn 1, damn the torpedoes; 

in a longer race, never even turning onto pit road for fuel, instead
running out of it and crawling along the track, another recipe for
disaster and invitation to the rageaholic drummers. The pit road entry
point in the "Pits" section is usually far enough for the robots to be
able to get off the track in time and turn onto pit road, but for some
unknown reason, they don't even try to pit; 

in races where they do go to the pits, the robots usually delay their
pit stop way too much, with less than 1 liter of fuel in the tank, and
if they fail to find that pit stall, they drive off and inevitably run
out of fuel on the next lap. This should be alterable in the robot code
(right?), the amount of fuel left that causes them to pit;

some robots occasionally stopping on the track on the front
straight/stretch (right alongside the pit wall) and supposedly trying to
pit there, completely idiotic and suicidal, with others coming down the
front straight/stretch at breakneck speed while these morons decide to
park right there. This may occur on tracks with a curving front stretch
or a simple front straight too; 

olethros-specific issues: this robot acts like a complete psycho on pit
road, often turning onto it very late, losing control, slapping against
the wall, then parking in the middle of it in an attempt to pit,
failing, driving off and pounding continuously against the pit wall on
the front straight in its rage, finally rushing back in the middle of
traffic in turn 1. Even when it does find its way to the left side of
pit road, more often than not it doesn't find the pit stall and keeps
coming back to pit road as described in the first example of these pit
road failures. 

-----
I hope everybody understands the intent of this long message is to help
with the development of this racing (the operative word here) game, not
to deride the efforts or abilities of unpaid volunteers. I've simply
tried to honestly and accurately describe the flaws of robots that
should deserve more attention in the game development. And since I lack
the skill and understanding of the game code to make any changes myself,
this lengthy appeal needed writing. Now the truth is out there. Thanks
for sticking it out, and drive safely.

st
http://stdesigns.orgfree.com/

-- 
http://www.fastmail.fm - Access all of your messages and folders
                          wherever you are

I've created a track supposedly located on the waterfront, an illusion
more or less supported by the background image. Unfortunately, if I run
trackgen with the -a option, even when the "border margin" is 0 or a
negative value, trackgen adds the terrain to the outside of the track to
form that typical rectangle of terrain. This totally ruins the creative
intent and the appearance. The track without the terrain at all is
equally unsatisfactory, as if the track were floating in the air. 

I checked trackgen -h and tried the -B option, which removed the outside
terrain at some parts but not entirely (this example image
http://www.mojoimage.com/free-image-hosting-view-12.php?id=1295torcs-terrain1.png
 shows the problem area in yellow). Are there any other tricks to help
me get rid of the unwanted terrain so this track wouldn't look
absolutely ridiculous? Please don't point to the masterpiece also known
as Blender. In my desperation, I tried opening the -msh.ac file there
(which did open), but I literally can't do anything in that chaotic
environment. If there's any other option and maneuver left to try, I'd
gladly hear about it. 

st
http://stdesigns.orgfree.com/

-- 
http://www.fastmail.fm - IMAP accessible web-mail

This is a continuous nuisance and a cause for engine overheating, and I
hope there is a simple solution. In my track creation and editing
efforts, I always have to re-start TORCS like a hundred times to see how
the track looks and what changes are still needed, and the stupid mouse
pointer from the desktop is always in the way, right in the middle of
the screen, the last thing I need before my eyes. And while you might
consider this totally trivial, it really slows me down a lot, having to
always reach for the mouse and chase the uninvited pointer off the
screen before being able to continue to the track. And multiply that by
a hundred (or whatever), and it really gets annoying.

Now, is there a way to edit the game code so that the pointer would no
longer appear in the middle of the screen as described above but
preferably at the bottom? I know "make" probably needs to be run
afterward too. If anybody out there could point out the right source
file where this variable is and how to alter it appropriately, I'd be
grateful, and the misfiring engine might cool down too.

st
http://stdesigns.orgfree.com/

-- 
http://www.fastmail.fm - One of many happy users:
  http://www.fastmail.fm/help/overview_quotes.html

Hi

Please run the commands without "",e.g.

java -version

I just use "command" to denote it.

Best regards

Bernhard

On 05/03/2013 01:54 AM, AceMot wrote: