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.