Yes, it's a pain in the butt.
I'm sure Codewalker realizes this, but for the benefit of a few people who are recommending computer graphics books to me, I know a little more about this than I'm often letting on, just because I'm trying to approach this from the perspective of someone who might want to write a bot, and has to learn everything from scratch. Also, I'm busy and lazy, and so I'm playing this completely by ear and detecting problems by running into them face first. And I think it might be helpful if I discuss this (mostly but not always talking to myself) at a slower pace than normal.
In this case, my idea for somehow extracting just what I wanted from the map files was a bit naive. I can always hope, but the problem with that idea is the notion that there is anything remotely called "the ground" I could pull from the map files, or anything like that. Map files are organized by object (and probably implicitly space) trees.
See, there's just no way any game could figure out fast enough whether I hit every single thing on the map: it would take too long to check if I potentially hit thousands of different objects. To speed that up, games with 3D collision detection all use some form of subdivision algorithm. The idea is that rather than check to see if I hit any of a hundred trees in Atlas Park, Atlas Park itself is subdivided into groups of objects. Each group is surrounded by a bounding box that contains all of them. Before you go checking to see if you hit anything in the box, you first check to see if you are *inside* the box. If you aren't, you can ignore everything in it. If you make groups of objects, and groups of groups of objects, and groups of groups of groups of objects, you can eventually check for collisions much faster. The ultimate in speed (but with caveats) is the binary space partitioning algorithm, where your entire map is split roughly into two parts, and each part is split into two parts, etc etc. Even if you have a million objects, checking for collision is just a matter of making 20 checks for collision with ever smaller boxes, and then finally checking for detailed collisions between you and the few things in that final box. That's fast.
Whether you use BSP or some other algorithm, it helps if you design the space in a manner that reflects how you intend to subdivide it. Everything should be in one and only one box (or in a box inside a box inside a...), and the boxes should connect together in a reasonable fashion (or your map designers will go crazy). So big maps like Atlas Park are actually "islands" of geometry, with City Hall here and the Tram station there, each with its own "ground" and all of the "grounds" connected together in a patchwork of ground. You don't have to specifically deal with the tram, but you still have to handle the "Tram island" of geometry, which includes the ground in that area.
This is all redundant discussion for computer graphics geeks, but its something bot writers who are not computer graphics geeks need to be moderately aware of. Or they need to make ghostbots. There's nothing wrong with ghostbots per se.
While I'm thinking about that, I am going to redouble my efforts to get costumes and costume hashes working (of course, so far I've put in almost nothing, so that's not saying a lot). At first, I thought combat was more interesting to get working (pseudo, no effects, shadow boxing type combat). But last night, before I went to bed, I had an inspiration. Now I think getting the costume hash is a lot more important. Hopefully, by the weekend, I'll be able to demonstrate why.