Walkabout Navigation Toolkit help thread

#61 Okay, I'm still unable to reproduce this on my end. Does calling onObjectSelected manually cause the NavMesh to appear in the list?

#62 correct.

#63 And I assume that same as Steve, you have a ServerNavMeshSet and it's got your NavMesh in it. Does calling NavTreeView.buildVisibleTree() in the console have any effect? What does NavTreeView.getItemCount() return?

Also, I assume no mesh shows up in the browser regardless of whether it's a new mesh created while the mission is running, or if the mesh is loaded from the mission file?

#64 Actually, mine's just a singular mesh floating free as the last entry in the missiongroup.

///first test: loading up without running the function

loading up a mission and calling NavTreeView.buildVisibleTree() places a blue-tiled 12382: Navmesh - Nav guibitmapcntrl (guessing there) in navigation that is clickable, but doesn't seem to perform any function (no console errors).

NavTreeView.getItemCount() after performing that step returns 2.

///loading up, running the function, performing the test
(should note that on calling the previously mentioned function the navigation pane is blank)

calling NavTreeView.buildVisibleTree() does not seem to perform differently.

NavTreeView.getItemCount() returns 2.

*edit: definitely looks like it's trying to reference something along the lines of a simset, but reviewing the map file directly does show it strictly as an isolated element within missiongroup.

*edit2: attempting manual creation of a simset labeled ServerNavMeshSet gave the following error: Object names must be unique and there is an existing SimSet Object with the name 'ServerNavMeshSet' (defined in an unknown file). Please choose another name.

#65 Ah sorry - ServerNavMeshSet is automatically created by Walkabout. It's not visible anywhere in the editor, you'd have to check its existence in the console. It's a SimSet, not a SimGroup, so your NavMesh can belong to the MissionGroup and the ServerNavMeshSet at the same time.

Okay, this is going to take some effort :P.

#66 Yeah, was tracing SimSet *NavMesh::getServerSet().

On the off chance it was an order of operations error due to having rigidshapes using WalkaboutUpdateAll(), pushed nav to the top of the list. no dice.

likewise with

function RigidShapeData::onAdd(%this,%obj)
{
...
if (isObject(MissionCleanup)) WalkaboutUpdateAll(%obj);
else schedule(1000,GAME,"registerwithwalkabout", %obj);
...
}
function registerwithwalkabout(%obj)
{
if (isObject(MissionCleanup)) WalkaboutUpdateAll(%obj);
else schedule(1000,GAME,"registerwithwalkabout", %obj);
}

to give it additional time to push the mesh in first.

Only thing I can think of at this point that we're making heavy use of in terms of potentially oddball behavior.

#67 I don't imagine that's causing problems, the update functions just peek at the list of existing navmeshes.

When you said the item was 'clickable, but doesn't seem to perform any function', you mean you didn't see any effect of clicking on the mesh? The visible mesh in the mission didn't change colour, and its properties didn't appear in the inspector?

Can I ask you to try installing Walkabout in a fresh project to see if the issue persists? I just really can't work out where it's going wrong, and it seems to work fine for me - if it's an issue with your code or another pack it'll be much harder to resolve the issue.

#68 When you said the item was 'clickable, but doesn't seem to perform any function', you mean you didn't see any effect of clicking on the mesh? The visible mesh in the mission didn't change colour, and its properties didn't appear in the inspector?

Didn't see any effect when clicking the button added to the navigation panel after calling NavTreeView.buildVisibleTree() in terms of navmesh coloration, or gui entries filled out, and received no console errors.

Will try and grab a day to do a from-scratch repro if possible. (Kinda juggling about 3 different research tracks at present, so might be a day or two.) Mean time, incorporated 3rd party utilities include AFX, and Walkabout, with the rest being homebrew.

#69 Hi,

I have this exact same error on a stock installation of the latest dev branch of T3D MIT.

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

NavTreeView.buildVisibleTree();
Populates the Nav list with a non-clickable entry, it does seem to be the correct Nav in my mission, I only have one for now. It does highlight on mouse over.

NavTreeView.getItemCount();
returns 2

5284.build(true, false);
builds the nav mesh fine.

Cheers,

Andy

#70 Oh dear. Thanks Andy for the confirmation. I'll have a look into that error and see what I can find out...

#71 Daniel, any news on the fix?

#72 Sorry Andy, I've been away from my dev environment and will be for another week and a half. Before I left, it was infuriating me though - though I didn't get to the stage of doing a complete fresh install, so maybe that's what needs to happen. If anyone wants to help me debug this remotely, can you stick a breakpoint on this line and see what's causing it to run? It will either be the case that mAwake is false, which seems silly, or onWake() failed. Which means... I'm not sure what. Probably that this code failed:

bool GuiTreeViewCtrl::onWake()
{
   if(!Parent::onWake() || !mProfile->constructBitmapArray())
      return false;

Which probably implies the second part failed, the profile bitmap array. Not sure what that has to do with the tree view though. Can someone check this line too?

Sorry for this crowd-sourced debugging, it's definitely not how I'd prefer to be going about this. I'm just getting ideas popping into my head and I don't have a dev computer set up here!



EDIT: On the other hand, what the heck. I'm having coding withdrawal symptoms already... VS2012, here we come!

#73 mAwake is true, so yeah, it'd have to be the onWake

callstack seems to be saying there's a scripted setvisible being set someplace related to "tools/navEditor/NavEditorGui.gui". Premature call maybe?

#74 Having issues installing the DXSDK, strangely :P. I should be set up by tomorrow though. The setVisible may come from the entire editor itself being woken up and turned on. Not sure why that would count as coming from a .gui file though.

Or, possibly, it could be in NavEditorGui::onModeSelect in navEditorGui.cs

#75 Okay, I think I have something. Someone feel like testing this out? On line 123 of navEditor/NavEditorDlg.gui, change the first few lines of the object declaration to read:

new GuiTreeViewCtrl(NavTreeView) {
               canSaveDynamicFields = "0";
               Enabled = "1";
               isContainer = "1";
               Profile = "ToolsGuiTreeViewProfile";

I think it was just a matter of profile names changing. I just wanted to put this out there because I can do it faster than releasing a patch ;P.

#76 confirmed functional. much obliged.

#77 Thanks, sorry it took so long to figure this out. It must have been a case of me not noticing script changes had snuck into the templates, and hadn't been reflected in my test project. This will be in the next patch.

#78 Brilliant, work perfectly now. Thanks for the fix.

#79 That's

Tools/navEditor/NavEditorGui.gui

:P

lol, one word fix and all is well!

#80 Technically:

game/tools/navEditor/NavEditorGui.gui

Yeah... software, right!?