worldforge-all-lists Mailing List for WorldForge

Nothan Phal wrote:
> 
> Oops..
> 
> Oh well, never mind.  I thought I had included a commit comment- it's my
> first cvs commit of anything, and the msg file I was presented with was
> edited before I comitted.  Anyway, the reason I did it was that I
> couldn't get the architecture.tex file to display properly - something
> to do with missing whatnots or something.  So, when the conversion to
> HTML worked, I figured I'd share the experience so to speak.
> 
> Nothan Phal

No worries. I probably should put a 'HACKING' file in there...

Again, thanks for taking an interest. :-)

--
Oliver White
STAGE Janitor
www.worldforge.org
_______________________________________________
Server mailing list
Se...@ma...
http://mail.worldforge.org/lists/listinfo/server

I'll be glad to edit, spell-check, and grammar check.  

Tim R Ansell wrote:
> 
> Well i think its about time we had another Chopping Block!
>  There seems to much going on in Worldforge this should be one packed
> issue. I hope to start monthly Chopping Blocks up again.
> 
> Already the articles are being readied,
> zzorn: How to Render a Forest in 3D
> phal: newbies guide to Stage
> Sal: Large-Scale terrain rendering
> 
> Other articles i would like to see for this issue,
> We have a new web site, why not an article about that?
> ?? Upcoming Acorn release ??
> What ever happened to the story bryce was writing for the previous CB??
> I see lots of commits for Erlang-stage, how about some info on this
> project?
> What about this comic i keep hearing about? Maybe have a "issue" of the
> comic with each CB release?
> 
> All other articles are welcome, as well short status reports about
> projects are VERY welcome!
> 
> I'm going to try and get an interview up and running as well, any ideas
> on who I should interview?? I was thinking along the line of maybe an
> artist or a person involved with STAGE.
> 
> All articles should be submitted to me by the 30 of July (Is that too
> soon?) and the CB should be ready about 1 week after that.
> 
> I'm also interested in a new Chopping Block "front cover" graphic for
> each issue. Anyone want to volunteer for this issue?
> 
> Mithro
> 
> PS I'm not that good at spelling and/or grammar so i would love a
> co-editor that could help pickup those types of errors.
> _______________________________________________
> General mailing list
> Ge...@ma...
> https://mail.worldforge.org/lists/listinfo/general

-- 
-[Dave Turner                              Stalk me:  (215)-545-2859]
---------------------------------------------------------------------
"It's like filing a suit for your own wrongful death because somebody 
coughed next to you and they might have had TB--first of all, you 
ain't dead, second of all, they didn't have it!" - Effugas
_______________________________________________
General mailing list
Ge...@ma...
https://mail.worldforge.org/lists/listinfo/general

zzorn, thanks for the spot.=20
As I said, the draft is still rough. I plan to go
through and revise/proof it, i just thought people
might want to read it so I could get feedback that it
was going in the right direction.
If anything in the story inspires you as to directions
that the comic should go in, let me know.

Im thinking of elaborating some cities on the south
coast, higher tech places that ascribe to a sortof
'zombie-punk' technology. Think the stiched put to
everyday industrial uses.

-Hal
--- Hans H=E4ggstr=F6m <han...@he...> wrote:
> At 09:23 2001-07-08, Halsted wrote:
> >Chapter 1 of the Oman Story is now up in rough
> draft.
> >For those who don't know, the Oman Story is a
> serial
> >story set in the Sands of Syllus game world, for
> the
> >purpose of world and character development, as well
> as
> >to get people interested in the project and the
> world.
> >The story acts as a bit of a prologue to the Sands
> of
> >Syllus Comic.
> >
> >Oman Story Page:
>
>http://www.worldforge.org/website/rules/syllus/oman.html
>=20
> Very good story!
>=20
> It has a good pace, keeping up reader interest.
> The description of witch woman's cave sounds
> intriguing,
> and the plot has a certain feel that suits well with
> the desert nomads, I=20
> think.
>=20
> The mention of the old forest that once covered the
> Syllus basin was=20
> interesting.
>=20
> At the end, I think there was a name mixup:
> "And with that thought, Phyras drifted off to the
> last night of easy sleep=20
> he would have for a long time."
> Shouldn't that be Oman instead of Phyras?
>=20
> --=20
> Hans H=E4ggstr=F6m (aka zzorn)
> http://www.iki.fi/zzorn/
> "Share and Enjoy" - Cirius Cybernetics corp. -
> THHGTTG
>=20
> _______________________________________________
> Rules mailing list
> Ru...@ma...
> http://mail.worldforge.org/lists/listinfo/rules


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
_______________________________________________
Rules mailing list
Ru...@ma...
http://mail.worldforge.org/lists/listinfo/rules

I am working on the container stuff with Rakshasa. You have to wait
some time for it. It is damn hot here so we are running little low on
enthusiasm to do anything else than lie in the beach right now. Anyway
terrain stuff is free to work on as long as you talk with Rakshasa
and ask what physics/collision detection require from the terrain.
Also Bryce had some ideas on how to implement the Terrain so read
back the posts. AFAIK in server side we need only height, normal
and terrain type information in each coordinate. At some point we
also need to be able to have several layers of "terrain" on top of each
other for example surface and cave floors etc. Whether we use
some fractal or interpolation approach is up to performance I figure.

Majority of the moving entities are connected to terrain and in each
movement they need to inquire earlier mentioned data from the
terrain engine.

Code sharing with  clients would be great if we can rip only those
portions of the terrain engine what we need.

best regards,
Morgenes

Oliver White wrote:

> Just a kick-start post:
>
> Stage needs a terrain engine to be of any great use. I'd like to take
> charge of development of this module. Also needed is the container code
> for shepherd's core, which I believe will need to interface with the
> terrain engine.
>
> The plan is as follows:
>
> 1) Investigate COAL as a potential building block for the system.
> 2) Develop a terrain database system.
> 3) Develop the Shepherd container code.
> 4) Integrate the database and container code, along with the rest of
> shepherd.
> 5) Work out a map delivery system via Atlas.
>
> 5 may need to be moved back, if it looks like it will influence the
> database design significantly. If you reckon this might be an issue,
> pipe up now, otherwise we'll go with that sequence of development.
>
> Morgenes/Team: Does this meet with your approval?
>
> --
> Oliver White
> STAGE Janitor
> www.worldforge.org

_______________________________________________
Server mailing list
Se...@ma...
http://mail.worldforge.org/lists/listinfo/server

> * Soil layers such as base rock layer, regolith, and topsoil, with
> thickness and type information.

Are we trying to do some geological simulation model ?=)

> * Vegetation and forest layers.
> * Item layers (stones, flowers, trees, etc).  Density, uniform/clustered
> distribution, minimum distance, etc.

If we are going to use this approach each time the game world is booted
and client also render their world like this and not object by object basis
then we need to share the rendering code so we don't get ambiquity in the
game world.

>
> * 1D objects such as rivers, roads, and such, with various properties
> describing how they will be "rendered".
> * Special effect layers, such as 'This area was under a glacier 10 000
> years ago', 'This area was burned 50 years ago', etc.

This layer stuff sounds pretty interesting but is this glaciar stuff a bit too
fancy?

> * Weather / climate layers, with average rainfall, clouds, wind, and
> temperatures.

Weather simulation too? Mmm.. sounds very nice.

> * Layers generated by players, such as negative layers for where the
> players have hauled away ground,
>    and additional layers where they have deposited material.

Deposited materials as well as 3d objects on the map should propably be
saved similar way as all entities in the world. Maybe static entities and
dynamic entities should be handled separately.. Ie modified trees and
players for example..

All together good ideas.

rgs,
Morgenes

_______________________________________________
Server mailing list
Se...@ma...
http://mail.worldforge.org/lists/listinfo/server

Tim R Ansell wrote:

> Aloril has agreed to do an article on atlas...
> Wilton has agreed to do an article on "Creating maps for Xclient's
> intior engine"..
> 
> The more articles the merrier!

Good stuff mith. Put me down for a short story.

--
Oliver White
STAGE Janitor
www.worldforge.org
_______________________________________________
General mailing list
Ge...@ma...
https://mail.worldforge.org/lists/listinfo/general

The webalizer logs for the WF web server have been updated.
They are available at: http://www.worldforge.org/~wf/webalizer/

anubis
_______________________________________________
Infra mailing list
In...@ma...
http://mail.worldforge.org/lists/listinfo/infra

Hans H=E4ggstr=F6m wrote:

> Interesting example:  Digging a moat around a castle, and leading the
> water from a nearby stream into it by digging a channel and blocking th=
e
> original stream below the channel forking.

Interestinger example: Water seeps through moat bed, filling up the
Gnomeish Caverns, the occupants of which are Not Amused.

--
Oliver White
STAGE Janitor
www.worldforge.org
_______________________________________________
Server mailing list
Se...@ma...
http://mail.worldforge.org/lists/listinfo/server

*ahem*

I did say I'd like to keep generated documentation *out* of CVS. It
should be possible to generate HTML docs though a make command. No
commit comment either... naughty.

Thanks for taking an interest though. :-)

If you can come up with a good reason why generated documentation should
stay in the repository, let us know, otherwise I'll remove these files.

worldforge cvs wrote:
> 
> CVSROOT:        /home/cvspsrv/worldforge
> Module name:    forge
> Changes by:     phal    01/07/08 22:17:01
> 
> Added files:
>         servers/stage/docs/programmer/architecture_html:
>                                                          architecture.css
>                                                          architecture.html
>                                                          images.log
>                                                          images.pl
>                                                          images.tex
>                                                          index.html
>                                                          labels.pl
>                                                          node1.html
>                                                          node10.html
>                                                          node11.html
>                                                          node12.html
>                                                          node13.html
>                                                          node14.html
>                                                          node15.html
>                                                          node16.html
>                                                          node17.html
>                                                          node18.html
>                                                          node19.html
>                                                          node2.html
>                                                          node20.html
>                                                          node21.html
>                                                          node22.html
>                                                          node23.html
>                                                          node24.html
>                                                          node25.html
>                                                          node26.html
>                                                          node27.html
>                                                          node28.html
>                                                          node29.html
>                                                          node3.html
>                                                          node30.html
>                                                          node31.html
>                                                          node32.html
>                                                          node33.html
>                                                          node34.html
>                                                          node35.html
>                                                          node36.html
>                                                          node37.html
>                                                          node38.html
>                                                          node39.html
>                                                          node4.html
>                                                          node40.html
>                                                          node41.html
>                                                          node42.html
>                                                          node43.html
>                                                          node44.html
>                                                          node45.html
>                                                          node46.html
>                                                          node47.html
>                                                          node48.html
>                                                          node49.html
>                                                          node5.html
>                                                          node50.html
>                                                          node51.html
>                                                          node52.html
>                                                          node53.html
>                                                          node54.html
>                                                          node55.html
>                                                          node56.html
>                                                          node57.html
>                                                          node58.html
>                                                          node59.html
>                                                          node6.html
>                                                          node60.html
>                                                          node61.html
>                                                          node62.html
>                                                          node63.html
>                                                          node64.html
>                                                          node65.html
>                                                          node66.html
>                                                          node67.html
>                                                          node68.html
>                                                          node69.html
>                                                          node7.html
>                                                          node8.html
>                                                          node9.html
> 
> Log message:
> 
> _______________________________________________
> CVS mailing list
> CV...@ma...
> http://mail.worldforge.org/lists/listinfo/cvs

--
Oliver White
STAGE Janitor
www.worldforge.org
_______________________________________________
Server mailing list
Se...@ma...
http://mail.worldforge.org/lists/listinfo/server

At 19:22 2001-07-09, Morgenes wrote:
> > * Soil layers such as base rock layer, regolith, and topsoil, with
> > thickness and type information.
>
>Are we trying to do some geological simulation model ?=3D)

Why, how did you guess? =3D)

Actually, that is a pretty simple model of the ground, but will add reali=
sm=20
for digging
tunnels and such.  On a bare mountain the regolith layer would be zero=20
thickness,
and the topsoil only occasional.  In a desert the topsoil would probably =
be=20
a thick layer
of sand, and the regolith perhaps coarser stone further down.

Keep in mind that all this is stored in the map server or map module, and=
=20
is not exposed to
the rest of the game.  When the players dig a pit, a negative layer is=20
created and added to
the landscape, and if they dig deeper any negative layer at that spot is=20
thickened.
When the map server/module creates the final visual/"rendered" maps that=20
the game server
and clients use, the height is just lower at the pit, and the texture=20
changes to that of the local
regolith or base rock.



> > * Vegetation and forest layers.
> > * Item layers (stones, flowers, trees, etc).  Density, uniform/cluste=
red
> > distribution, minimum distance, etc.
>
>If we are going to use this approach each time the game world is booted
>and client also render their world like this and not object by object ba=
sis
>then we need to share the rendering code so we don't get ambiquity in th=
e
>game world.

The map server/module would do the rendering to a final map, and only sen=
d a
map with height and terrain (and perhaps water and forest) data to the cl=
ients.
To the server it would also send the item layers (stones here, with=20
distribution
such and such, etc), or alternatively the map server could decode an item=
=20
layer
and just tell the game server what items there are in that area.
In any case, the game server will send the items to the client the normal=
 way,
when the client is close enough to see them.


> >
> > * 1D objects such as rivers, roads, and such, with various properties
> > describing how they will be "rendered".
> > * Special effect layers, such as 'This area was under a glacier 10 00=
0
> > years ago', 'This area was burned 50 years ago', etc.
>
>This layer stuff sounds pretty interesting but is this glaciar stuff a b=
it too
>fancy?

Well, these are both tools that world developers or an automatic world=20
generator
can use to shape the landscape, and also effects that actual events in th=
e
game can create (forest fire, flood, ash from a volcano eruption, etc).

The special effects would just consist of some rules, operations, or=20
perhaps scripts
that modify the affected area.  A glacier would flatten and smoothen the =
land
(except the peaks that rise above the glacier surface), leave ridges of=20
lose rock
along melting lines, leave huge boulders sitting here and there on the=20
landscape,
and perhaps also create many shallow lakes.


> > * Weather / climate layers, with average rainfall, clouds, wind, and
> > temperatures.
>
>Weather simulation too? Mmm.. sounds very nice.
>
> > * Layers generated by players, such as negative layers for where the
> > players have hauled away ground,
> >    and additional layers where they have deposited material.
>
>Deposited materials as well as 3d objects on the map should propably be
>saved similar way as all entities in the world. Maybe static entities an=
d
>dynamic entities should be handled separately.. Ie modified trees and
>players for example..

Hmm.
If you create a really big pile of sand somewhere, it would be nice if it=
 was
actually a part of the landscape, that you could walk on and dig in, inst=
ead
of just a big object.

I think a good way to handle this would be to convert any pile bigger tha=
n=20
some
fixed amount, perhaps 1 cubic meter, to a layer.  You can still dig in th=
e=20
layer
and move the material elsewhere if you wish, but it also makes it possibl=
e
to shape the landscape better.

Interesting example:  Digging a moat around a castle, and leading the
water from a nearby stream into it by digging a channel and blocking the
original stream below the channel forking.


As for static trees, stones, etc:
Those should only be made entities if they are modified by a character, s=
o=20
that their
state changes.  Unmodified trees are always generated at the same place=20
next time
the local landscape is generated.  This way we don't have to store all th=
e=20
trees in the
forests.

For bigger modifications, such as forest fires, we can use effect layers,=
=20
that for
example could give a tree X points of fire damage when it is created from=
 a=20
item/forest layer.


>All together good ideas.
>
>rgs,
>Morgenes

--=20
Hans H=E4ggstr=F6m (aka zzorn)
http://www.iki.fi/zzorn/
"Share and Enjoy" - Cirius Cybernetics corp. - THHGTTG

_______________________________________________
Server mailing list
Se...@ma...
http://mail.worldforge.org/lists/listinfo/server

Brent and Lisa wrote:

> If you haven't already go ahead and write up a wish list for John Sheets.
> Post it to client@ if you like.  I know he's considered integrating Atlas
> into COAL.

I'm certainly happy to accept help with Atlas support in COAL.  If anyone wants
to work on this, let me know!  I probably won't get around to it for awhile.

> I've been thinking about the layer approach for a while too and
> how it might work as an interface into COAL.  I especially think 'generic'
> layers would be helpful.  The client code asks for x number of samples from
> a given area and COAL returns a string of values.  Interpretation of these
> values is entirely up to the implementor.  Sort of like an auxilary buffer
> in OpenGL.  Internally COAL could use fixed size blocks, splines, fractals
> whatever.  Right now I'm working on semantic maps in Ptah though so I don't
> know when I would get around to implementing the a layer interface.  Still,
> I think it's a good idea and if you specify what you want it might get
> worked into the 0.3.x version of COAL somewhere along the line.

Could someone go into more detail about this "layer" system, just so we're all
on the same page?  I'll then respond with comments on how it fits (or can fit)
into COAL.

> > Latest finding from #stage:
> > Description: Map format discussion.
> > URL:
> http://grimicus.dyndns.org/logs/info.php?file=stage200107080913.irc#line138

I've been glancing over this discussion.  Here are some of my thoughts...

> zzorn
>   As long as there is a good way to plug in fractal map generation
>   later, I'm happy.

It'll be as simple as deriving a new COAL component class to encapsulate it.
The inheritance path will probably look something like this:

  CoalComponent --> CoalMapComponent --> CoalFractalMap

The COAL database can iterate through all CoalComponent's when it does its
queries (which makes up most of your interaction with the database).  So for
the most part, it should be a simple, low-impact addition.  Mainly it'll
involve coming up with a fractal map format (I'm guessing binary, like with
heightmaps...?) and support on the client side.  COAL will handle it mostly at
the semantic-free blackbox level, not caring what the data means but happy to
manage it for you.  Possibly with some convenience functions to make client
developer life easier.

Hmmm, if there's a fractal pattern that you will tend to reuse, you could
create a class derivative of CoalInfoComponent rather than CoalMapComponent.
The former is for meta-objects, like graphic images, which you'd refer to from
your actual map instances, e.g. terrain polygons and objects.

As far as layering and terrain (landscape) polygons, COAL already supports
(errhum, though it's currently broken in 0.3.x) polygon layering and rendering
to 2D tiles.  If you can get Anvil to run with the stable branch of COAL and
load the various BLADE maps (using runanvil), you'll see it in action.

The 0.3.x series will add support for heightmaps as used in UClient, plus
fractal maps if someone else wants to implement that.  I imagine that fractal
maps would be separate files, like heightmaps.  This will make it very easy to
implement optional support for those "enhancing" formats.  If the client
doesn't receive a heightmap or fractal map (or chooses to ignore it), it can
display the maps in flat format, like Anvil and old UClient.

> zzorn
>             I'm not sure how well it could deal with different detail levels
for
>             different screen areas on the client..  But if it's all polygons,
I
>             suppose it should be possible.

Regarding detail level, there's nothing in the new COAL architecture which
should make this difficult to deal with.  I'm planning to have heightmaps
individually scalable (based on discussions I've had with Sal).  So you could
have two different 200 pixel x 200 pixel heightmaps, one which covers a 50
square kilometer area and another which covers a 600 square meter area, based
on a scaling constant.  The same could apply to a fractal map format.  The
details would be handled by the respective CoalHeightmap or CoalFractalMap
classes.

> james
>             we need to make it support layers and creating the boundary tiles

What do you mean by "support layers"?  You can already stack polygons, though
IIRC stacking order is implicit (by map order), not explicit (by some <layer>
tag in the map format).  Is this the distinction you're referring to?  Or to
"terrain that faded in/out", as zzorn commented?  FWIW, in the 0.3.x
architecture, you can nest landscape polygons inside each other, e.g., create a
meadow object that holds grass and path polygons and tree objects, and even
heightmaps.  You could then toss the meadow object around as if it was a single
unit.

In any case, my preference is to keep it simple for as long as we can afford
to, implementing the bare minimum that we need to, to get things working
properly.  Later on, we can refactor and add in things like extra layer
support.

> james
>             creating polygons based on things like erosion is another process

Right.  As far as I'm concerned, all special dynamic effects like erosion will
take place entirely on the server.  Any map/object formats that the client
receives (and COAL handles) should be static snapshots of data.  If a river
erodes, and a riverbank collapses over night, the client shouldn't be
responsible for extrapolating that from map formats it downloaded the day
before.  The server should simply send it an update for that area.  Thus, all
client data should be pre-rendered to static formats.

> james
>             we need to polygons so the AI can figure out how to naviagte and
so
>             on

Very cool idea!  It's much easier to say "follow this polygon called 'road'"
than it is to say, "figure out a road based on this list of tile types and try
to follow it".

> zzorn
>             Isn't blade already a fairly ok polygon format?
> james
>             blade with whatever changes you think are useful

Blade is a good start, but is still pretty rough around the edges.  I'd like to
fix the BLADE map loader to be easier to modify.  Currently it's pretty ugly
under the covers, mostly as a side effect of using a SAX XML parser with C
callbacks (not too friendly with C++ encapsulation).  I'm open to suggestions
on how to improve the BLADE specification.  In particular, it doesn't support
the cool edge filling stuff that MIM supports.  That would be a very welcome
addition, and a nice small project for someone....

> james
>             it would be useful to provide a 'boundary thickness' for polygon
>             edges

Ooo, yep!

In summary, I agree with James that it's very important to keep things as
simple as possible.  COAL should be able to handle new formats with minimal
extra maintenance, so we won't be limited by the implementation.  We're much
more likely to get something useful in the short term if we keep it simple.
Down the road, we can refactor and redesign as needed.  If we spend all our
energy designing for systems two years in the future, we'll end up creating
tons of cruft and dead-end code that we may never need, or that are
fundamentally mis-implemented because we let theory drive the design, not
practicality.

Okay, enough of the soapbox.  (c:  I'm enjoying this discussion.  Let's keep it
going!

John

--
John R. Sheets, Consultant
js...@mc...
McCaa, Webster & Associates, Inc.

Writing GNOME Applications
http://www.aw.com/cseng/titles/0-201-65791-0/


_______________________________________________
Client mailing list
Cl...@ma...
http://mail.worldforge.org/lists/listinfo/client

Oops..

Oh well, never mind.  I thought I had included a commit comment- it's my
first cvs commit of anything, and the msg file I was presented with was
edited before I comitted.  Anyway, the reason I did it was that I
couldn't get the architecture.tex file to display properly - something
to do with missing whatnots or something.  So, when the conversion to
HTML worked, I figured I'd share the experience so to speak.

Nothan Phal

Oliver White wrote:
> 
> *ahem*
> 
> I did say I'd like to keep generated documentation *out* of CVS. It
> should be possible to generate HTML docs though a make command. No
> commit comment either... naughty.
> 
> Thanks for taking an interest though. :-)
> 
> If you can come up with a good reason why generated documentation should
> stay in the repository, let us know, otherwise I'll remove these files.
> 
> worldforge cvs wrote:
> >
> > CVSROOT:        /home/cvspsrv/worldforge
> > Module name:    forge
> > Changes by:     phal    01/07/08 22:17:01
> >
> > Added files:
> >         servers/stage/docs/programmer/architecture_html:
> >                                                          architecture.css
> >                                                          architecture.html
> >                                                          images.log
> >                                                          images.pl
> >                                                          images.tex
> >                                                          index.html
> >                                                          labels.pl
> >                                                          node1.html
> >                                                          node10.html
> >                                                          node11.html
> >                                                          node12.html
> >                                                          node13.html
> >                                                          node14.html
> >                                                          node15.html
> >                                                          node16.html
> >                                                          node17.html
> >                                                          node18.html
> >                                                          node19.html
> >                                                          node2.html
> >                                                          node20.html
> >                                                          node21.html
> >                                                          node22.html
> >                                                          node23.html
> >                                                          node24.html
> >                                                          node25.html
> >                                                          node26.html
> >                                                          node27.html
> >                                                          node28.html
> >                                                          node29.html
> >                                                          node3.html
> >                                                          node30.html
> >                                                          node31.html
> >                                                          node32.html
> >                                                          node33.html
> >                                                          node34.html
> >                                                          node35.html
> >                                                          node36.html
> >                                                          node37.html
> >                                                          node38.html
> >                                                          node39.html
> >                                                          node4.html
> >                                                          node40.html
> >                                                          node41.html
> >                                                          node42.html
> >                                                          node43.html
> >                                                          node44.html
> >                                                          node45.html
> >                                                          node46.html
> >                                                          node47.html
> >                                                          node48.html
> >                                                          node49.html
> >                                                          node5.html
> >                                                          node50.html
> >                                                          node51.html
> >                                                          node52.html
> >                                                          node53.html
> >                                                          node54.html
> >                                                          node55.html
> >                                                          node56.html
> >                                                          node57.html
> >                                                          node58.html
> >                                                          node59.html
> >                                                          node6.html
> >                                                          node60.html
> >                                                          node61.html
> >                                                          node62.html
> >                                                          node63.html
> >                                                          node64.html
> >                                                          node65.html
> >                                                          node66.html
> >                                                          node67.html
> >                                                          node68.html
> >                                                          node69.html
> >                                                          node7.html
> >                                                          node8.html
> >                                                          node9.html
> >
> > Log message:
> >
> > _______________________________________________
> > CVS mailing list
> > CV...@ma...
> > http://mail.worldforge.org/lists/listinfo/cvs
> 
> --
> Oliver White
> STAGE Janitor
> www.worldforge.org
> _______________________________________________
> Server mailing list
> Se...@ma...
> http://mail.worldforge.org/lists/listinfo/server

-- 
Captain Nothan Phal
XO - USS Pulsar
ph...@mu...
ICQ: 3392951
_______________________________________________
Server mailing list
Se...@ma...
http://mail.worldforge.org/lists/listinfo/server

At 2:59 PM +0300 7/9/01, Hans H=E4ggstr=F6m wrote:
>At 19:22 2001-07-09, Morgenes wrote:
>>  > * Soil layers such as base rock layer, regolith, and topsoil, with
>>>  thickness and type information.
>>
>>Are we trying to do some geological simulation model ?=3D)
>
>Why, how did you guess? =3D)
>
>Actually, that is a pretty simple model of the ground, but will add=20
>realism for digging
>tunnels and such.  On a bare mountain the regolith layer would be=20
>zero thickness,
>and the topsoil only occasional.  In a desert the topsoil would=20
>probably be a thick layer
>of sand, and the regolith perhaps coarser stone further down.

Allowing players to dig seems likely to lead to a lot of=20
complications. If I dig a trench at a lake will it fill with water?=20
Can I drain the lake? What about grief players who spend an hour each=20
day trying to dig up an entire zone? Or who carve some rude slogan=20
into the ground? It seems like players can dig a trench around a=20
corner, pull a monster there, and jump or levitate over the trench=20
and kill the mob with spells with no risk to themselves.

   -- Jesse
_______________________________________________
Server mailing list
Se...@ma...
http://mail.worldforge.org/lists/listinfo/server

Oliver White wrote:

> Just a kick-start post:
>
> Stage needs a terrain engine to be of any great use. I'd like to take
> charge of development of this module. Also needed is the container code
> for shepherd's core, which I believe will need to interface with the
> terrain engine.
>
> The plan is as follows:
>
> 1) Investigate COAL as a potential building block for the system.

Cool, though I'd have to rename it to CSOAL....  (c;

Seriously, if you have any questions about how COAL works and what it's
capable of, ask away (preferrably on client@, though server@ works too).

John

--
John R. Sheets, Consultant
js...@mc...
McCaa, Webster & Associates, Inc.

Writing GNOME Applications
http://www.aw.com/cseng/titles/0-201-65791-0/


_______________________________________________
Server mailing list
Se...@ma...
http://mail.worldforge.org/lists/listinfo/server

>First, we have source maps at the Map Server (or some map module, it 
>doesn't have to be on a separate machine).
>The source maps can consist of many layers:
>
>* Soil layers such as base rock layer, regolith, and topsoil, with 
>thickness and type information.
>* Vegetation and forest layers.
>* Item layers (stones, flowers, trees, etc).  Density, 
>uniform/clustered distribution, minimum distance, etc.
>* 1D objects such as rivers, roads, and such, with various 
>properties describing how they will be "rendered".
>* Special effect layers, such as 'This area was under a glacier 10 
>000 years ago', 'This area was burned 50 years ago', etc.
>* Weather / climate layers, with average rainfall, clouds, wind, and 
>temperatures.
>* Layers generated by players, such as negative layers for where the 
>players have hauled away ground,
>   and additional layers where they have deposited material.

What are you trying to achieve with all this complexity? Wouldn't it 
be better to get something simple working and add frills later? For 
example, a 256-color heightmap, a custom texture map, and a 
skybox/sphere? This is really simple, but in most ways I think it's 
capable of doing better than Kunark level EverQuest graphics.

>All these layers are combined, "rendered", in the map server for a 
>specific area at a specific resolution, when requested.
>The rendered map has much fewer layers, just a terrain type layer 
>(that decides which textures are used), a height layer, a water 
>height layer, item layers for things like stones and trees, and 
>perhaps vegetation layers for forest, under vegetation,

This sounds like you're hoping to automate the textures based on 
things like elevation, slope, and terrain type. I think that this can 
produce reasonable results, but it'll be tricky to do well and it'll 
never produce results as good as a hand generated texture map. I 
think the way to go is to create some tools to make it easy for 
artists to create the texture maps and add objects like vegetation.

>Also, the map sent to the client would probably have highest detail 
>level close to the observer, and lower detail further away.
>This way it is easy to also display far away mountains, without 
>reducing the local area too much.

This is no longer always a Good Thing. Modern video cards can render 
huge amounts of polygons, but only if you shovel the data over to the 
card in an optimal manner. It's tough to do this with a progressive 
LOD scheme so brute force solutions are making a come back.

   -- Jesse
_______________________________________________
Server mailing list
Se...@ma...
http://mail.worldforge.org/lists/listinfo/server

>  > james
>>              we need to polygons so the AI can figure out how to naviagte and
>so
>>              on
>
>Very cool idea!  It's much easier to say "follow this polygon called 'road'"
>than it is to say, "figure out a road based on this list of tile types and try
>to follow it".

I'm still not sold on having polygons: tool support is easier with 
heightmaps, and polygons make it harder for clients to select 
different rendering methods (although you can argue that this is a 
good thing).

EverQuest seems to handle pathing by attaching invisible paths that 
NPCs lock onto and follow. It's often rather cheesy since they'll 
always take the same route if they start at the same location and in 
dungeons they often path strangely (and pick up their buddies), but 
it reduces the load on the server and could work well if you want to 
have an NPC patrol a fixed route (at least until you support 
deformable terrain).

   -- Jesse
_______________________________________________
Client mailing list
Cl...@ma...
http://mail.worldforge.org/lists/listinfo/client

>From: Hans H=E4ggstr=F6m <han...@he...>
>Reply-To: in...@ma...
>To: in...@ma...
>Subject: [WF-Infra] Web site down?
>Date: Sat, 07 Jul 2001 18:35:30 +0300
>
>
>I can't reach www.worldforge.org, and other people on IRC seemed to have=
=20
>the same problem.
>
>My browser says:
>
>Unable to Open Site
>URL: http://www.worldforge.org/
>Reason: ETIMEDOUT Connection timed out in Connect
>
>
>I couldn't reach http://purple.worldforge.org/ either.
>
>
>--
>Hans H=E4ggstr=F6m (aka zzorn)

I can only speak for purple.  We had some rather intense thunderstorms ro=
ll=20
through town on Saturday.  While my home network stayed up, the dsl appea=
rs=20
to have been borked a bit.  We couldn't see outside, and outside couldn't=
=20
see us for a few hours.

Sorry about any outages.  And if we have any Japanese listmembers; could =
you=20
please keep those butterflies from flapping just a bit? ;)  Thanks.

anubis
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

_______________________________________________
Infra mailing list
In...@ma...
http://mail.worldforge.org/lists/listinfo/infra

On Mon, 09 Jul 2001 12:38:02 +0930
Tim R Ansell <mi...@se...> wrote:
> The more articles the merrier!

I could give a statusreport on silence-py so that everyone will find the
builtin webserver, ircbot and all the nice interfaces and commands. ;-)
If I actually get around to writing anything in this heat that is.
-- 
Anders Petersson aka Demitar
"Isn't that dangerous?" "Yes, but I'm reckless and welding is fun!"
       - Beneath a Steel Sky
_______________________________________________
General mailing list
Ge...@ma...
https://mail.worldforge.org/lists/listinfo/general

On Sun, Jul 08, 2001 at 07:12:10PM +0800, Edmund wrote:
> Btw, this is pretty much an offtopic question, but it's in regards to
> sourceforge.net.   What are the requirements of joining(ie. signing up
> for an account)?  I pretty much suck at programming in C++ (in the
> learning process).  I do a bit of PHP w/ MySQL.  I've checked some of
> the skillsets these people have on sourceforge.net, and quite frankly,
> I don't even know whether or not I should even bother.  I mean, the
> term 'wizard' is being thrown about pretty liberally.  Do I need to
> join a project?   Anyway, I did want to ask this question in WF.general,
> but felt it was a stupid question to ask there.  Heck, it's not that
> bright to ask here (being offtopic and that), but I felt that being
> a 'training' mailing list, it's a good place to ask it.   

You should think of signing up for sourceforge like signing up for slashdot with the addition of you could work on a project if you wanted to ;-).  I mean, it doesn't cost you anything to sign up, and you can get informed on projects you might find interesting enough to figure out wassup.  In fact, I signed up for it like a year ago, and didn't every use it till this weekend!  So, don't sweat the gurus.  there are 200,000 registered users, they can't all rock ;-).

Dan (Grimicus)

-- 
    Aliquid melius quam pessimum optimum non est
_______________________________________________
cpptraining mailing list
cpp...@ma...
https://mail.worldforge.org/lists/listinfo/cpptraining

Tim R Ansell wrote:
> 
> Well i think its about time we had another Chopping Block!
>  There seems to much going on in Worldforge this should be one packed
> issue. I hope to start monthly Chopping Blocks up again.
> 
> Already the articles are being readied,
> zzorn: How to Render a Forest in 3D
> phal: newbies guide to Stage
> Sal: Large-Scale terrain rendering
> 
> Other articles i would like to see for this issue,
> We have a new web site, why not an article about that?

Kosh as agreed to do this article...^

> ?? Upcoming Acorn release ??
> What ever happened to the story bryce was writing for the previous CB??
> I see lots of commits for Erlang-stage, how about some info on this
> project?
> What about this comic i keep hearing about? Maybe have a "issue" of the
> comic with each CB release?
> 
> All other articles are welcome, as well short status reports about
> projects are VERY welcome!
> 
> I'm going to try and get an interview up and running as well, any ideas
> on who I should interview?? I was thinking along the line of maybe an
> artist or a person involved with STAGE.
> 
> All articles should be submitted to me by the 30 of July (Is that too
> soon?) and the CB should be ready about 1 week after that.
> 
> I'm also interested in a new Chopping Block "front cover" graphic for
> each issue. Anyone want to volunteer for this issue?
> 
> Mithro
> 
> PS I'm not that good at spelling and/or grammar so i would love a
> co-editor that could help pickup those types of errors..

Aloril has agreed to do an article on atlas...
Wilton has agreed to do an article on "Creating maps for Xclient's
intior engine"..

The more articles the merrier!

Mithro
_______________________________________________
General mailing list
Ge...@ma...
https://mail.worldforge.org/lists/listinfo/general

> -----Original Message-----
> From: Lee Begg [mailto:ll...@pa...]
> 
> "McGinnes, Damien" wrote:
> >
> > http://actcomm.dartmouth.edu/dynamic/readme.html
> 
> it should be README.html  ;-)

 d'oh. The link would be better without the filename 
at the end at all - this goes to the author's page.

> > <snip>
> 
> Have a look at stage/scratchpad/dii  from
> the cvs for more.

I'll check it out.

> The one big question i have with dynamic loading is the use 
> for functions in stage by the dynamically loaded module(s).
> Could a RIM call methods from shepherd (assumming it
> compiled fine)?

The references aren't bad 
(The PS file referenced in the above readme is a good read
but needs a little bit of time (12 pages)
Another source I'm using is 
http://www2.linuxjournal.com/lj-issues/issue73/3687.html

anyhow, the answer is yes. I'm sure there are other ways but
one way is this:

assume class hierarchy 
base.h = the dynamic classes header file (from the distribution)
rimbase.h = rim interface spec inherits from base
xxxrim.h=header file for a xxx rim (inherits from rimbase)
xxxrim.cpp=xxx rim implementation
test.cpp=main test code that uses the dynamic class xxxrim


in the .h for your module globally declare the object/
function you need as extern, dont forget to include headers if needed
eg. #include aclass.h
extern aclass fred;

in the .cpp, use it as you would normally

in test.cpp instantiate fred as global

when linking test.cpp use the -rdynamic flag which forces the
main program to export its symbols to the libraries loaded
with dlopen (which in our case is the dynamic class)

> I have had a brief look at the readme for "libdynamic".  I am 
> about to download
> it and have a look

To save some hassle here are some commands :
when compiling a dynamic class use the following options
-fPIC     => creates position independant code

when linking use:
-shared -Wl,soname,${libname} -o ${libname}
where ${LIBNAME} is for example libRIM.so.1.0

when linking the code that calls a dynamic class use:
-ldl -ldynamic -rdynamic
(assuming libdynamic is in the library path eg /usr/local/lib)

I tried the above in some test code and it seems to work.
without the -rdynamic option, the library will throw an 
invalid version exception on load and report 
undefined symbol

> 
> Thanks again.
> 
> Later
> Lee

cheers,
Damien
_______________________________________________
Server mailing list
Se...@ma...
http://mail.worldforge.org/lists/listinfo/server

At 09:23 2001-07-08, Halsted wrote:
>Chapter 1 of the Oman Story is now up in rough draft.
>For those who don't know, the Oman Story is a serial
>story set in the Sands of Syllus game world, for the
>purpose of world and character development, as well as
>to get people interested in the project and the world.
>The story acts as a bit of a prologue to the Sands of
>Syllus Comic.
>
>Oman Story Page:
>http://www.worldforge.org/website/rules/syllus/oman.html

Very good story!

It has a good pace, keeping up reader interest.
The description of witch woman's cave sounds intriguing,
and the plot has a certain feel that suits well with the desert nomads, I=
=20
think.

The mention of the old forest that once covered the Syllus basin was=20
interesting.

At the end, I think there was a name mixup:
"And with that thought, Phyras drifted off to the last night of easy slee=
p=20
he would have for a long time."
Shouldn't that be Oman instead of Phyras?

--=20
Hans H=E4ggstr=F6m (aka zzorn)
http://www.iki.fi/zzorn/
"Share and Enjoy" - Cirius Cybernetics corp. - THHGTTG

_______________________________________________
Rules mailing list
Ru...@ma...
http://mail.worldforge.org/lists/listinfo/rules

At 12:22 2001-07-08, Oliver White wrote:
>Just a kick-start post:
>
>Stage needs a terrain engine to be of any great use. I'd like to take
>charge of development of this module. Also needed is the container code
>for shepherd's core, which I believe will need to interface with the
>terrain engine.
>
>The plan is as follows:
>
>1) Investigate COAL as a potential building block for the system.
>2) Develop a terrain database system.
>3) Develop the Shepherd container code.
>4) Integrate the database and container code, along with the rest of
>shepherd.
>5) Work out a map delivery system via Atlas.
>
>
>5 may need to be moved back, if it looks like it will influence the
>database design significantly. If you reckon this might be an issue,
>pipe up now, otherwise we'll go with that sequence of development.
>
>Morgenes/Team: Does this meet with your approval?


We had a discussion with James about the map format earlier today on IRC.
http://grimicus.dyndns.org/logs/info.php?file=3Dstage200107080913.irc#lin=
e138

As a result, I sketched up a rough diagram with some of the ideas:
http://purple.worldforge.org/wf/zzorn/terrain_diagram_01.png



It seems there's at least three different types of maps being passed arou=
nd=20
or stored at different stages in the process;
as source data on a map server, for collision and other purposes on the=20
game server, and for rendering the landscape on
the client.

Map server
"""""""""""""

First, we have source maps at the Map Server (or some map module, it=20
doesn't have to be on a separate machine).
The source maps can consist of many layers:

* Soil layers such as base rock layer, regolith, and topsoil, with=20
thickness and type information.
* Vegetation and forest layers.
* Item layers (stones, flowers, trees, etc).  Density, uniform/clustered=20
distribution, minimum distance, etc.
* 1D objects such as rivers, roads, and such, with various properties=20
describing how they will be "rendered".
* Special effect layers, such as 'This area was under a glacier 10 000=20
years ago', 'This area was burned 50 years ago', etc.
* Weather / climate layers, with average rainfall, clouds, wind, and=20
temperatures.
* Layers generated by players, such as negative layers for where the=20
players have hauled away ground,
   and additional layers where they have deposited material.

All these layers are combined, "rendered", in the map server for a specif=
ic=20
area at a specific resolution, when requested.
The rendered map has much fewer layers, just a terrain type layer (that=20
decides which textures are used), a height layer, a water height layer,=20
item layers for things like stones and trees, and perhaps vegetation laye=
rs=20
for forest, under vegetation,
or similar backgrounds (see my forest rendering article=20
http://www.worldforge.org/website/clients/rendering_forests.html ).
In addition, the game server may request some specific layers, such as=20
current weather (if it is done on the map server),  etc.

The map server could allow for different ways to generate the map data, a=
nd=20
"render" it to a final map.
Different sources of map data could perhaps be used simultaneously for=20
different areas or at different detail levels.
Fractal generation techniques can be used to generate detailed terrain fr=
om=20
overview maps that may contain additional
data for detailed terrain (fractal dimension, average height variation,=20
random seed, etc).

But to start with we could just store pre-"rendered" maps of the world=20
(Acorn, Mason), and concentrate on getting the
the basic map transport infrastructure working.


Game Server
"""""""""""""""

The game server will need the map for collision detection, path planning=20
for AI (or is that done on AI clients?), and various RIMs
will need different information about the environment.


Client
"""""""

When the map is sent to the client (either from the game or map server?),=
=20
some layers like item layers are removed,
and instead items such as trees and stones are sent by the game server th=
e=20
normal way.
Also, the map sent to the client would probably have highest detail level=
=20
close to the observer, and lower detail further away.
This way it is easy to also display far away mountains, without reducing=20
the local area too much.
The client could also indicate some way what data it already has, and wha=
t=20
is needed (needs to be checked with the game server
first, of course, so we know the client can see the terrain).


Map format
"""""""""""""

All three representations could use the same map format for storing the=20
information, they will only differ in what layers they contain.
The map format allows polygonal (perhaps a good idea would be to restrict=
=20
ourselves to triangular) areas, which data attached to the
area and/or to vertexes.

Blade could perhaps be used as a base for the format.  Layers would=20
probably have to be added.

Thoughts?  Flames?  Suggestions?
--=20
Hans H=E4ggstr=F6m (aka zzorn)
http://www.iki.fi/zzorn/
"Share and Enjoy" - Cirius Cybernetics corp. - THHGTTG

_______________________________________________
Server mailing list
Se...@ma...
http://mail.worldforge.org/lists/listinfo/server

*** Sorry if you get two of these messages DAMN NETSCAPE ***

Well i think its about time we had another Chopping Block!
 There seems to much going on in Worldforge this should be one packed
issue. I hope to start monthly Chopping Blocks up again.

Already the articles are being readied,
zzorn: How to Render a Forest in 3D
phal: newbies guide to Stage
Sal: Large-Scale terrain rendering

Other articles i would like to see for this issue,
We have a new web site, why not an article about that?
?? Upcoming Acorn release ??
What ever happened to the story bryce was writing for the previous CB??
I see lots of commits for Erlang-stage, how about some info on this
project?
What about this comic i keep hearing about? Maybe have a "issue" of the
comic with each CB release?

All other articles are welcome, as well short status reports about
projects are VERY welcome!

I'm going to try and get an interview up and running as well, any ideas
on who I should interview?? I was thinking along the line of maybe an
artist or a person involved with STAGE.

All articles should be submitted to me by the 30 of July (Is that too
soon?) and the CB should be ready about 1 week after that.

I'm also interested in a new Chopping Block "front cover" graphic for
each issue. Anyone want to volunteer for this issue?

Mithro

PS I'm not that good at spelling and/or grammar so i would love a
co-editor that could help pickup those types of errors.
_______________________________________________
General mailing list
Ge...@ma...
https://mail.worldforge.org/lists/listinfo/general

Well i think its about time we had another Chopping Block!
 There seems to much going on in Worldforge this should be one packed
issue. I hope to start monthly Chopping Blocks up again.

Already the articles are being readied,
zzorn: How to Render a Forest in 3D
phal: newbies guide to Stage
Sal: Large-Scale terrain rendering

Other articles i would like to see for this issue,
We have a new web site, why not an article about that?
?? Upcoming Acorn release ??
What ever happened to the story bryce was writing for the previous CB??
I see lots of commits for Erlang-stage, how about some info on this
project?
What about this comic i keep hearing about? Maybe have a "issue" of the
comic with each CB release?

All other articles are welcome, as well short status reports about
projects are VERY welcome!

I'm going to try and get an interview up and running as well, any ideas
on who I should interview?? I was thinking along the line of maybe an
artist or a person involved with STAGE.

All articles should be submitted to me by the 30 of July (Is that too
soon?) and the CB should be ready about 1 week after that.

I'm also interested in a new Chopping Block "front cover" graphic for
each issue. Anyone want to volunteer for this issue?

Mithro

PS I'm not that good at spelling and/or grammar so i would love a
co-editor that could help pickup those types of errors.
_______________________________________________
General mailing list
Ge...@ma...
https://mail.worldforge.org/lists/listinfo/general