[CF-Devel] RE: CFJavaEditor

Tue Aug 13 02:24:16 CDT 2002

Andreas Vogl wrote:
>

     >

      The real blessing about this is that it takes only about one

     >

      third the time to load from collected arches. On my system

     >

      it takes only 9 secs as opposed to 30 secs.

  Yeah - I figured it would be a bit faster.

>

     >

      Now the problem: What if a mapmaker modifies the arches, so

     >

      he cannot run from collected files anymore? For this case I've

     >

      included an option to generate the collected files automatically

     >

      (menu "Collect->Collect CF Arches").

  I've not tried it myself (being I don't have a windows development system), 
but does the perl collect script in the server not work on windows platforms? 
That would be the only case I could think of where the need for a full 
collection method would be needed (I know there are perl ports for windows, so 
that shouldn't be much of an aspect with it).

  Otherwise, it is sort of an odd issue.  Its probably safer to say that for 
many people, the perl collection method is more convenient (don't need to fire 
up a java editor).  That is certainly the only one that has been fully kept up 
to date with regard to image sets and other features.

  That said, it is certainly convenient for the editor to be able to 
load/collect stuff from the arch directory for those people that are pure 
mapmakers.  But obviously, it only needs to support the collection 
functionality/files to the extent the editor uses it.

  I'm a little unclear on how the editor works on this - does the editor now 
basically always load from collected arch's, and has no support to load from the 
arch directory, so that if you want to sue a new arch, you need to collect and 
re-run?  Or will it use the arch directory if collected files are not available 
or something else?

>

     >

      I also used this as opportunity to write an additional variable

     >

      into the arches that mark the "directory path" of the arch.

     >

      This allows the editor to recogize which arch belongs to which

     >

      folder. Hence, when you load collected arches they are displayed

     >

      in the exact same cathegorys as when loaded from individual files.

     >

      (Note that the aforementioned additional variable is only present

     >

      in the collected "archetypes" file generated by the editor,

     >

      so it shouldn't bother anyone.)

  That works I suppose.  For the server side of things, it could just ignore 
those fields as it loads it from the archetypes file (and similarly, editor can 
similarly not put that information in the maps it creates).  In that way, it 
won't really be used for anything but arch sorting in the editor.

  I'm still not 100% convinced that sorting based on directory entries is ideal, 
but I guess may be more accurate than editable field.  And adding such a field 
won't really hurt anything else.

  Real solution is to somehow support the 'pick map' like crossedit has, which 
allows someone to make up an arbitrary collection of archetypes that they can 
easily choose from.

  support for that probably wouldn't be too hard - the picks are in standard map 
format - need to add some code to search the directories for them, and an 
attribute for those within the editor so that clicking in them has different 
actions than for normal maps.  The bigger problem which was previously alluded 
to is how to do it without completely cluttering the working area.

>

     >

      This has the advantage that the sorting of arches is consistent,

     >

      so mapmakers can get used to it. Moreover, the arch directorys

     >

      provide a good and detailed cathegorization.

  Consistent as long as things are not moved around, which does happen 
occasionally.  Sorting may not always be obvious for some people (eg, the 
special god given items are in the gods directory, and would not be found under 
armor/weapons).

>

     >

      Another advantage is that the editor no longer requires a seperate

     >

      downloading of the arch package, unless a mapmaker wants to

     >

      modify arches. The entire thing is still only around 3 MB.

  Yeah, but he still needs to get the archetypes and image file from someplace. 
  But it certainly makes a binary distribution of the editor easier.

>

     >

      I had to rewrite large parts of the loading methods to get this

     >

      done. The worst part definitly was messing with that bytestream

     >

      of png-data. Anyways it seems to work fine now. Available at:

     >

      http://mids.student.utwente.nl/~avogl/CFJavaEditor/

  surprised that part would be very hard, but I don't know java i/o very well. 
I would have expected that you could have taken the loader logic from crossedit 
easily enough.

>

     >

      I didn't put any of it on CVS yet, but I plan to. If I don't

     >

      receive any negative feedback I might do it in the next days.

     >

      This goes along with the changed directory setup of the editor

     >

      and a considerable bunch of smaller changes (like the summary

     >

      button on attribute windows).

  I don't see any real problem with that.  I do need to make diffs of the work I 
have done with the editor so that they don't get lost when things get re-arranged.

>

     >

      As a sidenote, the feature to collect arches with the editor

     >

      produces "archetypes" and "crossfire.0", both in valid CF format.

     >

      It probably wouldn't be too hard to extend this so it does a

     >

      full arch collect with animations and face file. Not sure if

     >

      that would be worth the effort?

  See notes above.  Unless needed for win systems, I'd say keep the arch 
collection of the editor simple, and tell people that they really should use the 
arch collection as part of the server distribution to collect the arches.