ID:149366
 
Many of my verbs are messed up.

mob/verb/Fire_Life_Gun(mob/M as mob in oview(20))
if (lifegun = 1)
if (usr.HP >= 10)
usr << "You shoot a blast of your own life at [M]!"
oview() << "[usr] engages [M]!"
var/damage = rand(10,30)
world << "[damage] damage!"
M:HP -= damage
M:DeathCheck()
usr.HP -= 10
usr.Experience += 1
usr:Experience()
src.lifegun = 0
sleep(60)
src.lifegun = 1
else
usr << "You shoot a blast of your own life at [M]!"
oview() << "[usr] engages [M]!"
var/damage = usr.HP - 1
world << "[damage] damage!"
M:HP -= damage
M:DeathCheck()
usr.HP = 1
usr.Experience += 1
usr:Experience()
src.lifegun = 0
sleep(60)
src.lifegun = 1
else
usr << "Dont click so fast!"

mob/verb/LAW_fire(mob/M as mob in oview(20))
if (src.LAW = 1)
if (src.LAWs >= 1)
usr << "You shoot a LAW @ [M]"
oview() << "[usr] engages [M]!"
var/damage = rand(22,30)
world << "[damage] damage!"
M:HP -= damage
M:DeathCheck()
src.LAWs -= 1
src.LAW()
usr.Experience += 1
M:Experience()
src.LAW = 0
sleep(75)
src.LAW = 1
else
usr << "Not enough LAWs"
else
usr << "Dont click so fast!"

mob/verb/autorifle(mob/M as mob in oview(20))
if (src.autorifle = 1)
if (src.Bullets >= 300)
usr << "You shoot a Bullet @ [M]"
oview() << "[usr] engages [M]!"
var/damage = rand(4,12)
world << "[damage] damage!"
M:HP -= damage
M:DeathCheck()
src.Bullets -= 1
src.ammocheck()
usr.Experience += 1
M:Experience()
src.autorifle = 0
sleep(5)
src.autorifle = 1
else
usr << "Not enough bullets"
else
usr << "Dont click so fast!"

mob/verb/Naded(mob/M as mob in oview(20))
if (src.nade = 1)
if (src.HandGrenades >= 1)
usr << "You shoot a nade @ [M]"
oview() << "[usr] engages [M]!"
var/damage = rand(10,30)
world << "[damage] damage!"
M:HP -= damage
M:DeathCheck()
src.HandGrenades -= 1
src.Nade()
usr.Experience += 1
M:Experience()
src.nade = 0
sleep(40)
src.nade = 1
else
usr << "Not enough nades"
else
usr << "Dont click so fast!"

mob/verb/autorifle(mob/M as mob in oview(20))
if (src.autorifle = 1)
if (src.Bullets >= 300)
usr << "You shoot a Bullet @ [M]"
oview() << "[usr] engages [M]!"
var/damage = rand(8,16)
world << "[damage] damage!"
M:HP -= damage
M:DeathCheck()
src.Bullets -= 1
src.ammocheck()
usr.Experience += 1
M:Experience()
src.autorifle = 0
sleep(10)
src.autorifle = 1
else
usr << "Not enough bullets"
else
usr << "Dont click so fast!"

mob/verb/Use_razor_blade(mob/M as mob in oview(1))
if (razorblade = 1)
usr << "You cut [M] with your razor blade!"
oview() << "[usr] engages [M]!"
var/damage = rand(1,6)
world << "[damage] damage!"
M:HP -= damage
M:DeathCheck()
usr.Experience += 1
M:Experience()
src.razorblade = 0
sleep(10)
src.razorblade = 1
else
usr << "Dont click so fast!"



mob/verb/Use_life_pack()
if (src.Lifepack >= 1)
usr << "You use a life pack..."
var/heal = rand(5,10)
usr.HP += heal
usr << "Healed [heal]!"
else
usr << "Your all out of Life Packs"
Drafonis wrote:
Many of my verbs are messed up.

Well by all means, then, don't tell us what's going wrong. We'll just guess. I say the space pixies probably scrambled your code.

Lummox JR
In response to Lummox JR
It flags everything with indentation error.
In response to Drafonis
Drafonis wrote:
It flags everything with indentation error.

Inconsistent indentation isn't too hard to fix. Just make sure you don't mix spaces and tabs, and everything lines up properly, indenting in the right place. It seems in some cases you're indenting blocks of code a tab or two too far.

Meanwhile, I noticed that lines like this one aren't helping you:
if (lifegun = 1)

In C this would be a valid statement but would produce a warning--because = is assignment, but == is for comparison. In BYOND this is rejected.
The correct Syntax would be ==1, not =1, but better still is this:
if(lifegun)

If you're just comparing on/off vars, never use ==1. It's bad programming practice and not strictly "safe", even though in most cases it won't cause a problem. Seems to have burned you here, though.

Likewise, in a lot of places you check if a value is >=1, you probably would be better off checking >0. Same effect (unless you have values between 0 and 1), but it's simpler in a lot of ways.

Lummox JR
In response to Lummox JR
Can you show me how the code would look?
In response to Drafonis
Drafonis wrote:
Can you show me how the code would look?

You mean fix all your code? Of course not.

The indentation errors should be easy to fix--in fact, they should be trivial. As for the other suggestions I made, I was pretty clear on how you'd go about changing them.

Lummox JR
In response to Lummox JR
At least give me an example to work with.
In response to Lummox JR
LOL -- once again me here with the ignorant question:

What's unsafe about using the == 1 operator? I'm sure this is just my system programming stuff going here, but I always use == 1 and then add an assert if it's higher so I can make sure no procs are incrimenting it at any point in time because I don't want them to.

( That's during debug sessions ONLY just so you know :) )

I can understand that it may not be ACCEPTED usage of the programming language, but that's similar to how in C++ most people use unsigned variables when they do not want negative values, where a system programmer often keeps them unsigned to limit the variable size and has the ability to use assert()s to make sure it never goes negative, OOORR disable threads / processes when they go negative.

By system programmer I mean Operating System programmer ie-> Linux Hacker ( except I don't play with the Linux kernel, but my own :) )
In response to ShadowWolf
ShadowWolf wrote:
LOL -- once again me here with the ignorant question:

What's unsafe about using the == 1 operator? I'm sure this is just my system programming stuff going here, but I always use == 1 and then add an assert if it's higher so I can make sure no procs are incrimenting it at any point in time because I don't want them to.

( That's during debug sessions ONLY just so you know :) )

I can understand that it may not be ACCEPTED usage of the programming language, but that's similar to how in C++ most people use unsigned variables when they do not want negative values, where a system programmer often keeps them unsigned to limit the variable size and has the ability to use assert()s to make sure it never goes negative, OOORR disable threads / processes when they go negative.

You're talking about a specific use of a specific type of var, though: reference counters. For simple boolean values, a more boolean syntax should be used--for simplicity if nothing else, but I think it also makes the code more readable.

For reference counters, there's usually a good reason to compare to a specific value. For on/off values, if(var) works fine. (Well, in Java it'd have to be if(var!=0) to make it boolean, but that's still an improvement over comparing to 1.)

Lummox JR
In response to Lummox JR
OHHH! I actually use booleans in my stuff as well, but I use them like this:

var/whatever

proc/myproc()
src.whatever = TRUE

proc/myotherproc()
if(src.whatever == TRUE)
Do stuff
else
Do other stuff

But yeah, I see yer point.