What are you working on? v1

[miceiken]

Well that is a shame. Im looking at flying navigation, and im trying to find a "good" way... but adding Z + modifier is just ugly... You still end up flying "around" rocks.

I agree, eventually I will move on to something else that is much better. Truth is I didn't really care about the gatherbot, right now I just want to extend my framework. It was more of a demonstration of how simple it can be :P

Pic related:

Added functionality to open forms from outside the STAThread, also demonstrating the API.

[-Ryuk-]

That's cool, btw what language is your pc? I can't inject my bot without it screwing up on none-English systems


[[Sent from my iPad using Tapatalk]]

[miceiken]

My win7 setup is in english, but I use the norwegian keyboard layout

[-Ryuk-]

Okay, on my laptop it's English & English, but on my VM it's German & English... Something is causing a stack overflow and i can't see where lol


[[Sent from my iPad using Tapatalk]]

[boredevil]

Well that is a shame. Im looking at flying navigation, and im trying to find a "good" way... but adding Z + modifier is just ugly... You still end up flying "around" rocks.

you could try to smooth your path using raycasts. let´s say you want to smooth the next 3 path steps. raycast down for each, to get the closest hitpoint on z level. adjust the height according to this,
then raycast a tunnle with the size of your hitbox from curPos to path step 3. if no hit, great. else try if path to step 2 can be smoothed

that should hopefully make the path look a little bit smoother, without the need to have a full blown abstacle avoidance logic, as you just fall back to the original path if you can´t smooth it.

the problem about raycasts is:
1. the objects testet with flag 0x1 are only considered in raycasts if they are not too far away from your char/camera. for me 0x1 objects don´t get mapped if further than 12yards in my back, and around 50yard in front of the camera. so you may just try to smooth steps that are not futher away than wherever the limit is for you.

2. you will need to push out a lot of raycasts to not get stuck on small bullshit. depending on your machine that could be a problem or not.
i would setup a mesh of toonheight * toonwidth with a precision between 0.2 and 0.5 and raycast the shit out of it.
on my i5-2500k for example. doing 4k raycasts every frame brings fps down from 140 to 18. but just doing like 2-4k every second or 200per Frame is pefectly fine.

[gononono64]

I'm working on a giant quest bot and database. Not too much to show off right now but a bunch of strings and number but it should be fairly impressive once i get it done.

[PyGuy]

I saw Mikko Mononen's blog about Loose Navigation Grids and decided to give it a shot. The part that he didn't cover in the code posted with that blog is the actual grid navigation. Below is a screenshot from that test that shows a 256x256 grid running with one dynamic object in the middle.



The black lines are the inaccessible regions. The blue circle is the dynamic object (think a mobs aggro region or a pool of water). The redish blocks indicate which cells were visited by the pathfinder and the cost to reach them. The green line represented the path that was found.

Dynamic objects use a cost-based function, which could allow the path to go through the region if that's truly the shortest distance (though you can set the cost to infinity, providing an inaccessible region).

The path-finder I used is an implementation of a Theta* algorithm.

With the test app, I recalculate the path for every frame. In this test the average time spent in the path-finding library was about 10ms(PentiumD 2.8GHz), which isn't bad for such a large grid. That's not something I'd want to run every frame in a real app, but it would be possible to run every second or so (especially on better hardware). This test wasn't too bad on time, but some take an average of 50ms if one of the inaccessible areas creates a local minima that it has to find its way around.

Mikko suggested that a 64x64 grid would be about right for most apps, but I'm not so sure. If a WoW character is 0.6 units big, you would have to use a cell size of 0.3 or 0.2 or you couldn't get through doors, right? A 64 cell grid would only be able to pathfind for the 12.8yd near a character, which isn't even enough for many mobs aggro radius. A 64x64 DOES run fast enough (0.7ms / call) that you could call it several times a second without killing performance, so maybe that would make up for not being able to look ahead very far.

Next up: Figuring out how to store a 32,000 x 32,000 world rasterized down to 0.2 cells in something less then 2TB. Most of that space is empty so a good quad or oct-tree implementation would certainly help in partioning and searching, but there's no way it fits in memory.

Edit: The picture below is the original, and you can see it has two issues: (a) it isn't checking behind the start location (damn off-by-one strikes again) and (b) I was using distance-squared to avoid sqrt. While sqrt hurts speed, it also decreases the accuracy of the path and causes more cells to be tested.

[namreeb]

To make an entire continent's mesh fit into memory, I performed a flood fill removal of unreachable mesh regions. Combined with a GUI to render the mesh and terrain, it is also a very effective way to look for gaps or bugs in the mesh.

[-Ryuk-]

Here is a little sneak preview :P

My Co-Developer has been working on this and its now in a (semi)working state.



The picture doesn't tell you much, but this is our Flying Navigation system.

Basically it uses traceline to find a good path(The drawing is just for debugging), and then continues to search for a faster/better path.

The performance hit using this method is tiny... On my really bad(4 year old) laptop, that doesn't even reach the minimum specs for WoW(but its still playable for some reason) I drop from about 15FPS to 14FPS. If we remove the drawing the FPS stays at 15.

This method can navigate around trees & floating rocks. At present its handled everything we have thrown at it.

[J0llyGr33n]

Here is a little sneak preview :P

My Co-Developer has been working on this and its now in a (semi)working state.



The picture doesn't tell you much, but this is our Flying Navigation system.

Basically it uses traceline to find a good path(The drawing is just for debugging), and then continues to search for a faster/better path.

The performance hit using this method is tiny... On my really bad(4 year old) laptop, that doesn't even reach the minimum specs for WoW(but its still playable for some reason) I drop from about 15FPS to 14FPS. If we remove the drawing the FPS stays at 15.

This method can navigate around trees & floating rocks. At present its handled everything we have thrown at it.

Art at its finest in my opinion.

[-Ryuk-]

Art at its finest in my opinion.

Haha! Ill print this on canvas and display it at the next art show :P Its sure to be classed as "modern-art" and sell for a rip off amount :P

[SpikedCola]

I've been working on a little enchanter-bot that I can let loose to level me up



It's not quite as cool as any of the stuff you guys are working on.. Truth be told, it's my first real adventure into memory editing. But it's been a lot of fun, and I've learned lots so far!

[Neer]

SpikedCola, thats actually quite an interesting thing you have there
+rep for epicness

[mrdennis87]

Well I currently I am working on my own bot, for bg's, or farming.. One more thing to figure out before it's finished I am using Visual Basic 6 to create it, and it's been working pretty good so far. It would probably be easier to make a fishing bot I suppose ? haven't tried lol hardest part is going to be making my toon find waypoints in the map after combat

[adaephon]

hardest part is going to be making my toon find waypoints in the map after combat

Hardest part is going to be forgiving yourself for programming in VB 6