Idea - anyone see a problem with this?

[mycroft]

While waiting on the update to the broker place command I've been playing around with a script to auto-create paths for use in lavishnav.

My initial idea was to check for movement beyond a certain distance and if it was greater than a set value then add a new 'point'.

The script then looks through the navigation file for any other 'points' and if any are close enough it adds them to that point as a connection and that point as a connection to them also.

If a point is close enough to your current location already it doesn't add another point but ensures that that existing point and the one you just came from are linked already.

The premise is you cross an area as many times as you want/can and create a mesh of possible paths through it...

My original idea was to alter my copy of eq2harvest to find a way to stop using moveto.iss to avoid it getting jammed against rocks/ zone walls etc and it sort of developed from that.

 

[curtsey]

Crafting Pathing Issues

I have been having horrible pathing issues in Freeport in the crafting zone doing general crafting and doing writs as well.

It used to work perfectly 2 days ago or so and now I can't even find the path to the crafting tables.

I understand that there was an update and now there is a pathing option under the options tab. I have modified the default 1.5 from 0 to 99 at various increments to see if would change anything but I am still having problems.

The new "Fix" does not allow me to find the writ giver correctly, the broker, nor the fuel merchant.

Now I can't even do generic crafting where I just check the buy fuel option.

Can we have the Crafting Bot version back that worked 3 days ago please? I didnt have any problems with that one!

 

[wired203]

Pathfinding

Mycroft what you are suggesting sounds similar to the A* pathfinding found in game engines? If that's what your looking to do the OOOO I WANT. Would definatly cut back the stickiness of harvest boting, and if you could make it learn where the bad spots are it would be even better.

Would be a ton of work to implement though.

 

[Pygar]

We've experimented with this several times and never ended up with something that was ready for release.

You should try to talk to ownage about it as he did more work on it than anyone. If I catch him, I'll see about getting what we worked on previously added into the experimental tree on the SVN.

In theory its a great navigation system. The devil was in the details, significant time is spent mapping and refining to get something that really works, and the absence of colision detection in isxeq2 was making automapping a real issue.

I don't want to discourage you though, if anyone every really got this working well, it would benefit all of our scripts.

 

[mycroft]

so , this is the premise...

An area mapped out - O is a mapped region linked to all ajoining regions making a mesh.

X is a harvesting node
1 is a region with an obstacle
* is the Player..

ABCD

OOOO A
OXOO B
OO1O C
OOO* D
OOOO E

Player scans for the node , heads from region (D,D) towards (B,B) , gets stuck on the obstacle at (C,C) and the connecton between (C,C)->(B,B) and (D,D)->(C,C) will be severed so the lavishnav will not attempt to use that route again.

If the region at (C,C) contains many obstacles then eventually all the connections to that region will eventually become severed , in effect isolating it...making the scripts avoid that area.

 

[Pygar]

No I follow you. We started down this path about 18 months ago, and I forget the exact problems we had.

One, regions have to be VERY small to work out, but it might have been elevation changes causing problems with plotting solutions. That and the shear amount of time to build good paths.

Having to use a small region size meant spending lots of time mapping regions such that the nodes would be found to exist within an allowed area.

I don't want to discourage anyone from this path though, so don't take anything I commenting too seriously

 

[mycroft]

No I follow you. We started down this path about 18 months ago, and I forget the exact problems we had.

One, regions have to be VERY small to work out, but it might have been elevation changes causing problems with plotting solutions. That and the shear amount of time to build good paths.

Having to use a small region size meant spending lots of time mapping regions such that the nodes would be found to exist within an allowed area.

I don't want to discourage anyone from this path though, so don't take anything I commenting too seriously

I know what you mean , I've been experimenting in Sinking Sands , so far I've got a script that auto-plots regions and their connections , if it gets stuck then it's disconnecting region connections.

I need to find a way to remove regions that are isolated so the region file doesn't get too large.

My main problem is the lack of examples to look through and the Lavishnav wiki isn't exactly self explanitory.

 

[mycroft]

I know what you mean , I've been experimenting in Sinking Sands , so far I've got a script that auto-plots regions and their connections , if it gets stuck then it's disconnecting region connections.

I need to find a way to remove regions that are isolated so the region file doesn't get too large.

My main problem is the lack of examples to look through and the Lavishnav wiki isn't exactly self explanitory.

Yep , spent hours on this today and came to the same conclusions , to really make it work I had to make the regions REALLY small...

The script then had problems getting to the nodes and mapping was a real pig , I've put it in my 'someday' pile for when when I've got a lot more time , I never know I might have one of those 'Eureka' moments and be able to make it work.

Perhaps Lav will update his Lavishnav wiki one day too so it's easier for me to more fully understand it. :dazed:

 

[vxjester]

just an idea

from reading this thread. I'm not very good with the programing side of things. but it sounds to me like your trying to something along the lines as open-bot for wow did. like with the harvester bot it's basically point to point. what open-bot does is it moves around in one area within some limits. you could map the whole zone with it then let loose the bot and it would find it's way around the zone. the web site is www.open-bot.net

 

[Pygar]

several of the wow bots use lavishnav.

The distinguishing factor I found was they had LoS checking point to point. This really allowed them to use larger region sizes and adjust movement more easily.

 

[mycroft]

Yes , the major stumbling block for an auto-map script unfortunately is the EQ2 client and data itself.

It really doesn't have/receive the data needed to easily automate the process.

Just as an minor example Vanguard has more options/data available to the client so Ama was able to add more options to ISXVG , making the scripting of mapping an area easier to work on.

So we're stuck with what we have , I'm still tinkering with it in-between other projects and have several ideas that seem to be feasible , but may take a little while to actually code.

It will be a lot more hands on than I wanted it to be when actually mapping an area , but eventually it will produce a mapped area of various region sizes with the 'no-go' parts (zone walls , buildings , trees, etc) marked that can then be used in any script.

 

[Pygar]

Yeah, I got maybe 30% of antonica done when I futz'd with it. I know exactly what you mean.

 

[gp1001]

Yes , the major stumbling block for an auto-map script unfortunately is the EQ2 client and data itself.

It really doesn't have/receive the data needed to easily automate the process.

Just as an minor example Vanguard has more options/data available to the client so Ama was able to add more options to ISXVG , making the scripting of mapping an area easier to work on.

So we're stuck with what we have , I'm still tinkering with it in-between other projects and have several ideas that seem to be feasible , but may take a little while to actually code.

It will be a lot more hands on than I wanted it to be when actually mapping an area , but eventually it will produce a mapped area of various region sizes with the 'no-go' parts (zone walls , buildings , trees, etc) marked that can then be used in any script.

Mycroft, so are you saying that when mapping an area you only map the obstacles and anything else that is not mapped is considered traversable?

 

[Pygar]

No, you have to map the traversable regions with lavishnav. Your creating the space you can move thru. You then break region connections when you reach a colision point.

Eventually you get some orphaned regions cause you've run out of connections between them.

 

[mycroft]

Ok , the script so far..

The UI has 8 tickboxes , each a region size.... from small (just enough to walk through a narrow gap , almost a single step) right though to Massive (Basically the 1/5th the width of antonica).

User selects the size of a 'region' and as the character traverses a zone and reaches that distance from the previous region (mid-point of the previous region) another rectangular region is created of the same size and a link between the 2 is created.

Any region bigger than the smallest is then automatically populated with smaller (box) regions , Z axis is always the same height at this point.

All the box regions are linked so the 2nd smallest rect region looks like this initially.
---------
|O-O-O |
| |\| /| |
|O-O-O |
| |\| /| |
|O-O-O |
---------

Next time the character moves through the box regions the script 'updates' the Z axis values to match the actual height of the character.

There is a button on the UI that when pressed will mark the current box region as avoid, the current box region is then removed and all links to it removed.

(basically the user marks his own obstacles , I tried automatically marking them as a script moved the character and got stuck , but it wasn't very good at it and caused all sorts of problems)

So clicking the button when in the middle box region would effectively isolate that box region making any Lavishnav movement index ignore that region.

I'm working on an option where the user presses an 'North / South / East / West edge' buttons and wherever the character runs from then on all box regions from there to the furthest Compass points in that direction are removed until the button is pressed again.

Hopefully by re-iterating through the smaller box regions to find the most distant X and Y values I can then shrink the larger rectangular regions to match the furthest X and Y values.

Doing it this way meant I had to name all the boxes etc using a formula instead of auto (Which is a shame), not the most elegant solution.

It's a lot more manual that I wanted it to be , but it seems to be working (so far).

 

[mycroft]

Given up

After 4 solid days working with this idea I've given up on the above version of the script , the maps were becoming too large and the script had major problems dealing with all the various region alterations I was asking it to do.

The difference between the amount of information needed compared with the amount of in-game data available to the script was just too large.

Instead I'm working on a varient of the existing eq2harvest script , it still uses a slightly altered moveto.iss (added one function and function call) to move between nodes etc.

1) you map regions to travel along, rectangles 40 x 40 are mapped, you can put points within any of the regions you map as you go along.

2) as you move along those regions , smaller (10 x 10) boxes are added.

3) if a node is scanned , the script checks to see if it's within a box , if it is and a route to that box is known then it uses lavishnav to get there , it then re-routes itself back to the destination point and carries on.

4) If the node is not in a box but in a region then it uses moveto to try and move directly to the node , mapping extra boxes and links between boxes as it moves.

If it is blocked for any reason then the current box it just added or entered is marked as avoid.

5) If the node is outside any known region the script uses lavishnav to move to the closest box/rect region then moveto is used to reach the node and another (40x40) rectangle region and boxes are added where needed.

Over time a mesh of allowed boxes and connections for that area will be automaticallty mapped and hopefully the direct brute force method of reaching a node will be used rarely.

 

[wired203]

Mycroft,
Have you taken the chance to look a the sphere instead of box navigation. Back when I played Vanguard and followed those forums below I recall their craft script moving over to spheres as they were smaller to code and were easier to calculate.

Forgive my noobness if that nav is completly unavailable in isxeq2.

 

[Pygar]

Mycroft,

My only request is for you to externalize the entire mapping, navigation, and movement code to an external library, so that if you do get this working at an acceptable level, we can more easily integrate this into other scripts.

-Pygar

 

[mycroft]

Mycroft,

My only request is for you to externalize the entire mapping, navigation, and movement code to an external library, so that if you do get this working at an acceptable level, we can more easily integrate this into other scripts.

-Pygar

I'm trying :yea: , I'm hitting the same 'brick walls' you did though which is Z axis problems , lack of data available from the client....etc...

Still trying to working around it though...

I just wish Innerspaces option to bind a key and force it to be held down had been added instead of 'for future development' , that would make life so much easier...

 

[coolman]

the open bot for WOW is a great script. Hope they could write one for EQ2, although I know it will never happen.

 

[Pygar]

It can't be ported to eq2, cause functionality it is built upon does not exist here.

 

[mycroft]

It can't be ported to eq2, cause functionality it is built upon does not exist here.

One of my probems right now is making the character being moved move between region smoothly without missing the destination box.

The 'boxes' in each 'rectangular region' have to be small enough to ensure accuracy in movement , using a similar system to moveto.iss the movement between them is jerky because of the short distance involved.

By adapting the system to work using box regions instead of exact co-ordinates the character sometimes over-runs the destination box because of the run speed of the character and this causes tracking problems....

I've tried hitting the screen and shouting at the PC , but nothing helps so far...

 

[wired203]

Just a question really on the base theory that might reduce the amount of data logged, would it be possible instead of 1000's of regions to just re-use some of the bad node code to calculate bad locations aka stuck, then just run a calculation to see if there is said obstruction between point a and b?

Then region it to larger regions so it's a not calculating a whole zone at once.

Just shooting out idea's I really haven't looked at the limitations of isxeq2 yet (really should someday soon) to know exactly what is or isn't exposed.

 

[mycroft]

Just a question really on the base theory that might reduce the amount of data logged, would it be possible instead of 1000's of regions to just re-use some of the bad node code to calculate bad locations aka stuck, then just run a calculation to see if there is said obstruction between point a and b?

Then region it to larger regions so it's a not calculating a whole zone at once.

Just shooting out idea's I really haven't looked at the limitations of isxeq2 yet (really should someday soon) to know exactly what is or isn't exposed.

I originally tried this idea, the problem was the limitations of EQ2 data available and Lavishnav data querying...

What I would REALLY like is this...but I'm struggling to come up with code create a mesh to match , there is just no way to check an area around a character , say 'hey' there is an obstacle there , I'll reduce the region size to avoid it from the data in EQ2..

Unless you create a mesh map manually...

http://www.lavishsoft.com/wiki/index.php/LavishNav:Avoidance_Comments

 

[Amadeus]

What I would REALLY like is this...but I'm struggling to come up with code create a mesh to match , there is just no way to check an area around a character , say 'hey' there is an obstacle there , I'll reduce the region size to avoid it from the data in EQ2..

Collision detection is not a part of isxeq2. I've searched for it several times and it was never easily obvious ...perhaps I'll look again at some point, but I wouldn't bet on it.

 

[mycroft]

I actually coded a script that knew where it was in a set of regions.

If it hit an obstruction it knew what to change the x1,z1 / x2,z2 co-ordinates of that region to based on the heading of the character and if the character was heading into or away from the center of the region..

So the region size started large and varied automatically.

Only trouble was I still started to have problems with connections between regions.

I may leave this to minds more used to regions and co-ordinate mapping than I am...

 

[v01d]

The client itself certainly knows what's navigable and what is not. It's definitely not doing a server side check when you hit a rock too big to walk over. Supposedly there is a simplified zone mesh in the client .vpl files (.hit file) used for collision detection. The ideal would be to use that information to generate the lavish nav file. Also, moveto is not a good choice for navigation as it is only intended to get you from one point to another. Calling moveto repeatedly to move through a series point causes you to start and stop and each one like what you see in eq2craft nav (bot alert). The closer the points the more dramatic the effect. I personally use what is basically a polymoveto given an array of points which allows for continuous/fluid movement through a series of nav points without start/stop at every point.

 

[mycroft]

The client itself certainly knows what's navigable and what is not. It's definitely not doing a server side check when you hit a rock too big to walk over. Supposedly there is a simplified zone mesh in the client .vpl files (.hit file) used for collision detection. The ideal would be to use that information to generate the lavish nav file. Also, moveto is not a good choice for navigation as it is only intended to get you from one point to another. Calling moveto repeatedly to move through a series point causes you to start and stop and each one like what you see in eq2craft nav (bot alert). The closer the points the more dramatic the effect. I personally use what is basically a polymoveto given an array of points which allows for continuous/fluid movement through a series of nav points without start/stop at every point.

I would be interested to see the code you use for this , how do you check for agro using this type of movement?

 

[mycroft]

Ok , I have a working script , it maps regions (variable sizes) , connects all surrounding regions to the region it just added / passed through and if it hits an obstacle then it reduces the size of the current region so that blockage is totally avoided in future.

Needs lots of work and tidying up before I release a library of the functions though.