[crossfire] [Daimonin-devel] Proposal: object attribute cross-reference

[Christian Hujer]

Hi dear co-devs,

Am Freitag, 18. August 2006 21:48 schrieb Björn Axelsson:
> I got started on this despite the lacking enthusiasm from the list. :-)
Don't worry, you're not the only one feeling ignored by *-devel lists :-)

> The proof-of-concept prototype is available as static HTML at
> http://www.acc.umu.se/~gecko/daimonin/object_ref/
Looks good.

> It is basically a cross reference using data mined from the editor docs,
> the lua documentation, C headers and lex grammar files.
> At the moment it lacks some info for different reasons, but it works good
> enough to show the principle.
>
> If scripters and/or coders find this useful, I will try to finish it and
> also get it integrated into the editor. (Hint: feedback wanted ;-).
It looks useful.

> > I propose the following project:
> > 1. Extend types.xml with documentation of server-internal attributes and
> > mappings for server code and the lua plugin attribute names.
> > - I think this is the best way to document attribute usage, since it
> > already contains a good deal of the needed info.
Yes. That's also good because it keeps this information in one single central 
place.
I think this suggestion is also interesting for crossfire (that's why I 
crossposted to crossfire).

> > 2. Create a cross reference where one can search the information in
> > types.xml.
> > - Currently the info in types.xml can only be accessed through the online
> > help in the editor attribute editing window.
> > - This should be accessible from the map editor's embedded script editor,
> > but maybe also in some external way (for people who doesn't use the
> > embedded editor, or server developers who don't want the editor open).
> > - I see several ways of searching the info, for example I might want to
> > know which lua attributes are relevant to waypoint obejcts, or I might
> > want to find out which attribute the "waypoint active" flag corresponds
> > to. As a server developer I want to see which attributes are used by a
> > specific object type, and which are free to use for new purposes.
Yep.

> > I can whip up a prototype in perl and run it as a web service (like I do
> > with the core reference), but then someone would have to reimplement it
> > in Java for integration in the editor. My Java is simply to rusty to do
> > this efficiently myself. Any ideas or reflections from the
> > Gridarta team?
I think a prototype in Perl is a good idea. Most if not all Gridarta 
developers know Perl, either good enough to at least understand a prototype, 
or good enough to write a word histogram (which word occurs which often) with 
sorted output in two statements.
(My sole recent usage of Perl is looking for the holy grail to solve this 
problem in a single statement ;-)

Also, there are some Perl-evangelists active on the Crossfire side, so if you 
prototype it in Perl there's a good chance that Gridarta won't be the only 
editor implementing it.
(On the other side, they might also lynch you if you're not using their Perl 
style, but that's your problem not mine ;-)


> > While I'm at it, the embedded script editor needs a few updates:
> > - syntax highlighting for lua (should be only a little work).
Ummm... strange, should already be there. Strange, very strange. I'll have a 
look at that.

> > - integration with the lua core reference for function popups and
> > built-in documentation (I can supply a XML document with the lua function
> > documentation used for the core documentation if needed, just propose a
> > format to use).
Currently I don't prefer a particular format, just send it to the gridarta 
developer list if it's below 50k or to me if it's bigger than that. Of course 
I prefer valid XML over invalid XML, so if you could supply a DTD or Schema 
(I prefer W3C Schema over Relax NG, but Relax NG would also do) along with 
it?

Cu :-)
-- 
Christian Hujer
Free software developer
mailto:cher at riedquat.de
http://www.riedquat.de/
PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20060819/f1842922/attachment.pgp