runtime error: Cannot read null.HP
proc name: Attack (/mob/PC/verb/Attack)
usr: Miller (/mob/PC)
src: Miller (/mob/PC)
call stack:
Miller (/mob/PC): Attack(null)
wtf does this meen?!?!? I think it has something to do with the enemy being killed right when i press attack but dont make fun of me if im way off plz help me I think this is scaring people off lol.
ID:174685
 Jul 25 2003, 7:33 pm
|
|
Mob/PC/verb/Attack(mob/M in oview(1))
if (!M) return if(usr.weapon == null) sleep(5) else usr.overlays -= /obj/overlay/sword usr.overlays += /obj/overlay/swordattackoverlay sleep(5) usr.overlays -= /obj/overlay/swordattackoverlay usr.overlays += /obj/overlay/sword var/hitter = STR * SPD var/hit = DEF * SP/2 var/random = rand(1,LUCK) var/damage = hitter/hit * random M.HP -= damage M.Death() thats the new code still doesnt work though it was the same but without the if (!M) return. plz help. | |
okay, chris, that is bad coding etti... manners. YOu see, !M doesn't explain to a reader very well.
Use if(!isnull(M)) //combat code goes below here... else return it may not fix your problem, but it is easier to read. | |
Ter13 wrote:
if(!isnull(M)) The "else return" bit there is completely useless. It will return anyway; it's at the end of the proc. =P Also, a much better way to say "if(!isnull(M))" is "if(M)". Shorter, probably slightly faster to execute, and easier to understand. I prefer using if(!M) return anyway, because it means you don't have to indent the rest of the proc. I hate horizontal scrolling, and I don't want to have to break off lines in the middle to avoid it scrolling horizontally. There's no need to impose your weird coding style on others. =P | |
Well, if you'd shown me this code before I would have been able to fix it right then and there. =)
Your problem is the sleep(). Things can happen during sleep()s; in this case, while your verb was sleep()ing the mob died. Put the "if(!M) return" check just before the line "var/hitter = STR * SPD" as well. Also, I hope you're aware that sleeping won't prevent the verb from being called again during the sleep; you can still attack as fast as you want with that code. If you want to restrict attacks to once every half second, search for demos and posts on the subject. | |
I know it may be easier to write, but it's not easier to read. For most people, reading the words isnull(M) is easier than !M usually people just starting out are a little better off using the proc. I did not say it wa more efficient, I just said that by the programming theory taught at business level training institutes covers most things. THough BYOND is not covered at business institutes, it's syntax is not unlike C++, C, and Java's, and by these standards, !M is considered less favorable to isnull(M).
| |
Ter13 wrote:
I know it may be easier to write, but it's not easier to read. It is for me. For most people, reading the words isnull(M) is easier than !M We were talking about !isnull(M) and (M), actually. =) Personally, I just find !isnull(M) confusing. "Is M not null"? Couldn't I just say "If M" and leave it at that? =) | |
it'ss be easier to toss another if(isnull(M)) return before he removes the overlays, if it is already null, then it won't need to continue.
| |
be it that it is redundant, and I see your point, higher programming principles and techniques state that the most obvious method is to be taken, and "not M" isn't as detailedly obvious as "not is null M"
Your method is right for you, while I follow professional techniques which make my code lengthy, but easy to read, and easy to debug. I never said right or wrong, I said it is considered better. (in a business enviornment, which I consider my desk to be when I program.) | |
That's EXACTLY what I was trying to avoid. Just think about it for a second. If he adds the attacking overlays and doesn't remove them, the character will be walking around with its sword held up in the attack position. Not what he wants, I would think. =P
| |
woah, it's late here, 2:30ish, I made a mistake, I'm not perfect... I thought the overlays were an attack animation going onto the target, so he wants to add the if(..) return after the removal of the overlays. However, I see no purpose to them being there if the player can still move freely. Anything else I missed?
| |
You reply too fast... anyway... =)
Ter13 wrote: be it that it is redundant, and I see your point, higher programming principles and techniques state that the most obvious method is to be taken, and "not M" isn't as detailedly obvious as "not is null M" But "Not is null M" is just like... what the? =P Your method is right for you, while I follow professional techniques which make my code lengthy, but easy to read, and easy to debug. I never said right or wrong, I said it is considered better. Considered better, is it? More professional, is it? Which professionals did you consult on this? Just yourself? Yeah, thought so... =P The way you do it, your code becomes: 1. Longer. 2. Possibly slower. 4. HARDER and more confusing to read (see above) 5. Harder to debug, because the logic is more complex. Which does a computer find simpler? A simple true/false boolean check, or a check on a logical not preceding a proc that effectively works like ANOTHER logical not? (If you noticed there was no 3, well done. Give yourself a cookie! =) ) | |
Ter13 wrote:
woah, it's late here, 2:30ish, I made a mistake, I'm not perfect... I thought the overlays were an attack animation going onto the target, so he wants to add the if(..) return after the removal of the overlays. However, I see no purpose to them being there if the player can still move freely. Erm... what? =) Anything else I missed? Not that I noticed... hehe. | |
If you take any programming classes you would be lectured for days on this, I almost failed because of my attitude for the order... that is, until I had to debug a three-hundred line progtam in java. Three hundred is not so bad, is it? Try doing it when it's all jumbled, and there are no notes?
Enjoy! I never forced you to conform, don't take offense, I merely offered a suggestion, I recognize your arguments as valid, but your argument that they are harder to debug? Wrong, you want to do as little thinking as possible when debugging, if the function call is very verbose, it is easier to figure out what it does by logical deduction. | |
*snicker*
sorry I'm such a jerk, but it's how I am, man, I don't lay down for anybody, I apologize from time to time, but I don't give up, my way is right until I decide it's wrong, that's how it is, that's how I've always' been, doesn't mean it's right, doesn't mean it's right for everyone, take what you will and leave me be, that's my logic. I'm just stubborn | |
Ter13 wrote:
If you take any programming classes you would be lectured for days on this, I almost failed because of my attitude for the order... that is, until I had to debug a three-hundred line progtam in java. Three hundred is not so bad, is it? Try doing it when it's all jumbled, and there are no notes? I've taken all the programming classes my school offers, and I've never ONCE been lectured on matters of style. =P As long as you don't have procs all on one line and crazy things like that, and you know what the java program is supposed to do, it shouldn't be too hard... but then, I didn't see the source code, so I could be wrong. =) I never forced you to conform, don't take offense I'm not taking offence. It's just that you're wrong. ;-) I merely offered a suggestion, I recognize your arguments as valid, but your argument that they are harder to debug? Wrong, you want to do as little thinking as possible when debugging, if the function call is very verbose, it is easier to figure out what it does by logical deduction. "you want to do as little thinking as possible when debugging" - exactly! When debugging, I try and "think like the computer". It's easier to do that the fewer steps there are. if(!isnull(M)) involves three steps: (1) Is M true (non-null)? (2) Reverse your answer for #1. (3) Reverse your answer for #2. However, if(M) involves just one step: (1) Is M true? That's it. If it is more verbose, that implies more instructions (especially in the !isnull(M) case). If there are more instructions, there are more logical steps to follow, which makes logical deduction harder; and debugging is mainly logical deduction. Ergo, verbose code is harder to debug. Edit: Anyway, let's get off this newbie's topic. We're probably confusing him. =) | |
OK thank you it worked. thanks for all the help on this.
| |
This can occasionally happen with verbs. Just check to see if the argument is true before doing the attack.
EXAMPLE ONLY:
<code>mob/verb/attack(mob/M) if (!M) return // attacking stuff goes here</code>