[CF-Devel] FW: Crossfire & Java

[Mark Wedel]

Michael Toennies wrote:

>
     
      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.
     
     
 The current editor does show this to some extent.

 For example, if you edit an exit, it does show you the destination X and Y
coordinates (as well as path) in the form you expect (ie, you don't have to know
that you really want to change the slaying field).  Now this isn't done for all
objects, but it does know it for some objects.

 But yes, the editor should show you this in the form you want.  One problem is
simply that the server may evolve faster than the editor - I think that is one
of the current problems - realistically, the editor could have done this for
most all objects, but no one was maintaining the editor to do this.


>
     
      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.
     
     
 Agree.  

>
     
      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.
     
     
 Agree again.  This was one of my goals in redoing the object structure, but
that is a major undertaking.  And the unfortunate fact is, when someone wants to
add a new feature to some current object type, it is easier to find some field
in the object structure that the object type is not currently using it and use
that instead of adding a new field which would actually be clear.

>
     
     
     >
     
      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?
     
     
 Probably not.  Note that one of my other goals in the object re-do was to
remove the constant integer values and instead replace them with strings.

 Ie, many arch may have attacktype 12345 for example.  What does 12345 amount
to?  Well, convert it to hex (or binary), and look in the define.h (the the doc
file), and you can figure it out.  But it would be much more useful to be
something like 'attacktype physical|confusion|fear' for example.

 At least with the partial resistance code, the pro/vuln/immune bitmasks are
gone.

 The above change isn't really hard to code.  It would slow down loading some,
but depending how bad/important this is, there could very well be a setting/flag
which says to save in string form or numeric form.


>
     
      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.
     
     
 And ideally, this transformation language should be easy to understand so its
easy for other people to make additions.

 ie, if I want to put a number of uses value in an exit, and say I store it in
the exp value, then something like exit(number of uses) -> exit(exp) so that its
easy to update the editor with this new meaning.  If I have to code a new
dialogue box, this will just fall out of date.