In response to Cloud73
That's basically what I meant. =/
Also, oview() and view() default to usr.
In response to Ol' Yeller
Aaaahhhh.....this language is still confusing to me, so I misunderstood.
In response to Ol' Yeller
usr isn't my problem. I need a way to bypass the one-tile only working range for the pistol. Any ideas?

 mob/DblClick()
if(!usr:alive || get_dist(src,usr) > 1 || usr:handable == 1 || !alive)
return


How do I make it so it ignores the distance for the pistol?
In response to Justin Knight
...=/ I guess you didn't make this code yourself, correct? Anyways, I'll give you a hint:
Look up the procs you're using in DblClick in the DM ref
In response to Jamesburrow
What if your boolean ends up being two? if(var) still returns true, which is probably what you want. if(var==1) doesn't.

It lets you do things like this:

mob
var/stun=0
Move()
if(stun) return
..()
verb/StunSomeone(mob/m in view(5))
if(stun) return
m.stun++
spawn(20) m.stun--
In response to Justin Knight
No, it's used in a proc CALLED by DblClick(). There is a major difference:

What if you want npcs to shoot/pistol whip people? Well, suddenly you get " hits Bob with the pistol!".

You should be adding an argument.

To get at more of the silly mistakes in that code, why in all hell do you have m:hp-=0? Why set m:hp to m:hp-0? It doesn't do anything. 0 is the identity for addition and subtraction.
In response to Jp
Jp wrote:
No, it's used in a proc CALLED by DblClick(). There is a major difference:

That's more of a grammar thing than an actual coding problem.

What if you want npcs to shoot/pistol whip people? Well, suddenly you get " hits Bob with the pistol!".

You should be adding an argument.

If NPCs are added, I will deal with it then.

To get at more of the silly mistakes in that code, why in all hell do you have m:hp-=0? Why set m:hp to m:hp-0? It doesn't do anything. 0 is the identity for addition and subtraction.

That's really more of a reference thing for myself when i'm looking over the code, I see which does damage and which doesn't. As everyone has said, it does nothing, so stop bothering me about it. It's just for reference.
In response to Justin Knight
It's not just a grammar thing. Usr is perfectly fine in DblClick(), but even in procs called by DblClick(), you really shouldn't be using usr.

(I know, I know, I posted again)
In response to Justin Knight
Do you know what comments are? Better reference there.

If you know that you're probably going to have NPCs using those procedures, why write them so that only PCs can use them and then rewrite later? Do it right first.
You are getting repetitions of the shooting because view() procs don't work on rinigs or circles, they work on blocks. Using return at the end of the pistol whip section should help a bit. However, your third usage of view() is wrong - it needs to be in the form view(distance,centre). I think that if you put return at the end of the second block and view(4) for the last block the code should at leeast read distances properly.
My version of the code looks like this:
    pistol
icon_state = "pistol"
desc= "A standard 9mm pistol." //There is a perfectly good var, desc, that can be used in place of this.
var/fuel = 8
Harm(var/mob/Q)
if(Q in view(1))
sleep(20)
var/shot = (rand(1,4))
if(shot == 1)
view(8,Q)<<"<b>[usr] tried to pistol whip but [Q] dodged the attack!</b>"
var/turf/lol = Q.loc
for(var/mob/M in lol)
M.hp -= 0
M.Health()
if(shot > 1)
view(8,Q)<<"<b><font color = red>[usr] has pistol whipped [Q]!</b></font>"
var/turf/lol = Q.loc
for(var/mob/M in lol)
M.hp -= 25
M.Health()
return

if(Q in view(2))
if(fuel > 0)
var/shot = (rand(1,3))
if(shot == 1)
fuel --
view(8,Q)<<"<b>[usr] shot [Q] with [src] but missed!</b>"
var/lol = Q:loc
for(var/mob/M in lol)
M:hp -= 0
M:Health()
sleep(30)
if(shot > 1)
fuel --
view(8,Q)<<"<b><font color = red>[usr] has shot [Q] with [src]!"
var/turf/lol = Q.loc
var/obj/Misc/bullet/lol2 = new(usr.loc)
while(get_dist(lol,lol2) > 0)
sleep(1)
step_towards(lol2,lol)
del(lol2)
for(var/mob/M in lol)
M.hp -= 35
M.Health()
sleep(30)
else
usr<<"<b>*click*</b>"
return

if(Q in view (4))
if(fuel > 0)
var/shot = (rand(1,2))
if(shot == 1)
fuel --
view(8,Q)<<"<b>[usr] shot [Q] with [src] but missed!</b>"
var/turf/lol = Q.loc
for(var/mob/M in lol)
M.hp -= 0
M.Health()
sleep(30)
if(shot == 2)
fuel --
view(8,Q)<<"<b><font color = red>[usr] has shot [Q] with [src]!</b></font>"
var/turf/lol = Q.loc
var/obj/Misc/bullet/lol2 = new(usr.loc)
while(get_dist(lol,lol2) > 0)
sleep(1)
step_towards(lol2,lol)
del(lol2)
for(var/mob/M in lol)
M.hp -= 35
M.Health()
sleep(30)
else
usr<<"<b>*click*</b>"


As a side note, I also changed all of your :s to .s. There is a time and a place for :s, but it's not here. Also, I closed the html tags so that they wouldn't affect other output. I'm not sure if BYOND checks this anyway, but it's best to be on the safe side.
I also type-cast many of your vars. A type cast var is much more stable than an untyped one.
I do have some minor ideas for the code, as well. Instead of the while() loop you have, why not just keep the bullet moving then use Bump() to see if it hits something?
Also, why is it that there is more chance of hitting something further away from you than there is of hitting something directly next to you?
I suggest you also look up prob() (I think that's what the proc is called.
In response to Jamesburrow
In response to Justin Knight
I didn't bother going into the whole argument about my advice but Artekia was right in his first reply to you. And if you're editing someone's code then doing it right matters even more.
In response to Hazman
I use the aboutthingy var because it is already attached to an examine verb.

Like I said before, the guy who coded this used the : operator much more than the . operator. It is good to be on the safe side. What's a type cast var?

The bullet thing doesn't really work anyway,I just carried it from the other coding. I don't really know how to code the bullet like that.

There's supposed to be a higher chance of missing someone far away.

Isn't it supposed to be the same as fractions and probability? 1/2 chance of missing is greater than 1/4 chance or 1/3rd chance.

By the way, thanks a lot for your help, Hazman. I edited what was stopping it from working after a 1 tile radius but after view(2) it wasn't working. I didn't know what was wrong with the other coding.
In response to Justin Knight
Artekia knows exactly what he is talking about.

It's not that your code doesn't work so much as it is, its if you get used to doing it improperly you'll be stamping usr over all your procs and sooner or later it will bite you in the ass. You'll be posting on here again with another proc with usr abuse, and usr will be the problem that time, and you still won't listen. It's better to just fix it now, get used to doing it correctly, and prevent problems later.
In response to SSJ2GohanDBGT
Okay, i'm sick of people defending Artekia. I hope this will clear things up:

Artekia knows BYOND coding, but in this instance he has been rambling on about usr. usr is mentioned hundreds of times in this source code and has caused no problems for the game. NPCs are not an issue because there are none in the game.

You people feel the need to defend Artekia because he mentioned a valid points about usr, and I haven't seemed to say they are. Although, with this game his points do not prove any point, and this makes him look like he doesn't know what he is talking about. When I post about a real problem, he just ignores it, which supports my point that he doesn't know what he is talking about with this game.

Please, usr is not an issue for the game or the issue I posted about, so stop posting about it.
In response to Ol' Yeller
Ol' Yeller wrote:
That's basically what I meant. =/
Also, oview() and view() default to usr.

I read it somewhere (can't remember where....) that a change was amde a couple of versions ago so that oview() and view() would work in procs.
In response to Justin Knight
Justin Knight wrote:
Please, usr is not an issue for the game or the issue I posted about, so stop posting about it.

Even if it is not the problem, it is best to change it to prevent it from causing a problem.
Now, why don't you just use that M thing i was talking about? It will work and it will end this arguement.
In response to Justin Knight
He's helping you, and it is an issue. Usr abuse will turn into a game which will not function properly.
In response to Jamesburrow
mob
proc
test()
var/mob/m=new
usr=m
for(var/turf/t in oview(1))world<<t
for(var/turf/t in oview(src,1))world<<t
verb
test2()test()

Try that. =/
In response to Justin Knight
Lesson to be learned: You can't argue with stupidity. Nor can you teach those who do not wish to learn.

usr abuse is valid in your game. usr abuse is valid in any game, utility, demo, library, or otherwise programmed in DM.

What you mentioned before was like saying "Correctly using varaibles in my game isn't a problem". It's ludicrous. Hopefully you learn fom your mistake, but from the looks of it, that's not likely to happen.

I'm not going to present you with help in the future, regardless of how much you need it. Hopefully other people will follow after showing how you treat those who try to help you.
Page: 1 2 3 4