Regarding reachability, a related question is: "Why doesn't Item implement IReachable?" What classes do implement this interface?

Never did get an answer on this, but I would really like some help explanation regarding the now absent isReachable() method. Didn't GameBots used to include an isReachable flag with each object? What's the story?

I've completely overlooked this thread, sorry.

1) isReachable attribute is really gone. Computing reachability of all thing the bot could see was very expensive and caused server to lag when more bots were connected. Moreover we agreed that usability of this information is not very high - always there exist path towards thing you see if you use navigation graph and running somewhere straight is usually not a good idea anyway (even if something was reachable, it could mean the bot needed to do at least one jump to reach the destination, but there was no way how to find out if it is the case). Can you describe the scenario where you have been using isReachable attribute previously?
The check reachability command returns the same info isReachable attirubte did, but now you need to send this request manually and wait for the answer (you get a message back with the same id you have issued. You also need to input id of the object you want to find if it is reachable or not.) The whole reachability thing in UT has issues, if the object will be further than 1000 ut units, the reachable will always return false, even if there is straight way towards it (that's another reason for us to remove it).
The easiest replacement of isReachable (and better I think) is something like - i want to know the reachability of object A - first step - find closest navpoint to A, second step, find path with floydwarshall map towards A, step three - examine the path I have gotten - does ti "go around" (not very straight) - this means the point probably is not reachable, does it go more or less straight? - this could mean I can reach it directly, does it go more or less straight, but there are tricky navpoints and edges (e.g. jump spots, jump points, etc) - this means the point could be reachable, but I should be careful.

2) FloydWarshall path planner indeed is fully functional and we are using it ourselves in all of our examples. How it works - in the handshake when the bot receives info about nav points, FW planner computes all the paths in advance (on the biggest maps it can take tens of seconds, on normal maps its instant). This means that when the bot is spawned you can use FW planner to compute any path instantly (it responds even faster then UT A* - you don't need to wait for the response from UT server ). You don't need any locks, the FW should be finished by the time botFirstSpawn method is called (Is that right Jakub? ). Well so far I hadn't any issues with FW planner concerning this, so I am pretty confident it is the case.
Also we have used FW planner in our lectures half a year now and everything was smooth...

Best,
Michal

Ad 2)

Right, FloydWarshallMap initializes itself upon receiving all navpoints/links from UT2004. Moreover, if you alter the graph using 'navBuilder' (I've already covered this topic in: http://diana.ms.mff.cuni.cz/main/tiki-view_forum_thread.php?comments_parentId=1025&topics_offset=4&topics_sort_mode=lastPost_desc&forumId=4), FWMap will auto-pick those changes upon leaving 'botInitialized()' method.

3) Jacob, please note that from now on we're using Clirr to collect all API changes we've done to the Pogamut, see http://diana.ms.mff.cuni.cz/maven-sites/pogamut/3.3.0-SNAPSHOT/pogamut-ut2004/clirr-report.html for changes between 3.3.0 and 3.2.5. Clirr is now running for all projects we have always comparing changes to previously released version of Pogamut. So if you are unsure whether to upgrade to newer version of Pogamut, consult Clir. You may find all Pogamut Maven sites here perm-link: http://diana.ms.mff.cuni.cz/maven-sites

Cheers!
Jakub

Thanks for all the help. Let me go ahead and describe the situation in which my problem came up.

In the previous version of Pogamut I was using isReachable to decide whether items where worth going to. When this method was removed, I simply switched it to isVisible. This isn't as good, because the bot can sometimes be right next to an object it wants, but looking in the wrong direction, and therefore miss it. So, I then replaced isVisible with a proximity check ... which is fine unless the object is right above the bot's head through a ceiling, but that can also be checked by looking at the z coordinates.

This seemed to work ok, but then I found an example that broke this, and I think it would break Michal's proposed approach too: On Curse4 there is a UDamage that is hidden behind a door that can only be opened by shooting it. Whenever the bot got near the door, it would slam into the wall repeatedly because the item was close enough, and on the same level. I suppose before that the isReachable method realized that the door prevented the bot from reaching the item.

This may be an extreme special case, but isReachable seemed like a general solution. I don't know how many other cases like this one exist, but I don't currently know of any. So, I'll rely on heuristic methods and treat this as a special case for now.