Ok I've commit a third revision of the code. For the most part, I've simply reorganized and documented Building related code. I've moved code from Unit that relates to building into Building itself in order to better encapsulate building. Code such as a unit taking or putting in a ressource into a building, or quitting a job, etc..
I have done one major change, however. Previous to now, units would apply to go "inside" a building, for eating, healing, or upgrading, and the building would look over its subscriptions and allow the most worthy units inside, dispatching the rest. It was this dispatching that can cause bottlenecks, and even with many open spaces available on Inns, there would still be units starving. This is very similair to the flaw in the original unit allocation system. So I've changed this as well, similair in style to the new unit allocation system. If a unit wants to go "inside" a building, it tells the building, and is instantly added to the list. There is no sorting proccess. While its possible an unworthy unit may be given the position, it has the clear advantage that every unit will be connected to a valid building, instead of applying, then being rejected. My tests show substantial improvements. ReachToInfintity used to peak starvation at arround 8% untill it begins to run out of wheat (where it jumps to 20 - 30%), it now peaks at 2%, and the death rate by starvation is much, much lower. Only after the new system have I seen reach to infinity actually reach 1024 units before starving itself. Probably as a combination of the fact that units are used more efficiently, and that they are garunteed placement at an Inn if one is available, as opposed to the trial and error system that bottlenecked the old style. -- Really. I'm not lieing. Bradley Arsenault. _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
