1
Coding / Re: Stairway bug solution found ?
« on: December 16, 2008, 06:44:25 am »
@Duke, you're right on the money with your description of how the pathfinding and routing code works. Teach away
You're also right about not getting the routing right if the tracing does not work. And I think that there is an issue with the tracing. Somehow, the traces between cells is not correctly detecting the presence (or lack there of) of brushes. That is what I need to focus my efforts into. I am also hesitant about the code that merges the random maps; I have not been able to assure myself that works 100%.
Getting back on the original topic, we could bump up the STEPUP values, but then we could end up with actors climbing over stuff they shouldn't. It would get things working, but I proposed an additional trace that would look for finer step intervals, allowing for steep stairs or slopes that an actor could get up without allowing the actor to scale a cliff. But that would also add more code and debug time, and we are already hurting from new tracing code.
I think that for the time being, at least to ensure that the tracing code is working, we should bump the STEPUP values to get stairs working as it would allow me to fix the other tracing issue. Later we can decide to add more floor tracing or to leave it as is.
There may be another logic error in the routing code I am not aware of, but it seems that all fingers point to the tracing causing routing errors. Compile your map with -tracefile and two csv files will be created in the directory of the map files. The *.elevation.csv file contains the floor and ceiling of each cell in QUANT units, relative to the base of the current cell. The *.walls.csv contains the passage size leading into the given direction. If you open the *.walls.csv file in Open Office, the center number is the floor height for that cell and each number surrounding it is the passage size for that direction from the cell, with the top 3 numbers being north/+Y and the right 3 numbers being east/+X. Negative floor values indicate the floor is below the base of the current cell. What I am looking for is logical places where a wall should be detected but a passage is available, or vice versa. Exact map and XYZ coordinates are helpful if known.
If the issue is in fact routing, it will violate the values recorded in the trace files. So far, I have not seen any more since the last commit I made referring to bad logic, about two months ago.
And thanks for the help! I feel like I'm drowning as of late...
wilminator
You're also right about not getting the routing right if the tracing does not work. And I think that there is an issue with the tracing. Somehow, the traces between cells is not correctly detecting the presence (or lack there of) of brushes. That is what I need to focus my efforts into. I am also hesitant about the code that merges the random maps; I have not been able to assure myself that works 100%.
Getting back on the original topic, we could bump up the STEPUP values, but then we could end up with actors climbing over stuff they shouldn't. It would get things working, but I proposed an additional trace that would look for finer step intervals, allowing for steep stairs or slopes that an actor could get up without allowing the actor to scale a cliff. But that would also add more code and debug time, and we are already hurting from new tracing code.
I think that for the time being, at least to ensure that the tracing code is working, we should bump the STEPUP values to get stairs working as it would allow me to fix the other tracing issue. Later we can decide to add more floor tracing or to leave it as is.
There may be another logic error in the routing code I am not aware of, but it seems that all fingers point to the tracing causing routing errors. Compile your map with -tracefile and two csv files will be created in the directory of the map files. The *.elevation.csv file contains the floor and ceiling of each cell in QUANT units, relative to the base of the current cell. The *.walls.csv contains the passage size leading into the given direction. If you open the *.walls.csv file in Open Office, the center number is the floor height for that cell and each number surrounding it is the passage size for that direction from the cell, with the top 3 numbers being north/+Y and the right 3 numbers being east/+X. Negative floor values indicate the floor is below the base of the current cell. What I am looking for is logical places where a wall should be detected but a passage is available, or vice versa. Exact map and XYZ coordinates are helpful if known.
If the issue is in fact routing, it will violate the values recorded in the trace files. So far, I have not seen any more since the last commit I made referring to bad logic, about two months ago.
And thanks for the help! I feel like I'm drowning as of late...
wilminator