Need help with understanding objects

ID:749380
 
May 17 2012, 12:56 pm
(See the best response by Albro1.)
Code:
Players
 parent_type = /mob
 var
  list
   Inventory = list()
   Equipment = list()
 verb
  //verbs defined in type /Players

//////////////////////////////////
Obtainable_Item
 parent_type = /obj
 var
  Equipped = 0
 DblClick(location, src_control, over_control)
  if(src_control == "Inventory_Grid")
   Equip()
 proc
  Equip()
   if(!Equipped)
    Equipped = 1
    usr.Inventory.Remove(src)
    usr.Equipment.Add(src)
   else if(Equipped)
    Equipped = 0
    usr.Inventory.Add(src)
    usr.Equipment.Remove(src)


Problem description:
Alright, so I'm trying to have list of items that are in Inventory and list of items in Equipment, and place them in two separate grids. But when I try to compile the code, I get the following error:
Code\Mouse.dm:67:error: usr.Inventory.Add: undefined var
Code\Mouse.dm:67:error: usr.Equipment.Add: undefined var


I obviously have it defined. But apparently it only looks into /mob 's var instead of what I want it to look at. How would I fix this? Surely I can just add the var to /mob, but that'll defeat the purpose of making /Player. loc:Inventory.Add(src) doesn't work that well either. If someone knows a better way to coding this, can you explain the why it does such thing and what I can do to fix this?

P.S. I don't want a code for this, I just want to understand this whole var thingie mingiy.
May 17 2012, 1:26 pm
Best response
You need to typecast usr to /Player.

var/Player/p = usr


Then call it:
p.Inventory.Remove(src)


On a side note, use tabs instead of spaces. Your code is horrible in terms of readability.
May 17 2012, 3:30 pm
I wrote the code instead of copy and paste from DM. And if you read the post I did ask for an explanation for why to do what to do. Thank you for answering my question though.
May 17 2012, 3:37 pm
An explanation? You need to typecast the usr.

It thinks usr is a /mob, regardless of what you put it under (Honestly I think Player/verb/test() should think that usr is a /Player.).

It doesn't know what the variables under /Player are. So, you instance a new mob of the /Player type and set it to usr. Now you just use p instead of usr, and it knows what the variables are.

If you are still confused, please try to explain what you are confused about and I will do my best to relieve you of it.
May 17 2012, 3:45 pm
I understand typecasting, just didn't understand the reason or objective of doing so. That'll be absolutely annoying to name usr a different variable everytime I define a verb or proc. Could I post it under /atom or something, so the variable is already defined?
May 17 2012, 3:47 pm
If you want to access a variable specific to /Player, you'll need to typecast.
May 17 2012, 3:51 pm
Meh, that's just annoying. There's no variable better suited for usr other than usr. >.> Thanks.
May 18 2012, 9:43 am
In response to Albro1
Albro1 wrote:
If you want to access a variable specific to /Player, you'll need to typecast.

No- you don't NEED to do anything. Alternatively, you may use the : operator as means of doing that.
May 18 2012, 9:52 am
In response to Shanegirl
Shanegirl wrote:
No- you don't NEED to do anything. Alternatively, you may use the : operator as means of doing that.

This is true. HOWEVER, to be on the safe-side, typecasting is recommended as, if you make a typo or rename a variable/path later on, the compiler will not catch this mistake and you will spend time scratching your head wondering where the runtime error came from (that resulted from the said situation)
May 18 2012, 10:07 am
In response to GhostAnime
GhostAnime wrote:
Shanegirl wrote:
No- you don't NEED to do anything. Alternatively, you may use the : operator as means of doing that.

This is true. HOWEVER, to be on the safe-side, typecasting is recommended as, if you make a typo or rename a variable/path later on, the compiler will not catch this mistake

That's unlikely. If it's a typo, chances are that isn't a name of a variable. There has to be a variable of that name or otherwise a runtime error will occur.

Ghost Anime wrote:
and you will spend time scratching your head wondering where the runtime error came from (that resulted from the said situation)

Not if you log all of the errors like a smart person.
May 18 2012, 10:11 am (Edited by moderator on May 18 2012, 12:02 pm)
In response to Shanegirl
Shanegirl wrote:
That's unlikely. If it's a typo, chances are that isn't a name of a variable. There has to be a variable of that name or otherwise a runtime error will occur.

His point about renaming a path that you removed from the quote still stands. If you have:
mob/var/health = 100


And somewhere in your code you use:
usr:health += 1


And then later on you change it to this:
mob/player/var/health = 100


You will get a runtime error and it will take you more time to figure out why and where it is than if you just typecasted.

Not if you log all of the errors like a smart person.

Please read the first part of this post.
May 18 2012, 10:30 am (Edited by moderator on May 18 2012, 12:03 pm)
In response to Albro1
Albro1 wrote:
His point about renaming a path that you removed from the quote still stands. If you have:
> mob/var/health = 100
>

And somewhere in your code you use:
> usr:health += 1
>

And then later on you change it to this:
> mob/player/var/health = 100
>

You will get a runtime error and it will take you more time to figure out why and where it is than if you just typecasted.

If the playing character is mob/player in your scenario the runtime error won't occur unless you're using usr when it is not needed, such as outside of object/verb callings.

Albro1 wrote:
Not if you log all of the errors like a smart person.

Please read the first part of this post.

There's no relevance because he simply didn't know how to deal with said error. Note that I was also referring to runtime errors, not ones outputted by the compiler.