[CF-Devel] FW: Crossfire & Java

Michael Toennies michael.toennies at nord-com.net
Wed Mar 7 09:08:29 CST 2001


Hi

As answer to all mail about the new editor, i had some addition ideas.

In fact, what is the part crossedit don't have?

Well, its a map editor - but not a arch editor.

In fact, crossedit has no real idea about the objects he handles.

A map is not a real object - means it has no own data structures or flags
you set.

A map is nothing more than a collection of arches. And a arch is a text
script of commands.

Well, what we need is a editor who handles first the arches - means it SHOWS
you what happens
when you change the arches values or a add a command line. Values like SP 3
or HP 4 in different arches
are not very clear.

We need a editor who packs a layer above the this values - in fact a map
designer has no interest
to know what a SP 3 do in a arch who count as a teleporter - what he want to
know is, how he can
adjust the teleporter to a new map point.

Again, because we had all arches pre defined and the server knows how he has
to handle them, we
can do a layer in the map editor on them - how the editor them store map is
no interest to a map
designer.

The arch scripts we use are very bad in technical style.

The spirit of a text script or storing data/objects in texts lines is, that
you can READ them.
Means, a humans can simply understand them and change them easily (with a
text editor of course!).

Well, i don't think that our arches are simple to understand...!!?
Reason is the not only the bad documentation we have, reason is first the
bad style the arches had.
Also, they do something really forbidden: Using many non "describeable" text
command - and more bad they
double use them in different arches with different meanings.

Ok, there a some "historical" reason why it is so in CF, but its against all
style rules - and it makes
arch reading and parsing for HUMANS hard. Or is here anyone who really can
tell what the SP or HP command
in all kind of arches do? Or which commands are allowed in different arches?

Also with documentation - not.

But this can easily changed when we include a layer in the new editor.
Means, the editor parse always
all arches you do. You include then commands like "teleport 3,2" in a arch
who does teleport action
is much more logical. And when you want change to a new map you write
"teleport ../newmap.map 3,2".
And the editor then parse the whole arch in the moment you write the line
and generate the "real arch" -
invincible to the user.

This is not so hard to include. All what you need is some slightly
intelligent parser in the input
part of the editor. And then he must drop as output code the SP/HP stuff -
or whatever.

Its really nothing other script editor don't do - its only a question of
design. There are MASS or
script editors out which does the same in much much more complex contexts.

Of course, the editor should also give you a mass of predefined arches.
(create gold, silver, monster,
weapon, armor, key... etc. detector of fire, cold,... and so on). This is
work one has to do one time,
and them it stays untouched the next years (if we don't change the use in
server of course ).

More good is a popup menu, which shows you the commands you include in a
arch - and unshow the one you
can't combine with the one you have before included. Also simple to do, if
we have a input parser.

Also, we should include a arch constructor - where you can design a arch  -
of course it use the same
input parser. Because java has a intern understanding about tiles ,you can
easy show and edit tiled
pictures. So, we can include, cut and collect new animation with it. Also no
real hard technical stuff.




>
     
      > It seems to me, we found or map editor coder.
     
     >
     
      >
     
     >
     
      > Ok, he needs some advice. So question to all:
     
     >
     
      > Which feature we want? What we want see?
     
     >
     
      > etc.etc.
     
     >
     
      >
     
     >
     
      > We should help this guys as good we can, so he don't lost
     
     >
     
      > his minds or drop the project in middle of work - what always
     
     >
     
      > can be happen. So, we should collect sources as often we can do -
     
     >
     
      > also to help him with single code sections.
     
     >
     
      >
     
     >
     
      > I have some work to do yet, so i will answer marks mail to the
     
     >
     
      java editor
     
     >
     
      > later.
     
     >
     
      >
     
     >
     
     
     >
     
       IMO, basically we want what the current editor can do, which is load map,
     
     >
     
      insert objects, delete objects, modify objects, wipe below, and
     
     >
     
      fill below.
     
     >
     
     
     >
     
       The features I consider missing from the current editor:
     
     >
     
      1) connected object navigator:  When looking at maps others have
     
     >
     
      made, it is
     
     >
     
      often very difficult to figure out what gets connected to what
     
     >
     
      (handle to what
     
     >
     
      grate, etc).  Something like being able to click on a connected
     
     >
     
      object and then
     
     >
     
      select something which shows me all the other connected objects
     
     >
     
      of that same
     
     >
     
      value would be very cool (whether this is done via highliting on
     
     >
     
      the map window,
     
     >
     
      or another window popping up, or whatever - I haven't thought
     
     >
     
      about the exact
     
     >
     
      navigation of it much).
     
     >
     
     
     >
     
       Thats the big one for me.  I'm sure others may have other stuff
     
     >
     
      they want added
     
     >
     
      (I usually don't create new ones but instead modify old ones - I
     
     >
     
      could see those
     
     >
     
      creating new ones might have different demands).  Going with the above, an
     
     >
     
      easier way to connect them might be desired (ie, you click on
     
     >
     
      one, say connect
     
     >
     
      to, click on another, and it updates the connected vals).
     
     >
     
      _______________________________________________
     
     >
     
      crossfire-devel mailing list
     
     >
     
     
      crossfire-devel at lists.real-time.com
      
      
     >
     
     
      https://mailman.real-time.com/mailman/listinfo/crossfire-devel
      
      
     >
     
     
     
    


More information about the crossfire mailing list