[CF-Devel] More Lore

Tue Apr 30 04:25:37 CDT 2002

>

        But at some level, I wonder if it really makes sense to try and grap

     >

      information from maps instead of just having something like a 'scorn.lore'

     or a
>

      'dungeon.lore' or whatever else - that lore file just being a freestanding

     file
>

      in the proper lore syntax.  A lot easier to collect those.  A lot easier

     for
>

      anyone else dealing with those maps in the future to find the lore

     information.
>

     I did do that initially with the script (I put some sample .lor files in
different map folders to represent information on those quests.)
This is fine, but there are two reasons I wanted to put it in the maps,
1. external .lore files will not get updated and will go out of sync (this
will happen with lore in maps also, but to a lesser degree and more locally
since if the map is no longer used, the lore will no longer be used.)
2. It will require a run through the maps anyway to collect arches with
modified lore.

...You know the more I think about it (and I didn't plan on writing this
till just now...), a maplore arch with only a name and a lore field wouldn't
be that bad, it wouldn't require any changes to server or editor at all (add
a lore field to a marker perhaps?--what the heck is the marker for anyway)
would work in both map editors by default, and they would show up in the map
editor as a big bright letter L icons just waiting to be clicked on  by map
makers much like the creators or no_magic arches or other system arches
do...  It would automatically add lore to the maps in a usable format and
use the same collection routines as the arch lore, and It wouldn't be any
more of a hassle than managing a handful of connectors really...

arch
Object
face maplore.111
name
lore

endlore
invisible 1
no_pick 1
end

>

        As for collection, I'd prefer that the scripts be in perl and not

     python,
>

      largely because I know the former, and not the later.  Which is probably

     related
>

      to why all the existing scripts are also in perl.  However, that isn't a

     major
>

      point.

If I can't wing it myself I'll call in the perl posse since Perl is required
software and Python isn't.
I'll still do it as a CFPython script as well (maybe make a map with bunch
of big levers where you can go as DM to access these sort of things - one
lever to reload the lore, one to reload the arches, one to send a nasty
e-mail to the     ring a bell in Mark's house...)

>

      server changes - I'd think something needs to be done to read in the lore

     file
>

      and process all the meanings (area, weighting, etc).

     >

     >

        As for file format, probably doesn't make a big difference - but do keep

     in
>

      mind that the server has to be able to parse it.  And since we are taking

     raw
>

      data, I don't know if it makes a lot of sense to convert it to xml - one

     could
>

      certainly have an option in the collect script to also spew out xml if

     desired.
>

        AT some level, I'd prefer not to require yet more libraries to compile

     the server.

Yes, after I posted that I thought about XML and using this data from a
server perspective.  I was primarily considering accessing this lore from
the scripting language (writing classes that could be used to generate books
or simple chat routines in python) when I should be thinking more openly.
You can blame Andreas for this since he mentioned XML a little while ago and
got me all excited about it again.
So even though it would be nice someday not to have to convert data or write
parsers from scratch, there is no compelling reason to use XML at this
point* so I'll stick to something very close to the treasures and archetypes
formats.

>

        It is not legal to have multiple arches with the same name, so the point

     of
>

      using the name to combine data doesn't really apply.  But I otherwise

     think that
>

      idea is fine - the probability of lore information about an orc is only

     relative
>

      to the orc itself.

Actually I was intending to use the name field not the object field so there
would be overlap.  This was intentional since the name is more friendly, is
more commonly used from in the game, (especially for stuff like 'say') so
more relevant, and will collapse similar arches into the same bucket of lore
(although why you'd put lore on stuff like windows and standard sword arches
is beyond me...)

*Of course if a simple XML parser is something that we wanted to explore
someday there is always Perl, Python and shell friendly PYX notation and the
really tiny xmln and xmlv C utilities used to power it
(

     http://pyxie.sourceforge.net

     ).
And to compile these from source you need expat (

     http://www.libexpat.org

     ) so
it isnt' painless...

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

     https://mailman.real-time.com/mailman/listinfo/crossfire-devel