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

Hi, Christos, and all.

>> Currently working on force feedback integration in Torcs,
>> I am very close to the moment when I'm able to inject some effects into my wheel.
> 
> Since we already use the Pacejka formula, adding the aligning force is
> trivial.  I hope that it works correctly.
> 
> I guess I can export a couple of variables in some structure..
> How about
> struct SteeringFeedback {
> 	float align; // magnitude of the horizontal force
> 	float bump; // magnitude of the vertical force
> 	float bump_frequency; // in case the force updates are too slow
> };

Great !

But, just to see if I understand (feel free to correct me if not) :
- what you call "magnitude of the horizontal force" is the _signed_ magnitude
   (say negative on left hand side and positive on right hand side, or reverse,
    depending on the orientation of the axis) of the force that "tries and force"
   the front (steering) wheels to align themselves back
   to the car movement axis ?
- what you call the "magnitude of the vertical force" is the magnitude
   of the force that the front (steering) wheels feel from the ground ?
   I guess this time, this force is always positive or nul ... am I right ?
- for the "bump_frequency", when you say "in case the force updates
   are too slow", do you means that :
   - if we are able to feed the device at a sufficient pace (Shannon says :
     at least twice the frequency of the vibration that the wheels feel
     when rolling on a kirb), there is no need for the "bump_frequency"
     as we can simply use a ConstantForce effect,
     updated at the sufficient pace ?
   - if not (too high speed for the car, too slow device effect update pace),
     we need this bump_frequency to inject a consistent Periodic Force Effect
     in the device ?

> Now, there bumps may be a bit tricky.  The simulation's dt is currently
> 0.002 if I remember correctly.

What do you call the "simulation's dt" ? I was believing that the pace of the
simulation was variable, according to the current frame rate ? In other words,
that, say, the human module "rbDrive()" function was called once per global
Torcs loop (the one that runs and runs raceengineclient/raceengine::ReUpdate(),
and so the update function of the simulation engine) ?

Does this have something to do with the fact that 
raceengineclient/raceengine::ReOneStep is called multiple times (loop) inside
of raceengineclient/raceengine::ReUpdate() ?

Can you explain how it works, then ?

> I think that the control feedback is set to 0.01, though I could be wrong.

What do you mean by "control feedback" ? In Torcs ? in the device ? ... ?

May be that's not relevant, but a quick computation indicates that
a car that rolls at 200 km/h on a kerb with a bump every 50cm,
will experience a 111 Hz vibration (200*1000/3600/0.5).
Does this ~0.01s period as something to see with your 0.01 value
for the "control feedback" ?

 > In that case, you wouldn't need a bump_frequency, just a magnitude for the 
vertical forces and then how
> that is handled would depend on the actual feedback wheel used.
> Are there any other forces that you'd feel on the wheel?

For the moment, I have no ther idea, but may be someone else
with more physics skills and feelings will ...

> I think I'll add the structure in interfaces/car.h and
> add it to the tPrivCar structure.
> 
> How's that?

Simply GREAT !

I'm very impatient to get your patch ;-)

Thanks a lot for you quick answer and help.

Cheers,

Jean-Philippe.

Hi everybody,

My name is Michael and I work at the Robotics Institute at the 
University of Valencia (Spain).

We've been doing some amazing work with torcs here. Our goal is to 
develop an urban driving simulator, so I've modified torcs in order to 
represent crossroads, dead ends, etc.

There are two new segment types: crossroad (TR_XRD) and dead end 
(TR_DED).

I've added some extra info to the XML 3D description, modified 
trackeditor in order to edit these new segments in a visual way, as 
well as the track.dll module, and the trackgen tool to generate the .ac 
3D model with the new XML specification.

Where next?
Well, I guess we may start editing some collision stuff in torcs race 
engine, adding traffic lights, and develop a robot capable of navigate 
trough the new links present in crossroads while respecting traffic 
rules in order to setup surrounding traffic.

A couple of screenshots showing new torcs track editor and the ac3d 
generated file of a test track are attached to this mail.

Of course, we want to release all the source code if anyone is 
interested.

Greetings.

--
/*********************************
* Miguel Angel Expósito Sánchez *
*********************************/

Annick et Jean-Philippe wrote:
> Hi, all.
> 
> Currently working on force feedback integration in Torcs,
> I am very close to the moment when I'm able to inject some effects
> into my wheel.
> 
> But now, it's time to really think about :
> 1) what effects we want to render in the drivers hands
>     (let's list them all ; we'll see later if we can, depending on the FF device)
> 2) what forces / moments computed into the physics simulation engines
>     (simu V2 and simu V3) we can use to set effects / effects parameters ;
>     and may be there is a need to compute other ones ?
> 3) how we get these forces / moments from the simu interface
>     to the human driver module.
> 
> I have some very small ideas about that, but really need your input :
> 
> 1) - increase the steering counter-force with speed
>       (more and more hard to steer when speed increases,
>        linked to wheels' inertia, and also active steering systems)

We'll have to see if that works out.

>     - provide some vibrations when rolling on kerbs,
>       but also on sand, grass, ... or bumpy road / track
>       (we have data about the ground under each wheel,
>        but can we have / compute realistic "vibration" frequencies
>        for these different grounds, apart from the real bums/holes ?)

This should be handled directly from the suspension info.

>     - is there a way to make the driver feel in its hands
>       * the spinning of the front wheels for front wheel drive cars
>       * the sliding of these wheels when the car under-steers
>

In general I don't feel the first one on the wheel itself..  I can feel
the second one more from the sound

Annick et Jean-Philippe wrote:
> Hi, all.
> 
> Currently working on force feedback integration in Torcs,
> I am very close to the moment when I'm able to inject some effects
> into my wheel.
> 

Since we already use the Pacejka formula, adding the aligning force is
trivial.  I hope that it works correctly.

I guess I can export a couple of variables in some structure..
How about
struct SteeringFeedback {
	float align; // magnitude of the horizontal force
	float bump; // magnitude of the vertical force
	float bump_frequency; // in case the force updates are too slow
};

Now, there bumps may be a bit tricky.  The simulation's dt is currently
0.002 if I remember correctly.  I think that the control feedback is set
to 0.01, though I could be wrong.  In that case, you wouldn't need a
bump_frequency, just a magnitude for the vertical forces and then how
that is handled would depend on the actual feedback wheel used.

Are there any other forces that you'd feel on the wheel?

I think I'll add the structure in interfaces/car.h and
add it to the tPrivCar structure.

How's that?

Hi, all.

Currently working on force feedback integration in Torcs,
I am very close to the moment when I'm able to inject some effects
into my wheel.

But now, it's time to really think about :
1) what effects we want to render in the drivers hands
    (let's list them all ; we'll see later if we can, depending on the FF device)
2) what forces / moments computed into the physics simulation engines
    (simu V2 and simu V3) we can use to set effects / effects parameters ;
    and may be there is a need to compute other ones ?
3) how we get these forces / moments from the simu interface
    to the human driver module.

I have some very small ideas about that, but really need your input :

1) - increase the steering counter-force with speed
      (more and more hard to steer when speed increases,
       linked to wheels' inertia, and also active steering systems)
    - provide some vibrations when rolling on kerbs,
      but also on sand, grass, ... or bumpy road / track
      (we have data about the ground under each wheel,
       but can we have / compute realistic "vibration" frequencies
       for these different grounds, apart from the real bums/holes ?)
    - even provide shocks when hardly bumping on kerbs
    - is there a way to make the driver feel in its hands
      * the spinning of the front wheels for front wheel drive cars
      * the sliding of these wheels when the car under-steers

2) Racer <http://www.racer.nl> : they use
    * the steering wheels/tires aligning torque, computed through a Pacejka
      model, to inject a constant force effect,
    * the speed of the car and the "force applied by the ground
      on the steering wheels/tires", when one roll on a kerb,
      to inject a periodic force effect

    Vdrift <http://vdrift.net> is at the very beginning, only testing ...

3) After a quick look into car.h, I don't understand many details,
    but I feel that we lack some variables here to make the job ...
    Then, looking further into simuV2/V3, I found many more computed variables,
    but I don't see clearly the ones that could we exported ...
    even if some have a nice name, like "feedback", "raeaction", "Inertia", ...

I'm pretty sure some of you guys have very precise ideas about all this ...

Your help would be greatly appreciated !

Cheers, Jean-Philippe.

PS: As far as libs, compilation, ... that is code is concerned, I'm working
     with the very promising open source library OIS <www.wreckedgames.com>,
     that already provides force feedback under Windows (R 1.2.0)
     in a very close future under Linux (there is a published patch
     on the forum), but not under Mac OS for the moment, even if the
     infrastructure is ready now.

     My opinion is that when Torcs is ported to SDL (isn't it already ?),
     we have the opportunity to get rid of Plib/js and replace it by OIS,
     that already ships a SDL input manager ... so, no supplementary dependency !

     When I have something working, you'll get the patch and the HOW-TO-BUILD
     (if you are interested, of course).

My English is not good, but I try write a good message. 

TORCS is a great simulator, it simulates physical process but it is not posible play in Network, ¿ Do yoy think that is dificult add network support ? ¿ Someone is workink in it ?



_________________________________________________________________
Tecnología, moda, motor, viajes,…suscríbete a nuestros boletines para estar siempre a la última
Guapos y guapas, clips musicales y estrenos de cine. 

Hi, all.

This is a small patch that fixes little bugs
around displaying results in race screens
(the name of the car of the driver is often replaced by random chars,
  coming from released string pointers ...).

To apply it,
- get the last CVS revisions of src/libs/raceengineclient/raceresults.cpp
   and src/libs/racescreens/miscscreens.cpp
- cd into the directory that constains src
- patch -p1 <raceResultsCarName.patch

Please, test and tell me.

Cheers,

Jean-Philippe.

Hi, all.

For the happy owners of a Logitech G25 wheel that did not manage yet
to enjoy the full features of the beast under Linux, this is a small
summary of what I found on the net and my own humble experience about it
on a 2.6.22.9 Kernel (Mandriva 2008.0 x86_64) :

Note: This is only my own understanding and summarizing of what people cleverer
       than me discovered by themselves. My work only consisted to put
       all the stuff together in an as clear, simple and explict as possible
       sum-up. See at the bottom for references and real authors.

1) when plugged in, the G25 identies itself as a Logitech Formula Force EX
    USB device (046d:c294) ; you only get 4 axes and 12 buttons, that is
    neither clutch pedal nor any of the 3trd to 6th gear on the grid shifter
2) to get the lacking native features of the beast, it must be sent a command
    to switch to its native mode, that makes it disconnect and reconnect
    as itself this time (USB device ids 046d:c299)
    Note: Another similar command can also switch it to the Logitech Driving
          Force Pro mode.
3) to send the command, you need a userland tool that basically writes
    the associated bytes on the USB device, and the one I am using is
    usbtool <ftp://srv.l14.ru/pub/usbtool-0.1.tar.gz>
    (the package includes pre-built binaries for python 2.5,
     and sources if you need to build it yourself) ;

    to swhitch the G25 to its native mode, after plugging it in, I simply use :
      ./usbtool -v g25-set-extended-mode

    Note: you can also send other pre-configured commands with the usbtool
          (run ./usbtool --list-commands to see which)
          like g25-set-range-wheel-900 (teasing ;-)
    BUT: I never succeeded to send 2 successive commands to the device :
         the first one is generally OK (sometimes, though, you may need to repeat
         it), but the second (and following ones) seems to be completely ignored.

4) but this makes disappear the /dev/jsX and /dev/input/eventY devices !
    to get them back and be able to play with the G25, I use :
      sudo rmmod joydev
      sudo rmmod usbhid
      sudo modprobe usbhid
    (man sudo and sudoers to be able to run these root commands)

5) Then, if you find that the "dead zone" at the center of the wheel
    is too large (the centered angle where nothing happens when you steer into),
    it is only beacause you need to calibrate your device.
    I use jscal (ff-utils @ http://www.sourceforge.net/projects/libff)
    to do that :
    a) plug-in the device
    b) send the native mode-switch command if you like (see above 3)
    c) jscal -c /dev/jsX (X being 0, 1, ... look which in /dev after plugging-in)
    d) jstest /dev/jsX (to test if everything fits your desire)
    e) jscal -p /dev/jsX (to get the jscal command to put in your .bashrc
       or any script you would run before your favorite games ...)

Note: All this stuff should also work for a Driving Force Pro, and some says
       that it's also true for the Momo Racing wheels ... but don't tested.

Now, as far as force feedback is concerned, I have no such good news
for the moment : fftest and ffcstress don't work for me for the moment.

References:

Thanks to avl, eckzow, anrp, thelusiv, tof8pool, synapse247 and cuckoo,
  on http://vdrift.net forum :
   http://vdrift.net/Forum/viewtopic.php?t=412&postdays=0&postorder=asc&start=60
   http://vdrift.net/Forum/viewtopic.php?p=3751&highlight=linuxinput#3751
   ftp://srv.l14.ru/pub/usbtool-0.1.tar.gz

Thanks to Jiri Kosina, Chris Guirl,
  from the Linux input dev team
   http://www.mail-archive.com/lin...@at...
   http://www.mail-archive.com/lin...@vg...
(search "g25" on each list)

Hoping this helps ...

Jean-Philippe.

Hi.

I'm new to this list, but I've used torcs for some time. It's great! But now I have a problem...

I have downloaded torcs 1.3.0 and tryed to execute it.

Compilation needed --x-libraries=/usr/lib, as exposen in previous posts.

Everything compiled well (some warnings).

Executions is ok until race starts. after some secons of race screen freezes and the program stops responding. Finally it does a segmentation fault and dumps core.

/usr/local/bin/torcs: line 52: 28937 Segmentation Fault  (core dumped) $LIBDIR/torcs-bin -l $LOCAL_CONF -L $LIBDIR -D $DATADIR $*

Same source, compiled un KUbuntu 8.04 but 32 bits ruuns smoothly. No problems.

My system is:
KUbuntu Linux 8.04
compiler: gcc-4.2.3
Kernel  2.6.24-16-generic x86_64 GNU/Linux

I was not able to locate the problem.

Many thanks
Rafa Torres



      ______________________________________________ 
Enviado desde Correo Yahoo! La bandeja de entrada más inteligente.

Hi, all.

A Torcs user (Mario Veygel) has the exact same compilation pb
I experienced some time ago on Mandriva 2008 x86_64, for 1.3.0 and also CVS :

 > [Torcs-users] torcs compilation problem
 > checking for XOpenDisplay in -lX11... no
 > configure: error: Can't find libX11. Please check config.log and if you
 > can't solve the problem send the file to
 > torcs-users@li... with the subject "torcs compilationproblem"
 >
 > Of course I have libX11 and also the devel packages installed
 > (Ubuntu Hardy), so I checked what's wrong here, and found the following
 > bug in ./configure, line 6454:
 >
 > LDFLAGS="$LDFLAGS -L$x_libraries"
 > ^^
 >
 > That -L there is wrong. If I remove it, configure succeeds.
 > The same bug exists in the CVS sources.

There is probably a small issue with libX11 detection
that should be fixed (don't know how).
But waiting for that fix, I would suggest modifying configure.in
the following way : replace the line :

LDFLAGS="$LDFLAGS -L$x_libraries"

by the 3 following lines :

if test "$x_libraries" != ""; then
   LDFLAGS="$LDFLAGS -L$x_libraries"
fi

Any suggestion ?

Cheers,

Jean-Philippe.

PS: In configure.in, there is also 2 lines that could be removed,
that is the second occurence of the 2 following lines :

CFLAGS="$CFLAGS $ADDCFLAGS"
CXXFLAGS="$CXXFLAGS $ADDCFLAGS"

It's not a big issue, but it duplicates some flags in compilation commands.

Hi all,

I have submitted a little modification in simuv2 in aero.cpp to avoid 
the "nose-up" effect when cars jump.
The side effect is that the cars tend to fly a little more than before, 
but in a more natural way.

Have fun,
Eric.

Hi, all.

I discovered a bug in the patch : the idle function that cools the CPU
was used in race practice mode, when blind mode is on (only results),
and also during all kinds of race qualification (another type of "blind mode").

This is the corrected version.

Please, test and tell me about your impressions.

Cheers,

Jean-Philippe.

Hi, Wolf-Dieter.

 >> But at this point, we should look at future needs too:
 >> Give to the robot a torcs version number and torcs back a robot
 >> (interface-type) number.

At last, I found some time to examine closely your long mail explaining
your request !

> having an independent possibility to identify the interface to use helps to run a mixed mode
 > for interfaces between robots and TORCS.
 > Mixed mode means here to be able to use different TORCS-Interfaces
 > (by the robot) or to load robots of different versions (by TORCS).

By "interface version exchange" between Torcs and the robots,
do you mean something like (as an example) :
- in the robot DLL entry points, have one to get the robot interface version,
   like :
    extern "C" void getItfVersion(int* major, int* minor)
    { major = 2; minor = 0; } // Interface version 2.0
- in the robot DLL entry points, have one to set the Torcs version,
   like :
    extern "C" void indicateTorcsVersion(int major, int minor, int patch)
    { TorcsMajor = major; TorcsMinor = minor; TorcsPatch = patch}
    // TorcsMajor, Minor and Patch being global variables of the robot
- make Torcs call these 2 entry points before calling the robot
   initialization entry point extern "C" <robot name>(tModInfo* modInfo),
   in order,
   * for the robot, to be able to have a different behaviour
     from one version of Torcs to another,
   * for Torcs to initialize the robot differently from one interface version
     to another ?

> Why change the interfaces? One example is your work to use bots with variable numbers of drivers.
> Or to make the interface more flexible.
> 
> Here some informations from a coder using other languages then C/C++:
> 
> If you use only standard robots (written in C/C++) you can change a TORCS interface structure, recompile all and use it. 
 >But if you use an other programming language (like 
Delphi(windows)\Larazus(linux) = Object Pascal),
 >you have to change your code (at least update the translations of the header 
files).
 >You will do this work only, if you want to use the new features.
> 
> Example: With the change of TORCS 1.2.4 to TORCS 1.3.0 the structure of the own pit was changed:
> 
> (Delphi code:)
> {$IFDEF TORCS_V1.3.0}
>   TTrackOwnPit = packed record
>     Pos: TTrkLocPos;   // Center of the pit position
>     PitCarIndex: Int;  // Index of Car using the Pitbox
>     Lmin: Tdble;       // Pitting area length min
>     Lmax: Tdble;       // Pitting area length max
>     FreeCarIndex: Int; // Index of next free car entry
>     Car: PCarElt;      // Driver's car link
>   end;
> {$ELSE} // means V1.2.4
>   TTrackOwnPit = packed record
>     Pos: TTrkLocPos;   // Center of the pit position
>     State: Int;        // not yet used (will be used for pit sharing within teams)
>     Lmin: Tdble;       // Pitting area length min
>     Lmax: Tdble;       // Pitting area length max
>     Car: PCarElt;      // Driver's car link [TR_PIT_MAXCARPERPIT]
>   end;
> {$ENDIF}
> 
> What was bad here? If you put new things to the end only, not between, you could use the old code in the most cases unchanged. You get a pointer to the start of the structure and it does not affect you, that the block is greater now, because the sender allocates/frees the memory, you use it only (or not, no pitsharing):
> 
>   TTrackOwnPit = packed record
>     Pos: TTrkLocPos;   // Center of the pit position
>     State: Int;        // NOT USED BUT KEPT!
>     Lmin: Tdble;       // Pitting area length min
>     Lmax: Tdble;       // Pitting area length max
>     Car: PCarElt;      // Driver's car link [TR_PIT_MAXCARPERPIT]
>     PitCarIndex: Int;  // NEW: Index of Car using the Pitbox
>     FreeCarIndex: Int; // NEW: Index of next free car entry
>   end;
> 
> The central structure used now is
> 
>   TCarElt = packed record                       // car.h
>     Index: Int;         // car index
>     Info: TInitCar;     // public
>     Pub: TPublicCar;    // public
>     Dummy1: Int; // Alignment to 8 Byte instead of 4 Byte using Delphi 5
>     Race: TCarRaceInfo;	// public
>     Priv: TPrivCar;	    // private
>     Ctrl: TCarCtrl;     // private
>     PitCmd: TCarPitCmd;	// private
>     Robot: PRobotItf;	  // private
>     Next: PCarElt;      // Next in List
>     Dummy2: Int; // Alignment to 8 Byte instead of 4 Byte using Delphi 5
>   end;
> 
> Here all structures are combined ("by value"), which leads to a complete rework, if one of the structures is changed.
> 
> In many other systems an other strategy is used:
> 
>   TCarElt = packed record                       // car.h
>     Size: Int;          // Number of pointers filled in    // 4 Byte
>     Index: Int;         // Car index                       // 4 Byte so we are again on the 8 byte alignment!
>     Next: PCarElt;      // Pointer to Next in List         // 4 Byte or 8 Byte ...
>     Info: PInitCar;     // Pointer to a TInitCar structure
>     Pub: PPublicCar;    // Pointer to a TPublicCar structure
>     ...
>     Robot: PRobotItf;	// private  
>   end;
> 
> Using a list of pointers, you are free to let all structures grow without the need to change all old modules even if the new data is not used (New features/pointers are at the tail only!)

So, if I try and sum up, you are stating/suggesting that :
- until now, robot interface was changed in Torcs with no real care about
   non C/C++ robot code, assuming that "one has only to recompile
   with new headers, and all's right" ; and this is a bad assumption for
   Delphi-coded robots.
- in next Torcs versions, such brutal changes should be avoided,
- but the only solution would be to make ONE last brutal change :
   use pointers on sub-structures as main structures fields,
   in place of sub-structure values (ex: Next: TCarElt => Next: PCatElt) ;
   then, no (less?) alignement issues when adding new fields
   in sub-structures ...

You may be right, but my opinion is that it would probably imply big changes
in Torcs code for that "brutal" (;-) last big interface change ...
and that this big changes would be difficult to support against
the main stream of "I'm not interested ; it may imply some unstability ;
so I prefer not".
But you are right, it should be quite easy to try and minimize robot interface
changes ... with some mail exchanges ...

> Ok, we see there may be possible alternatives to be used by future TORCS releases.
> 
> At the moment, you want to change the size of the tModInfo structure, to fit robots with more than 10 drivers.
> Now, the first call of the module (dll) is used to get the drivers names and with the changed version this would remain.
 > After a call to the new interface 'extern "C" unsigned int <module 
name>_NbItf()', TORCS allocates
 > the memory needed and gives it to the robot to get the names.
> But this is not consequently! 

What do you mean by "consequently" ?

> A good robot should use the names, defined in the teams XML-file. So the user can change these to fit his own needs. 
 >Therefore all robot programmes would have to write code to read out this file.
 >In future, having the possibility to use robots with a variable number of 
drivers, you could get this information from this file too!
> Why not make TORCS read this file (only one implementation of the code is needed). 
 >You find the names, the descriptions, the teams, the car types, the racing 
numbers,... and the required number of drivers.
>Then allocate the memory, copy the pointers of the names and give it to the robot, together with the number of drivers to use.

You are right, all this static could be directly read by Torcs in the robot XML 
file. But by "static", I mean : that never change during races.

 >If the robot needs special names, it can change the names (set new pointers). 
If not, it only sets the function pointers for TORCS.
>If the robot knows, what version of TORCS-Interface is used, it could switch between this possibilities without much work to do.
>Having the version information (of the TORCS interface) in a structure, used for other purposes too (the "gfid" field of tModInfo
 >structure for example), means, you are not longer free to uses different 
structures because you have to know, where the imformation is!

Can you explain me the purpose of the "gfid" field ? Of course, I was not 
meaning to use it for multiple purposes at the same time !

> So a first contact with a function like "robot_interface_version = version(torcs_interface_version)" is a good idea.

OK, this seems quite close to what I was proposing in the first line of this mail.

>All following steps can be done, knowing the interfaces. 
 >You will not get more freedom to change interfaces in an distributed system 
running 24*7.

> Here a question: Why to use robotname ('extern "C" unsigned int <module name="robotname">_') as part of the function names?
> So I have to change my code at many places, if I want to use an old and a new version of my bot, to compare my work! Fixed names like "robot_module()", "robot_version()" , ... would work too, you could combine/replace it with the modules name before you use it in your lists.

Yes, you are right. It could be simpler.

> A common principle used in most systems is the sandwich pattern:
> Allocate resource
> Use resource
> Free resource
> 
> To have interfaces following this pattern will help to make coding easy.
> 
> InitModul      // allocate resources for the modul
>   InitTrack    // allocate resources for the track
>     InitDriver // looped over all drivers to allocate resources for the driver
>       NewRace  // register driver at teammanager or teammates (allocated in InitDriver)
>         ...
>       EndRace  // looped over all drivers to unregister or do statistics ...
>     Shutdown   // looped over all drivers to free resources of the driver
>   FreeTrack    // free resources for the track
> FreeModul      // free resources for the modul
> 
> At the moment we have
> 
> InitFunc       // allocate resources for the modul
>   InitTrack    // allocate resources for the track
>     NewRace    // allocate resources for the driver
>       ...
>     Shutdown   // free resources for the driver  

Actually, under Linux only, you have also the "FreeModul" : when unloading the 
modules, if a "<module name>Shut" function exists (of type tfModShut defined
in tgf.h), it is called. BUT not under windows (I don't know why, may be there's
another special Windows trap ...)

But you are right, the sandwich pattern should be fully implemented !

> If you allocate resources for a teammanager (at InitFunc), that is used by all drivers and uses track informations, when do you free it? 
 > A call to Shutdown is robot specific, you don't know if you are the last!

Right !

> Same is writing a logfile of communications between all robots and the teammanager in one file to keep the chronological order.
 > Open in InitModul and close in FreeModul is so easy.
> Yes, there are ways do solve this, on windows and linux, but why not use a calling sheme, making it easy to understand (and use) 
 > and beeing independent from windows or linux?

Right !

> At the moment, the need for changes of the interfaces is not very urgent. But if we now install the exchange of the two interface versions
 > (not TORCS version or robot version!), we can profit by this, when the need 
grows.
> And it will grow, if the game will be online playable! And the advantage of being able to use mixed modes (of interfaces) too. 
 > Not all players will have to use the same (last) version.
 > If you look how to realize it, you will see, that it would be a little step
 > to do now.

Oh, oh. But there, you are talking about BINARY compatibility between different 
versions of Torcs and one version of a robot ...
As far as I understand, we can achieve it with "robot module entry points
stuff" listed above, but what about the calls from the robots to Torcs itself ?
At least the robottools DLL should also be kept binary compatible ...
And there may be others (I'm not so much aware about robots code) ...

 >But the benefit later will be great. And torcs will be changed slowly, step by 
step, no revolutions needed, but many steps!

Good method. I agree with that.

Regards,

Jean-Philippe.

Hi, Mart, and all.

Question to all developpers at the bottom ...

> linuxModInfo is a variant of linuxModInfoDir, which is used when creating the 
> list of available robots (so you can select the robots you want to race 
> against). So I think the robot priority can be used to place your own robot 
> higher in the list such that it is easier to select it. I don't know if it is 
> actually used.

Actually, it only loads one module (contrary to linuxModInfoDir).
It is not currently called anywhere in Torcs.

>> About the calloc check (does it return 0 ?), I did not change anything,
>> but I'm open to any suggestion.
> 
> If calloc returns 0, then both the RAM memory and the swap memory (if 
> available) is full. It usually causes X (in Linux) to be very slow. So Torcs 
> isn't playable at all. So the memory of Torcs can better be used to kill the 
> program what causes the memory leak (if that doesn't kill itself), in my opinion.

Not sure to understand ... So, what do you think to be the best solution ?
1) do not check c/malloc at all (p = calloc(...); p->...) ?
2) check it, printf a message on the console (if any), and then exit(1); ?
3) same a 2, but don't exit(1) : return error code from the current function if 
applicable ?
4) any better suggestion ?

Thanks all in advance !

Cheers,

Jean-Philippe.

Hi Jean-Philippe,

Op Thursday 01 May 2008 21:34:40 schreef Annick et Jean-Philippe:
> Hi, Mart, and all.
>
> This is a new version of the second half
> of the "no maximum number of interfaces for Torcs modules" patch.
>
> It fixes the issues you detected in linux/windowsModLoad function :
>
> - if the module is already present in the modlist, it is not reloaded,
>    BUT the associated modlist item is moved to the head of the list
>    (raceinit.cpp needs that, and the lack of it in previous version
>     DID really lead to bad car<->robot assignements in certain cases
>     like the following racing driver list: bt 1, inferno 2, bt 4
>     => inferno 4 robot/car used in place of bt 2)
>    Moreover, even if linux/windowsModInfo is never used, I made the same
> fix in it and also removed the priority sorting while adding the modinfo
> item (this was a bug, wasn't it ?), to be fully consistent.

linuxModInfo is a variant of linuxModInfoDir, which is used when creating the 
list of available robots (so you can select the robots you want to race 
against). So I think the robot priority can be used to place your own robot 
higher in the list such that it is easier to select it. I don't know if it is 
actually used.

> - added documentation about the fact that modules are not reloaded
>    if already present in the list WITH EQUAL SOPATH, but are reloaded
>    each time a different sopath is used for the associated library
>    (ex: relative and absolute one). As far as I can see, this is sufficient
>    in current torcs code to avoid loading twice the same module ...
>
> About the calloc check (does it return 0 ?), I did not change anything,
> but I'm open to any suggestion.

If calloc returns 0, then both the RAM memory and the swap memory (if 
available) is full. It usually causes X (in Linux) to be very slow. So Torcs 
isn't playable at all. So the memory of Torcs can better be used to kill the 
program what causes the memory leak (if that doesn't kill itself), in my 
opinion.

> Regards,
>
> Jean-Philippe.
>
> PS: Tested on Linux Mandriva 2008.0 GCC 4.2.2 rc x86_64
> and Windows XP SP2 VC6 SP6

Regards,

Mart

Hi, Mart, and all.

This is a new version of the second half
of the "no maximum number of interfaces for Torcs modules" patch.

It fixes the issues you detected in linux/windowsModLoad function :

- if the module is already present in the modlist, it is not reloaded,
   BUT the associated modlist item is moved to the head of the list
   (raceinit.cpp needs that, and the lack of it in previous version
    DID really lead to bad car<->robot assignements in certain cases
    like the following racing driver list: bt 1, inferno 2, bt 4
    => inferno 4 robot/car used in place of bt 2)
   Moreover, even if linux/windowsModInfo is never used, I made the same fix
   in it and also removed the priority sorting while adding the modinfo item
   (this was a bug, wasn't it ?), to be fully consistent.

- added documentation about the fact that modules are not reloaded
   if already present in the list WITH EQUAL SOPATH, but are reloaded
   each time a different sopath is used for the associated library
   (ex: relative and absolute one). As far as I can see, this is sufficient
   in current torcs code to avoid loading twice the same module ...

About the calloc check (does it return 0 ?), I did not change anything,
but I'm open to any suggestion.

Regards,

Jean-Philippe.

PS: Tested on Linux Mandriva 2008.0 GCC 4.2.2 rc x86_64
and Windows XP SP2 VC6 SP6