Yet another suggestion

[M_Frohike]

CMB,

Sorry if someone already brought this up.....

An option to have moving mobs leave behind breadcrumbs. This way, over a period of time, you could find where mobs *don't* go. This would greeatly help in pull spots to avoid adds or healing spots, etc. Click the option off and repaint the screen.

Does this have possibilities or is it lame?

M

(My first post here) :p

[MrDoh]

I have no idea how hard it may be to code, or what kind of resources it may require.
That being said, I personally think, if it's doable, it's a wonderfull idea!

I am currious though, would this be something you wanted on an individual mob, several mobs, or the whole NPC list, or??

Mr. Doh

[M_Frohike]

Originally posted by MrDoh
I have no idea how hard it may be to code, or what kind of resources it may require.
That being said, I personally think, if it's doable, it's a wonderfull idea!

I am currious though, would this be something you wanted on an individual mob, several mobs, or the whole NPC list, or??

Mr. Doh

Very good question. I originally thought all mobs by default. The screen would eventually look like a mess but you could zoom in and see the gaps in paths.

I say start simple (all mobs) and if it's easy, maybe allow a filter to the non-green cons, or maybe your alert filter (don't know how that would help).

M

[cavemanbob]

Could be interesting to see the paths the mobs take sometimes, I'll try and hack something up for this.

[gawker]

I've added in some code to do this. Just waiting for the patch fallout to test it out. Fairly simple to add in a history of mob points. Working on a filter now. My version does not try to draw a path, but merely paints history for all distinct reported mob positions.

[M_Frohike]

Hey - that was quick!!!

It doesn't necessarily have to draw lines. The underlying goal is to show where mobs have been. I anticipate that after a while, the map will look cluttered - which is good. Then you just zoom in a little and look for spots that are still bare. Hopefully accessable spots and not just water and moutain tops.

MYSEQ users will have to keep in mind PCs altering mob paths by pulling will exagerate the drawn paths.

Also, keep in mind that some mobs have hella aggro radius while others are so near sighted, they remind me of Mr. Magoo.

My question is - how do individual coding contribution get rolled into CMB's source? I'm definately new to this CSV stuff. :rolleyes:

Thanks people,

M

[cavemanbob]

For individual code contributions, just attach a diff of the modified files if possible or the modified files themselves with the modified bits marked and I'll add the stuff into CVS.

[Lyroschen]

It appears that mob position updates are based on proximity, now, so folks won't see mob position updates unless they are somewhat near them. If this is true, it may hamper the effectiveness of such a feature. That's what appears to be happening. Can anyone verify if it is or not?

[cavemanbob]

Mob update speed is based on proximity and AFAIK it's been that way for quite some time. I think it could still be useful to see where stuff paths in smaller areas like dungeons to map out where wanderers go or to find dead spots in larger zones where stuff won't path through.

[immortalsam]

It appears that mob position updates are based on proximity, now, so folks won't see mob position updates unless they are somewhat near them. If this is true, it may hamper the effectiveness of such a feature. That's what appears to be happening. Can anyone verify if it is or not?

yes, this is correct



I think it could still be useful to see where stuff paths in smaller areas like dungeons to map out where wanderers go or to find dead spots in larger zones where stuff won't path through.

problem is, you have to get within almost visible range to "see" the updates.. when seq was running, i would run towards something showing on seq, and it would "warp" to where it is currently, clearing out the area i was running towards. if i remember correctly, the circle around the player for seq defines the general max casting distance, and just a short range beyond that is the general visual range. and they seemed to warp just a short distance away from the circle. its like they put in a monster bubble where outside the range, player/mob updates arent sent to the client.. actually quite good for reducing lag, but hell on you if you want to decode the datastream and see where everything is.

[M_Frohike]

Originally posted by immortalsam
problem is, you have to get within almost visible range to "see" the updates.. when seq was running, i would run towards something showing on seq, and it would "warp" to where it is currently, clearing out the area i was running towards. if i remember correctly, the circle around the player for seq defines the general max casting distance, and just a short range beyond that is the general visual range. and they seemed to warp just a short distance away from the circle. its like they put in a monster bubble where outside the range, player/mob updates arent sent to the client.. actually quite good for reducing lag, but hell on you if you want to decode the datastream and see where everything is.

This explains another annomaly I noticed last night. I'm trying to round up 2 or more of the same mob type for kiting. I see their skittles already close to each other so that makes them good targets. But when I run towards them, the skittles will "warp" apart and I'm left with just a single pull.

Even with this "performance enhancing feature", I think having trails, breadcrumbs, whathaveyou might still be beneficial - just for a smaller area. Users will just need an education in how to use it.

M

[eq_freak]

I think its an excellent idea.

And about updates, its true that updates for mobs that are far away are alot less frequent, but they do get updated eventually.
Also if you have a mob targetted you will get more frequent updates for that mob I believe.

Especially in a zone such as PoEarth that have tons of roamers this would be a handy feature to pin-point semi-safe exp-spots.

Btw when in "breadcrumb" mode perhaps it would be beneficial to have each individual trail in a different color? That way you could tell the amount of different roamers that passes by your potential exp spot.

How I would do it:

Menu: Breadcrumb
- Breadcrumb mode (on/off)
- View static mobs (on/off)
- View trails (on/off) (you would turn this to off when viewing the roaming path for one particular mob)
- Trails as lines/points (a toggle of sorts)

Also it could be cool, that when you are in breadcrumb mode that the listview to left would switch to ONLY showing roaming mobs(aka not statics).

And then when you select one of these mobs its particular roaming path would be highlighted. Imo that would be super super cool :D (if in line mode, perhaps even with arrowheads on the lines, so you can see the direction of travel)

As for how to implement it, I am not sure. To be able to show individual paths, you would have to for each mob save every location it ever visits. I suppose you could simply have a list/map for each mob, and save new locs there every time it moves. Of course this would slowly gobble up memory, unless you check that the new location is not a previously visited one(but this is probably no big deal, a loc doesnt take a whole lot of memory storage).

[M_Frohike]

Some good ideas.

I particularily like the idea of having the ability to select a mob and see just it's roaming path.

But start simple. Turn on breadcrumbs and let the skittles leave a line behind them. Let it clutter up your display. Turn off breadcrumbs and clear / repaint the display. Toggle back on, start with a clean display.

After this works and is stable, add another feature - like the ability to track just one mob.

Cool stuff tho

M

[gawker]

Sorry. Got distracted. I will try to finish this up and post a diff.

Basic summary:

Menu item to turn tracking on/off

When mob is drawn add the point to a new mobtrail array (limited to x,y ints) if not already an element.

Draw the points before ground items and mobs.

Associating the point to a particular mob might grow the array too large, but you can certainly filter the additions to the array by mob id.

May have to limit the number of elements (history) in the array if performance becomes poor. I have not had a chance to try it out yet.

[gawker]

OK. Don't laugh. Here are my changes to the 1.12 client to add mobtrails. Nice little project to learn a little C#.

Don't try to run this on the same machine as the server. It impacts performance a bit when the feautre is enabled.

Added 3 menu items to options:

Show Mob Trails - Paints the collection of points with each screen update. Probably want this off most of the time. Turn it on to see the trails.

Clear Mob Trails - Will clear the array holding the points. Basically start over.

Collect Mob Trails - Start or Stop adding all new unique NPC x,y points (ints) to the history array. This allows you to keep the history you have collected up to now, and start collecting more later on.

Both adding points and displaying points impact performance. Maybe someone can come up with a better way to implement this.

[cavemanbob]

Thanks, I'll add it in.

[lostinspace]

Well, there is simple way to record mobs positions for 'roam tracking' without ANY hit on performance. Also, its possible to show tracks on map with only slight performance impact.

Additionally, good thing would be to show with different colors spots where mobs rarely go and spots where they often go.

Something like following picture. Bright red spots are where mobs are often (or stationarry), and range from dark yellow to bright red shows how often spot is visited by mob. You can recognize roamers path as red lines on map , and pulled mobs pathings as dark yellow lines .

http://easypichost.com/Dummy/poeartha.JPG

hmm... if picture do not show, try this link:
http://lostdummy.topcities.com/poeartha.jpg

Anyway, since I did this for my program, and I dont know how it is implemented for mySEQ, here is suggestion ( how I did it):

- make 2 dimensional array of 1500x800 bytes
- at start of map, divide max width of map into 1500 parts (call it DX) and max height of map into 800 parts (call it DY),
- whenever you draw mob, find in which square it belongs ( divide X pos with DX and add offset... basic math. same with Y)
- increment that byte in array by one (untill it reach 255)

This approach makes no noticeable hit on performance (only few arithmetic operations per mob are used).

When drawing, just do loop thru that 2 dimensional array and where value >0, draw square colored depending on value (like $00003000+ value). This will also reduce number of drawing operations.


You can notice that mob updates are more frequent close to player - either that, or south part of PoeA does not have roamers :)

[gawker]

Just noticed the mobtrail draw routine was inserted twice in the client.

Please remove one of them at your next update:

MapCon.cs

if (Settings.Instance.ShowMobTrails) {
foreach (MobTrailPoint mtp in mobtrails)
{
g.FillEllipse(whiteBrush, -mtp.y*(rawscale*scale)+(offsetx+offsetxg)-2, -mtp.x*(rawscale*scale)+(offsety+offsetyg)-2, 2,2);
}
}


if (Settings.Instance.ShowMobTrails) {
foreach (MobTrailPoint mtp in mobtrails) {
g.FillEllipse(whiteBrush, -mtp.y*(rawscale*scale)+(offsetx+offsetxg)-2, -mtp.x*(rawscale*scale)+(offsety+offsetyg)-2, 2,2);
}
}

[gawker]

I was using the same resolution as the mob drawing, but I see no reason not to reduce the resolution drawing on the trails. It will certainly reduce the size of the array. I also like the difference in the roamers and the pulled mobs. I'll try to get that in also.

I'll make the changes and post them here soon.

Edit:
I found something useful to fill my double post :-)

[Dedpoet]

I get it! A double post about something that's duplicated in the code! Bwahahahaha!

Sorry, slow day at work :-(