In response to Ol' Yeller
usr already works, you guys just like arguing about it. Like I said before, usr is mentioned hundreds of times already. Replacing the hundreds of times it's mentioned with m is impratical. I'm not the main coder for this, i'm only doing a few things.
In response to Justin Knight
Yes, but you could fix what you have, couldn't you?
And I didn't say you had to replace them all, just the ones in the procs.

Also, you won't get any help unless you show that you are willing to accept the problems that people do point out. Once you fix them, it will be more likely people will help you fix the rest of the code.
In response to Justin Knight
You just changed your argument [link]
In response to Jamesburrow
Hazman was the only one that actually helped me with my problem. You guys are too concerned with the usr var and the original coder's use of the : operator.
In response to Justin Knight
You just don't get it do you?

[link]

If you do all that we can stop the crazy argument. Why are you so bent on using usr and not changing everything yet have time to type up all this crap? If you don't want to change it according to what we want ask your thread to be closed, or preferrably deleted.
In response to DeathAwaitsU
DeathAwaitsU, you're just a moron.

I haven't bothered to try and understand your problem (I only skimmed through it once) and really have no want to see what the code is doing but I noticed certain mistakes within it.

YOU DIDN'T BOTHER TO UNDERSTAND THE PROBLEM. YOU JUST STATED STUPID 'MISTAKES' IN THE CODING.
In response to Justin Knight
How does that make me a moron? If you post in code problems your coding will be constructively criticized. You're the moron for not following any of it and arguing with about 4 developers all giving roughly the same advice.
In response to Justin Knight
Justin Knight wrote:
DeathAwaitsU, you're just a moron.

I haven't bothered to try and understand your problem (I only skimmed through it once) and really have no want to see what the code is doing but I noticed certain mistakes within it.

YOU DIDN'T BOTHER TO UNDERSTAND THE PROBLEM. YOU JUST STATED STUPID 'MISTAKES' IN THE CODING.

When you post in Code Problems, the basic mistakes will genreally be corrected first. If you cannot assept the fact that they are mistakes, people generally won't help you.
Thats how it works. You either change the code and then get the help you need, or you are universally labeled as a 'noob' and people will prefer not to help you.
These same people are willing to give you second/third/fourth/fifth/etc chances. Eventually though, people will ignore you until you begin to realize that you need to accept the help given if you want to continue to recieve help.
In response to Justin Knight
Ok, this topic was so long that I forgot my main point -_-
But I do remeber one thing about the : operator =p

There is a difference. A "." operator is used to "access the procs and vars of a prototyped object". When the ":" operator searches for the procs and vars in all child types.

I would have been able to help you more, but I forget what I was gonna say >_<. Thats what you get for argueing =p
In response to Jamesburrow
Jamesburrow wrote:
When you post in Code Problems, the basic mistakes will genreally be corrected first. If you cannot assept the fact that they are mistakes, people generally won't help you.
Thats how it works. You either change the code and then get the help you need, or you are universally labeled as a 'noob' and people will prefer not to help you.
These same people are willing to give you second/third/fourth/fifth/etc chances. Eventually though, people will ignore you until you begin to realize that you need to accept the help given if you want to continue to recieve help.

Is this your approach to solving everyones problems? It's not a good way, because my 'mistakes' weren't mistakes. The way it was coded, it works, bottom line. The 'mistakes' in my coding are just 'the way you like to do it so I have to do it that way as well'. You guys shouldn't approach problems that way, it's dumb. What if someone came up to you at work with a problem? "Hey I can't do this, can you show me how? I was doing this and had a problem with this one thing." "Oh man your way is weird, do it my way and then I might want to help you. If you don't do it my way I will tell everyone else to hate you for as long as I work here."
In response to Justin Knight
Nobody insults Lummox, his coding is weird, and it works, very well, because it's -meant- to work, because it's programmed properly. Your's, on the otherhand, is not, it's chock full of : & usr abuse which is highly incorrect.
In response to Justin Knight
The reason this approach is often used is because these are the types of things that cause problems and are easy to spot. With these out of the way the problem is at least narrowed down (a lot of times it's gone completely). When people ask for help but ignore the advice it looks like they aren't willing to put any effort into their own problem. I'm aware that usr isn't always a problem in a proc, but it's definitely a liability for any project that is going to still be worked on and sometimes doesn't even work how it's described ([link]). So when you do listen to the advice you show that you care about your project, and it may help you at very little cost in making the changes.

About your mistakes, though, there are mistakes. I know some people like to program in a different style, but no legitimate style wastes time by doing absolutely nothing (variable -= 0). The if(variable == 1) stuff is certainly better than if(variable) in this case considering you want to check the actual result, though, I'm guessing the others weren't looking close enough at it (using prob(25) instead of creating another variable would be more my "style" though). Of course, using if(variable > 1) after it is wasteful and makes it's more trouble to update when you can just use else.

As for your main problem, I'd suggest using get_dist(attacker, defender) to make this more flexible. If the return value is less than two, then you pistol whip them. If not, you could base the probability of hitting on the return value of get_dist().
In response to Sniper Joe
Ok. I dont have the time in my life to read all of these posts. And Im sure the problem has already been solved with 72 posts! But wouldnt this work..

mob/proc/accuracy(M as mob)
if(M in oview(10)
probability(--)+usr.accuracy
if(M in oview(5)
probability(--)+usr.accuracy


I am pretty sure the indentions are wrong (100%) and I am also almost sure that-probability(--)- etc is wrong. But With a little toutch up, wouldnt this work?
In response to WindShock
-_- If only you'd had read the majority of these posts.

But I won't yell, just don't put usr in a proc, WindShock.
In response to DeathAwaitsU
Sorry. I am inpatient and didnt want to read it all. Pure lazyness. But hey, I got my post out, trying to put in, and thats all that matters...

Right?
In response to WindShock
Yup that's right! =)
In response to YMIHere
YMIHere, I understand your point exactly, but usr is only used in the text announcement. It wasn't the problem, I had to make an exception like so:
 mob/DblClick()
var/pistol = locate(/obj/items/pistol) in usr.client.screen
if(pistol)
if (!usr:alive || usr:handable == 1 || !alive)
return
else if (!usr:alive || get_dist(src,usr) > 1 || usr:handable == 1 || !alive)
return


Basically, if you have a pistol in your inventory it ignores the distance with it.
In response to Justin Knight
Yes, but they are "mistakes"
By insisting on keeping your usr abuse, you show that youd on't care about coding. And, if you don't care enough to fix the minor problems, why should we care enough to fix the bigger ones?
In response to Justin Knight
Justin Knight wrote:
usr already works, you guys just like arguing about it. Like I said before, usr is mentioned hundreds of times already. Replacing the hundreds of times it's mentioned with m is impratical. I'm not the main coder for this, i'm only doing a few things.

usr doesn't always need to be replaced with M; sometimes it needs src, sometimes a different var. However, even if it's impractical you change you must change it if it's being abused through use outside of verbs. That and the sloppy use of the : operator are really not acceptable and are going to get the code into trouble by opening a lot of bugs you can't easily diagnose.

Saying "Well, usr works, so I'll leave it alone" is basically saying "Well, I have no clue that this is going to bite me in the butt later down the road and I'm going to waste people's time trying to solve problems I could have avoided." If you're not the main programmer, find them and have them fix the usr abuse. With that sort of problem in your code it's 10× more difficult to debug.

Lummox JR
In response to Lummox JR
Isn't it about time this argument ends? It's taking up a whole lost of roon in Code Problems. I think everyone knows this person is too stubborn and this argument will, most likely, never be solved.

P_S
Page: 1 2 3 4