On Saturday 07 April 2007, Kai Antweiler wrote: > > The number of bugs does not count, as correctly you say we are alpha. > > But one serious bug like: > > https://savannah.nongnu.org/bugs/?19542 > > Might ruin glob2. Our official release must be playable. > > I have uploaded a dirty fix that Leo proposed to alpha22-rc. > It simply removes the assert that fails. > But this has to be fixed for real sometime. > Someone has to find out why that id is not valid. > > We now can create a new tarball and deb-file or > schedul a bugfix release 0.8.23 for next weak. > I favor the last option. > > > Leo: > > crash can be avoided by removing the assertion as in the following code: > ConfigFiles.h:180 > std::cerr << "ConfigVector::get(" << static_cast<unsigned int>(id) << ") > : warning : id is not valid, returning default" << std::endl; > //assert(false); > return &defaultEntry; > > as "return &defaultEntry;" is unreachable code i guess there is work in > progress. removing the assertion leads to strange worker assignments (1 > worker here) but no further crash in local games.
Removing the assert is bad as it will put the engine in inconsistant state. The problem is triggered by lines 1225 and following of Building.cpp, where targetLevelTypeNum of value -1 got transmitted to globalContainer->buildingsTypes.get(). This can happen if the building effectively doesn't have a previous or future level. Bradley, could you have a look at those lines? Shouldn't Building::removeForbiddenZoneFromUpgradeArea() have symetric prev/next levels than addForbiddenZoneToUpgradeArea() ? I prefer not touching at this code before you have a look. Thanks, Steph -- http://nct.ysagoon.com _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
