brainiac / mq2nav Goto Github PK

current renderer is terrible, needs to be replaced

off-mesh links could be used to link disconnected parts of the mesh together, or it could also be used to implement support for triggers (such as teleporter NPCs)

In meshgen, when clicking to remove a tile, it will remove all tiles underneath as well.

Add ui to display models and their properties

1- There are some zones with one way doors or bad meshes that nav gets stuck on. Would be nice to be able to check ${Nav.Stuck}. Specific example: Plane of Nightmare. Mephit caves in north section. Has some drops that are one way. ( May be able to fix with editing mesh climb values). Another place is plane of water where there is a long vertical shaft.

2- ${Nav.Path[]} = list of points that is given to MQ2Map to show the line. Why? Simple farming method is to use ${NearestSpawn} to find next target. Using ${Nav.Path} would allow macro to check for spawns along the path and select a "closer" mob.

Current behavior is to generate a path to the nearest point on the mesh relative to the destination. Often times this is on the wrong part of the map if the mesh can be generated vertically above or below the target. It would be better if the navigation failed instead.

Allow the creation and usage of pre-created pathing. Similar to AdvPath. Could be integrated with mesh navigation to allow for traversing through difficult to navigate areas.

Allow resizing of areas (water/nonwalkable/etc) after adding them to the mesh. This would allow tweaks of how the areas intersect with the mesh without needing to guess the geometry beforehand.

see #36 for example of the issues these can cause.

Zones.ini can get out of date. Also, its an ini file. Make some improvements.

Some ideas:

• Update check for Zones.ini
• Convert to json?

Use spdlog to add good logging support. Allow for log level to be scoped to commands, as well as saved to settings.

This covers #49

Allow generating individual tile's meshes with different parameters and perhaps with subtiles to be able to increase localized mesh precision in particularly tight areas.

When trying to limit the scope of the mesh generation, the user cannot change the horizontal variables in the box (@brainiac mentioned something about origin calculation), or the generated mesh will not be coincident with the geometry it generated against.

fix issues with redrawing after resizing the window

From a basic user level; trying to move your view, and zoom in/out of the mesh for editing is difficult/slow. walking through the mesh, especially with complex 3d geometry can be very difficult when looking for a troubling corner to edit.

I speak from the viewpoint of an engineer who routinely uses 3D modeling programs of a CAD basis, whereby these functions are more fluid, faster, and easier. However, I have zero knowledge of the difficulties from the programming side to alter, or improve these functionalities.

Implement basic support for off-mesh links. This will only support basic links between the same or adjacent tiles.

The only options that will be supported are:

• pathing weight
• bi-directional vs uni-directional

Make sure the storage for links is extensible so future features can be added without breaking compatibility.

Similar in purpose to the request by dewey2461, a list of coordinates NEAR a given target location that are on the mesh. In other words... if a point is XYZ, then a set of meshed points on the matrix of a given radius 100 units from XYZ.

Access to LOS between any to such points would allow for "choice" of position from which to pull.

A command line list of waypoints would be wonderful rather than having to open the GUI and click through it.

This would make writing code to avoid raid mechanics amazing.

Other partial solutions, Allow for testing various path end points before actually running the toon.

For example: In a macro I could try moving "toward" my end location by selection a small movement in each direction / radius , to see which ones are "safe", pick one, repeat.

Render models with their textures

I am seeing pathExists return true when I believe it should not. In the case I am showing below, I am standing in a valid and otherwise navigable mesh, and my destination point is also on a valid mesh. However there is no valid path between the two. Rather than returning FALSE, it is choosing an impossible route (in this case the straight line from where I am to where I have asked to be, through a wall). Further, because the invalid path it has chosen is unusually short, my algorithm is choosing this destination because it has the lowest cost, versus other, better options.

There are a few examples of this in the game, below is a simple case from Crescent Reach. In this case the destination tunnel cannot be reached because of how I have generated the mesh. While I can solve this particular issue with the meshgenerator, I think the underlying problem is a bug.

I cannot tell from issue #41 if this behavior should also occur even when the start/end are not vertical. There is a z-axis delta in my example, but they are in different parts of the map.

Current navigation commands are positional arguments. Add keyword argument support, and start with the distance command.

Example:

/nav target distance=30

Will navigate to within 30 units of the target

While navigation is active, show a heads up display with:

• Current target & distance to target
• Moveable overlay
• Options to pause and cancel

Note required I convert solution as you are using a different version of VS than me. I'm using the following
Microsoft Visual Studio Community 2017
Version 15.1 (26403.7) Release
VisualStudio.15.Release/15.1.0+26403.7
Microsoft .NET Framework
Version 4.6.01586

Installed Version: Community

Visual Basic 2017 00369-60000-00001-AA332
Microsoft Visual Basic 2017

Visual C# 2017 00369-60000-00001-AA332
Microsoft Visual C# 2017

Visual C++ 2017 00369-60000-00001-AA332
Microsoft Visual C++ 2017

ASP.NET and Web Tools 2017 15.0.30320.0
ASP.NET and Web Tools 2017

JavaScript Language Service 2.0
JavaScript Language Service

Microsoft Visual Studio VC Package 1.0
Microsoft Visual Studio VC Package

Visual Studio tools for CMake 1.0
Visual Studio tools for CMake

Visual Studio Tools for Unity 3.1.0.0
Visual Studio Tools for Unity

C:\MacroQuest2\MQ2Nav-1.2.0.113 (1)\MQ2Nav-1.2.0.113\plugin\MQ2Nav.vcxproj : error : Unable to read the project file "MQ2Nav.vcxproj".
C:\MacroQuest2\MQ2Nav-1.2.0.113 (1)\MQ2Nav-1.2.0.113\plugin\MQ2Nav.vcxproj(38,5): The imported project "C:\MacroQuest2\MQ2Nav-1.2.0.113 (1)\Plugin.Debug.props" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.

Since this appears out of date and I'm impatient I figured I'd take a gander at the solution. MQ2Nav (Load Failed) populates when opening the solution.

#include "common/proto/NavMeshFile.pb.h" errors saying cannot open source file.

static void ToProto(nav::vector3& out_proto, const glm::vec3& v3) nav::vector3& shows namespace nav has no member vector3 - possibly related to previous errors?? Not really sure. Source not usable in it's current state for me as I'm uneducated in the ways of c. I just do macros and java atm. - MMOBugs::Chatwiththisname

Detect zoneline areas and add them as navigation targets

So I've been using nav to write a plugin and I've tried to silence it and have been mostly successful. The issue was when the m_activePath->IsAtEnd() in MQ2Navigation.cpp it reports that it's reached the destination. Possible to add a toggle to turn off messages from the plugin please.

void NavEnd(PSPAWNINFO pChar)
{
	PMQPLUGIN pNav;
	fNavCommand TheNavCommand = 0;
	if (pNav = FindMQ2NavPlugin())
	{
		TheNavCommand = (fNavCommand)GetProcAddress(pNav->hModule, "NavCommand");
		if (TheNavCommand)
		{
			bool bTemp = gFilterMQ;
			gFilterMQ = true;
			TheNavCommand(pChar, "stop");
			gFilterMQ = bTemp;
		}
	}
}

For the most part this works. Unless the Destination is reached before I issue the command. Which happens. So randomly I get a message that I've reached destination.

Thanks in advance.

Nav command to get within line-of-sight of a spawn / coordinates within a given range.

Add a model filter to MeshGenerator and MQ2Nav that can be used to identify problematic geometry and exclude it from the mesh. Useful for objects that cause collision on the mesh when they don't exist in game (invisible objects, walls, etc)

The UI window is not usable when having /viewport set. Text disappears as you move the window around the screen. Mouse position is offset.

Disabling viewport with /viewport reset makes the UI look correct and function correctly.

Replace old navigation system that goes back to the early days of mq2nav:

• Use DetourPathCorridor for handling dynamic path planning
• Add support for off mesh links, this is necessary for supporting #52
• Reusable components so that the same path planner can be used for the meshgen pathing simulation as well as the plugin

Marking an area as pathable does not counteract another, overlapping, area that is marked as unpathable.

When camping out to character select and logging into the same zone the previous character is/was camped in, the nav mesh for that zone does not load mesh on zone re-entry. Not a plugin breaking bug, but an annoyance all the same.

A couple ideas on had on this:

• Data could be "baked" into the navmesh file
• Separate json file like the doors files.

Would be nice to have MQ2Nav be able to supply back the "path" it will take as an array.

This will allow for several other things (please see my other suggestions that relate to this):

1. a script to check for NPCs on the way to the target and "stop" either going to the point or to calculate routes around the NPC.

2. Stop at a pre-determined DISTANCE from the target (to prevent aggro from an NPC)

JJB

We could download premade navmesh files for people who don't know how to make them.

MQ2Nav needs documentation so people understand how to use it.

Something like:

/nav avoidspawns spawnsearch
/nav avoidspawnradius radius

Should attempt to route around said spawns. Dunno if this is realistically possible or not.

Adding an issue as requested.

//============================================================================
// Wrappers for other plugins to access MQ2Nav
PLUGIN_API bool NavInitialized() // Used to check if MQ2Nav is initialized. TODO check if this is needed, the other stuff should catch if this failed
{
    if (g_mq2Nav)
    {
        return g_mq2Nav->IsInitialized(); // returns true if the plugin initialized
    }
    return false;
}

PLUGIN_API bool NavMeshLoaded() // Used to check if mesh is loaded
{
    if (g_mq2Nav)
    {
        return g_mq2Nav->IsMeshLoaded(); // returns true if mesh is loaded
    }
    return false;
}

PLUGIN_API bool NavPathActive() // Used to check if a path is active
{
    if (g_mq2Nav)
    {
        return g_mq2Nav->IsActive(); // returns true if the path is active
    }
    return false;
}

PLUGIN_API bool NavPathPaused() // Used to check if path is paused
{
    if (g_mq2Nav)
    {
        return g_mq2Nav->IsPaused(); // returns true if path is paused
    }
    return false;
}

PLUGIN_API bool NavPossible(PCHAR szLine) // Check path length
{
    if (g_mq2Nav)
    {
        return g_mq2Nav->CanNavigateToPoint(szLine);
    }
    return false;
}

PLUGIN_API float NavPathLength(PCHAR szLine) // Check path length
{
    if (g_mq2Nav)
    {
        return g_mq2Nav->GetNavigationPathLength(szLine);
    }
    return -1;
}


PLUGIN_API void NavCommand(PSPAWNINFO pChar, PCHAR szLine) // used to pass mq2nav commands
{
    if (g_mq2Nav)
    {
        g_mq2Nav->Command_Navigate(pChar,szLine);
    }
    return;
}

//============================================================================

Need the following to manage navigation options:

• UI for showing current applied options
• Save/Load options?
• Set defaults?

I would like to see an added feature (possibly user controlled) that allow for some variance in navigation path based on the path length.

i.e. if I'm running all the way across the zone I may not want the shortest path but would prefer a more natural path with less corners to look less automated.

changing the actor radius would prevent me from meshing in that area which is not what I want.

it's along the same idea as "take the interstate instead of backroads" because it's easier even if slightly longer.

Don't want to have to constantly distribute shaders and other files, so just bundle them in the executables

Make it so that pressing keys while navigating doesn't upset the navigation code.