Navmesh X, Y Collision

Soo lately I've been working on the navmesh files and I used drew's edxNVMViewer for this. But I've got a little stuck right now.

For my project I'm using the nvm.h and nvm.cpp to load the navmesh file and I'm saving it in my memory. Everything goes fine and I get the correct Z position from the navmesh but I can't figure out how to get the forbidden area's in the navmesh.

Like when a character walks up a mountain it will stop at some points since there is a collision.

How am I able to get the lines where the character cannot walk.

And also what does the 3 zones do? I've created a little app which draws the fx1, fx2, fy1 and fy2 at the map but it doesn't seem to be the one which i'm looking for.

Here are pictures of the zones at the 170x99 region which is at the north east of jangan. I used this one cause it has a little mountain on it.

All zones, Only zone 1, Only zone 2, Only zone 3

[Only registered and activated users can see links. Click Here To Register...] [Only registered and activated users can see links. Click Here To Register...] [Only registered and activated users can see links. Click Here To Register...] [Only registered and activated users can see links. Click Here To Register...]

I don't see anything logic which looks like the forbidden area on the mountain.

Btw I have tried to compile edxNVMViewer but It crashes when I compile it. I don't know if it has something to do with the sfml version but I hope anyone could help me with this:)

Thanks

Sorry I seemed to mess up some stuff and the zone3 kinda looks correct now so I guess that my problem is now solved.

Yea, those diagonal lines look wrong in the images.

I think the PK2 code used in that project broke. It's pretty old. You'd have to update the nvm viewer to use a newer PK2 reader code, such as [Only registered and activated users can see links. Click Here To Register...].

I was able to still get it to run, it just didn't have any textures since the data it loaded from the PK2 relating to the textures was messed up.

Indeed you're right the lines were mirrored but they are now kinda correct.
What I have to do right now is checking if the players are outside of the rectangle's but i'll take a look at some navmesh collision tutorials so I guess I'll be able to get this thing working right now.

I'll also take a look at the new pk2 reader code and update it in the project to make it work.

Thank you very much:)

But is the Z position important when the bot sends a walk command to the server? it would be only important for the client to sign where you stand, and the server needs it to be secure that the character isn´t buggy or in an forbidden area

Well I don't know what he is trying to create with this but for a bot you also need to have some kind of path finding if you want 100% auto walk. the z position is only important if you have the x and y position but you need the z position.

so if you know what the forbidden area is you can use some path finding algorithms to walk to any place at the map. and for those things you would also need the z position.

But let's take ibot for example it has those walking scripts which are just created by the user so you got the x y and z position which are all in the script and ibot simply sends it to the server and tada you got your character walking so you don't need all this stuff.

Autowalk would also work if you have a few scripts included, the bot just calculates wich one crosses the train area or walks near it so there is not a 100% autowalk. The ful autowalk would be very hard, forbidden area and objects where you can stuck... then you need a pixelanalyze that findes the roads to find a way where you cant stuck. mhm that is very hard.

now where is the z position part in an walkpacket? and how does it work clientless, there is no navmesh calculation

Well with drews nvm class it gets pretty easy to create such things.

Clientless just have scripts which the user have to create and the clientless just sends those values to the server and that's how the characters walk.

I guess that some bots do have the z position in their bot to walk around at the killing area but some of them only walk if there is a monster where you don't need any of the walking stuff since it's auto moving at that moment.

the movement packet doesn't contain the same data which the user can see at the screen.

The data in the movement packets looks like this:
Since all the navmesh files are splited in about 4,4k which is the amount of section which the game has you can check at what section the user is walking and check if it collides with something.

All you have to do is come up with some calculation which uses the zone3 of the exNVM class which checks if the user is inside a rectangle if i'm correct.

for the path finding you have some algorithm like A* so with A* you can create a autowalk function with the navmesh files.

but like you said there are still objects in it but they are in the bsr files if i'm correct which is also in edxNVMViewer so everything you basicly need to get a propper collision detection/autowalk is in that project.

Ok yes i saw this a few minutes after i wrote the last message =)

Now in an walkscript there are commands like this go(596,295) there is no Z position. do you want to say now that the bot valvulates with the navmesh and this bsr files the z pos? this is hard i never saw this in some codes. Btw whats the section?? X/Y this sounds weird.

Oke well i didn't know what that the x and y positions where saved like that but possibly they have extracted the z position from the files which gets loaded into the bot when it starts.

Oke so clearly you aren't in the whole movement thingy so I'll explain it a little bit.

The entire silkroad map is devided in sections this is to make things more efficient I guess since you don't have to work with the full x and y coordinates.

this: [Only registered and activated users can see links. Click Here To Register...]

is an image which a friend of mine created a while ago while he was working with the navmesh things. as you can see there are all those square blocks those are the sections which are arround jangan.

All the sections have the same size and they also have an addition x and y position which goes from 0 to 1920 for the x and y.

so actually there are 2 kind of x and y positions. the once which the player sees and the ones which are sended in the packets.

To fully understand these things you have to play arround with these things but if you take a look in the media.pk2 you can see a lot of files in the minimap folder which are a lot of ddj files. those are actually dds files but you have to remove the first 20 bytes to make them dds readable. but they all have a name like 168x97.ddj which means 168 xsection and 97 y section. Well this is the center of jangan with the npc's and that dragon thingy.

Every section has it's own .nvm file which is the navmesh for the collision stuff which can also be used for path finding so this way you don't have to work with a huge file but you simply check in which section the user is and then you can check for a collision.

I hope this clears some things up.

Why don't you both put a proxy between your client and the bot to put some "brightness" into this issue?

I think it just sends the z as 0...
And no, I'm not going to research on this :P

Yeah well that might be true. I'm also not gonna check it out since I don't care about what a bot sends for z position. If I would create a bot I would send the correct Z position and have some correct path finding in it.

As far as I know z is sent as 0 only outside caves. Dunno for Alexandria since I left the sro stuff about 5 months ago.

Quote:

Originally Posted by bootdisk Why don't you both put a proxy between your client and the bot to put some "brightness" into this issue? I think it just sends the z as 0... And no, I'm not going to research on this :P

That doesnt mater we have already our packet fragmentation

z is sended by the server and by client
i am not realy sure what the x and y sections are. but kevin made a very good view for this point.

Hmm I have one other question. How can I detect if for example a user or in my test the mouse cursor is inside the forbidden area?

I draw the zone3 at the screen so I have an good view of the whole collision thing. but the zone3 has x1 x2 y1 and y2 which is a line and the square which I tested weren't just 4 of those lines but one lines were a couple of lines attached to eachother so is there some kind of algorithm which can help with this or is it just unkown and does it needs to be reversed from the client?