On Tue, Mar 23, 2010 at 12:15 PM, Kai Sterker <kai.ster...@gmail.com> wrote:
> Yeah, I noticed that too, now that you mention it. I disregarded it as > a minor problem, however. Finding how it is related to the tree being > split is a good catch. You've probably seen, that the chunk class has > a debug method that generates a .dot file which can be processed with > graphviz' dot tool to see how the tree looks like. Maybe that helps in > this case. > OK. I have more to report on this issue. I may have some bad ideas on what is/should be happening, so I'm going to start a bit from the beginning, so if I have something wrong you can correct me. And for the most part, x/y coordinates don't matter in this, so they'll be vague. We have tiles defined in yard/stone.xml file, and these 'grow' downward. The one you stand on initially is at position (256, 480, 0) because it grows downward, the solid z min pos /max pos is -5 to 0. However, when we create the chunk_info in chunk::add, we start from position and add max size (5) to it. So In the chunks it is stored from 0 to 5. When we check in_bbox we use the solid size. So what is happening is if we have a Split.Z == 0, then we go to the wrong spot to look for the tile. I see two possible solutions. One, always grow the tile positively (remove negative values from the xml), and adjust the starting location. Two, adjust the chunk to store the correct Entire position. I have code that does number two, and I think it's what we want to do so I'm going to push it. If it turns out we would rather do number one, it's easy to back it out. One thing though is this causes some other issues. For example, now the character 'falls' to -5 instead of 0. This causes some more problems around the stairs. But sense I plan on looking at that next it shouldn't be a big deal. That's all for now, Tyler
_______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel
