Stairway bug solution found ?

[Duke]

Wilminator, Thx for your answer
So we're dealing with a whole bunch of problems. Standard procedure in these cases is: tackle them one by one.

I ran into some places in the code that look weird to say the least. Most likely bugs. But I couldn't tie them to a specific behaviour or bug. Is it ok if present those half-breed suspicions and other strange observations to you ? As you are familiar with the code, you can probably judge and fix them much faster than I could. Or should I rather wait until I can present the complete fix on a silver plate ?

We should have a single place where we collect insights and ideas regarding a certain bug. As the forums don't seem to be your preferred medium, I suggest the bug tracker. My plan is to work through the bug reports from richlv anyway.

Tracing: So it's just an assumption. I understand we have no reproducable situation where a point- or boxtrace definetly produces wrong results.

I already read about your concept to detect stairs by a series of more traces in the mailinglist. I guess you could get it to work for stairs and a few more shapes. But considering the endless number of different shapes a modeler can create, I fear you will end up with highly complex and slow code.
I still hope we find an easier solution.

Thx for the hint regarding the csv files, I might come back to them. But I have created a little ingame cmd that displays whatever data I'm interested in. I feel quite comfortable with it.

I'm glad you agree that increasing MIN_STEPUP is our best bet for now. So will you plz commit the change ? But before you do, I have one more question: Is there a way to make sure that an svn user recompiles all his maps ? If not, we might get a couple of bug reports that result from the version mismatch.
Worse than that, we could never be sure that a given bug report does NOT result from an outdated .bsp.
btw the above also applies to all other routing fixes that change the bsp files.

[Duke]

You are always talking about ingame maps, but those are usually way too complex to check them well.
Have you considered making a tracing/routing debugging map solely for testing?
Something with ever incresing stepups, all possibilities in a structured matrix.
I don't know how much work that would be, but it would ensure that you discover all bugs with it.

I already thought about asking for such a map. But then again, it can only contain those problems we can think of. If we can think of them, we can usually as well fix them right away.
Bug reports usually come from things the devs did NOT think of

[Mattn]

some test maps are also located at http://ufoai.svn.sourceforge.net/viewvc/ufoai/ufoai/data_source/maps/test/

[Duke]

Uhm... how do I display those red/green/yellow blocks indicating the routing data ? And the intended path ?
I have scanned through the cmdlist and cvarlist but couln't find anything.

[Mattn]

debug_map is the cvar you want

the line stuff is done in the options menu - the confirm actions stuff

[Duke]

Wow, you're fast
Funny, I had found the debug_map myself by now because you mentioned it in a post in the tracker I ran into. Thx anyway

[Duke]

btw we will soon need to *force* all maps to be re-compiled. See patch tracker, item 2462721.

What about adding some dummy_ufo2map_version.map file to the SVN ?

Option 1:
If the batch-file-artist who created compile_maps.bat is still around, he might be able to check for the timestamp of hat dummyfile as well (I have currently no clue if that is even possible for a .bat-file).

Option 2:
We could check for that file in the code when processing the '-onlynewer' param.

What do you think ?

[Mattn]

we should maybe introduce an ufo2map or bsp version check into the makefiles. much more reasonable imo - we could also bump the bsp version once "everything" (tm) is fixed

[Duke]

After a few more thoughts... forget about that additional file. It's much easier.

Let the onlynewer code check not just map vs. bsp, but also against a const date in that code.
We can then set that date to a value 'just before' we commit a bsp-breaking change.

Checking for the timestamp of ufo2map.exe would be too much. That exe changes all the time because of the shared code.