Hmm this is a reasonable idea. That problem stems mostly from the fact that mids server is very popular, and yet is running the cvs which is generally regarded as unstable. I think alot of problems begun here, firstly because we a relatively small group it takes a long time to release a new version sometimes, this can make server admins and players want to run the cvs just to take advantage of these great things. The problem lies in that while the cool new stuff which is bug free is there, so to are all the unbug free cool things! We could step up the speed of releasing new version, but I suspect we would start to release lesser quality code (this is my opinion, it is open to arguement). Secondly, we don't have a great deal of beta tester like people, so the only way a big change can get tested is by releasing it on a server that people play. It does mean we get feedback very fast ;), but at the same time we may upset lots of players. Perhaps it might be made clear that the cvs tree is really for those who enjoy new things, but at the same time are prepared to risk losing it all by accident. I did notice mids talking about running two servers on one machine, firstly it might be a good idea to have a stable and cvs server at mids.student...... ? but then again, i suspect players will all group to the cvs server because more people will be there? Well after the _bad_ incident with Mich =(, it is very hard hitting to see you (gros) leave too =((. I must stress I don't and didn't want to see either of you leave but it is your choice and I must let you take your own paths. Perhaps if people were alittle more open on exactly where they stood we might avoid these incidents, at the very least we could try and stop this developer loss, gros says there are to many... that point I completely, totally, and utterly disagree with. yours humbley dnh On Wed, Jan 02, 2002 at 04:51:49PM -0800, kevin at ank.com wrote: > I think what Yann really needs is a stable branch; or perhaps Tim > needs an unstable branch. I've worked on some very large projects > and you really have to be able to destabilize the tree at certain > points to make any progress. > > Overlays sound like a very useful feature for the large map work > that is going on. But that obviously shouldn't destabilize an > active server like 'mids'. By branching the CVS trunk at some > point it would be possible to continue patching problems in the > stable branch while adding more dangerous but also more exciting > changes to the main branch. Porting patches back to the main > trunk can become a bit of a chore, but ultimately when the next > stable version is branched it will stabilize regardless of whether > the patches have all been moved or not. > > Cheers, > -kls > > > On Wed, Jan 02, 2002 at 03:11:21PM -0700, Tim Rightnour wrote: > > > > On 02-Jan-02 Yann Chachkoff wrote: > > > Again unstable and undocumented feature popped out on the CVS code. > > > Although I understand quite well the motivations of acting so, as well as the > > > problems any OpenSource project like Crossfire needs to handle, I do not > > > approve them. > > > > Well.. I sincerely apologize for not posting first.. I really should have done > > so. So there are two things I'd like to try and do to rectify this: > > > > 1) Open this up for discussion. Yes, it's allready committed.. but I'm > > completely willing to backout and/or make changes. Since I screwed up, and > > didn't post first.. I will take complete responsibility for a backout if people > > want me to back it out. > > > > 2) Describe what it is that I did, and attempt to document it here for everyone. > > > > The overlay code does the following: > > > > An overlay is a partial map, which is loaded on top of the original map. > > Any items on the overlay are loaded in addition to items normally on the map > > from the standard map files. > > > > Overlay maps are not normally saved. There are two situations when an overlay > > map is saved. 1) During an emergency save. 2) When using the new world maps, > > the world map is slowly processed and re-saved via overlays. > > > > Overlays allow one to make modifications to a map, without modifying the > > original maps. In this way, information such as temperature or weather > > conditions can be saved in the map headers, and continually updated regardless > > of a new version of the map being downloaded. In addition, things such as > > additions by DM's can be saved on these overlays. Nothing alive is ever saved > > on an overlay. > > > > When a map is loaded via ready_map, it attempts to load the overlay for that > > map. If none exists, it continues without it. If one does exist, it loads the > > overlay, and replaces the map header with the one on the overlay. It also > > loads and places any items on the overlay map onto the map. > > > > There also exists a decay algorithim, which fires off at ready_map(). This > > algorithim looks over the entire map for things that were not loaded as part of > > the original maps (marked with a flag FLAG_OBJ_ORIGINAL) and slowly decays > > those objects, to prevent them from accumulating forever. In addition, the > > weather code, which slowly processes the entire worldmap over the course of a > > day, runs the decay as it goes. > > > > --- > > Tim Rightnour < root at garbled.net > > > NetBSD: Free multi-architecture OS http://www.netbsd.org/ > > NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel at lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > -- > // .--=, > .....::://::::::::::::::::::::::::::::.. (o O & kevin at ank.com > :::::::://:::://://://:/:://::||_// / V K > :::::://:::://:/:|//'/' // _,|' r , 'qk > :'''/____ // / // |_// // || .'~. .~`, > kls \_/-=\_/ > _______________________________________________ > crossfire-devel mailing list > crossfire-devel at lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel