[CF-Devel] More Lore

[crossfire-devel-admin at archives.real-time.com]

Todd Mitchell wrote:

>
     
     
     >
     
      How is this different than the lore coming in from the arches?  Remember if
     
     >
     
      you put lore in an orc or in a magical putter you have to be careful not to
     
     >
     
      cut and paste that to another map, (also it is still much easier to manage
     
     >
     
      than connectors and the like).  Remember that lore is going to work it's way
     
     >
     
      into the maps through the arches anyway. Putting it in the header only means
     
     >
     
      you need two routines to collect it and a way to distinguish between the
     
     >
     
      lore fields in the header.  That is the only benefit - that you need to
     
     >
     
      collect it from two different places in two different ways.  I can't see it
     
     >
     
      provides any extra flexability or functionality.  There was really not even
     
     >
     
      a need to make a special map lore arch since you could just use an orc for
     
     >
     
      the same purpose really, it just makes it easier to see if it has it's own
     
     >
     
      icon.
     
     
  I'd personally say that changing the lore of objects within the map is not 
allowed.  If you want to broadcast lore about an object, put it in the lore in 
the map header.

  This fixes the problems you describe - you don't want to have to worry about 
cut/paste and lore getting propogated all over the place.

  As for the format in the header - presumably, when we collect from the archs, 
we turn something like :

arch orc
name orc
..
lore
...
...
endlore
...
end

into

lore orc
...
...
end

  In the lore file (or whatever it is called) - at some point in the collection 
process, the object it describes has to be preserved and put into the lore file 
itself.  There is no reason that that the stuff within the maplore/endmaplore 
doesn't follow what ever format is put into that file.  So you may have 
something like.

maplore
lore siegfried
...
endlore
lore jonas
...
endlore
endmaplore


  All that said, this discussion is taking a lot longer than it should.  And 
that said, the person that has not submitted much code to making comments of 
what is hard to do or not seems a bit presumptuous.  I don't mean to be rude in 
that statement, but given all the time and effort exerted into this discussion, 
I could probably have made the necessary server changes to support a 
maplore/endmaplore field in the map header and written a collection script (as a 
nice bonus, if you know the maplore will only be in the map header, collection 
is also much faster, and thus more likely people will run it).

So that said, I'm putting me foot down here - the code will be implemented 
within the following rules or not implemented at all.

1) Lore information for maps will be located in the map header and only in the 
map header.

2) The format 'tags' for the map header will be 'maplore' and 'endmaplore' on a 
line by themself.  All the intervening data will be copied as is into the target 
lore file.

3) How the lore field is still open to some discussion, but it seems the format 
will be:

lore
@chance x <location> <other keywords>
one or more lines of data of lore.
@chance y <location> <other keywords>
one or more lines of data of lore
@endlore

  It is allowable to only have one @chance field.  In that case, the actual 
chance is pretty meaningless, but location or other keywords we decide can still 
be useful.

In the case of lore in map headers, the first 'lore' line will instead contain 
an object/field the categorizes this lore (hmm - maybe we should do this for the 
arch as well, thus you could just group things as like 'lore armor' or 'lore 
sword' or whatever else).



_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel