[CF-Devel] CFEditor cleaning up

[Mark Wedel]

Andreas Vogl wrote:
>
     
      in reply to Michael Keuchen:
     
     >
     
     
     
>
     
      1. The editor contains a menu "Collect->Collect Spells" to
     
     >
     
      generate the "spells.def" file from the spellist.h server
     
     >
     
      C-source file. This needs special attention for possible
     
     >
     
      jar-only distributions of the editor.
     
     >
     
      An editor version run from jar must either write the changes
     
     >
     
      directly into the jar archive, or the editor must read a
     
     >
     
      possibly changed extracted file version always before opening
     
     >
     
      the one out of the jar (The latter is currently the case).
     
     
  I think this point, and the points below, depend largely on how often this 
binary version of the editor is made.

  New spells are not added very often, so it isn't that likely that a user will 
need to run this a lot.  But perhaps more to the point, if a new editor release 
is made when the spells change, or new objects attributes are added, or whatever 
else, having these files in the jar file itself (for the binary distribution) 
isn't a big deal I don't think.

  The 'easiest' thing would be to make a binary distribution the same time a 
server release is done.  Sure, if a person is using CVS version of the 
server/arch's, but binary version of the editor, they could have some odd issues 
of things not being fully up to date.  But I'm not sure how likely that really is.


>
     
     
     >
     
      2. The file "types.txt" is very important and special (for me).
     
     >
     
      I really *want* to have users modify this file, or at least
     
     >
     
      look into it. My vision about this is that the "types.txt"
     
     >
     
      file could become an inofficial documentation-standard
     
     >
     
      for the Crossfire arch sysntax.
     
     
  We probably need to differentiate between mapmaker and developer.  Presumably, 
map makers don't care the 'sp' is used for the spell that a wand casts - he just 
wands it to shoot the fireball, and if the types.txt make that translation easy, 
it works fine for him.

  Obviously, developers need to be more aware of the java editor - first thing 
is to be aware that if they are adding new fields, that the java editor should 
be updated.

>
     
     
     >
     
      So, when some developer patches the server code to introduce
     
     >
     
      a new arch atribute (like for example a value for item power)
     
     >
     
      - then he might think "okay, now I must update types.txt
     
     >
     
      from the JavaEditor so that mapmakers know about by new feature".
     
     >
     
     
     >
     
      I can't force this to happen, but I want the types.txt file
     
     >
     
      to be present, visible and as well-known as possible.
     
     >
     
      That's why I left it in the root directory so far.
     
     
  I guess this really comes down to if we expect developers to be using the 
binary version of the editor, or if they will have the source version.

  If they have the source, then the types.txt is still available to them in 
plain sight, so that shouldn't be an issue.

  I think I actually wrote some docs about adding fields to objects in the 
server (step of things to do).  Something to add to that is probably 'update the 
types.txt in the java editor'.

  The problem of course is there might be some cases where the developer still 
forgets to do this.  If they are still using crossedit, they may not think about 
the java editor.  Hard to make it completely fullproof.


>
     
     
     >
     
      I agree it would be "cleaner" to move them into a subdir,
     
     >
     
      but would people ever look into a directory called
     
     >
     
      "resources/conf" in order to customize the editor?
     
     
  As above, hard to say.  They first need to look at the java editor.  I think 
if there is good documentation, this may not be much a problem - a top level 
README describing the different directories and important files in each (like 
the types.txt) may be enough.

>
     
     
     >
     
      Maybe an alternative solution to fit both our wantings
     
     >
     
      would be to include a way to view and modify the types.txt
     
     >
     
      file from within the editor.
     
     >
     
      Then I don't care in how many subdirs we put the file.
     
     >
     
      But in such a case we have to consider again what happens
     
     >
     
      when the editor is run from jar, like above.
     
     
  Not sure, but my taking is that it is really only run from a jar for binary 
distribution.  If I have the source (Because of changes or whatever else), and 
run it, it would still run from the class file, and presumably search my local 
directory as need for the files?  Or would the build process always generate a jar?

  The idea of having an interface tool within the program to modify the 
types.txt  probably isn't a bad idea in any case - while the format of the file 
is pretty easy, having some tool to better organize the entries might still be nice.

Feel free to ignore my comments - i'm not writing any of the code that is doing 
all of this.  I'm just trying to note usage patterns as well as release issues.

On a slightly related note, similar usage issues goes toward the arch directory 
and need to collect them.  While MT's point is valid that people should (may) 
add new images to the arch directory, actual usage shows this doesn't happen 
very often.  So ideally, if the editor could take advantage of the collected 
archetypes and image files, this saves the need for a player to have yet another 
distribution (eg, they grab server, editor, and maps, and don't worry about archs).

  This can become more of a packaging nightmare however.  Do you include the 
arch/images with the editor and server (in which case, you are adding a lot of 
extra bits to download if the user already has the server).  However, if they 
are only included in the server but the user doesn't want it (he is only making 
maps to run on someone elses server), that also is extra bits to download.  I 
suppose an arch/image could be made, which may not be a bad idea - they would 
basically mean the server is only source, so if there is a release in which the 
arch's don't change, a lot less bits for a user to download to get the latest 
server.