Menu
▾
▴
torcs-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
(1) |
Mar
|
Apr
(3) |
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(6) |
| 2002 |
Jan
(11) |
Feb
|
Mar
(5) |
Apr
|
May
(1) |
Jun
(2) |
Jul
(3) |
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(1) |
| 2003 |
Jan
(1) |
Feb
(11) |
Mar
(33) |
Apr
(8) |
May
(10) |
Jun
(1) |
Jul
(1) |
Aug
(5) |
Sep
(4) |
Oct
(3) |
Nov
(6) |
Dec
(22) |
| 2004 |
Jan
(46) |
Feb
(16) |
Mar
(39) |
Apr
(29) |
May
(27) |
Jun
(11) |
Jul
(8) |
Aug
(15) |
Sep
(29) |
Oct
(12) |
Nov
(42) |
Dec
(19) |
| 2005 |
Jan
(2) |
Feb
(64) |
Mar
(87) |
Apr
(35) |
May
(6) |
Jun
(20) |
Jul
(34) |
Aug
(73) |
Sep
(39) |
Oct
(20) |
Nov
(3) |
Dec
(9) |
| 2006 |
Jan
(3) |
Feb
(17) |
Mar
(6) |
Apr
(6) |
May
(20) |
Jun
(18) |
Jul
|
Aug
(2) |
Sep
(4) |
Oct
(5) |
Nov
(13) |
Dec
(5) |
| 2007 |
Jan
|
Feb
(4) |
Mar
(17) |
Apr
(4) |
May
(4) |
Jun
(4) |
Jul
(1) |
Aug
(3) |
Sep
(13) |
Oct
(15) |
Nov
(21) |
Dec
(9) |
| 2008 |
Jan
(12) |
Feb
(9) |
Mar
(14) |
Apr
(35) |
May
(17) |
Jun
(23) |
Jul
(28) |
Aug
(34) |
Sep
(24) |
Oct
(9) |
Nov
(6) |
Dec
(4) |
| 2009 |
Jan
(27) |
Feb
(8) |
Mar
(5) |
Apr
(3) |
May
|
Jun
(4) |
Jul
(7) |
Aug
(13) |
Sep
(9) |
Oct
(5) |
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
(3) |
May
(4) |
Jun
(4) |
Jul
(10) |
Aug
(7) |
Sep
(5) |
Oct
(4) |
Nov
(4) |
Dec
(1) |
| 2011 |
Jan
(3) |
Feb
(6) |
Mar
|
Apr
(2) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(5) |
| 2012 |
Jan
(5) |
Feb
(13) |
Mar
(6) |
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(5) |
Nov
(9) |
Dec
(3) |
| 2013 |
Jan
|
Feb
(5) |
Mar
|
Apr
(4) |
May
|
Jun
(3) |
Jul
|
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2014 |
Jan
(2) |
Feb
|
Mar
|
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(1) |
Nov
(4) |
Dec
(2) |
| 2015 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(2) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2023 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(4) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(2) |
2
(1) |
3
|
|
4
|
5
|
6
|
7
(1) |
8
(1) |
9
|
10
|
|
11
|
12
|
13
|
14
|
15
|
16
|
17
|
|
18
|
19
|
20
(2) |
21
|
22
|
23
(1) |
24
|
|
25
|
26
|
27
|
28
|
29
|
30
|
31
|
|
From: <net...@ho...> - 2004-07-23 00:18:51
|
<html><div style='background-color:'><TABLE id=HB_Mail_Container height="100%" cellSpacing=0 cellPadding=0 width="100%" border=0 UNSELECTABLE="on">
<TBODY>
<TR height="100%" UNSELECTABLE="on" width="100%">
<TD id=HB_Focus_Element vAlign=top width="100%" background="" height=250 UNSELECTABLE="off">
<P>Hi, </P>
<P>I´m working with the distance till the end of the segment. I use the function that everybody can read in the berniw's robot tutorial. That is:</P>
<P>float Driver::getDistToSegEnd()<BR>{<BR> if (car->_trkPos.seg->type == TR_STR) {<BR> return car->_trkPos.seg->length - car->_trkPos.toStart;<BR> } else {<BR> return (car->_trkPos.seg->arc - car->_trkPos.toStart)*car->_trkPos.seg->radius;<BR> }<BR>}</P>
<P>The problem is that the value that it returns seems to depend on... I don´t know. Sometimes it returns something like 0.09... and the car is in the point B and other times it returns someting like 2.3.... and the car is in the point A con A closer than B to the end of the segment. I know where is the end of the segment becouse I introduced some geometry just on it. Also the behaviour seems to change in almost every game.</P>
<P>If anybody had the same problem, please let me know. </P>
<P>Thank you.</P></TD></TR>
<TR UNSELECTABLE="on" hb_tag="1">
<TD style="FONT-SIZE: 1pt" height=1 UNSELECTABLE="on">
<DIV id=hotbar_promo></DIV></TD></TR></TBODY></TABLE>
<BLOCKQUOTE id=7773f9bd><BR><BR><BR>
<DIV>
<TABLE id=HB_Mail_Container height="100%" cellSpacing=0 cellPadding=0 width="100%" border=0 UNSELECTABLE="on">
<TBODY>
<TR height="100%" UNSELECTABLE="on" width="100%">
<TD id=HB_Focus_Element vAlign=top width="100%" background="" height=250 UNSELECTABLE="off"></TD></TR>
<TR UNSELECTABLE="on" hb_tag="1">
<TD style="FONT-SIZE: 1pt" height=1 UNSELECTABLE="on">
<DIV id=hotbar_promo></DIV></TD></TR></TBODY></TABLE>
<BLOCKQUOTE id=8fbc659a>
<DIV>
<TABLE id=HB_Mail_Container height="100%" cellSpacing=0 cellPadding=0 width="100%" border=0 UNSELECTABLE="on">
<TBODY>
<TR height="100%" UNSELECTABLE="on" width="100%">
<TD id=HB_Focus_Element vAlign=top width="100%" background="" height=250 UNSELECTABLE="off">
<P>_____________________</P>
<P><EM>Manuel Pecero Rodríguez</EM>.</P>
<P><A href="mailto:net...@ho...">net...@ho...</A></P>
<P><A href="mailto:m_p...@ya...">m_p...@ya...</A></P>
<P><A href="mailto:man...@bu...">man...@bu...</A> </P></ </TD></TR></TBODY>
<DIV></DIV>
<BLOCKQUOTE></BLOCKQUOTE>
<DIV></DIV>
<BLOCKQUOTE></BLOCKQUOTE></DIV></BLOCKQUOTE></DIV></BLOCKQUOTE></div><br clear=all><hr>Las mejores tiendas, los precios mas bajos, entregas en todo el mundo, YupiMSN Compras: <a href="http://g.msn.com/8HMAES/2746??PS=47575">Haz clic aquí...</a> </html>
|
|
From: Bernhard W. <be...@bl...> - 2004-07-20 10:53:06
|
Hi Christos
> There is a strange bug, and I am not sure where it is.
>
> When you have a curb on the right side of the road, while it is drawn
> correctly, the elevation seems incorrect. Normally the elevation
> should be 0 close to the road and equal to the height attribute of the
> curb furthest from the road. However, while it is drawn this way, the
> elevation is the other way around. It is easy to test that by setting
> up a curve with a width of 6 meters and a height of 1. Left side
> curves seem to be correct.
>
> I am not sure which part of the game is responsible for this, but I
> guess it is not trackgen since that only creates the graphics.
I looked into src/libs/robottools/rttrack.cpp, RtTrackHeightL. I think
the following is wrong:
if (seg->style == TR_CURB) {
if (seg->type2 == TR_RBORDER) {
return seg->vertex[TR_SR].z + p->toStart * seg->Kzl + tr * ...
should be (seg->width - tr) instead of tr:
return seg->vertex[TR_SR].z + p->toStart * seg->Kzl + (seg->width - tr)
* ...
Can you test that?
bye, thank you,
Bernhard.
--
visit my homepage http://www.berniw.org
coming soon: The TORCS Racing Board, http://www.berniw.org/trb
|
|
From: Christos D. <dim...@id...> - 2004-07-20 09:01:30
|
There is a strange bug, and I am not sure where it is. When you have a curb on the right side of the road, while it is drawn correctly, the elevation seems incorrect. Normally the elevation should be 0 close to the road and equal to the height attribute of the curb furthest from the road. However, while it is drawn this way, the elevation is the other way around. It is easy to test that by setting up a curve with a width of 6 meters and a height of 1. Left side curves seem to be correct. I am not sure which part of the game is responsible for this, but I guess it is not trackgen since that only creates the graphics. -- Christos Dimitrakakis IDIAP (http://www.idiap.ch/~dimitrak/main.html) |
|
From: Eric E. <eri...@fr...> - 2004-07-08 17:37:04
|
Peter Simard wrote:
> Hi,
>
>
>
> I am going through the process of adding force feedback to TORCS
> (windows version). I was wondering if this could be done via the
> humal.dll module? I need to know the state of the car – i.e. velocity,
> turning, etc. I would also like to know when other conditions are
> active, i.e. how to determine what type of terrain the driver’s vehicle
> is over? Is this possible from the [human] driver module, or will I need
> to look in the car specific code?
>
>
>
>
>
> Thx
>
> Peter Simard
>
> Immersion Corporation (Canada)
>
Hi,
The current player's interface is done in human.dll
but there is a separation between the robots drivers
(human is considered as a robot ;-) ) and the simulation
data.
A lot of info is stored in the tCarElt structure.
but if you need more info, the simulation holds
all the detailled info you may need,
and you can pass the info from the simulation to the
human robot by extending the tCarElt structure and copy
the data in the src/modules/simu/simuv?/simu.cpp
function "SimUpdate". At the end of the function
you'll see that the simulation module copies
the info for the robots.
The surface can be retrieved from the current data
available in the human.cpp code.
in the tCarElt structure: car->priv.wheel[i].seg->surface->material
gives you the surface under the corresponding wheel.
look in the code done by Christos for the skidmarks
in: src/modules/graphic/ssggraph/grskidmarks.cpp
function "grUpdateSkidmarks"
it's a good example of how to use that info.
A good thing would have been to store more information
in the XML file describing the tracks and extend
the track module to get the extra info needed in the
tTrackSurface structure.
Eric.
--
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
TORCS - http://torcs.org
The Open Racing Car Simulator
AKA The Other Release Coming Soon (Skin'r)
How soon is soon ? (RaceBlizter)
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
|
|
From: Peter S. <ps...@im...> - 2004-07-07 15:28:10
|
Hi, =20 I am going through the process of adding force feedback to TORCS (windows version). I was wondering if this could be done via the humal.dll module? I need to know the state of the car - i.e. velocity, turning, etc. I would also like to know when other conditions are active, i.e. how to determine what type of terrain the driver's vehicle is over? Is this possible from the [human] driver module, or will I need to look in the car specific code? =20 =20 Thx Peter Simard Immersion Corporation (Canada) |
|
From: Eric E. <eri...@fr...> - 2004-07-02 17:00:28
|
Christos Dimitrakakis wrote:
> After submitting my kludge for the case when the player revs up and
> then lets go of the clutch, causing the wheels to spin, I noticed that
> this does not have very good properties.
I agree with that :-(
>
> The problem is that when external forces are applied to the wheels,
> then their angular velocity is changed by taking into account the
> complete inertia of the system, including the engine, assuming that
> the clutch is not pressed.
that's not the only problem see later.
>
> So my kludge code should only be activated during periods when the
> rotational inertia of the system changes because the clutch has just
> been engaged/disengaged recently.
>
> My kludge consists of changing the updateRpm() code in engine.cpp so
> that instead of the engineRPM always matching the drivetrain rpm
> (times the gear ratio), there is a smooth change, while at the same
> time following the law of conservation of angular momentum..
>
> One thing I could do is to disregard the engine inertia when
> calculating the angular velocity for the drivetrain and use just
> the kludge to maintain a small rpm differential between the drivetrain
> and engine.
this can give good results.
>
> Or maybe there is a better way to account for changes in
> rotational inertia that lead to changes in in angular velocity. (Like,
> when you swivel with your arms stretched and then you pull your arms
> together, you rotate faster).
>
> I also have a question related to something that I was not sure of
> when looking at the code, which is how the new angular velocities are
> calculated in general. I think this is what happens:
>
> 1. According to the current transmission gear, we find an overall I
> for each one of the wheels, that includes its share of the load from
> the engine.
yes
>
> 2. We calculate the new angular velocity of wheels according to this I
> and external forces.
be careful that the engine force is the current one and the
wheel reaction forces are the one at the previous step.
so the 1st step can give high engine force and no road reaction,
the wheel goes too far, then at the next step, the road reaction
overcomes the engine force so the wheel goes back... too bad.
It is really tricky to compute road reaction forces to be ONLY
reaction forces...
>
> 3. We average those at the drivetrain(?)
>
> 4. We change the rpm of the engine to match exactly that of the
> drivetrain, since the rpm of the drivetrain was calculated with an I
> that takes into account the engine I.
this is for engine brake, when the wheel rotation revs up the engine.
>
> If this is correct, then the reason why it was necessary to kludge
> this was that when the player changes the clutch setting, the
> following thing happens:
>
> 1. The engine has a rotational momentum I_engine * w_engine
> 2. Total momentum J=I_engine*w_engine + I_wheels*w_wheels
don't forget the gear ratio ;-)
> 3. The player lets go of the clutch. Now we have J', which according
> to the conservation of momentum should be equal to J (disregarding the
> torque produced by the engine, which can be added later)
> 4. Then J'=(I_engine+I_wheels)*w_overall
>
> If anyone has a better idea of how to implement the conservation of
> rotational momentum for the engine-wheels system without requiring to
> rewrite everything, it'd be glad..
joker here ;-)
>
>
>
Eric.
--
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
TORCS - http://torcs.org
The Open Racing Car Simulator
AKA The Other Release Coming Soon (Skin'r)
How soon is soon ? (RaceBlizter)
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
|
|
From: Christos D. <dim...@id...> - 2004-07-01 22:02:08
|
After submitting my kludge for the case when the player revs up and then lets go of the clutch, causing the wheels to spin, I noticed that this does not have very good properties. The problem is that when external forces are applied to the wheels, then their angular velocity is changed by taking into account the complete inertia of the system, including the engine, assuming that the clutch is not pressed. So my kludge code should only be activated during periods when the rotational inertia of the system changes because the clutch has just been engaged/disengaged recently. My kludge consists of changing the updateRpm() code in engine.cpp so that instead of the engineRPM always matching the drivetrain rpm (times the gear ratio), there is a smooth change, while at the same time following the law of conservation of angular momentum.. One thing I could do is to disregard the engine inertia when calculating the angular velocity for the drivetrain and use just the kludge to maintain a small rpm differential between the drivetrain and engine. Or maybe there is a better way to account for changes in rotational inertia that lead to changes in in angular velocity. (Like, when you swivel with your arms stretched and then you pull your arms together, you rotate faster). I also have a question related to something that I was not sure of when looking at the code, which is how the new angular velocities are calculated in general. I think this is what happens: 1. According to the current transmission gear, we find an overall I for each one of the wheels, that includes its share of the load from the engine. 2. We calculate the new angular velocity of wheels according to this I and external forces. 3. We average those at the drivetrain(?) 4. We change the rpm of the engine to match exactly that of the drivetrain, since the rpm of the drivetrain was calculated with an I that takes into account the engine I. If this is correct, then the reason why it was necessary to kludge this was that when the player changes the clutch setting, the following thing happens: 1. The engine has a rotational momentum I_engine * w_engine 2. Total momentum J=I_engine*w_engine + I_wheels*w_wheels 3. The player lets go of the clutch. Now we have J', which according to the conservation of momentum should be equal to J (disregarding the torque produced by the engine, which can be added later) 4. Then J'=(I_engine+I_wheels)*w_overall If anyone has a better idea of how to implement the conservation of rotational momentum for the engine-wheels system without requiring to rewrite everything, it'd be glad.. -- Christos Dimitrakakis IDIAP (http://www.idiap.ch/~dimitrak/main.html) |
|
From: Eric E. <eri...@fr...> - 2004-07-01 16:44:00
|
Christos Dimitrakakis wrote:
> Hm.. it has been quite quiet lately.. anyway. For the car damages, I
> would like to add scratch marks to the car if possible. If I traverse
> the sg hierarchy, I guess I can find the surfaces and textures and
> write on them directly, but maybe it is easier to have yet another
> texture blended on top which has the scratchmarks and I can change its
> alpha channel. Do you think there is some other way to do it?
>
Currently the multitexturing is made in a "specific" way,
have a look in grvtxtable.cpp
I asked Christophe to rework on that part to make it
more generic.
Eric.
--
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
TORCS - http://torcs.org
The Open Racing Car Simulator
AKA The Other Release Coming Soon (Skin'r)
How soon is soon ? (RaceBlizter)
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
|