Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Did you pull the y down too much on the ceiling so it is not recognizing the top of that cliff or whatever
This plugin rocks in conjunction with Kiss. You can set your puller tank to use nav mesh and it will run around objects / turns etc and pull mobs back to the camp. I don't know if it uses waypoints yet or not.
Kiss detects if you have a mesh loaded and uses that to pull.
I see everyone using this plugin with success and I have yet to generate a mesh that doesn't have issues. Without fail my puller will run straight into a zone wall and bounce back and forth over and over. I look in the meshgenerator and I can't even figure out why he would take that path. /sigh. I'm posting my mesh, a screenshot of the settings I am using in hopes someone can help me out.
The only thing I've done is adjust the X, Y, and Z values to the area I am interested in hunting in.
Also I can't get the nav UI to draw, I am guessing an ISboxer issue.
So it is possible that my target (destination) was outside of my generated mesh or there was no path to that specific target. Right?No end reference means that the destination was not close enough to the mesh to produce a valid path.
So it is possible that my target (destination) was outside of my generated mesh or there was no path to that specific target. Right?
So I need to be sure that my mesh covers my entire possible pull radius.
If somebody wants to do that I would recommend waiting until after my next update, as the meshes won't be compatible (but will have a bunch of new features...)
You found a fix for the UI / ISB?!?!
I mean, Someone did it for maps afterall. Someone with a super powerful rig should do it up, or break it up by expansion, starting EoK backwards
Makes sense to me
I also think it's a nice incentive for paying members who want to use it, Just adds more value for the membership
If somebody wants to do that I would recommend waiting until after my next update, as the meshes won't be compatible (but will have a bunch of new features...)
Is it possible to work on a way to use the mesh to create a path rather than recording within EQ? Apologies if I missed this function already!
If you tell me what you want the settings to be for the maps I'll be glad to build them and upload. I currently try to make the (mesh??) size as large as I can before it tells me it's to large and hit generate. The generation takes seconds for me to do. Do you actually have to be in the zone your building as that would take longer.
Sent from my iPhone using Tapatalk
There is going to a new Mesh Builder soon so any meshes made now will not work with new ones. So don't go crazy making them.
You don't need to be in the zone while you're building, but its highly recommended that you have run MQ2Nav plugin while in the zone at least once to generate the dynamic data required to fully complete the mesh.
- - - Updated - - -
This.
Just for my understanding. Before a mesh is built and Nav is running its building the dynamic data for a mesh file? Then when you run the mesh builder it takes this dynamic data at a later point and inputs it into the nav file?
Yes. When you enter a zone, MQ2Nav will generate a file named like "MQ2Nav\poknowledge_doors.json" and then the MeshGenerator tool will read that in and load additional objects into the mesh. PoK is a good example because some of the PoK stones (crescent reach for example) do not appear on the static zone geometry, but are visible in the game. These objects are loaded through the dynamic object system in what MQ2 calls "Doors".
There is a message in the upper left of the mesh generator that says "No zone objects loaded" if you haven't generated this data yet.
Shouldnt we be able to just have a git repo with mesh's? people can submit there
It is unfortunate that the mesh files are not compressed some how thou =)
new mesh file format uses compression with ~50% or more space savings. You can track my development progress here: https://github.com/brainiac/MQ2Nav/commits/develop
- - - Updated - - -
Also worth noting, git would be generally terrible for hosting nav meshes. Since they won't diff and can be large. It would be better to pursue other solutions, either on the fly mesh generation or building and hosting a navmesh web service. I could build either system. Maybe even both, or maybe a service to provide popular settings for auto generating meshes. Maybe I'm just getting carried away again...
If it wasn't huge amount of trouble and there was someway to build a mesh on the fly. Say once you zone into a zone issue a command to build
Mesh with the default settings? Pipe dream on my part?
[defaults]
Tiling_TileSize=128
Rasterization_Cell_Size=0.6
Rasterization_Cell_Height=0.3
Agent_Height=6.0
Agent_Radius=2.0
Agent_Max_Climb=6.0
Agent_Max_Slope=60
Region_Min_Region_Size=8
Region_Merged_Region=20
[poknowledge]
[oldkaesorab]
Rasterization_Cell_Height=0.6
Agent_Radius=3.0
Agent_Max_Climb=2.0
I was thinking the MQ call the fat client externally. If the fat client crashed it would have no affect on that instance that way.
Sent from my iPhone using Tapatalk
I know braniac was considering the feature to call mesh build for a zone that was missing via MQ2
My concern is it would be inefficient if MQ2 was doing it, but if that is not the case than it makes sense
Regardless if it is initated by MQ2 or by the thick client....
A possible idea is if you had a json/xml/ini file of sorts that specified
- default mesh build settings
- each zone
- zone-specific-mesh-build-settings
If this was the case then the community could update git to specify the zone-specific-mesh-build-settings.
Example
I have found changing Rasterization_Cell_Height, Agent_Radius and Agent_Max_Climb fixed the pathing in oldkaesorab for me
Rich (BB code):[defaults] Tiling_TileSize=128 Rasterization_Cell_Size=0.6 Rasterization_Cell_Height=0.3 Agent_Height=6.0 Agent_Radius=2.0 Agent_Max_Climb=6.0 Agent_Max_Slope=60 Region_Min_Region_Size=8 Region_Merged_Region=20 [poknowledge] [oldkaesorab] Rasterization_Cell_Height=0.6 Agent_Radius=3.0 Agent_Max_Climb=2.0
That's an interesting idea. I'm adjusting the global defaults in the next update to solve some issues and I'm removing the tile limit so in theory the defaults should always work.
Can you store it in a separate or preferably global file instead? This way the community can keep zone-specific stuff updated without having to transfer/include the mesh itselfMeshes will store all of the settings and modifications moving forward.
After playing with Agent_Radius a bit I feel 3-5 is ideal. Many people here have complained about 'clipping' the sides of things and this is the setting I have found that helps
Can you store it in a separate or preferably global file instead? This way the community can keep zone-specific stuff updated without having to transfer/include the mesh itself