rec.autos.simulators

rars-digest 19950618

Dave Gym

rars-digest 19950618

by Dave Gym » Tue, 20 Jun 1995 04:00:00

Robot Auto Racing Simulation (RARS) Mailing List Digest 19950618

The rars-digest is a compilation of choice cuts from the RARS mailing list.
It's published once a week to comp.ai.games, rec.autos.simulators, and to
individual subscribers. Send mail to dgy...@gdcarc.co.uk with a subject of
'subscribe rars-digest' to subscribe, or 'unsubscribe rars-digest' to
unsubscribe.

Contents

  Some Questions concerning porting
  Re: Some Questions concerning porting (comments by m)
  practice conditions (solo or all together)
  bug & fix for 0.61 - to be used today
  joystick driver on the ftp site now...
  New Collision Code
  To the Robot Authors, and Would-be Authors
  Race Report and Upcoming Races
  Re: Some Questions concerning porting
  Re: practice conditions (solo or all together)
  UNIX RARS 0.62 on ftp site.

------------------------------------------------------------------------------
From:             Nicole.Grei...@FernUni-Hagen.de (Nicole Greiber)
To:               rars-l...@netcom.com
To:               rars-l...@netcom.com
Subject:          Some Questions concerning porting
Date sent:        Sun, 11 Jun 1995 20:32:57 +0100

Hello

since we couldn't find an existing port of RARS to OS/2,
Ralph Scott (rsc...@alpha.netusa.net) and I will do that.

The portability of the code is great, and it is very easy
to get along with the OS-specific parts. But when I wanted to
add another .cpp file or two, I found it very difficult
to get through all of these static variables that are spread over
the whole project.
Is it necessary that these variables are declared static?
Wouldn't it be easier to have a header file for each of the
.cpp files that can be included where needed?

Another "difficulty" is caused by some of the graphics functions
in draw.cpp. The function graph_setup() calculates the track and
paints it. This produces some overhead in a graphical OS
because when the program window will be refreshed during a race,
there is no need to recalculate the track, only the painting
is needed. To avoid this, the function could be split.

Is anybody already working on changes like these, or is
anybody interested in them? For us it doesn't make sense
just to implement them in our version since that will reduce
compatibility and portability very much.
------------------------------------------------------------------------------
From:             "Mitchell E. Timin" <m...@cac.psu.edu>
Subject:          Re: Some Questions concerning porting (comments by m)
To:               Nicole.Grei...@fernuni-hagen.de (Nicole Greiber)
Date sent:        Sun, 11 Jun 1995 22:53:22 -0400 (EDT)
Copies to:        rars-l...@netcom.com (Rars- List)

Hello Nicole,

It's OK with me if people make structural changes to their ports.  My version
was developed originally for DOS, and my own convenience.  Later I made a
lot of changes to help the porters, but certainly not everything possible.

The important thing with a port is that the cars run the same, so that a
robot that can average X mph on track Y will do the same on any system.
A person should be able to develop and test his robot under OS/2 and then
compete in a race in a DOS system, or vice-versa.

About static variables, that is done to give them file scope instead of
global scope.  It make the program a little more resistant to programming
errors, especially those in the many robot functions from different authors.

m
------------------------------------------------------------------------------
From:             "Mitchell E. Timin" <m...@cac.psu.edu>
Subject:          practice conditions (solo or all together)
To:               rars-l...@netcom.com (Rars- List)
Date sent:        Sun, 11 Jun 1995 10:39:32 -0400 (EDT)

Hello All,

Randy suggested that I disable collisions during practice so that each car
would have the track all to itself, so-to-speak.  There is some merit to
this suggestion, but after thinking about it, I prefer it the way it is,
Buy the floor is open for your comments.

I am of the opinion that practice should be under race conditions, with
the necessity to avoid other cars.  The main reason is that I have seen that
cars that are optimized to run on an empty track are usually hyper-sensitive
to disturbances of any kind, hence they are easily run off the track by
other cars.  To win in realistic races a driver needs a robust algorithm
that sacrifices some speed for much higher reliability.

Starting with the next races we will have a much higher collision probability
and it will be essential to have some crash avoidance code to have much of
a chance of winning.

I will release a tutorial with an example of crash avoidance code in a
couple of days.

In the real world I thought that most practice was done with other cars on
the track.  I don't follow racing very closely, but I have seen some sports
car races many years ago, and I think I remember that most practice was not
solo.  Also, I used to race moto-cross, and we always practiced together.

m
------------------------------------------------------------------------------
From:             "Mitchell E. Timin" <m...@cac.psu.edu>
Subject:          bug & fix for 0.61 - to be used today
To:               rars-l...@netcom.com (Rars- List)
Date sent:        Sun, 11 Jun 1995 10:22:34 -0400 (EDT)

Hello All,

Rob Creager, our entomologist, pointed out a small bug.  It only affects
practice sessions, and only when they are long enough that cars can run
out of fuel.  What happens with the current code is that after a car
runs out of fuel it is checked for damage, and maybe put out of the race.
The cars are not supposed to be checked for damage during practices.
Only a very small change in CARZ.CPP is required.  After the following text:

if((stage != PRACTICE && damage > MAX_DAMAGE) || fuel <= 0.0) {

You will find this line:

if(damage > MAX_DAMAGE)  {

It should be changed to:

if(damage > MAX_DAMAGE  && stage != PRACTICE)  {

I have made this change for today's races, to allow the cars to practice
for 200 laps.  We have at least two cars that learn from practice.

m
------------------------------------------------------------------------------
Date sent:        Sat, 10 Jun 95 12:28:37 +0200
From:             dv3ki...@ida.his.se (Kim Laurio)
To:               rars-l...@netcom.com
Subject:          joystick driver on the ftp site now...

Well, now the joystick.zip and joystick.txt are on the ftp site.
Have fun!
------------------------------------------------------------------------------
From:             "Mitchell E. Timin" <m...@cac.psu.edu>
Subject:          New Collision Code
To:               rars-l...@netcom.com (Rars- List)
Date sent:        Sat, 10 Jun 1995 07:26:11 -0400 (EDT)

Hello All,

Tomorrow's races will be run with the regular version 0.61, just like is
on the ftp site.  (i.e., no surprise changes for tomorrow.)

But, the next races, in two weeks, will use different code to handle
collisions.  There are changes to three files only, CARZ.CPP, MISC.CPP and
MISC.H.  I will now send you all these files; just replace your current
versions and re-compile.

The main effect is more frequent and realistic collisions.  Cars no longer
run through each other, they crash.  Some visual overlap is still present,
but much less than before.

The robots will have to become better drivers.  I am about to release tutorial
7 which will have some code using s.nearby to attempt collision avoidance.
------------------------------------------------------------------------------
From:             "Mitchell E. Timin" <m...@cac.psu.edu>
Subject:          To the Robot Authors, and Would-be Authors
To:               rars-l...@netcom.com (Rars- List)
Date sent:        Mon, 12 Jun 1995 17:36:14 -0400 (EDT)

Hello All,

I am considering whether or not to continue putting the source code for
the robots on the ftp site after each race.  Some of the authors would
prefer to not make their code public.

If I adopt the new policy I will leave it to the authors to put their
robots on the ftp site if they wish.  I will upload only the .obj files,
which I realize are only useful to borland compiler users.

I invite your comments.
------------------------------------------------------------------------------
From:             "Mitchell E. Timin" <m...@cac.psu.edu>
Subject:          Race Report and Upcoming Races
To:               rars-l...@netcom.com (Rars- List)
Date sent:        Mon, 12 Jun 1995 13:33:06 -0400 (EDT)

RARS Bi-weekly Race Report
& News About Upcoming Races
June 12, 1995

RARS is the Robot Auto Racing Simulation, a competition for
programmers and an on-going challenge for practicioners of Artificial
Intelligence and real-time adaptive optimal control.  It consists of
a simulation of the physics of cars racing on a track, a graphic
display of the race, and a separate control program (robot "driver")
for each car.  All RARS software and activities are free and open to
the public.  For more information e-mail to m...@cac.psu.edu.

Contents

Authors Point Standings
Upcoming Races
June 11 Competitors
June 11 Race Commentary
June 11 Race Report
--------------------------------------------------------------------

Expert Class Point standings
Jussi Pajala        22 pts         (Finland)
Randy Saint         13 pts         (U.S.A.)
Tim Battersby       10 pts         (Canada)
Safai Ma            10 pts         (Canada)
Bill Benedict        9 pts         (U.S.A.)
Mike Inman           6 pts         (U.S.A.)
Muir Lee Harding     6 pts         (U.S.A.)

Novice Class Points:
Oscar Gustafsson    14 pts         (Sweden)
Grant Reeve          8 pts         (New Zealand)
Tristrom Cooke       7 pt          (Australia)
Carl Burke           6 pts         (U.S.A.)
Patrick Tierney      5 pts         (Canada)
Thomas Rooney        2 pts         (U.S.A.)
--------------------------------------------------------------------

The Next Six RARS Race Meets
For the next twelve weeks we will have the oval track races three
times and the road races on the June 11 tracks three times.  This is
to give the authors time to master passing, collision avoidance and
the geometry of the two road race tracks, S1.TRK and S2.TRK.
There is live race commentary on IRC channel #RARS, 5:00 PM EDT.

June 25, July 23, August 20:
No. of races: 6 novice and 6 expert
Track: oval2
Laps: 10 each race
Software version:   0.62 (or latest variant of 0.60)
Surface type:       0
no practice on race day, practice at home all you want!
The default starting order system will be used, i.e. alternating
random and reversed.

July 9, August 6, September 3:
No. of races        2 novice and 2 expert
Tracks:             S1.TRK and S2.TRK, one race on each
Laps: 80 each race
Software version:   0.62 (or latest variant of 0.60)
Surface Type:       1
no practice, random starting order.
--------------------------------------------------------------------

June 11 Race Report:

Competitors, Novice Class:

Grant Reeve         New Zealand    Piranha
Oscar Gustavsson    Sweden         OscCar2
Tristrom Cooke      Australia      Bingo1
Carl Burke          U.S.A.         Blender2

Competitors, Expert Class:

Bill Benedict       U.S.A.         Rusty
Safai Ma            Canada         Burns
Jussi Pajala        Finland        WappuCar
Randy Saint         U.S.A.         Ramdu
Mike Inman          U.S.A.         Indretti

The novices found S1.TRK to be too much for them!  None could finish
more than 5 laps.  Piranha was clearly the fastest car by far, but
this race was determined by distance completed, not speed.  The novices
did better on S2.TRK, with all but Piranha able to go the distance.
There was no clear winner on the S1 races, but OscCar2 dominated the
races on S2.  Point totals gave first place for the day to OscCar2.

After the novices races were over it seemed to me that none of the
novices were ready to be advanced to expert.  Accordingly, I did not
enter OscCar2 in the expert races.  I now feel that that was a
mistake, because now that the races are over, it seems that OscCar2
compares favorably with some of the expert drivers.  Only WappuCar
and Ramdu, among the experts, were able to complete 25 laps on both
tracks.  If Oscar Gustavsson wishes to move into the expert class, I
will do that.  OTOH, he may prefer to stay a novice a little longer
in order to (maybe) take a first place in the novice class.

The expert races were dominated by WappuCar, which worked its way into
the lead early in every race, and kept it.  Ramdu had to fight with
Burns for 2nd place, but only for a while, as Burns was prone to
contact the walls and damage himself.  Ramdu and WappuCar were the
only robots capable of learning, and they were both able to increase
their average speed by over one mph during the 200 lap practice
session, on each track.  The robot Burns was very fast, and held the
lead briefly, and 2nd place for considerable time in several races.
But it couldn't avoid contact with the walls of the track, and was
therefore eventually damaged beyond repair.
--------------------------------------------------------------------

Novice Races

4 cars for 25 laps.  The track was s1.trk.  The drivers were:
Blender2, Bingo1, Piranha, and OscCar2.

The initial RVG seed was 2834.

results of race 1:
starting positions:
Bingo1, Blender2, Piranha, and OscCar2.

1  Piranha  avg spd 71.11     5 laps  30090 damage  131 fuel   10 pts accum
2   Bingo1  avg spd 63.32     5 laps  30318 damage  127 fuel    6 pts accum
3  OscCar2  avg spd 67.25     3 laps  30262 damage  137 fuel    4 pts accum
4 Blender2  avg spd 0         0 laps  30968 damage  148 fuel    3 pts accum

results of race 2:
starting positions:
OscCar2, Piranha, Blender2, and Bingo1.

1   Bingo1  avg spd 63.35     5 laps  30197 damage  127 fuel   16 pts accum
2  Piranha  avg spd 71.26     4 laps  30043 damage  134 fuel   16 pts accum
3  OscCar2  avg spd 67.1      3 laps  30566 damage  137 fuel    8 pts accum
4 Blender2  avg spd 0         0 laps  30191 damage  148 fuel    6 pts accum
--------------------------------------------------------------------
4 cars for 25 laps.  The track was s2.trk.  The drivers were:
Blender2, Bingo1, Piranha, and OscCar2.

The initial RVG seed was 17486.

results of race 1:
starting positions:
Piranha, OscCar2, Blender2, and Bingo1.

1  OscCar2  avg spd 60.13    25 laps    768 damage   62 fuel   10 pts accum
2 Blender2  avg spd 59.28    25 laps    222 damage   58 fuel    6 pts accum
3   Bingo1  avg spd 57.07    24 laps    211 damage   55 fuel    4 pts accum
4  Piranha  avg spd 63.45     1 laps  30146 damage  142 fuel    3 pts accum

results of race 2:
starting positions:
Bingo1, Blender2, OscCar2, and Piranha.

1  OscCar2  avg spd 59.82    25 laps  10247 damage   62 fuel   20 pts accum
2 Blender2  avg spd 59.28    25 laps   5155 damage   59 fuel   12 pts accum
3   Bingo1  avg spd 57.05    24 laps    752 damage   55 fuel    8 pts accum
4  Piranha  avg spd 63.03     1 laps  30123 damage  143 fuel    6 pts accum
--------------------------------------------------------------------
Overall Results of Novice Races:
day pts   season pts
1st place   OscCar2      28        10
2nd place   Bingo1       24         6
3rd place   Piranha      22         4
4th placd   Blender2     18         3
--------------------------------------------------------------------

Expert Races

5 cars for 25 laps.  The track was s1.trk.  The drivers were:
WappuCar, Ramdu, Burns, Rusty, and Indretti.

The initial RVG seed was 30850.
200 practice laps were requested.

results of race 1:
starting positions:
Rusty, Indretti, Ramdu, Burns, and WappuCar.

1 WappuCar  avg spd 74.03    27 laps   6996 damage   71 fuel   10 pts accum
2    Ramdu  avg spd 68.13    25 laps   4416 damage   66 fuel    6 pts accum
3 Indretti  avg spd 67       24 laps   5263 damage   76 fuel    4 pts accum
4    Burns  avg spd 71.96    12 laps  30099 damage  114 fuel    3 pts accum
5    Rusty  avg spd 62.15     1 laps  30152 damage  145 fuel    2 pts accum

results of race 2:
starting positions:
WappuCar, Burns, Ramdu, Indretti, and Rusty.

1 WappuCar  avg spd 74.27    27 laps    654 damage   71 fuel   20 pts accum
2    Ramdu  avg spd 68.17    25 laps   6147 damage   67 fuel   12 pts accum
3 Indretti  avg spd 67.03    24 laps   1154 damage   76 fuel    8 pts accum
4    Burns  avg spd 71.91    10 laps  30466 damage  119 fuel    6 pts accum
5    Rusty  avg spd 62.25     1 laps  30468 damage  145 fuel    4 pts accum
--------------------------------------------------------------------
5 cars for 25 laps.  The track was s2.trk.  The drivers were:
WappuCar, Ramdu, Burns, Rusty, and Indretti.

The initial RVG seed was 28777.
200 practice laps were requested.

results of race 1:
starting positions:
WappuCar, Indretti, Ramdu, Burns, and Rusty.

1 WappuCar  avg spd 67.29    26 laps    192 damage   63 fuel   10 pts accum
2    Ramdu  avg spd 62.36    25 laps  11998 damage   60 fuel    6 pts accum
3 Indretti  avg spd 59.66     7 laps  30029 damage  121 fuel    4 pts accum
4    Burns  avg spd 61.58     2 laps  30278 damage  140 fuel    3 pts accum
5    Rusty  avg spd 60.01     2 laps  30288 damage  142 fuel    2 pts accum

results of race 2:
starting positions:
Rusty, Burns, Ramdu, Indretti, and WappuCar.

1 WappuCar  avg spd 67.29    27 laps   3581 damage   63 fuel   20 pts accum
2    Ramdu  avg spd 62.31    25 laps  14766 damage   60 fuel   12 pts accum
3 Indretti  avg spd 59.6      6 laps  30050 damage  124 fuel    8 pts accum
4    Burns  avg spd 61.59     2 laps  30008 damage  140 fuel    6 pts accum
5    Rusty  avg spd 58.23     1 laps  30094 damage  145 fuel    4 pts accum
--------------------------------------------------------------------
Overall Results of Expert Races:
day pts    season pts
1st place   WappuCar     40        10
2nd place      Ramdu     24         6
3rd place   Indretti     16         4
4th placc      Burns     12         3
5th place      Rusty      8         2
--------------------------------------------------------------------
------------------------------------------------------------------------------
To:               "Nicole Greiber" <Nicole.Grei...@fernuni-hagen.de>,
"RARS mailing list" <rars-l...@netcom.com>
From:             "Marcel Offermans" <mar...@wbmt41.wbmt.tudelft.nl>
Date sent:        Mon, 12 Jun 1995 12:54:26 +0100
Send reply to:    "M.F.Offermans" <M.F.Offerm...@wbmt.tudelft.nl>
Subject:          Re: Some Questions concerning porting
Organization:     Private TCP/IP node

Hello Nicole,

> since we couldn't find an existing port of RARS to OS/2, Ralph Scott
> (rsc...@alpha.netusa.net) and I will do that.

As the author of the Amiga port of RARS, I couldn't resist adding a few
comments. :-)

> The portability of the code is great, and it is very easy to get along
> with the OS-specific parts. But when I wanted to add another .cpp file
> or two, I found it very difficult to get through all of these static
> variables that are spread over the whole project.
> Is it necessary that these variables are declared static? Wouldn't it be
> easier to have a header file for each of the .cpp files that can be
> included where needed?

These are two different things, IMHO. I totally agree with you that there
should have been header files with each source module. This would have made
the "interface" of each module much clearer.

The static variables (should) have been declared that way to hide them from
other modules completely. I'm sure there's room for improvement here.

In short, for future versions of RARS, I'd propose:

- to put all global variables at the top of each module;

- to make all global variables that are only of use to that specific
module static;

- to create a header file for each module, containing:

- prototypes for all globally accesible functions;

- a list of all "exportable" variables, constants and defines.

- to add prototypes for local functions at the top of the module and to
declare those functions static.

Does anybody have any other suggestions or comments about this? I'll make
this an item in the "ideas database" if necessary.

> Another "difficulty" is caused by some of the graphics functions in
> draw.cpp. The function graph_setup() calculates the track and paints it.
> This produces some overhead in a graphical OS because when the program
> window will be refreshed during a race, there is no need to recalculate
> the track, only the painting is needed. To avoid this, the function
> could be split.

I must admit that I haven't had to deal with this problem. The Amiga also
has a graphical OS. However, unless you really want to refresh window
contents yourself, you don't have to deal with this at all. In other words,
I haven't had problems with this, and I suspect that redrawing and
especially flood filling every time the window gets damaged is a
complicated thing. I am assuming you're talking about repairing "damage" to
the window after it has been (partly) overlapped by other windows.

Suggestions:

- look for a solution that lets the OS redraw the window without your
intervention (this will probably mean that the OS has to make a copy
of the part(s) of the window that are overlapped before it actually
draws another window on top of it);

- make a copy of the whole window yourself, and use it as a backup to
restore parts from;

- make a separate "repair" function that copies some of the functionality
of the graph_setup() function (and perhaps take this functionality
out of the graph_setup() itself and just add a call to your new routine
there.

> Is anybody already working on changes like these, or is anybody
> interested in them? For us it doesn't make sense just to implement them
> in our version since that will reduce compatibility and portability very
> much.

Taking the drawing itself out of the graph_setup() function seems a logical
idea. So if it increases portability (is this perhaps also an issue for the
Mac or X-Windows version?) I'm all for it.

Good luck with the port.

Greetings, Marcel
------------------------------------------------------------------------------
To:               "rars-list" <rars-l...@netcom.com>
From:             "Marcel Offermans" <mar...@wbmt41.wbmt.tudelft.nl>
Date sent:        Mon, 12 Jun 1995 02:12:34 +0100
Send reply to:    "M.F.Offermans" <M.F.Offerm...@wbmt.tudelft.nl>
Subject:          Re: practice conditions (solo or all together)
Organization:     Private TCP/IP node

> Randy suggested that I disable collisions during practice so that each
> car would have the track all to itself, so-to-speak. There is some merit
> to this suggestion, but after thinking about it, I prefer it the way it
> is, Buy the floor is open for your comments.

I have suggested something similar in the past, and for a reason.
Optimizing parameters for a circuit is difficult as it is. If you use a
genetic algorithm or any other optimization algorithm, you will usually use
the lap time as an indication of the success of the current settings. If
another car collides with you, and you get a bad laptime because of that,
the algorithm will not work well.

> I am of the opinion that practice should be under race conditions, with
> the necessity to avoid other cars. The main reason is that I have seen
> that cars that are optimized to run on an empty track are usually
> hyper-sensitive to disturbances of any kind, hence they are easily run
> off the track by other cars. To win in realistic races a driver needs a
> robust algorithm that sacrifices some speed for much higher reliability.

This is an important issue too. Cars should have a much better avoidance
routine from now on. Your new collision detection routine has shown that
most cars make a mess of it right now. I don't think this is caused by the
fact that they drive so much on the edge that there's no room for
corrections, most cars choose to simply ignore other cars. You will see
from the collision routines that I sent you that most cars won't even
finish if the collision mechanism itself is made more realistic (using
semi-elastic collisions).

> Starting with the next races we will have a much higher collision
> probability and it will be essential to have some crash avoidance code
> to have much of a chance of winning.

Better make that ...to have much of a chance of finishing. :-)

> I will release a tutorial with an example of crash avoidance code in a
> couple of days.

That would be nice.

> In the real world I thought that most practice was done with other cars
> on the track. I don't follow racing very closely, but I have seen some
> sports car races many years ago, and I think I remember that most
> practice was not solo. Also, I used to race moto-cross, and we always
> practiced together.

It depends. A lot of F1 teams for example have an extensive test program
that is done on an empty circuit. On the other hand, practice and
qualification sessions are on a "full" circuit. In the Indy cars, at least
on the Indy 500 the qualification is on an empty circuit. I guess it
differs. It wouldn't be too difficult to support both options in RARS. We
could just make it `yet-another-switch' and decide from race to race what
option is going to be used. Actually, we already have both options, as long
as the cars save practice results to a file. Just run RARS once for every
car before starting the actual race. :-)

Marcel

PS: If you want to choose only one option, I'm for the 1 car in practice
(or no-collision) option.
------------------------------------------------------------------------------
Date sent:        Wed, 14 Jun 1995 09:48:19 -0500
To:               rars-l...@netcom.com
From:             sa...@phoenix.net (Randy Saint)
Subject:          UNIX RARS 0.62 on ftp site.

The latest version of the UNIX RARS (0.62) is now on the ftp
site.  This includes the latest collision detection code, as
well as the bug fix for checking damage when out of fuel during
practice.

Ftp site administrator:  you may remove rars061.*.unix.* files
as they are superceded by this current version.

To the people that were having problems with undefined symbols:
Has the latest version fixed this problem, or are you still getting

>ld: Undefined symbol

>   ___ls__FR7ostreamRCt6smanip1ZUl

James Dooley offered this hint, but I'm not sure where to include it
or what to change to fix the error.

> The undefined symbol is: (from c++filt)
> operator<<(ostream &, smanip<unsigned long> const &)

Good Luck,
Randy
------------------------------------------------------------------------------

The rars-digest is compiled and published by (Dave `Gizmo' Gymer)
                  dgy...@gdcarc.co.uk  http://www.mal.com/~dgymer
-- Dave "Gizmo" Gymer                 Telephone +44 (0)1268 534228
--   General DataComm Advanced Research Centre Ltd, Basildon, UK
-- dgy...@gdcarc.co.uk            Team Shark-Porsche online racing
-- http://www.mal.com/~dgymer/     LFRS 95-96 co-director & car #3


rec.autos.simulators is a usenet newsgroup formed in December, 1993. As this group was always unmoderated there may be some spam or off topic articles included. Some links do point back to racesimcentral.net as we could not validate the original address. Please report any pages that you believe warrant deletion from this archive (include the link in your email). RaceSimCentral.net is in no way responsible and does not endorse any of the content herein.