![]() Aug 2 2005, 8:57 am (Edited on Aug 2 2005, 9:03 am)
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.
|
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. |
You just changed your argument [link]
|
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.
|
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. |
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. |
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.
|
Justin Knight wrote:
DeathAwaitsU, you're just a moron. 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. |
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 |
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. 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." |
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.
|
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(). |
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) 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? |
-_- 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. |
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? |
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() Basically, if you have a pistol in your inventory it ignores the distance with it. |
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? |
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 |