Menu
▾
▴
speed-dreams-devel — Mailing list for developers
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(39) |
Nov
(277) |
Dec
(299) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(261) |
Feb
(162) |
Mar
(70) |
Apr
(141) |
May
(55) |
Jun
(166) |
Jul
(202) |
Aug
(122) |
Sep
(368) |
Oct
(290) |
Nov
(232) |
Dec
(516) |
| 2010 |
Jan
(302) |
Feb
(253) |
Mar
(253) |
Apr
(184) |
May
(184) |
Jun
(82) |
Jul
(62) |
Aug
(154) |
Sep
(331) |
Oct
(450) |
Nov
(312) |
Dec
(249) |
| 2011 |
Jan
(252) |
Feb
(286) |
Mar
(175) |
Apr
(175) |
May
(194) |
Jun
(130) |
Jul
(211) |
Aug
(340) |
Sep
(150) |
Oct
(398) |
Nov
(572) |
Dec
(199) |
| 2012 |
Jan
(458) |
Feb
(378) |
Mar
(332) |
Apr
(385) |
May
(228) |
Jun
(188) |
Jul
(199) |
Aug
(336) |
Sep
(349) |
Oct
(271) |
Nov
(61) |
Dec
(155) |
| 2013 |
Jan
(230) |
Feb
(302) |
Mar
(350) |
Apr
(162) |
May
(118) |
Jun
(209) |
Jul
(75) |
Aug
(94) |
Sep
(32) |
Oct
(92) |
Nov
(276) |
Dec
(84) |
| 2014 |
Jan
(36) |
Feb
(50) |
Mar
(16) |
Apr
(32) |
May
(61) |
Jun
(233) |
Jul
(37) |
Aug
(13) |
Sep
(23) |
Oct
(38) |
Nov
(52) |
Dec
(34) |
| 2015 |
Jan
(9) |
Feb
(18) |
Mar
(148) |
Apr
(78) |
May
(15) |
Jun
(31) |
Jul
(60) |
Aug
(90) |
Sep
(41) |
Oct
(38) |
Nov
(177) |
Dec
(76) |
| 2016 |
Jan
(53) |
Feb
(41) |
Mar
(26) |
Apr
(25) |
May
(34) |
Jun
(44) |
Jul
(22) |
Aug
(1) |
Sep
(15) |
Oct
(18) |
Nov
(1) |
Dec
(16) |
| 2017 |
Jan
(29) |
Feb
(20) |
Mar
(5) |
Apr
(8) |
May
(6) |
Jun
(4) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
(25) |
Mar
(7) |
Apr
(2) |
May
(4) |
Jun
(9) |
Jul
|
Aug
(17) |
Sep
(6) |
Oct
(8) |
Nov
(7) |
Dec
(19) |
| 2019 |
Jan
(2) |
Feb
(31) |
Mar
(10) |
Apr
(1) |
May
(4) |
Jun
(3) |
Jul
(13) |
Aug
(5) |
Sep
|
Oct
(4) |
Nov
(164) |
Dec
(59) |
| 2020 |
Jan
(16) |
Feb
(20) |
Mar
(124) |
Apr
(236) |
May
(128) |
Jun
(31) |
Jul
(54) |
Aug
(34) |
Sep
|
Oct
(6) |
Nov
(30) |
Dec
(28) |
| 2021 |
Jan
(18) |
Feb
(6) |
Mar
(4) |
Apr
(44) |
May
(61) |
Jun
(178) |
Jul
(49) |
Aug
(44) |
Sep
(104) |
Oct
(75) |
Nov
(56) |
Dec
(61) |
| 2022 |
Jan
(177) |
Feb
(111) |
Mar
(36) |
Apr
(17) |
May
(10) |
Jun
(24) |
Jul
(17) |
Aug
(81) |
Sep
(19) |
Oct
(51) |
Nov
(36) |
Dec
(20) |
| 2023 |
Jan
(41) |
Feb
(37) |
Mar
(37) |
Apr
(19) |
May
(15) |
Jun
(7) |
Jul
(38) |
Aug
(8) |
Sep
(12) |
Oct
(2) |
Nov
(4) |
Dec
(45) |
| 2024 |
Jan
(11) |
Feb
(22) |
Mar
(160) |
Apr
(18) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Speed D. <no...@so...> - 2009-12-20 21:39:45
|
#54: LS1 cars don't always have the right names / file / folder names
--------------------------+-------------------------------------------------
Reporter: pouillot | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone: 1.4.0
Component: Cars | Version: 1.4.0-dev
Keywords: LS1 car name |
--------------------------+-------------------------------------------------
Comment(by pouillot):
Just added a Wiki page on this subject, including as is the list we had
compiled in the past monthes (feel free to update / complete) :
https://sourceforge.net/apps/trac/speed-dreams/wiki/NamingRules
--
Ticket URL: <http://sourceforge.net/apps/trac/speed-dreams/ticket/54#comment:2>
Speed Dreams <http://sourceforge.net/projects/speed-dreams>
An Open Motorsport Simulator forked from Torcs in order to deliver a better user experience through nicer and more consistent car sets, visually improved tracks and enhanced physics realism.
|
|
From: Speed D. <no...@so...> - 2009-12-20 21:31:51
|
#54: LS1 cars don't always have the right names / file / folder names
--------------------------+-------------------------------------------------
Reporter: pouillot | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone: 1.4.0
Component: Cars | Version: 1.4.0-dev
Keywords: LS1 car name |
--------------------------+-------------------------------------------------
Description changed by pouillot:
Old description:
> The LS1 cars are now in the trunk ... I would have prefered
> we did that before merging them from sdl-port ... now it will be double
> work.
>
> So, there are some name issues about these cars :
>
> - as stated previously at the end of the long and messy "car names"
> discussions on the devel list, each car should have a brand name and a
> model name ; that's OK for all ; but the choosen brand names don't always
> fit the real brand names replacements we had choosen :
>
> * ls1-ciclon-rgt : Toro R-GT => Ciclone R-GT (/ R-GT1 / R-LS1 ?)
> * ls1-f550 : Cavallo 570 S1 => OK
> * ls1-fury : Newcastle Fury LS1 => Lister Fury LS1
> * ls1-r9 : Archer R-9 => OK
> * ls1-s7 : Zentek Z7 XSR => OK
> * ls1-taipan : Taipan LTS-R => OK
> * ls1-vulture : Vulture V6-R => OK
>
> - then we had stated that the folder of each new cars would be named like
> that : <category>-<brand>-<model>, in consistency with the <car>.xml file
> contents (can be shorter in file/folder names though) :
>
> * ls1-ciclon-rgt => ls1-ciclone-rgt
> * ls1-f550 => ls1-cavallo-570
> * ls1-fury => ls1-lister-fury
> * ls1-r9 => ls1-archer-r9
> * ls1-s7 => ls1-zentek-z7
> * ls1-taipan => ls1-taipan-ltr (or -ltsr or ...)
> * ls1-vulture => ls1-vulture-v6r
>
> - the category LD-GT1 should be better named LS-GT1 or LDS-GT1 for
> consistency with car folder names and previous discussion ...
>
> Sorry about bothering you with this, but we need to set new things as
> clean as possible (at first commit is even better) if we hope to improve
> the whole artwork and code base we inherited of ... This will make our
> data tree / car sets more readable and maintainable.
New description:
The LS1 cars are now in the trunk ... I would have prefered
we did that before merging them from sdl-port ... now it will be double
work.
So, there are some name issues about these cars :
- as stated previously at the end of the long and messy "car names"
discussions on the devel list, each car should have a brand name and a
model name ; that's OK for all ; but the choosen brand names don't always
fit the real brand names replacements we had choosen :
* ls1-ciclon-rgt : Toro R-GT => Ciclone R-GT (/ R-GT1 / R-LS1 ?)
* ls1-f550 : Cavallo 570 S1 => OK
* ls1-fury : Newcastle Fury LS1 => OK
* ls1-r9 : Archer R-9 => OK
* ls1-s7 : Zentek Z7 XSR => OK
* ls1-taipan : Taipan LTS-R => OK
* ls1-vulture : Vulture V6-R => OK
- then we had stated that the folder of each new cars would be named like
that : <category>-<brand>-<model>, in consistency with the <car>.xml file
contents (can be shorter in file/folder names though) :
* ls1-ciclon-rgt => ls1-ciclone-rgt
* ls1-f550 => ls1-cavallo-570
* ls1-fury => ls1-newcastle-fury
* ls1-r9 => ls1-archer-r9
* ls1-s7 => ls1-zentek-z7
* ls1-taipan => ls1-taipan-ltr (or -ltsr or ...)
* ls1-vulture => ls1-vulture-v6r
- the category LD-GT1 should be better named LS-GT1 or LDS-GT1 for
consistency with car folder names and previous discussion ...
Sorry about bothering you with this, but we need to set new things as
clean as possible (at first commit is even better) if we hope to improve
the whole artwork and code base we inherited of ... This will make our
data tree / car sets more readable and maintainable.
--
--
Ticket URL: <http://sourceforge.net/apps/trac/speed-dreams/ticket/54#comment:1>
Speed Dreams <http://sourceforge.net/projects/speed-dreams>
An Open Motorsport Simulator forked from Torcs in order to deliver a better user experience through nicer and more consistent car sets, visually improved tracks and enhanced physics realism.
|
|
From: Speed D. <no...@so...> - 2009-12-20 21:09:48
|
#54: LS1 cars don't always have the right names / file / folder names
--------------------------+-------------------------------------------------
Reporter: pouillot | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone: 1.4.0
Component: Cars | Version: 1.4.0-dev
Keywords: LS1 car name |
--------------------------+-------------------------------------------------
The LS1 cars are now in the trunk ... I would have prefered
we did that before merging them from sdl-port ... now it will be double
work.
So, there are some name issues about these cars :
- as stated previously at the end of the long and messy "car names"
discussions on the devel list, each car should have a brand name and a
model name ; that's OK for all ; but the choosen brand names don't always
fit the real brand names replacements we had choosen :
* ls1-ciclon-rgt : Toro R-GT => Ciclone R-GT (/ R-GT1 / R-LS1 ?)
* ls1-f550 : Cavallo 570 S1 => OK
* ls1-fury : Newcastle Fury LS1 => Lister Fury LS1
* ls1-r9 : Archer R-9 => OK
* ls1-s7 : Zentek Z7 XSR => OK
* ls1-taipan : Taipan LTS-R => OK
* ls1-vulture : Vulture V6-R => OK
- then we had stated that the folder of each new cars would be named like
that : <category>-<brand>-<model>, in consistency with the <car>.xml file
contents (can be shorter in file/folder names though) :
* ls1-ciclon-rgt => ls1-ciclone-rgt
* ls1-f550 => ls1-cavallo-570
* ls1-fury => ls1-lister-fury
* ls1-r9 => ls1-archer-r9
* ls1-s7 => ls1-zentek-z7
* ls1-taipan => ls1-taipan-ltr (or -ltsr or ...)
* ls1-vulture => ls1-vulture-v6r
- the category LD-GT1 should be better named LS-GT1 or LDS-GT1 for
consistency with car folder names and previous discussion ...
Sorry about bothering you with this, but we need to set new things as
clean as possible (at first commit is even better) if we hope to improve
the whole artwork and code base we inherited of ... This will make our
data tree / car sets more readable and maintainable.
--
Ticket URL: <http://sourceforge.net/apps/trac/speed-dreams/ticket/54>
Speed Dreams <http://sourceforge.net/projects/speed-dreams>
An Open Motorsport Simulator forked from Torcs in order to deliver a better user experience through nicer and more consistent car sets, visually improved tracks and enhanced physics realism.
|
|
From: Wolf-Dieter B. <wd...@wd...> - 2009-12-20 16:36:14
|
Hello Andrew, so I will have a look for it. I missed some usr robots setups (i.e. for e-track-6), could you please check, wether all the setups you have on your system are in svn? Cheers Wolf-Dieter |
|
From: Speed D. <no...@so...> - 2009-12-20 15:34:36
|
#53: Weird layout of the Race options menu for the Practice race mode
-----------------------------+----------------------------------------------
Reporter: pouillot | Owner: pouillot
Type: defect | Status: closed
Priority: major | Milestone: 1.4.0 beta 1
Component: User interface | Version: 1.4.0-dev
Resolution: fixed | Keywords: practice menu
-----------------------------+----------------------------------------------
Changes (by pouillot):
* status: new => closed
* resolution: => fixed
Comment:
Fixed in r2018
--
Ticket URL: <http://sourceforge.net/apps/trac/speed-dreams/ticket/53#comment:1>
Speed Dreams <http://sourceforge.net/projects/speed-dreams>
An Open Motorsport Simulator forked from Torcs in order to deliver a better user experience through nicer and more consistent car sets, visually improved tracks and enhanced physics realism.
|
|
From: Speed D. <no...@so...> - 2009-12-20 14:43:36
|
#53: Weird layout of the Race options menu for the Practice race mode
----------------------------+-----------------------------------------------
Reporter: pouillot | Owner: pouillot
Type: defect | Status: new
Priority: major | Milestone: 1.4.0 beta 1
Component: User interface | Version: 1.4.0-dev
Keywords: practice menu |
----------------------------+-----------------------------------------------
The "Display mode" static label is lacking.
The associated combo-box-like control is not in the right place and it's
arrow buttons are too small.
--
Ticket URL: <http://sourceforge.net/apps/trac/speed-dreams/ticket/53>
Speed Dreams <http://sourceforge.net/projects/speed-dreams>
An Open Motorsport Simulator forked from Torcs in order to deliver a better user experience through nicer and more consistent car sets, visually improved tracks and enhanced physics realism.
|
|
From: Speed D. <no...@so...> - 2009-12-20 14:39:09
|
#52: Users can't simply play with AI skill level
-------------------------------------+--------------------------------------
Reporter: pouillot | Owner: pouillot
Type: defect | Status: new
Priority: minor | Milestone: 1.4.0
Component: User interface | Version: 1.4.0-dev
Keywords: robot skill menu option |
-------------------------------------+--------------------------------------
Once #51 is fixed, the AI global skilling should work and enable the users
to play with it (meaning: be able to globally lower the skill level of USR
and Simplix drivers to fit with its own skill level as a human driver).
BUT: He has no GUI to achieve that.
Wolf-Dieter and I propose to add a new "AI" menu in the Option menu tree.
--
Ticket URL: <http://sourceforge.net/apps/trac/speed-dreams/ticket/52>
Speed Dreams <http://sourceforge.net/projects/speed-dreams>
An Open Motorsport Simulator forked from Torcs in order to deliver a better user experience through nicer and more consistent car sets, visually improved tracks and enhanced physics realism.
|
|
From: Speed D. <no...@so...> - 2009-12-20 14:34:02
|
#51: Move USR robot code to the Simplix-style single source base
-------------------------------------+--------------------------------------
Reporter: pouillot | Owner: andrewsumner
Type: enhancement | Status: new
Priority: minor | Milestone: to be defined
Component: Robots | Version: 1.4.0-dev
Keywords: USR robot single source |
-------------------------------------+--------------------------------------
For the moment, there is 1 code tree for each car set and that make bug
fixing error-prone and longer, as the code is 99.9... % identical in the 3
instances.
--
Ticket URL: <http://sourceforge.net/apps/trac/speed-dreams/ticket/51>
Speed Dreams <http://sourceforge.net/projects/speed-dreams>
An Open Motorsport Simulator forked from Torcs in order to deliver a better user experience through nicer and more consistent car sets, visually improved tracks and enhanced physics realism.
|
|
From: Jean-Philippe <jpm...@fr...> - 2009-12-20 14:29:22
|
Hi, Andrew, and all. >> Yes, but Andrew asked not to change usr code some weeks ago, and normally I >> would like to respect such whishes ;). > > I don't have time to change it to use GetLocalDir() until mid January, but I've got no > problems with someone else doing it if they wanted. OK, I'll try and do it. But will accept to be over-taken by any other volonteer ;-) (please, simply warn me if this happens) > Great discussion btw, you seem to arriving at consensus on most things & I'm > fully in agreement with what you're saying. Thanks. Do you also agree on Wolf-Dieter's proposal to open a bit more the value ranges / list of changeable parameters for the SC cars in order to enable better AI drivers behaviour ? (please re-read Wolf-Dieter exact words to be sure) > Btw I'd like at some point to move to a simplix-style single source base for USR, > but that can wait for the next release. Yes, that would be a nice improvement (even for you ;-). Of course, not for now. Cheers, Jean-Philippe. |
|
From: Speed D. <no...@so...> - 2009-12-20 14:23:16
|
#50: USR robot never uses user settings files
-------------------------------+--------------------------------------------
Reporter: pouillot | Owner: pouillot
Type: defect | Status: new
Priority: minor | Milestone: 1.4.0
Component: Robots | Version: 1.4.0-dev
Keywords: USR user settings |
-------------------------------+--------------------------------------------
This make it impossible for users to :
- have their own USR setups in GetLocalDir() (USR ignores them)
- play with the global AI skill level in
GetLocalDir()/config/raceman/extra/skill.xml, the one that is used by
Simplix if present
A simple solution is to implement in USR the same "base directory"
strategy as in Simplix, if possible, and to have USR and Simplix setups
copied in GetLocalDir() at install-time.
--
Ticket URL: <http://sourceforge.net/apps/trac/speed-dreams/ticket/50>
Speed Dreams <http://sourceforge.net/projects/speed-dreams>
An Open Motorsport Simulator forked from Torcs in order to deliver a better user experience through nicer and more consistent car sets, visually improved tracks and enhanced physics realism.
|
|
From: Speed D. <no...@so...> - 2009-12-20 14:04:35
|
#28: USR TRB1 Silber TRBK can drive up on two wheels at least on Street-1
---------------------------------+------------------------------------------
Reporter: pouillot | Owner: somebody
Type: defect | Status: new
Priority: minor | Milestone: 1.4.0
Component: Robots | Version: 1.4.0-dev
Keywords: robot setup realism |
---------------------------------+------------------------------------------
Comment(by harunasan):
Has anyone checked the dampers on the offending cars? While I was messing
around with the LS1s, using a damper setting greater than 400 tended to
produce weird results... including cars suddenly going negative two
million something km/h, or even floating IN MID AIR.
But those are particularly extreme cases.
--
Ticket URL: <http://sourceforge.net/apps/trac/speed-dreams/ticket/28#comment:9>
Speed Dreams <http://sourceforge.net/projects/speed-dreams>
An Open Motorsport Simulator forked from Torcs in order to deliver a better user experience through nicer and more consistent car sets, visually improved tracks and enhanced physics realism.
|
|
From: Jean-Philippe <jpm...@fr...> - 2009-12-20 13:55:25
|
Wolf-Dieter, and all. >> I can see 2 candidate menus for that : > There is an other way: Use an AI-Menu in the options tree. > This could be a good solution, if we later will have more switches. > AFAICS this should have none of the disadvantages to mentioned. Yes, true. I was thinking about a solution that would only imply some existing menu ... but adding this AI menu is quite simple, doesn't put any threat on the whole code stability and behaviour, and ... you are right, is from far a better solution. >> And my answer every time is that the prebuild/postbuild system >> was designed in the past to mimic the Unix behaviour at run time >> (that is overwrite the GetLocalDir() files >> that older than the default installed ones). > I understand it, but please reread what you have written: > "(that is overwrite the GetLocalDir() files that older than the default > installed ones)". > And this is not what the script does! > It deletes all files, not only overwrites files beeing in the distribution. Actually, there seems to remain a bug in the Linux version that really overwrites all the GetLocalDir() files at first run-time after a "make install" if the -k option of the "speed-dreams" script is not used. Anyway, you are right : it's dirty. > I can understand, that this is done in the GetDataDir() part as a quick and > dirty solution, but in the GetLocalDir() tree? > It is not user friendly. This bad stuff is here only in case of a format change in the XML files that are copied by prebuild.bat from GetDataDir() to GetLocalDir() folder, and only because if the installed code is not consistent with the new formats, the game _may_ simply crash at start time or show bad behaviour. It's a simple, quick and dirty solution to avoid ANY such issue. >> Of course, you are free to improve prebuild.bat to make it work like in >> your dreams > I'm sorry to say, that my time is very limited this weeks, I perfectly understand ... and my sentence was only meaning that I have the same problem ... and don't want to work on something that will be thrown to the trash bin in some weeks ... and moreover is already solved in sdl-port. > and I see that there are many jobs done not beeing part of the release. > May be a priority problem? I 100% agree with you : there are still some tickets that should be fixed for the release and are not yet, while some non-release-related work is currently done ... I don't like it either, and personaly posponed some far more interesting (in my opinion) SD-related tasks, in order to close as many tickets I could first. And I'm not the only one. But we must also admit that some particular tasks / fixes need very special skills and know-how that only few team member have ... and the robots setup/skilling stuff is one of these ! That's why I'd really like you, Andrew, Gabor and Haruna, the robot / car setup experts, have a teachers' discussion about : - how to write down your methods, tips, ... - how to improve the way you do this difficult work - what changes in the code / new tool development would be usefull to make things simpler and help people know how, thus enabling more people to share these difficult tasks. Cheers, Jean-Philippe. |
|
From: Jean-Philippe <jpm...@fr...> - 2009-12-20 13:51:21
|
Wolf-Dieter, and all.
>> May be these constraints are not that clearly explained anywhere ?
> YES!!!
> But my opinion here is, that this is not for the relase, let's have a more
> detailed discussion after it.
Yes, of course, for later.
>> Then to be concrete here, are this pitting issues for many tracks, or only
> some,
> Some.
>> and then can we simply fix the track themselves ?
> No, because this conflicts with the visual 3D model.
OK. So, we can only :
1) or: find a workaround in the robots code / setup
2) or: remove the "bad" tracks from the release
3) or: warn our users that some drivers won't pit on some tracks
(I really don't like this)
>> But remember our main SD goal is the use to have fun.
>> SD is not an AI design platform like Torcs :
>> it's a game for the user. If the cars don't behave in a realistic way in the human driver's hands,
>> we FAILED. The robots have to adapt to this target.
>> And I understand that it may take some more time and work to.
>> But I consider it a real improvement even for the robot,
>> even if it might be hard to achieve.
> Agree, but please understand what I wanted to say here:
> To get a realistic feeling/view with the current simulation model CAN mean,
> not to have realistic values for the parameters, if we use it without any
> scaling.
> In a perfect model we should not have to do such a "scaling" of parameters,
> but ok.
I understand. With our current physics engine, we need some "scaling".
And for the moment, we choosed to do this scaling manually, by writing
sometimes unrealistic values in the car parameters.
I agree that it is the simplest and quickest solution.
But I only wanted to say that we have to think about improving that,
because it is very error prone, difficult to share and understand for new comers
... My proposition is to begin to think about automate this scaling in the code
to enable realistic parameters in the XML files.
A mid-term goal of course, not for the release.
> A realistic feeling would also mean to have robots driving a car as a human
> driver would do.
> And at the moment this would be much easier, if the robots could use
> specific setups, containing parameters being different as for the human
> drivers.
> This doesn't mean, that robots have an unfair advantage. It would just mean,
> that a player gets better opponents, that can be scaled to a wider range of
> speeds (skilling).
> I.e. the brake pressure: What we should have is a car, that brakes as a real
> car would do. It should not matter, whether the brake pressure parameter is
> like it would be in the real world. If we need the parameter to be twice as
> expected, we should use it. If the simulation model is stable we can use a
> parameter scaling that shows the player a "realistic" brake pressure value
> but gives the simulation model a modified (scaled) value to get a realistic
> feeling for the driver.
>
> At the moment we want to have both, but without scaling.
I agree it cannot work for the moment (need to add the scaling code somewhere),
even if I insist we should give ourselves this as a desirable target for the
future.
So, what do you propose to change, as far as car setups / category limits
are concerned ? Is it only for SC or also for 36GP and TRB1 cars ?
Are these changes compatible with current USR setups or would they imply
again changing them (only questions and hypothesis here, don't panic Andrew ;-) ?
> And some of the strange effects we have at the moment (driving on two
> wheels, driving only on rear wheels, ...) may be result of such missing
> parameter scalings for suspension as well.
I can't say myself, but trust you about that.
Cheers,
Jean-Philippe.
|
|
From: Andrew S. <and...@ya...> - 2009-12-20 12:58:07
|
Hi guys,
> Yes, but Andrew asked not to change usr code some weeks ago, and normally I
> would like to respect such whishes ;).
I don't have time to change it to use GetLocalDir() until mid January, but I've got no
problems with someone else doing it if they wanted.
Great discussion btw, you seem to arriving at consensus on most things & I'm
fully in agreement with what you're saying.
Btw I'd like at some point to move to a simplix-style single source base for USR,
but that can wait for the next release.
cheers
Andrew
__________________________________________________________________________________
See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/
|
|
From: Brian <bga...@gm...> - 2009-12-20 12:50:32
|
Xavier, You are right. It looks like I have a bug in the linux version of network host menus. I committed a fix that should solve the problem. Brian On Sat, Dec 19, 2009 at 4:05 PM, Bertaux Xavier <ber...@ya...> wrote: > Hi Brian, > > on last commit, I have an error on choice network race -> host, > segmentation error, but maybe it's normal because your have not finished > your modification > > Xavier > |
|
From: Wolf-Dieter B. <wd...@wd...> - 2009-12-20 12:43:14
|
Hello Jean-Philippe, > I understand here that the Speedway and Dirt tracks are still to do. Yes, and the quick and dirty solution I do at the moment means, that the (simplix) robots will have problems on unknown tracks. > May be these constraints are not that clearly explained anywhere ? YES!!! But my opinion here is, that this is not for the relase, let's have a more detailed discussion after it. > Then to be concrete here, are this pitting issues for many tracks, or only some, Some. > and then can we simply fix the track themselves ? No, because this conflicts with the visual 3D model. > But remember our main SD goal is the use to have fun. > SD is not an AI design platform like Torcs : > it's a game for the user. > If the cars don't behave in a realistic way in the human driver's hands, we FAILED. > The robots have to adapt to this target. > And I understand that it may take some more time and work to. > But I consider it a real improvement even for the robot, > even if it might be hard to achieve. Agree, but please understand what I wanted to say here: To get a realistic feeling/view with the current simulation model CAN mean, not to have realistic values for the parameters, if we use it without any scaling. In a perfect model we should not have to do such a "scaling" of parameters, but ok. A realistic feeling would also mean to have robots driving a car as a human driver would do. And at the moment this would be much easier, if the robots could use specific setups, containing parameters being different as for the human drivers. This doesn't mean, that robots have an unfair advantage. It would just mean, that a player gets better opponents, that can be scaled to a wider range of speeds (skilling). I.e. the brake pressure: What we should have is a car, that brakes as a real car would do. It should not matter, whether the brake pressure parameter is like it would be in the real world. If we need the parameter to be twice as expected, we should use it. If the simulation model is stable we can use a parameter scaling that shows the player a "realistic" brake pressure value but gives the simulation model a modified (scaled) value to get a realistic feeling for the driver. At the moment we want to have both, but without scaling. And some of the strange effects we have at the moment (driving on two wheels, driving only on rear wheels, ...) may be result of such missing parameter scalings for suspension as well. Cheers Wolf-Dieter |
|
From: Wolf-Dieter B. <wd...@wd...> - 2009-12-20 11:33:46
|
Hello Jean-Philippe, >> "each robot" means "simplix??? and usr???" > Not sure about what you mean ... Simplix??? stands for all simplix based speed dreams robots (simplix, simplix_trb1, simplix_sc, simplix_GP36, ...; All the same code) and usr??? for all USR robots (Different codes). >>> - each robot also reads a "global" (unique in the game) skill.xml file, >>> (in ~/.speed-dreams/config/raceman/extra) >> And no, this is not the way it works at the moment. > Actually, it seems yes, as far as I understand your explainations below :-) No, this would be the GetLocalDir() option, but at the moemnt we use the GetDataDir() option. > That's bad. We have to be consistent => TODO. Agree. > Yes. Or modify USRs to make them consistent with Simplix. > That's my prefered solution. > And IIUC, this is something : > - simple to achieve > - with no chances to break anything in the setup/skilling work > that was achieved til now. > Can you confirm ? Am I right or wrong in your opinion ? Yes, but Andrew asked not to change usr code some weeks ago, and normally I would like to respect such whishes ;). > So, you are meaning that you'd prefer to be able to change the > human driver skill level and the global robot drivers > skill level in an independant manner ? Yes. > If so, my opinion is that we have to give normal users > a SIMPLE mean to change the global AI skill level > (changing the XML file is not simple for everyone, > and certainly not user-friendly for anyone ;-). Agree. > I can see 2 candidate menus for that : There is an other way: Use an AI-Menu in the options tree. This could be a good solution, if we later will have more switches. AFAICS this should have none of the disadvantages to mentioned. > WD, we already had this discussion at least 5 times :-( Sorry (, but this is true for many other topics as well ;) > And my answer every time is that the prebuild/postbuild system > was designed in the past to mimic the Unix behaviour at run time > (that is overwrite the GetLocalDir() files > that older than the default installed ones). I understand it, but please reread what you have written: "(that is overwrite the GetLocalDir() files that older than the default installed ones)". And this is not what the script does! It deletes all files, not only overwrites files beeing in the distribution. I can understand, that this is done in the GetDataDir() part as a quick and dirty solution, but in the GetLocalDir() tree? It is not user friendly. > Of course, you are free to improve prebuild.bat to make it work like in your dreams I'm sorry to say, that my time is very limited this weeks, and I see that there are many jobs done not beeing part of the release. May be a priority problem? Cheers Wolf-Dieter |
|
From: Jean-Philippe <jpm...@fr...> - 2009-12-20 11:17:51
|
Wolf-Dieter, and all.
>> So, how do you consider the whole Simplix / USR setup / skilling work ?
>> Is it finished in your opinion, or is there some work remaining
>> for the release for any of the 3 cars sets and the 2 robots ?
> No, it is not finished.
Just to be clear, I'm only looking for information about where we are ...
I don't intend to reproach anything to anyone ... I understand that this
robot setup/skilling work is from far the most difficult problem
we have to solve in SD, in relation to the physics engine changes
and underlying "unperfectness" (but here again, very difficult), to the car
setups changes and track settings changes ...
So, thanks, Wolf-Dieter, for this clear list of done/to do things :-)
> First I made the simplix cars/drivers run on all tracks of the "Grand Prix
> Circuits" and "Road Tracks" group again.
I understand here that the Speedway and Dirt tracks are still to do.
> At the moment I have to race a lot of cars together on all tracks,
> to find the skilling scale factors to use for different tracks and skill
> levels.
>
> Andrew added individual skilling files for drivers, but what I see is, that
> there are drivers using the same car type having the same lap time while
> qualifying. This should not happen.
> (A very bad example are the autounion drivers. This way they are allways
> starting together and are blocking the road very often).
> May be we have to rescale the individual skilling to make the differences be
> greater.
Tha's to do for Andrew or any other robot expert, then.
> After all the changes to the surface parameters I have to check all the
> pitting parameters again!
>
> For some tracks, the default simplix pitting code doesn't work. In this
> cases you have to use a track setup switching off the "use first pit" option
> and/or the "use smooth path" option to prevent the game from freezing. This
> is not really a robot bug but there are tracks containing pitlane parameters
> conflicting with the common logic used here. The track definitions allow
> situations not handled by the robots (All robots I know except simplix are
> using the "basic pitting" from Bernhards tutorial).
>
> Using such a setup will work on all known tracks, but not on unkown! This is
> why I want to change the defaults for simplix robots.
>
> While testing I see problems with some usr drivers while racing and/or
> pitting.
> AFAICS there are not for all tracks setups for all cars.
> I send Andrew mails but didn't get an answer whether this is intentional.
So, here it seems we have an "interface" issue ; I mean that some tracks
doesn't obey to the constraints upoon which the robots code are designed.
May be these constraints are not that clearly explained anywhere ?
Couldn't we enforce these constraints in trackgen (I mean automatically fix
the issues with the track designer settings, or simply refuse to generate
if these constraints are not respected) ?
Because in the ideal world, we can well tune the robots code to support
any track issue ... but that's an endless work ...
Then to be concrete here, are this pitting issues for many tracks,
or only some, and then can we simply fix the track themselves ?
> While reworking the simplix setups I saw, that someone had changed it
> braking the correct structure (i.e. the differential block was part of the
> gearbox block instead beeing a separate one).
>
> Changing the cars basic parameters to "realistic" values and restricting the
> allowed changes to nearly nothing (for supercars) was not a good idea. The
> simulation physics is not the real physics and this is why real world
> parameters values can be different from model parameters needed to make the
> system work realisitc.
Sorry to maintain that we'll NEVER get out of all the issues you mention
if we don't try to make the robot/car setup process simpler.
And to my mind, using "realistic" values for car parameters is one
of the means we have to use for that.
(again a question of interfaces and contracts : don't fix issues
of a lower code layer in an upper one ; things at their right place)
OK, may be it's too early for that, as it would imply changing some code
in the physics engine ... and we didn't achieve it :-(
But remember our main SD goal is the use to have fun. SD is not an AI design
platform like Torcs : it's a game for the user. If the cars don't behave
in a realistic way in the human driver's hands, we FAILED.
The robots have to adapt to this target. And I understand that it may take
some more time and work to. But I consider it a real improvement even for
the robot, even if it might be hard to achieve.
> After all the changes to the simulation code (suspension, Anit-Rollbars,
> friction, wheels) it is much more difficult to make robot setups work on
> unkown tracks, means it takes a lot of time.
Let's concentrate on our known tracks for the moment, as proposed before.
And state that new tracks will have to obey may be more stricter rules
for SD than for Torcs (and that's not a high priority issue for me).
Cheers,
Jean-Philippe.
PS: Under the impression that I already proposed that, but it seems to me
that we should really have a deep reflexion on these tight links
between the physics engine, the car setups and the track setups,
and see how we can make things simpler everywhere, may be simply through
a detailed and documented procedure with to do / to avoid things,
or more likeky through improvements to the code, like thin layers
between the car / track parameters and the physics engine, where
we could temporarily implement workarounds from realistic car /track
parameters (in the XML) to the non-realistic values that are needed
by the physics engine for the moment. Of course, we should also
plan to really fix these issues in the physics engine latter
(and so enable us to simply remove these thin workaround layers).
May be this reflexion could lead us to develop some new tool / code
to help in setting up the robots ...
I'm really convinced that we have some important reflexion work
to achieve here, and that if we don't do it, we'll always keep stuck
with this bad issues, will loose time and energy ... if not more ...
|
|
From: Jean-Philippe <jpm...@fr...> - 2009-12-20 10:36:08
|
Hi, Wolf-Dieter, and all. Please guys, read on this long mail ... we need your opinions. > (Let us assume "each robot" means "simplix??? and usr???") Not sure about what you mean ... but as you can easily imagine, I'm trying to understand what exact work has still to be done for the release ... so, you can easily deduce the meaning of the sentence ... >> - each robot has a specific skilling.xml file >> that tells how quick/aggressive it is on its own > Set "driver" instead of "robot" here and it is "skill.xml". > - each driver has a specific skill.xml file > - it reads this file at startup. OK. Clear. >> - each robot also reads a "global" (unique in the game) skill.xml file, > Yes >> (in ~/.speed-dreams/config/raceman/extra) > No. "~/.speed-dreams/config/raceman/extra" is not a path used with windows! > (AFAIK it would be "~/speed-dreams.settings/config/raceman/extra") Of course, WD, I know that. I was meaning GetLocalDir()/config/raceman/extra. > And no, this is not the way it works at the moment. Actually, it seems yes, as far as I understand your explainations below :-) >> as a global lowering coefficient for its speed / aggression level >> (it is actually added to the robot specific skill level). > "Added", yes. > The simplix robot: > > This is same for all "speed dreams simplix robots", because it is the same > code used for all robots (Just a copy of the dll renamed to the robot's name). Yes,. Clear. > 0. "Robot base directory" > While executing "moduleWelcomeV1_00" the > simplix robot first tries to find the robot base configuration file > as "GetLocalDir()/drivers/<robot>/<robot>.xml". > If not found it retires it > as "GetDataDir()/drivers/<robot>/<robot>.xml". > Depending on where the file was found, the "robot base directory" is > buffered as > RobotBaseDirectory = "GetLocalDir()/drivers/<robot>" or > "GetDataDir()/drivers/<robot>". > > 1. There is an "default.xml" in the "robot base directory" > In this file there are two switches > enable/disable skilling and > enable/disable team driving features > > 2. If skilling is enabled in the robot "default.xml" it first searches a > "skill.xml" file in > "GetLocalDir()/config/raceman/extra/" and if not found it tries > "GetDataDir()/config/raceman/extra/". > > 3. The drivers individual skillling is searched in a file "skill.xml" > in the drivers subdirectory of the "robot base directory" > "RobotBaseDirectory/<index>" OK. Clear, and exactly what I had understood til then :-) > The usr robot: > > Here we can not assume that this is same for all "speed dreams usr robots", > because it is not the same code used for all robots. OK. But we'll have to enforce it "manually". > AFAIK it does not look for files in the "GetLocalDir()" tree. That's bad. We have to be consistent => TODO. > This means that you have to use simplix without copying files to the > GetLocalDir() tree > to make both robots use the same global skill.xml file in > "GetDataDir()/config/raceman/extra/". Yes. Or modify USRs to make them consistent with Simplix. That's my prefered solution. And IIUC, this is something : - simple to achieve - with no chances to break anything in the setup/skilling work that was achieved til now. Can you confirm ? Am I right or wrong in your opinion ? >> - is it really working like this now for USR _and_ Simplix ? >> (I mean for the 2 robots and with this exact file search strategy) > AFAIK no. > It only works if you use simplix without the "manually copied file option". > >> - for the moment, ~/.speed-dreams/config/raceman/extra/skill.xml (global) > No, it is "GetDataDir()/config/raceman/extra/skill.xml" and differs between > windows and other systems. OK. Clear from above explainations. > Hope this helps Yes, a lot. We have now a clear idea of where we are about this skilling domain. >> holds a 0.0 value (maximum skill) that is never changed anywhere ... > It has to be changed by the user, to really use skilling. > >> Shouldn't we change its value at race load time (before loading the > robots) >> in order to make it consistent with the human player "skill level" >> that is set in the "Player configuration" menu >> (rookie, amateur, semi-pro, pro) ? > YesNo. > Some month ago we discussed to have a place in the "menu" where the user can > change it. > I don't think that it should be driven by the human player "skill level" but > be a free option to use. So, you are meaning that you'd prefer to be able to change the human driver skill level and the global robot drivers skill level in an independant manner ? If so, my opinion is that we have to give normal users a SIMPLE mean to change the global AI skill level (changing the XML file is not simple for everyone, and certainly not user-friendly for anyone ;-). Then, I propose to add an "AI skill level" control in some menu to enable the user to change it in a simple way. I can see 2 candidate menus for that : 1) the Driver Select menu 2) the race settings menu (the one that comes after the Driver Select one) IIUC, this skilling method is not compatible with our future "Career" race mode, so I'd imagine that the best place would we in a menu that is "race type/mode" specific. Unfortunately, this "race settings" menu only exists (for the moment) for the Quick Race type/mode. And if we don't want Quick Race settings to interfere with other race types/modes, we'd have to reset the global skill.xml at each non-QuickRace race start. But this could work : enable the user to play with AI skilling ONLY in Quick Race mode, and keep the default 0.0 global skilling for the other race types/modes. What do you think all ? > BTW: While prebuild/postbuild the GetLocalDir() tree is deleted! Why? This > is not what a user expects because he has to copy it manually! So all the > individual settings are lost without a warning. WD, we already had this discussion at least 5 times :-( And my answer every time is that the prebuild/postbuild system was designed in the past to mimic the Unix behaviour at run time (that is overwrite the GetLocalDir() files that older than the default installed ones). And it just works as expected in this purpose. OK, that's not fair when you are a developer of a robot, like you. And IIRC, my answer about that was that you had to be patient and wait for sdl-port becoming our trunk (after the release) ... because in sdl-port, Mart has setup a nice versionning system for the user settings files that will be very close to what you are dreaming of. Of course, you are free to improve prebuild.bat to make it work like in your dreams ... provided you keep the current default behaviour _as_is_ (you are free to add some option to the script and some 'if' clause to avoid overwriting <My Documents>/speed-dreams.settings when the option is selected ...). Cheers, Jean-Philippe. |
|
From: Wolf-Dieter B. <wd...@wd...> - 2009-12-20 09:13:32
|
Hello Jean-Philippe, hello all, > So, how do you consider the whole Simplix / USR setup / skilling work ? > Is it finished in your opinion, or is there some work remaining > for the release for any of the 3 cars sets and the 2 robots ? No, it is not finished. First I made the simplix cars/drivers run on all tracks of the "Grand Prix Circuits" and "Road Tracks" group again. This was done with skilling set to zero, means the fastest mode. At the moment I have to race a lot of cars together on all tracks, to find the skilling scale factors to use for different tracks and skill levels. Andrew added individual skilling files for drivers, but what I see is, that there are drivers using the same car type having the same lap time while qualifying. This should not happen. (A very bad example are the autounion drivers. This way they are allways starting together and are blocking the road very often). May be we have to rescale the individual skilling to make the differences be greater. After all the changes to the surface parameters I have to check all the pitting parameters again! For some tracks, the default simplix pitting code doesn't work. In this cases you have to use a track setup switching off the "use first pit" option and/or the "use smooth path" option to prevent the game from freezing. This is not really a robot bug but there are tracks containing pitlane parameters conflicting with the common logic used here. The track definitions allow situations not handled by the robots (All robots I know except simplix are using the "basic pitting" from Bernhards tutorial). Using such a setup will work on all known tracks, but not on unkown! This is why I want to change the defaults for simplix robots. While testing I see problems with some usr drivers while racing and/or pitting. AFAICS there are not for all tracks setups for all cars. I send Andrew mails but didn't get an answer whether this is intentional. While reworking the simplix setups I saw, that someone had changed it braking the correct structure (i.e. the differential block was part of the gearbox block instead beeing a separate one). Changing the cars basic parameters to "realistic" values and restricting the allowed changes to nearly nothing (for supercars) was not a good idea. The simulation physics is not the real physics and this is why real world parameters values can be different from model parameters needed to make the system work realisitc. After all the changes to the simulation code (suspension, Anit-Rollbars, friction, wheels) it is much more difficult to make robot setups work on unkown tracks, means it takes a lot of time. Cheers, Wolf-Dieter |
|
From: Jean-Philippe <jpm...@fr...> - 2009-12-20 09:13:08
|
Hi, Xavier, and all. > After last update, I have a freeze on launch race. > Track loaded, car and driver loaded but screen blocked on this screen. Any traces in the console ? Did you try to reinstall ~/.speed-dreams/config/raceman ? Do you have removed sub-folders in data/tracks or in data/track/* ? Did you try a full rebuild /reinstall after make clean + rm -fr /usr/local/share/games/speed-dreams ? I have no idea for the moment ... Cheers, Jean-Philippe. |
|
From: Speed D. <no...@so...> - 2009-12-20 09:06:58
|
#46: Freeze if selecting deleted track for use
-----------------------------+----------------------------------------------
Reporter: kmetykog | Owner: somebody
Type: defect | Status: closed
Priority: major | Milestone: 1.4.0
Component: User interface | Version: 1.4.0-dev
Resolution: fixed | Keywords: track selection
-----------------------------+----------------------------------------------
Comment(by pouillot):
This fix was done through svn r2013.
--
Ticket URL: <http://sourceforge.net/apps/trac/speed-dreams/ticket/46#comment:3>
Speed Dreams <http://sourceforge.net/projects/speed-dreams>
An Open Motorsport Simulator forked from Torcs in order to deliver a better user experience through nicer and more consistent car sets, visually improved tracks and enhanced physics realism.
|
|
From: Speed D. <no...@so...> - 2009-12-20 09:03:49
|
#42: No default opponents in non Quick/Practice race types
-----------------------------+----------------------------------------------
Reporter: pouillot | Owner: somebody
Type: defect | Status: closed
Priority: minor | Milestone: 1.4.0 beta 1
Component: User interface | Version: 1.4.0-dev
Resolution: fixed | Keywords: race type opponent
-----------------------------+----------------------------------------------
Comment(by pouillot):
This last quick fix was done through svn r2012.
--
Ticket URL: <http://sourceforge.net/apps/trac/speed-dreams/ticket/42#comment:3>
Speed Dreams <http://sourceforge.net/projects/speed-dreams>
An Open Motorsport Simulator forked from Torcs in order to deliver a better user experience through nicer and more consistent car sets, visually improved tracks and enhanced physics realism.
|
|
From: Wolf-Dieter B. <wd...@wd...> - 2009-12-20 08:57:35
|
Hello Jean-Philippe, hello all,
there are some more details:
(Let us assume "each robot" means "simplix??? and usr???")
> - each robot has a specific skilling.xml file
> that tells how quick/aggressive it is on its own
Set "driver" instead of "robot" here and it is "skill.xml".
- each driver has a specific skill.xml file
- it reads this file at startup.
> - each robot also reads a "global" (unique in the game) skill.xml file,
Yes
> (in ~/.speed-dreams/config/raceman/extra)
No. "~/.speed-dreams/config/raceman/extra" is not a path used with windows!
(AFAIK it would be "~/speed-dreams.settings/config/raceman/extra")
And no, this is not the way it works at the moment.
> as a global lowering coefficient for its speed / aggression level
> (it is actually added to the robot specific skill level).
"Added", yes.
The simplix robot:
This is same for all "speed dreams simplix robots", because it is the same
code used for all
robots (Just a copy of the dll renamed to the robot's name).
0. "Robot base directory"
While executing "moduleWelcomeV1_00" the
simplix robot first tries to find the robot base configuration file
as "GetLocalDir()/drivers/<robot>/<robot>.xml".
If not found it retires it
as "GetDataDir()/drivers/<robot>/<robot>.xml".
Depending on where the file was found, the "robot base directory" is
buffered as
RobotBaseDirectory = "GetLocalDir()/drivers/<robot>" or
"GetDataDir()/drivers/<robot>".
1. There is an "default.xml" in the "robot base directory"
In this file there are two switches
enable/disable skilling and
enable/disable team driving features
2. If skilling is enabled in the robot "default.xml" it first searches a
"skill.xml" file in
"GetLocalDir()/config/raceman/extra/" and if not found it tries
"GetDataDir()/config/raceman/extra/".
3. The drivers individual skillling is searched in a file "skill.xml"
in the drivers subdirectory of the "robot base directory"
"RobotBaseDirectory/<index>"
The usr robot:
Here we can not assume that this is same for all "speed dreams usr robots",
because it is not the same code used for all robots.
AFAIK it does not look for files in the "GetLocalDir()" tree.
This means that you have to use simplix without copying files to the
GetLocalDir() tree
to make both robots use the same global skill.xml file in
"GetDataDir()/config/raceman/extra/".
BTW: While prebuild/postbuild the GetLocalDir() tree is deleted! Why? This
is not what a user expects because he has to copy it manually! So all the
individual settings are lost without a warning.
> - is it really working like this now for USR _and_ Simplix ?
> (I mean for the 2 robots and with this exact file search strategy)
AFAIK no.
It only works if you use simplix without the "manually copied file option".
> - for the moment, ~/.speed-dreams/config/raceman/extra/skill.xml (global)
No, it is "GetDataDir()/config/raceman/extra/skill.xml" and differs between
windows and other systems.
> holds a 0.0 value (maximum skill) that is never changed anywhere ...
It has to be changed by the user, to really use skilling.
> Shouldn't we change its value at race load time (before loading the
robots)
> in order to make it consistent with the human player "skill level"
> that is set in the "Player configuration" menu
> (rookie, amateur, semi-pro, pro) ?
YesNo.
Some month ago we discussed to have a place in the "menu" where the user can
change it.
I don't think that it should be driven by the human player "skill level" but
be a free option to use.
Hope this helps
Wolf-Dieter
-----Ursprüngliche Nachricht-----
Von: Jean-Philippe [mailto:jpm...@fr...]
Gesendet: Samstag, 19. Dezember 2009 19:01
An: Speed Dreams devel; Mart Kelder
Betreff: [Speed-dreams-devel] User / robots skilling
Wolf-Dieter, and all,
To come back to the skilling stuff : IIUC,
- each robot has a specific skilling.xml file that tells how
quick/aggressive
it is on its own
(first searched first in ~/.speed-dreams/drivers/<robot>/<index>,
otherwise in <install>/drivers/<robot>/<index>) ;
it reads this file at startup.
- each robot also reads a "global" (unique in the game) skill.xml file,
(in ~/.speed-dreams/config/raceman/extra)
as a global lowering coefficient for its speed / aggression level
(it is actually added to the robot specific skill level).
Questions :
- is it really working like this now for USR _and_ Simplix ?
(I mean for the 2 robots and with this exact file search strategy)
- for the moment, ~/.speed-dreams/config/raceman/extra/skill.xml (global)
holds a 0.0 value (maximum skill) that is never changed anywhere ...
Shouldn't we change its value at race load time (before loading the
robots)
in order to make it consistent with the human player "skill level"
that is set in the "Player configuration" menu (rookie, amateur,
semi-pro,
pro) ?
Cheers,
Jean-Philippe.
|
|
From: Haruna S. <ato...@gm...> - 2009-12-20 07:48:44
|
Hi all, I committed to the Z7R's directory a new set of proper racing wheels, which can be used for any car class except GP1600 and 1930's GP. "POW Dynamics R-Spec" http://i45.tinypic.com/33oh0sp.jpg These five-spoke wheels are a simple, but very distinct appearance, feeling lightweight and sturdy in design. Its simplicity allows the look to fit onto nearly any sporty modern car. If you guys want, I can also commit alternate versions, which feature black spokes with red or yellow rims. Cheers, Haruna. |
494 messages has been excluded from this view by a project administrator.