I want to make it so when a player attacks the way it attacks strays from the generic "One tile ahead" function that most games employ. Instead i would like to make it so it does say a sweeping fashion in which it does say a pixel range based on the weapon type.

E.g. Dagger 30 pixel, Sword 40 pixel, spear 55 pixel and in a sweeping fashion so an arc based on that pixel range.

I also want it so that the "weapon" extends over the generic mob which in this case would be 32x32 so that the weapon image represents the actual range so it doesn't look like a tiny 32x32 mob and weapon is hitting over it's generic range. aka the "spear" would actually be "over" the mob the player was attacking instead of stuck to the boundaries of the player. This would dictate that your actually hitting the mob

What are your thoughts on how to get this to work most effectively in regards to the pixels and the weapon displaying.

For reference sake i use Forum_Accounts pixel movement library which makes me want to incorporate the pixel range attacking more.

in a pixel based calculation using the libary would be great as it already adds variables and keeps track of them, you would just need to add a getpxdist proc. Seems pretty simple.

As far as the graphic overlay, i think personally I would make a 9x9 (96px x 96px) and put it on the mob centered. (with the icon objects, this would work now wouldn't it?)

Just use the attack verb to flick it to it's attack state. I would want to stay away from splitting and merging together a multi tiled attack just because it can look a little jumpy sometimes, especially with lag.
You can use the library's front(d) proc. It returns a list of atoms within d pixels of the front of the mob.

|mob|     |

The mob is facing right, so mob.front(d) returns the list of atoms inside the box whose width is d and height is the same as the mob's.

It sounds like you want something a little more complex than this, but you can take a look at the code for the front proc (in in the library) and see how it works. If you wanted to get a list of mobs inside an arc, you'd do something like this:

. = list()
for(var/atom/a in oview(1,src))
if(a is inside an arc of size d)
. += a

You just need to figure out how to decide if an atom is inside the arc.
In response to Forum_account
Im sure i can figure something out with whats already built into the library you have already added so much to it that it allows for alot of creativity and working around it to match what people may want to use.

Really more looking for an effective and clean manner of doing the weaponisation and mobs to match said parameters.
In response to Midgetbuster
If you're okay with the simplicity of rectangles, front() will work fine. It was intended to be used like people use get_step():

for(var/mob/enemy/e in get_step(src, dir))

for(var/mob/enemy/e in front(weapon.range))

If you do work on something more complex than rectangles for the weapon hit ranges, let me know (post on my forum about it). I'd like to include as many helper procs like this as I can in the library.
In response to Forum_account
I just heard from Amary (The guy who does some iconning and also the co-founder) that its more or less based identically on the pixels of the weapon itself.

So a spear would generally focus on a stabbing motion so say its a 50pixel stab range. and its say iunno 8 pixels wide. so that would be the hittable zone i guess

But a sword would be in a more sweeping fashion hence the arc.

So tldr a rectangle would probably work fine for spears but as for other things im not entirely sure its more along the lines of pixeling collisions
In response to Pirion
yea it would work that was pretty much exactly what Amar and me talked about when we wanted to do it this way.

I was just curious as to see if there was any other ways that may be more efficient.
In response to Midgetbuster
Midgetbuster wrote:
So a spear would generally focus on a stabbing motion so say its a 50pixel stab range. and its say iunno 8 pixels wide. so that would be the hittable zone i guess

Using the front proc, the width of the box is the width of the player. If you want different widths to the attacks you can do something like this:

pwidth = 50
pheight = 8

var/obj/weapon = new /obj/sword()
// position the sword object

for(var/mob/enemy/e in weapon.inside())

The atom's inside() proc (when passed no arguments) returns a list of all atoms that overlap its bounding box.

<small>Note: You'd need to set the pwidth and pheight of the sword based on its direction. If you're facing north or south, you'd want its pheight to be 50 and pwidth to be 8.</small>
In response to Forum_account
Yea i figured that having the parameters of the attackable zone inside the weapon for spears would do the trick.

i would say a rectangle would be fine for swords but i want the attack damage being dealt to represent the actual sweeping formation so the rectangle wouldn't work. although a circle would and ofcourse the code you supplied earlier does that

Do you agree with the other poster about using the larger overlay for weapons centered for the animation?
In response to Midgetbuster
Midgetbuster wrote:
Do you agree with the other poster about using the larger overlay for weapons centered for the animation?

Yes, I think that's a good way to handle the graphical effect.

If you're creating a separate object and using it's bounding box to figure out who gets hit, you'd also need to move that object every time the player moves. This could get annoying. If you want to use a helper proc like front, you can just use an overlay for the visual effect and call the helper proc to get the range.

Instead of using an object's bounding box to get the 50x8 range, you could make a proc like front() that takes a second argument that's the width of the region.
In response to Forum_account
Yea im not a big fan of using secondary objects that stick onto the main object i found it almost always causes problems during laggy situations.

So a helper proc would most likely be the easiest solution using the arguments defined inside the weapons to define the damaging zone