Re: [Torcs-ng-devel] New Interfaces

[Annick et Jean-P. <jpm...@fr...>]

Mart, Wolf-Dieter and all.

Some thought I have, hoping this helps to converge to a good
and stable solution :

- the name of the DLL/SO/... file is today the Torcs-NG-internal name
   of the associated robot (the one that is passed to the robot
   through moduleWelcome(...), and this name is also the one of the directory
   where the DLL/SO/... file is installed, and also where the robot XML file
   is stored, and also the name of the robot XML file itself (without ".xml")

   to my mind, these constraints are not a problem : only Torcs-NG rules
   that a robot have to follow if it wants to race ...

- for "schismatic" robot DLLs, the above rules force us
   to copy and rename the DLL file to get a new "AI driver set for special cars
   and or tracks"

   * that copy is really NOT a problem : it can be made at install time,
     or manually in a Torcs-NG binary installation (for people who want
     to setup a new "AI driver set for special cars and or tracks"
     without having to even compile Torcs-NG)

   * there is no associated source copy (look at drivers/simplix source tree).

   * the only issue I can see is the memory one : multiple DLLs are loaded
     with the same code, whereas this code could be loaded only once
     in an ideal solution ;

     and Mart proposed us one of these "ideal" solutions (robot merge)

   * to my mind, we can well stay with this copy-stuff for the release,
     and adopt Mart's solution afterward : no backward compatibility issue
     about it.

- we should NOT change anything in the tModInfo structure ...
   otherwise, robot backward compatibility is broken !

- to my mind, we should not make module loading/querying more complicated
   than it is already ... more precisely, I find Wolf-Dieter's proposal to use
   a base/derived "class" (a C implementation) scheme to initialize
   modules in a different way according to their "type" (the "robot" type,
   the "human" type, the "ssgraph" type ...) ... a complicated solution.

   May be we could simply add usefull services in robottools to achieve
   the same purpose.

- I'm also not very fond of moduleWelcome returning a "robot interface version",
   because Torcs-NG's side will soon become a hard-to-maintain piece of code
   with many choices ... do we really need this, and why ?

   To my mind, each robot has to implement at least one of the "robot interfaces"
   (the legacy one from Torcs, or the new one),
   and may be the two ones, Torcs-NG selecting the "better" one through
   a hard-coded strategy. The new one enables the robot to know the version
   REQUIRED by Torcs-NG, and so to adapt to what he knows and can do.


Finally, another way to try to converge : to you opinion, what remaining
issues and missing features to you see in current implementation
of the robot interface (new scheme with moduleWelcome, Initialize and Terminate) ?

Cheers,

Jean-Philippe.