ID:149409
 
ok it seems that my ifs just dont work. Im trying to make it so other people cant take a pet that is already taken. Bye this i use a if to check if the pet has a owner.
Cat
icon='pets.dmi'
icon_state="Cat"
var/owner=null
verb
Tame()
set src in oview(1)
if(owner==null)
if(usr.pets=="1")
usr<<"You can only have one pet at a time"
else
owner=usr.key
else if(owner== usr.key)
usr<<"You own this pet already"
else
usr<<"someone owns this pet"

now lets pretend all the var work, and everything you dont see is fine(so dont ask about thinks like "weres the mob at the front" ok.) Do you see a problem i am missing?
I see you're trying to check a text string in place of a number:

if(usr.pets == "1")

should be:

if(usr.pets)//This is if the var is 1 or TRUE


Also; "if(owner == null)" can be "if(!owner)"
In response to Nadrew
would it realy make a diffrence, i mean as to work or not, not how efficent.
In response to Scoobert
hold on, i think i found my proble, it was just one of those forget to add things, ill try it and see if it works.


[EDIT]
I got it, sorry for asking, if forgot to tell it to add the verb when you tame the animal, it had no way of knowing that i had one pet untell i fixed it, thanks anyways.
In response to Nadrew
Nadrew wrote:
Also; "if(owner == null)" can be "if(!owner)"

I'm not sure how BYOND handles a comparison to null, but in some languages, that check will always return false, even when owner truly is null.

The reason is that null really means "unknown." You can't really compare two unknowns, and assert that they are equivelant. ("I don't know that person's name, and I don't know that other person's name... therefore, they have the same name")

This is hard to grasp because we all know that null means "nothing," right? The answer is it's really only sort of nothing.

To sum it up, always use: if(!owner)
In response to Skysaw
Skysaw wrote:
Nadrew wrote:
Also; "if(owner == null)" can be "if(!owner)"

I'm not sure how BYOND handles a comparison to null, but in some languages, that check will always return false, even when owner truly is null.

if(owner==null) will be true when owner is null, but only null. if(!owner) is equivalent to if(owner==null || owner==0 || owner==""). However, the if(!owner) form is almost always preferable.

Lummox JR
One problem I see with your code is that there's no reference to the pet; just to whether the owner has one. That won't affect your bug but it is bad design.

You have a numerical value, mob.pets, that says whether a mob owns a pet. This isn't at all useful, because knowing whether you have a pet is less inherently practical than knowing which pet you have; and if you have a var for that, a null value would indicate you don't have a pet anyway, answering the question of whether you have one as well as which one it is.

So what you should be using is mob.pet, where that var points to the pet obj/mob itself. Similarly, if you had more than one pet, you should use a list.

Lummox JR
In response to Lummox JR
Any time I've tried comparing two items as null it always returned false...

such as i've tried:
if(P == null)
break
for a movement thing to capture a but I used to get where my AI's movement would return a run-time error, and it never worked...

I don't see how two null items could ever be equal because null doesn't mean 0, it means non-existant.
In response to ShadowWolf
Null is actually 0, 0 in an information structure is empty or null.
In response to Nadrew
Nadrew wrote:
Null is actually 0, 0 in an information structure is empty or null.

Null is not 0 at all. In fact, this line:

if(0 == null)

should return false every time.
In response to Skysaw
0 as a number means zero but 0 as in comp crap means nothing, off, unknown. Not zero.null is the same as 0 but not zero.
Attempt using it like this

Cat
icon='pets.dmi'
icon_state="Cat"
var/owner=null
verb
Tame()
set src in oview(1)
if(owner==null)
if(usr.pets=="1")
usr<<"You can only have one pet at a time"
else if(owner== usr.key)
usr<<"You own this pet already"
else
owner=usr.key
else
usr<<"someone owns this pet"
In response to NeoHaxor
dont worry, i got it.
In response to Scoobert
Scoobert wrote:
0 as a number means zero but 0 as in comp crap means nothing, off, unknown. Not zero.null is the same as 0 but not zero.

What a load of gibberish! I'd love to refute your point, but I'm not sure you have one!
In response to Skysaw
Skysaw wrote:
Scoobert wrote:
0 as a number means zero but 0 as in comp crap means nothing, off, unknown. Not zero.null is the same as 0 but not zero.

What a load of gibberish! I'd love to refute your point, but I'm not sure you have one!

Lemme try...

"The numeral 0 in the real world means "zero", but in computer terms it means "false" -- i.e. nothing, off, or unknown. "null" in computer terms is the same as 0, but is not the same as "zero" in the real world."

Information is still wrong, however, since ((0 != "") && (0 != null) && ("" != null)) is TRUE. (It's nice when you can use boolean logic to express a point =P).


I could get paid money to translate Engrish manuscripts...!