kevin at ank.com wrote: > I'll reserve judgement until I have a chance to review the mailing list > discussions. My main concern is in the ability to create custom worlds > while still using some of the existing cities. This approach has been > of historical importance with many muds as the default cities provide a > way of bootstrapping the new world before people have had a chance to > customize it I understand that. I guess a lot depends on the end desire and how correct the bootstrap city should be. Certainly, if crossfire grows in popularity, people designing their own maps is desirable. OTOH, I do plan to make some scripts to make mass relocations of exits much easier (eg, you tell the script the source map, and tell it the new destination maps with offsets, and it goes through and fixes the things up). This will generally make it fairly easy for maps to get relocated. > > But I am thinking of changing the way to do cities - I'm now leaning to giving > > the city its own 50x50 tile, and updating the links in the adjoining world maps > > to use this tile, and putting a note in the 'missing' tile that in fact this > > tile is /scorn/city or the like. This at least makes it a little easier to move > > things around, and I think will also make it a bit easier to know how maps are > > related to each other (eg, everything in /scorn would go back to /scorn/city, > > and not /world/world_110_124 for example). > > > > This approach shares much of the value of what I was trying to suggest, > so I won't try to argue you out of it, but I do think you should consider > whether it is feasible to put every city on a mod 50 boundary. thats obviously a potential problem - especially if at some point a city grows beyond 50 spaces. Somethign that may work would be to leave a copy of the whole city (eg, /city/city), but for the actual map, copy the bits over to be on the world map tiles, and then run my proposed update script above to get the exits in the right plac As I think about that idea, one thing that would make updating exits A LOT easier would be for all the exit information to be on the same line, eg, instead of something like arch house x 5 y 10 slaying /path/to/house sp 8 hp 15 end Instead be arch house x 5 y 10 slaying /path/to/ house at 8 ,15 end Makes it trivial easy to update exits in that case, as well as find exits to update. It also removes the overloading of the sp and hp values - it does mean that the exit code has to parse the slaying line to get the destination coordinates, but for how often exits are actually used, that isn't a very big deal.