Todd Mitchell wrote: > > I think as the editor is used more widely and is easier to use, it will > happen more often. When making maps there is always the idea - if only I > had this...I should create a... and sometimes it isn't as easy as tweeking > an existing arch in a map (although that should be encouraged) sometimes you > want a new arch (like for summoning/creation purposes) or need to modify the > treasures file to make an ability work. > As it becomes easier to create maps, I believe there would be more frequent > modifications to the images and archs. Fair enough. Note that the only real gotcha is the additional of images. You can always make up your arch's, and do something like 'cat *.arc >> /path/to/archetypes'. > > I think there would be some benefit in discussing seperating the arcs and > the server a bit more than they currently are. It would be nice if the > Treasures and Races files were shipped with the archs (or a package as you > suggest) so you didn't have to get the server download to modify them. > (actually it would be nice to redo the way this works so that the arch could > contain the creature inventories and parts lists and treasures could be a > list of treasures > to assign), It would also be nice to redo the arches (perhaps wrap them up > in XML) so you could more easily generate documents from them and easily > design other utilities-features around them (like books and descriptions and > such). The races file is sort of a hack. Its basically an easy way to change the race definition in the .arc files. In practice, if the race is set properly in the the .arc files, there is no need for a races file. The problem of placement can be tricky. They, like the archetypes file, is included in the server simply because you need them to run the server. OTOH, they sort of are more closely tied to the arcs than the server. I certainly wouldn't want two copies - one in archs, one in servers, as you know they will get out of sync in that case. It wouldn't be too hard to make it so that the 'treasures' file is automatically generated just like the other files. You could have something like: arch orc ... randomtimes orc_treasure ... end treasurelist orc_treasure <normal treasurelist stuff> endtreasurelist Then when collect runs, it examines the data a little bit (it already does so) - if it is an arch definition, it puts the relevant data in the .arc file, if it is a treasurelist, it puts it in treasures. Could also do seperatre files, like orc.trs or something, but it probably makes more sense to have it in the same file. Treasureslists can of course contain other treasurelists. this still doesn't let you specify a treasurelist in the object itself (if you wanted to customize the treasure a monster could get) in a map for example. But doing that is a bit harder - doing the above is pretty simple. I think the above is probably the right approach. It then means that someone can say 'here is my new objects', and you put in the in the arch directory, rebuild, and that is it - you don't need to worry about fudging with the treasures or races file. Bob Tanner was looking at little bit into doing XML for objects and what not. The problem is that there is so much that would need to get updated - in addition to what is in CVS, you have to worry about perhaps unlinked maps that are on ftp sites, etc. > (It would be cool if the arc extention could be changed to something that > didn't conflict with winzip as well.) Problem is I'm not sure what it could get changed to that may not conflict with something at some point. winzip is certainly a more common program, so conflicting with some obscure thing might not be such a big issue. Of course, of unix users don't have any conflict at all :). Other problem is that changing all the names is a non trivial task (but could easily enough be scripted) > > It would also be nice if you could plug new arches into the server without > having to reinstall - or having to have access to the server files or your > own test server. Something like a ftp landing pad and an update command to > do a collect. It would make it a whole lot easier to work on content and > make it available for testing. It would make sense from a server security > standpoint and maybe encourage more consolidation of common servers with > content contributers rather than indirectly pushing a large personal server > base out there. Not sure about that - it seems that someone being able to push new objects to a server is probably a bit thing. If what your really asking is an easier way to add new archs without needing to do a full collect, that could perhaps be added. Something like a 'here is a a tar file containing the images and archetype file for my new stuff'. Instead a rebuild, some script does something like a 'cat new_arcs >> archetypes', and also have a script that just adds the new images to the back end of the current image files. Would also deal with races or treasure files if needed. Of course, these changes won't take effect until the server is restarted. I have no immediate desire to try and let the server handle update to its files while running. Should be possible, but there are more important things to do.