Having a bit of trouble...

ID:180449
 
Jun 11 2001, 8:49 am
I have a "Split Form" technique that makes a copy of yourself. Now, it works perfectly, but when I use it, I get this error:
Cannot modify null.name.
proc name: Click (/client/Click)
usr: Cinnom (/mob/AdminPC)
src: Cinnom (/client)
call stack:
Cinnom (/client): Click(Split Form (/obj/SplitForm), "Techniques")

Here's how I have it done (under the Click() proc):

// Stuff before it.
else if(loc:attacktyp == 9) // Split Form
usr.lock = 1
if(usr.split != 1)
usr.hp -= 10
var/mob/buddy = new /mob/SplitPC/(usr.loc)
buddy.name = usr.name // I guess this is where the error occurs
buddy.trg = usr.trg
buddy.pwrlvl = usr.pwrlvl / 2
buddy.icon = usr.icon
buddy.maxpwrlvl = usr.maxpwrlvl / 2
buddy.level = usr.level - 2
buddy.skill = usr.skill / 2
buddy.attacktyp = 1
buddy.attackpwr = 1 * loc:attackpwr
buddy.warmode = 1
usr.maxpwrlvl -= (usr.maxpwrlvl / 5)
usr.split = 1
usr.lock = 0
return

So how can I get rid of that seemingly pointless error?
Jun 11 2001, 9:16 am
Cannot modify null.name.
proc name: Click (/client/Click)
usr: Cinnom (/mob/AdminPC)
src: Cinnom (/client)
call stack:
Cinnom (/client): Click(Split Form (/obj/SplitForm), "Techniques")

Well, first off, it might help if you compiled with DEBUG on. It's in the Dream Maker reference.

var/mob/buddy = new /mob/SplitPC/(usr.loc)
buddy.name = usr.name // I guess this is where the error occurs

Notice the extra "/" after the /mob/SplitPC. This is likely confusing the compiler.

You'd be much better off doing:

var/mob/SplitPC/buddy = new (usr.loc)
Jun 11 2001, 9:54 am
In response to Spuzzum
You'd be much better off doing:

var/mob/SplitPC/buddy = new (usr.loc)

It does the exact same thing, with the same error...
What I'd really like to know is why the error is showing up. I think it just plain shouldn't, since the name is still getting assigned along with everything else. And it works just fine.
Jun 11 2001, 9:56 am
In response to Cinnom
You know, I had the exact same thing showing up in my game... I even figured out how to fix it. Again, I don't think I was doing anything incorrectly, but I shuffled some things around and it stopped. I wish I remember what it was. Try putting a sleep() right after the line where you make the new mob, just for fun.

On 6/11/01 12:54 pm Cinnom wrote:
You'd be much better off doing:

var/mob/SplitPC/buddy = new (usr.loc)

It does the exact same thing, with the same error...
What I'd really like to know is why the error is showing up. I think it just plain shouldn't, since the name is still getting assigned along with everything else. And it works just fine.
Jun 11 2001, 10:03 am
In response to LexyBitch
On 6/11/01 12:56 pm LexyBitch wrote:
You know, I had the exact same thing showing up in my game... I even figured out how to fix it. Again, I don't think I was doing anything incorrectly, but I shuffled some things around and it stopped. I wish I remember what it was. Try putting a sleep() right after the line where you make the new mob, just for fun.

Already tried it...
Jun 11 2001, 10:23 am
In response to Cinnom
It looks like 'buddy' is never being created. Print out the value after the new statement.

You are creating it at usr.loc. If usr is a dense mob, that might not be possible. I forget what the exact behavior is in this case, but it might be aborting creation and returning null when the location can't be assigned.
Jun 11 2001, 10:44 am
In response to Tom
On 6/11/01 1:23 pm Tom wrote:
It looks like 'buddy' is never being created. Print out the value after the new statement.

You are creating it at usr.loc. If usr is a dense mob, that might not be possible. I forget what the exact behavior is in this case, but it might be aborting creation and returning null when the location can't be assigned.

But as I said, it is being created, and it works fine. Well, in any case, Ebon fixed it for me. Thanks anyways.
Jun 11 2001, 10:47 am
In response to Cinnom
On 6/11/01 1:44 pm Cinnom wrote:

But as I said, it is being created, and it works fine. Well, in any case, Ebon fixed it for me. Thanks anyways.

So what was the problem? If we are reporting errors incorrectly I'd like to know.