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

solved.
I update with "cvs update -Ad"

thanks


--- El vie 16-ene-09, ANGEL <man...@ya...> escribió:

> De: ANGEL <man...@ya...>
> Asunto: [Torcs-devel] bug to use 3dwheel?
> A: tor...@li...
> Fecha: viernes, 16 enero, 2009, 12:48 am
> hello
> 
> I am new to the list. I am developing cars and circuits for
> torcs.
> I had installed torcs from cvs since January 2009 and have
> also updated from cvs.
> So far I used 3dwheel without problems but i can not
> upgrade in any way to use them. I have read in the lists
> that this is achieved with a patch that apparently is
> already included by default. It do not works for me.
> Can this be an error in the latest updates.
> 
> thanks
> 
> 
>       ¡Todo sobre la Liga Mexicana de fútbol!
> Estadisticas, resultados, calendario, fotos y más:&lt;
> http://espanol.sports.yahoo.com/
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Torcs-devel mailing list
> Tor...@li...
> https://lists.sourceforge.net/lists/listinfo/torcs-devel


      ¡Todo sobre la Liga Mexicana de fútbol! Estadisticas, resultados, calendario, fotos y más:&lt;
http://espanol.sports.yahoo.com/

Hello, this is my plan for the next year for simuv3

1. Fix collisions. [Right now 50% done]
2. See why 4wd cars can't output as much power on the road
as their engine nominally allows.  [I suspect this is related to the
central differential].
3. Allow camber and caster settings for the suspension itself, rather 
than merely the wheel. [should be easy, but needs testing and car tuning]
4. Aerodynamics improvements. [easy, but needs testing and tuning]
5. Better/more differential models. [needs a model]
6. Better/more suspension models. [needs a model]
7. Re-introduce tire wear and temperature effects. [needs a _lot_ of 
testing]

For 5 and 6, those of you with some knowledge, books, diagrams, could 
post some designs on the list or send them to me so that I can try and
make an appropriate model. Currently the only differential model which 
is verified to be 100% correct is the FREE differential. The suspension 
models should be correct though.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Please test and comment.

- - Fixed some scaling errors in CollideXY();


- - Made CollideZ() somewhat better.  Still work to do though.



- - Incorporated a shift in the slip angle that depends on

road camber angle for tyres, according to the advice of

Pacejka in 'Tyre and Vehicle Dynamics'. The difference

in handling is small. The important thing is that

now you can 'preload' the tyres so that the car

responds more sharply or more gently.  This is an effect

similar to that obtained by toeing the tyres, but it

is speed dependent.



- - Fixed the OPTIMAL model for aerodynamics. Now it is the

default model in PRO mode. It is slightly more efficient

than the other model, so that should make up a bit for the

reduced downforce. I think I will also add an 'efficiency'

term here to model the viscous drag.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJduO7yBv6kELa61sRAtk2AJ4v500QmZiJTlrVw5yinBUJhmSdkACfVFXA
C8beOincME7yPV0RnocwGQ8=
=V0PE
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have now added two callbacks, as Paolo Leoncini suggested, for
skidamarks.  Namely:

int grSkidmarksPredrawCallback(ssgEntity *obj)
{
~    glDepthMask(GL_FALSE);
~    glPolygonOffset(-15, -20);
~    glEnable(GL_POLYGON_OFFSET_FILL);
}

int grSkidmarksPostdrawCallback(ssgEntity *obj)
{
~    glDisable(GL_POLYGON_OFFSET_FILL);
~    glDepthMask(GL_TRUE);
}


This however, is not sufficient to prevent skids from flickering on and
off depending on the viewing angle.

I noticed this:

When the skidmarks are not visible on a portion of the track, the part
of the car's shadow which has soft alpha blending disappears as well (so
it does not appear blurry any more).

So my guess is that this has something to do with thresholding, but I
have no other clues.

Any ideas?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJdFCtyBv6kELa61sRAozRAJ90ETKXeswsqb/dV2X40gSa7FxCJACeJX2B
58zw6c9l2FUy2BqkwWQWnd0=
=kxsv
-----END PGP SIGNATURE-----

	
hello

I am new to the list. I am developing cars and circuits for torcs.
I had installed torcs from cvs since January 2009 and have also updated from cvs.
So far I used 3dwheel without problems but i can not upgrade in any way to use them. I have read in the lists that this is achieved with a patch that apparently is already included by default. It do not works for me.
Can this be an error in the latest updates.

thanks


      ¡Todo sobre la Liga Mexicana de fútbol! Estadisticas, resultados, calendario, fotos y más:<
http://espanol.sports.yahoo.com/

ping

Hi Christos

> I have patched all tracks and default surfaces to use higher barrier
> friction coefficients, as detailed in my recent post.
> 
> TODO: fix simuv2 friction code (ideally based on simuv3's
> SimCarCollideXYScene()).  Should I take care of that as well, Bernhard?

Yes, please let me know when you committed it, I would like to review it
afterwards. Please test your changes as well carefully. Thank you.

Sincerely yours

Bernhard

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Torcs-devel mailing list
Tor...@li...
https://lists.sourceforge.net/lists/listinfo/torcs-devel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Albert Vilella wrote:
| This is really good. Does this also apply to the beginners level?
| Maybe some people would like to be able to endlessly scratch the sides of
| the car in beginner's mode and still win the race :-p
|

The friction values themselves apply to all levels.  I would have to
change the code to specifically lower the friction for lower skill
levels.  Currently skill levels affect traction, damages, downforce
(simuv3) and suspension/axle damage (simuv3).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJbLh7yBv6kELa61sRApTpAJ4wDHqt8uvOctH+YLAvaEmrE6HEIwCZAWyc
8NAQafajds5XTI4UKpmD1rg=
=DHfy
-----END PGP SIGNATURE-----

This is really good. Does this also apply to the beginners level?
Maybe some people would like to be able to endlessly scratch the sides of
the car in beginner's mode and still win the race :-p

On Tue, Jan 13, 2009 at 12:36 PM, Christos Dimitrakakis <
ole...@fa...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I have patched all tracks and default surfaces to use higher barrier
> friction coefficients, as detailed in my recent post.
>
> TODO: fix simuv2 friction code (ideally based on simuv3's
> SimCarCollideXYScene()).  Should I take care of that as well, Bernhard?
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFJbIrDyBv6kELa61sRAn9XAJ45YCSZ5uxCW1GRbXRXJqfJWeOxwgCePqrR
> CqTiOT7xM/9O66T54topygo=
> =unJv
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Torcs-devel mailing list
> Tor...@li...
> https://lists.sourceforge.net/lists/listinfo/torcs-devel
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have patched all tracks and default surfaces to use higher barrier
friction coefficients, as detailed in my recent post.

TODO: fix simuv2 friction code (ideally based on simuv3's
SimCarCollideXYScene()).  Should I take care of that as well, Bernhard?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJbIrDyBv6kELa61sRAn9XAJ45YCSZ5uxCW1GRbXRXJqfJWeOxwgCePqrR
CqTiOT7xM/9O66T54topygo=
=unJv
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


| I removed all parameters from the model but the "spring". The other
parameters
| just scale the result and waste performance, so I threw these out of
the model.
|

Yes, you are right.

|
| Does not matter, finally it is just a torsion spring again, for little
angles it
| is just a spring (correct me if I got this wrong,
phi*springconst=momentum, and
| sin(x) ~ x for small phi, so the moment of inertia just ends up in the
spring
| constant as constant).
|


| I think you cannot feel the difference, so it does not make sense.
|

Did a quick test just to make sure, and yes: it only makes things more
complex without really gaining anything.  So I'll follow your example
and get rid of the extra stuff.

Cheers,
Christos


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJY9SdyBv6kELa61sRAngRAJ4kdzEldUTB+0PJST3q7AFF12I/wACdGw+z
GRz//eutUocMnb89V3Vcma4=
=XUkn
-----END PGP SIGNATURE-----

Hi Christos

> Recently on the TRB it has come to light that the simuv2 and simuv3
> anti-roll bar models are slightly different.

> Im simuv3, the anti-roll-bar uses a limit on the force applied through
> the bar, implemented via the anti-roll-bar course (xMax). However, in
> simuv2 the anti-roll-bar suspension course plays no role whatsoever. I
> think this makes more sense, actually.

I removed all parameters from the model but the "spring". The other parameters
just scale the result and waste performance, so I threw these out of the model.

The roll bar model does simply transfer "force" proportional to the suspension
lenth difference from one side to the other, thats it (exactly what a real fixed
installed anti rollbar does when he operates on "Hookes" range of the material).

> 1) 4th power model (corresponds to the tension of a stiff metal rod, so
> is probably the most realistic)

Does not matter, finally it is just a torsion spring again, for little angles it
is just a spring (correct me if I got this wrong, phi*springconst=momentum, and
sin(x) ~ x for small phi, so the moment of inertia just ends up in the spring
constant as constant).

> 2) piecewise 2nd power model: linear until xMax, then quadratic
> 3) piecewise linear model with 'play': no force until xMax, then linear,
> with no upper limit,
> This seems relatively realistic, since most such mechanical systems have
> a bit of play.
> 4) make it an option! (complicates things for drivers)

I think you cannot feel the difference, so it does not make sense.

> tangent: a lot of options in torcs sim right now are implemented via ifs

Tangent, what are you talking about?

Bye, Bernhard.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Recently on the TRB it has come to light that the simuv2 and simuv3
anti-roll bar models are slightly different.

Im simuv3, the anti-roll-bar uses a limit on the force applied through
the bar, implemented via the anti-roll-bar course (xMax). However, in
simuv2 the anti-roll-bar suspension course plays no role whatsoever. I
think this makes more sense, actually.

So, perhaps I should change simuv3's ARB to be like simuv2's. But while
we're at it, let's examine all the alternatives. So, what we have is:

simuv2: linear model of anti-roll bar
simuv3: linear model with force clamped at a maximum depending on the
course (xMax).

There are four other options:

1) 4th power model (corresponds to the tension of a stiff metal rod, so
is probably the most realistic)
2) piecewise 2nd power model: linear until xMax, then quadratic
3) piecewise linear model with 'play': no force until xMax, then linear,
with no upper limit,
This seems relatively realistic, since most such mechanical systems have
a bit of play.
4) make it an option! (complicates things for drivers)

If we change the models, I will go through all standard 7 cars to fix
the parameters if necessary, but I can't do it for all other cars.

My suggestion is to make simuv3 like simuv2 and add an option for other
suspension models.

tangent: a lot of options in torcs sim right now are implemented via ifs
or cases.  Would it be more efficient to implement them via function
pointers? (we are using straight C in any case for most of the sim)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJYy41yBv6kELa61sRAltnAJ9u5oHkU7puvxmlt4YZ7osol3ixZACeMGVR
uH6L4kaw5fMiAHRCpOlpURM=
=3sip
-----END PGP SIGNATURE-----

Hello,

we want to do some research with torcs. The goal is to simulate some unusual
situations on the road. For example the subject is driving and suddenly a
dear appears on the road. A other case would be that the subject has to
follow an other car which makes some unpredictable movements.

For the experiments we have the cases:
1) We would like to prepare a track such that the dears appear on the same
spots.
2) They appear on random spots
3) We can make them appear in front of the subject by typing a key.

For every case the event which occurs must be reported back on a external
device e.g. the parallel port.

We know that not everything is currently in the engine but we would be happy
about some hints where to start with the changes and how difficult it will
be. (In terms of the engine design).

Kind regards, Max.

Mon, 05 Jan 2009 20:03:37 +0100, Pacho Ramos
<pa...@co...> :

> It also gives some messages like:
> make[2]: warning: jobserver unavailable: using -j1.
I reproduced that in Pardus too, I had to specifically add -j1 to
compile successfully.

                   Doruk

--
FISEK INSTITUTE - http://www.fisek.org.tr

Hi Pacho

The TORCS Makefiles do not allow proper parallel builds, just use ordinary make.

> It also gives some messages like:
> make[2]: warning: jobserver unavailable: using -j1.  Add `+' to parent
> make rule.

Hmm, wierd, I am not sure if this is the known issue, thank you for the hint.

Bye, Bernhard

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here are two patches increasing the surface friction of all barriers.
The increases are conservative (from 0.0 to 0.2-0.4) and are done mainly
to prevent cars from being able to take turns simply by sliding around
the barriers.  Anyway, this is only a first step.  I think it should be
up to the individual track writers to give correct values (now that the
simuv3 barrier friction is working properly - I'll backport the fixes to
simuv2 once I've finished with simuv3).

The surface.xml patch additionally lowers the friction of curbs to 1.0.
Again, it is up to individual track owners to fix their curb friction
according to what is desired.

I am only giving a patch here rather than submitting to CVS directly,
since the values are tentative.  I have tested all the tracks, however.

Christos Dimitrakakis wrote:
| Andrew Sumner wrote:
|
| | Sounds good to me.  By the same token, perhaps lowering the default curb
| | frictions in data/tracks/surfaces.xml to 1.2 would be a good improvement
| | too?  1.4 is a lot higher than most track surfaces & causes cars to get
|
| OK, I guess it's a good idea to put this as the default.
|
| PS2. The CollideXYScene friction calculation needs to be fixed in simuv2
| as well.

- 
------------------------------------------------------------------------------
_______________________________________________
Torcs-devel mailing list
Tor...@li...
https://lists.sourceforge.net/lists/listinfo/torcs-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJYozjyBv6kELa61sRAk0PAKCa8YqYTPGcLi5xokXVtmrq9Wv9YQCfbd8b
huwzKUmcQRXRPQtEC+z/vpk=
=LXQm
-----END PGP SIGNATURE-----

It works fine with me for -j2.

The warning should only pop up for make install, I think.

Hello all and thanks for your time.
I want to know if there is some way to make/script some kind of
"trigger" or same thing in the simulator. I mean, let's say i want to
show a message on the player screen in case the car steps on a certain
area or stays in an area for a certain period of time. Is there a way
to do that? what should i read?

Thanks in advance

Pablo

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Sumner wrote:

| Sounds good to me.  By the same token, perhaps lowering the default curb
| frictions in data/tracks/surfaces.xml to 1.2 would be a good improvement
| too?  1.4 is a lot higher than most track surfaces & causes cars to get

OK, I guess it's a good idea to put this as the default.

PS2. The CollideXYScene friction calculation needs to be fixed in simuv2
as well.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJYbyFyBv6kELa61sRAtrvAJ9NazvLLvLA7RgaiYeVMwtGIL1XRgCcCeAi
/8squpamE+6rjPWibnIw2YI=
=+kKV
-----END PGP SIGNATURE-----

> PS. A lot of tracks have 0 friction coefficients for the barriers.
> This is a bit silly.  In Michigan, for example, you can take all bends
> with 250+ km/h simply by letting the car slide against the right
> barrier.  I'll change those to more reasonable values.  Namely:

> 0.1-0.2 for metal barriers
> 0.2-0.4 for concrete barriers

> Anyway, this is more a game-play question, but I'd like to hear your
> thoughts.

Sounds good to me.  By the same token, perhaps lowering the default curb
frictions in data/tracks/surfaces.xml to 1.2 would be a good improvement
too?  1.4 is a lot higher than most track surfaces & causes cars to get
badly hung up on the curbs (especially inner-corner ones).  For some tracks
that may make sense, but it'd be better to have a more driver-friendly value
as the default wouldn't it?

cheers
Andrew

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

PS. A lot of tracks have 0 friction coefficients for the barriers.
This is a bit silly.  In Michigan, for example, you can take all bends
with 250+ km/h simply by letting the car slide against the right
barrier.  I'll change those to more reasonable values.  Namely:

0.1-0.2 for metal barriers
0.2-0.4 for concrete barriers

depending on how 'rough' they look, but I think that
values at the lower end are fine.  Using 0.2 for the walls in michigan
slows you down considerably, but you are still able to take the turns
at 200 km/h.  A 0.4 can make you spin if you touch the walls.

There is also the question of whether to make the friction
speed-dependent (this could be implemented naturally via the roughness
coefficient - for smooth walls, there is no reason for speed dependency).

Anyway, this is more a game-play question, but I'd like to hear your
thoughts.



Christos Dimitrakakis wrote:
| I have now fixed SimCarCollideXYScene() for simuv3 in the trunk.
| Forces and moments are now calculated correctly.  Please test.
|
| Fixes for CollideZ() [when the car touches the ground] and
| CollideResponse() [when two cars are touching] are upcoming.
|

- 
------------------------------------------------------------------------------
_______________________________________________
Torcs-devel mailing list
Tor...@li...
https://lists.sourceforge.net/lists/listinfo/torcs-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJYUn9yBv6kELa61sRAisJAJ4yeUeTpjPE3f7jIJtmm3kYicy5agCeOd+F
4zR8uhGRogZYfbkoFBOweHs=
=yDpi
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have now fixed SimCarCollideXYScene() for simuv3 in the trunk.
Forces and moments are now calculated correctly.  Please test.

Fixes for CollideZ() [when the car touches the ground] and
CollideResponse() [when two cars are touching] are upcoming.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJYTylyBv6kELa61sRAvLtAJwOkTyrQQo6fjdlVISrxHibB93fFQCeKu9r
31ykTB/NS3FZDgiunMiRsYM=
=yCxI
-----END PGP SIGNATURE-----

I forgot to mention: I still need the patch of Miguel Martínez:
http://sourceforge.net/mailarchive/message.php?msg_name=20081124195334.48c56feb%40lcpybm
otherwise compilation fails with:

g++ -I/home/fe/torcs/torcs/export/include -I/home/fe/torcs/torcs -g -O2 -Wall -fPIC -fno-strict-aliasing -O2 -DUSE_RANDR_EXT -DGL_GLEXT_PROTOTYPES -Wall -fPIC -fno-strict-aliasing -O2 -DUSE_RANDR_EXT -DGL_GLEXT_PROTOTYPES  -D_SVID_SOURCE -D_BSD_SOURCE
-DSHM -DHAVE_CONFIG_H -Wno-deprecated -c K1999.cpp
K1999.cpp:15:22: error: iostream.h: Datei oder Verzeichnis nicht gefunden
K1999.cpp:26:21: error: iomanip.h: Datei oder Verzeichnis nicht gefunden
K1999.cpp:29:21: error: fstream.h: Datei oder Verzeichnis nicht gefunden
K1999.cpp:105: error: ‘ostream’ has not been declared
K1999.cpp: In function ‘void initTrack(int, tTrack*, void*, void**, tSituation*)’:
K1999.cpp:525: error: ‘ends’ was not declared in this scope


The appended patch is against today's CVS,
> diff -u src/drivers/K1999/K1999.cpp.orig src/drivers/K1999/K1999.cpp >K1999.cpp.patch


Greetings,
Frieder

Hi,

Bernhard Wymann schrieb:
> Hi all
> 
> I committed the following changes (check out branch r1-3-1):
> 
> - Fixed remaining const char* gcc warnings.

there are some (very few) warnings left here with:
gcc (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036]

namely:
img.cpp: In function ‘unsigned char* GfImgReadPng(const char*, int*, int*, float)’:
img.cpp:158: warning: format ‘%u’ expects type ‘unsigned int’, but argument 3 has type ‘png_uint_32’
img.cpp:158: warning: format ‘%u’ expects type ‘unsigned int’, but argument 4 has type ‘long unsigned int’

CarSoundData.cpp: In member function ‘void CarSoundData::calculateTyreSound(tCarElt*)’:
CarSoundData.cpp:205: warning: suggest parentheses around && within ||

TorcsSound.cpp: In constructor ‘OpenalTorcsSound::OpenalTorcsSound(const char*, OpenalSoundInterface*, int, bool, bool)’:
TorcsSound.cpp:333: warning: ‘void alutLoadWAVFile(ALbyte*, ALenum*, void**, ALsizei*, ALsizei*, ALboolean*)’ is deprecated (declared at /usr/include/AL/alut.h:113)
TorcsSound.cpp:333: warning: ‘void alutLoadWAVFile(ALbyte*, ALenum*, void**, ALsizei*, ALsizei*, ALboolean*)’ is deprecated (declared at /usr/include/AL/alut.h:113)
TorcsSound.cpp:357: warning: ‘void alutUnloadWAV(ALenum, ALvoid*, ALsizei, ALsizei)’ is deprecated (declared at /usr/include/AL/alut.h:116)
TorcsSound.cpp:357: warning: ‘void alutUnloadWAV(ALenum, ALvoid*, ALsizei, ALsizei)’ is deprecated (declared at /usr/include/AL/alut.h:116)

mainaccc.cpp: In function ‘void init_args(int, char**)’:
mainaccc.cpp:256: warning: suggest explicit braces to avoid ambiguous ‘else’

ac3dload.cpp: In function ‘int doKids(char*, ob_t*, mat_t*)’:
ac3dload.cpp:770: warning: suggest explicit braces to avoid ambiguous ‘else’

Thanks again and a good new year!

Greetings,
Frieder