Walkabout Navigation Toolkit help thread

#41 Daniel, I'm trying again to compile this under T3D (MIT) 3.0 but I keep getting errors in VS2008. The latest was from aiPlayer.cpp concerning interiorObjectData (or some such). To be honest, I've never had much luck compiling anything, as I know almost nothing about using VS or compilers in general. Your excellent docs die for me at step 6. Recompile the engine.

I do have all the non-engine stuff in and showing up. Just no navmesh. Do you (or anyone else) know if this works out-of-the-box with 3.0?

#42 @Dan: I can't speak for the out-of-the-box implementation of Walkabout for T3D 3.0, but I can say that the InteriorObject format is no longer a feature of T3D as of 3.0. Anything that tries to utilize that no-longer present class will indeed fail and would have to be updated accordingly.

#43 Thanks Michael. Can I comment that snippet out and try recompiling?

EDIT: Just commented it out and compiled with 0 errors, so I guess that's one way of doing it. Unfortunately, now it looks like I need to actually add each file manually. I'll post my results later.

#44 Dan: Michael is right, 3.0 no longer supports .dif so the mask that was previously in aiPlayer.cpp is out of date. It totally slipped my mind that I'd have to have Walkabout ready for the 3.0 release - I'm bringing it up to scratch as we speak, should have a patch ready soon.

#45 Daniel, good on you mate. As I just got 46 critical errors trying to compile, I think I'll wait for said update. :D

#46 Oh wow, I didn't realise it was that bad. I should be done with it soon - I've got it working with 3.0, now I'm just updating Recast.

#47 And it's done.

#48 Finally got round to updating my project to Walkabout over the recast resource. Using MIT 3.0, having used the "easy install" method from the documentation. Apologies if these are know issues.

1. After creating a new navmesh and saving and reloading - there is no way to select the navmesh for the walkabout editor. Thus no way of rebuilding it via the walkabout editor. Nothing shows up in the "navigation" pane of the walkabout editor.

Only creating a new navmesh gives the walkabout editor the navmesh data in the properties window panel. Still doesn't add anything to "navigation" panel.

2. Some long paths (500 metres) fail to create all of their nodes. Final path node can fall short by around 150-200m. When Ai reaches final node path is cleared. Starting a new path from Ai's final position to same area then works. This can be replicated every time using similar positions on some maps - other maps never seem to have this issue, including ones with more complicated objects/routes.

Suggest onReachDestination code checks that target position and last node position are nearby and autobuild a new path if not.



Picture for example.

Obviously there are simple script workarounds for both of these issues - but figured I'd bring them to your attention.

Anyhow, those are the only issues I've found. Really like Walkabout, massive improvement on your free recast resource.

#49 Arggggh. Dan Webb was noticing that issue with the NavMesh never appearing in the navigation pane, but I can't reproduce it here. I've got his console log, so I'll start to get into it this weekend/next week. Oh, and until then, don't forget you can build the navmesh from the console. Function reference is in the user manual.

About the paths falling short on long journeys. In navPath.h, there's a line:

static const U32 MaxPathLen = 2048;

Do you want to try increasing that and seeing if your paths make it closer? I'll definitely put this on my list of things to fix in a more permanent fashion, but I just want to make sure this is the issue and not something else!

Unfortunately this is a weakness of the Detour API - you need to give it a fixed-size buffer to pathfind in. I can fix it in the way you suggest, though, and will be doing that.

#50 Increasing MaxPathLen to 4096 got the path a little closer, and setting it to a whopping 8192 got it to go all the way. Obviously 8192 is ... a lot ... and I'm not sure about other issues which having it that high may crop up.

#51 Okay, cool. At least it's no more a complex bug than that. It's just a memory usage thing - AFAIK I think it just allocates an array of short ints of that size. An optimisation would be to make that buffer static rather than stack or dynamically allocated, but I'll have a look into more robust solutions like splitting long paths up.

#52 @Steve - what's your terrain's squareSize? It's probably unrelated, but I thought I'd mention it as a possible influence.

#53 Dan: it shouldn't change the generated navmesh, Recast simplifies the output mesh as much as it can. I think.

Steve: if you want to help debug the issue with the editor browser not showing any navmeshes, can you tell me whether there exists a SimSet named ServerNavMeshSet and what's in it?

#54 @Mr Webb
squareSize is 2, terrain size is 512x - so not really big, 1km in real terms. And ... I only use half of it. navmesh is 256x256x128

@Mr Buckmaster
The nav mesh is the only thing in ServerNavMeshSet - however serverNavMeshSet has not been added to the MissionGroup (so I had to get the ID via the console).

#55 And checking the console I got:

GuiControl::awaken: failed onWake for obj: 3488:GuiTreeViewCtrl (NavTreeView)

3488 is NavTreeView

#56 Ok, thanks. I'll see what I can find out when I get back to this. Also when I can get my computer to start up reliably :P.

(ServerNavMeshSet sounds like it's working right - it's supposed to just hold the navmeshes, and it's not supposed to be in the missiongroup. It's something going wrong in the editor scripts.)

#57 Daniel, feature request:
EngineDefine/Console Function for "find nearest path poly at %xyz" without the need for having a path use to/from, returning %coordinate for success or 0 for fail.

Has all kinda of applications, currently I always have a generic path to/from, but it'd be nice just to call from script %obj.getNearestPathPoly(%xyz); instead.

#58 As in, get the nearest point on a navmesh? Good idea, added it to the list of things to do :P.

#59 Yep, the nearest point on the navMash to xyz. Would save like ... typing 2 whole lines of script for creating a path to find it. :P

#60 Hit the same error as steve where it wasn't propagating values to the gui. console entry of:

NavEditorGui.onObjectSelected(12392)

where 12392 was the ObjectID of the navmesh filled the data out and made it interact-able, so the breaks above that portion of functionality.
Additional console log, systems used, source map, and resultant navmesh sent via email in case it's something obscure we're both doing.