• You've discovered RedGuides 📕 an EverQuest multi-boxing community 🛡️🧙🗡️. We want you to play several EQ characters at once, come join us and say hello! 👋
  • IS THIS SITE UGLY? Change the look. To dismiss this notice, click the X --->

Request - MQ2Nav Beta by Brainiac and Donation Kick Starter. (3 Viewers)

Status
Not open for further replies.
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.
 

Attachments

  • beastdomain.bin
    9.3 MB · Views: 3
  • beastsdomain.PNG
    beastsdomain.PNG
    2.6 MB · Views: 12
Did you pull the y down too much on the ceiling so it is not recognizing the top of that cliff or whatever

yes, I moved it down to exclude that geometry. I guess my reasoning was that there is no possible path to that location so I should exclude it?
 
It will only consider the geometry with the teal(ish) colored tiles. You can run a pathing sim in the meshgenerator as well to test the mesh. Ctrl+t to show the tools window and use the testing tools to place start and endpoints.

I'm currently doing a review of the UI in various places to make it easier to use. I've making a lot of changes, working towards a big feature+stability update. Will have more details when i'm closing to releasing.
 
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.

Right - I guess I may just be missing the command to do this? Or does kiss do it automatically when you have a mesh loaded? In the Nav guide it doesn't show something to specifically swap between normal Kiss pulling and this.

/nav [save | load] Save/Load settings.
/nav Reload Reload Navmesh.
/nav Recordwaypoint <waypoint name> <waypoint tag> create a waypoint.
/nav Target Navigate to target.
/nav X Y Z Navigate to coordinates.
/nav Item [click] [once] Navigate to item (and click it)
/nav Door Navigate to door/option (and click it)
/nav Waypoint Navigate to waypoint.
/nav Stop Stop navigation.
/nav Pause Pause navigation.
/nav ui toggle displaying the in-game user interface
 
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.


The mesh looks fine. Can you give me an approximate start and end point /loc so I can reproduce the pathing issue?

I'm also looking into the isboxer stealing my graphics context (preventing the ui from drawing)
 
I am tearing my hair out with this plugin... I know it works but clearly I'm not smart enough to figure it out.

Here's my mesh, a screenshot of a path test, and I continue to get "No end reference". I don't understand what that means or how to fix it. I test it with the tools in meshgenerator and it works fine.

GAH!
 

Attachments

  • kattacastrumb.bin
    2.4 MB · Views: 1
  • mesh.PNG
    mesh.PNG
    1.9 MB · Views: 13
  • noend.PNG
    noend.PNG
    6.2 KB · Views: 180
No end reference means that the destination was not close enough to the mesh to produce a valid path. It might be one of the several issues related to some issues I've commented on previously though. I'm working on a major update and I'll make sure to make this part of it better as well
 
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...)
 
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
 
Last edited:
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


Maps were volunteer, this plugin is volunteer. Brainiac and 99% of the other developers do this on their own time and a small amount of donations, there is no payroll here. The meager amount it costs for membership to RG I bet barely keep the lights on(and coffee in Maskoi/Ctaylors cups). You could earn a years worth of membership in redcents if you did it yourself for the community. You don't need a powerful rig for it.

Give me a porter with access to all EoK zones Id happily soak up those free redcents =p
 
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!
 
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!

That was part of another thread. But the question of "can we get MQ2nav to output a list of waypoints" has been raised and it was discussed it might eventually be implemented. Droid looked at the code on GitHub and found a place where it could be done. I don't know if Brainiac still has it on his radar, so to speak.
 
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.
 
Last edited:
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

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 - - -

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.

This.
 
Last edited by a moderator:
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?


Sent from my iPhone using Tapatalk
 
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.
 
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.

That is good to know. Now that you say that I remember seeing a ton of json files. That would make building accurate mesh files a little more difficult. [emoji1]

I'd be willing to take a stab at it though when your finished though.


Sent from my iPhone using Tapatalk
 
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...
 
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?


Sent from my iPhone using Tapatalk
 
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?

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
  1. default mesh build settings
  2. each zone
  3. 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
 
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 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

Right. It would call out to the mesh generator process in a special headless mode (no UI) that would be under the direct control of mq2. It would do queueing if you had multiple clients running in different zones and allow you to configure the CPU cores to use and would provide progress and info to the client.

- - - Updated - - -

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
  1. default mesh build settings
  2. each zone
  3. 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.

Meshes will store all of the settings and modifications moving forward. I'm also adding true support from r marking areas as unwalkable and giving you the ability to mark other areas with cost modifiers. All of these will be stored in the mesh file so it can be reopened later and further modified

I expect these different modifications are what will be interesting to save. Also, off mesh links (teleports, etc) will be supported at a later date
 
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.

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

Meshes will store all of the settings and modifications moving forward.
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
 
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

I can add a function to export and import the settings but the current settings need to be part of the mesh because certain features require regenerating tiles on demand and that needs to be done with the correct settings. It also means that certain settings like tile size will be locked in once a tile has been added to the mesh

I think this will be a bit more obvious when I get this into your hands but there's a lot of new functionality coming soon that requires more data saved with the mesh

- - - Updated - - -

I've managed to fix the EoK zones. The catch is MeshGenerator.exe is now a 64bit application. Loading a zone like frontiermtnsb takes upwards of 1.5gb of memory and is REALLY SLOW and laggy. I haven't begun rewriting the renderer, so it will have to do until then... this will be in the next release which is coming soon...
 
Request - MQ2Nav Beta by Brainiac and Donation Kick Starter.
Status
Not open for further replies.

Users who are viewing this thread

Back
Top