ID:2720586
 
(See the best response by Shadowkaroth.)
How do you use a proc in a datum for a mob? Like setting up stats names etc.. or what should datums be used for exactly? Pleas don't come for me but here is an example of what I have.

Join

parent_type =/mob

var
Name as text
Color as text
Weight as num


proc
Join(N as text)
src.Name = N
world << "[src] logged in!"


mob
var/Join/J =new()
Login()
.=..()
J.Join(usr)


Thank you!
You used src in the Datum, so the datum is referring to itself. To make it use the mob, add an argument mob/m.

Then when you call the procedure on login, you can pass the mob as an argument it should be fine.
Join

var
Name as text
Color as text
Weight as num


proc
Join(mob/m)
world << "[m] logged in!"


mob
var/Join/J =new()
Login()
.=..()
J.Join(src)



Didn't compile. Let me know how this works for you.

EDIT: REMOVED PARENT TYPE since that was causing a runtime error. Datums are abstract and should be attached to atoms, iirc.

So that makes total sense.
I'm not sure what you're trying to accomplish exactly. Can you describe what you're trying to do in more detail?

But, don't use usr in Login(); src would be the better choice there.
In response to Lummox JR
Lummox JR wrote:
I'm not sure what you're trying to accomplish exactly. Can you describe what you're trying to do in more detail?

But, don't use usr in Login(); src would be the better choice there.

Basically I'm trying to make it read a proc in datum to use it. Does procs in datums act differently? This was just an example of trying to use a proc.
In response to Kidman90
Kidman90 wrote:
Lummox JR wrote:
I'm not sure what you're trying to accomplish exactly. Can you describe what you're trying to do in more detail?

But, don't use usr in Login(); src would be the better choice there.

Basically I'm trying to make it read a proc in datum to use it. Does procs in datums act differently? This was just an example of trying to use a proc.

See the code above. I did some experimenting, you also need to remove the parent type. This is bugging the code. I don't understand why you would make a datum a child of mob, was there anything in particular you were attempting to accomplish with that move?
In response to Meme01
Meme01 wrote:
Kidman90 wrote:
Lummox JR wrote:
I'm not sure what you're trying to accomplish exactly. Can you describe what you're trying to do in more detail?

But, don't use usr in Login(); src would be the better choice there.

Basically I'm trying to make it read a proc in datum to use it. Does procs in datums act differently? This was just an example of trying to use a proc.

See the code above. I did some experimenting, you also need to remove the parent type. This is bugging the code. I don't understand why you would make a datum a child of mob, was there anything in particular you were attempting to accomplish with that move?

Okay this works but is this necessary for it to work? Is this technically the right way to do this or am I making it complicated.
mob
var/Join/J =new()
Login()
.=..()
J.Join(src)
In terms of inheritance, /mob is actually /datum/atom/movable/mob.

Datum is an extremely simple type, being the root type of most built-in types and all custom types. They don't have any of the vars or procs related to appearance that atoms have, or movement/collision that objs and mobs have.

There's nothing special about them, except that they don't really do anything by default. They're the opposite of special. All the built-in types are the actual special modifications on top of datum. That makes datums very easy to understand and deal with, as long as you keep them focused in their responsibilities.

Vars and procs work the exact same way for datums as they do for any other type of thing.

DM Reference: datum (also F1 in Dream Maker):
http://www.byond.com/docs/ref/index.html#/datum

DM Guide: User-Defined Data Objects:
http://www.byond.com/docs/guide/chap18.html

Resource repository:
http://www.byond.com/forum/post/120721 programming tips #4 - datums, Forum_account
http://www.byond.com/forum/post/35530 Dream Tutor: Datums Are Our Friends, Lummox JR
In response to Kidman90
Your example is complicated in the sense that the datum has a few variables that it doesn't use, and in the code so far, there's no reason to keep it around after calling Join(). The same can be achieved with just this:
Join
proc/Join(mob/joiner)
world << "[joiner] logged in!"

mob
Login()
..()
new/Join().Join(src)

If that is all it'll do for the foreseeable future, it's a lazy class. There's no point in having it over this:
mob
Login()
..()
world << "[src] logged in!"
In response to Kidman90
Kidman90 wrote:
Meme01 wrote:
Kidman90 wrote:
Lummox JR wrote:
I'm not sure what you're trying to accomplish exactly. Can you describe what you're trying to do in more detail?

But, don't use usr in Login(); src would be the better choice there.

Basically I'm trying to make it read a proc in datum to use it. Does procs in datums act differently? This was just an example of trying to use a proc.

See the code above. I did some experimenting, you also need to remove the parent type. This is bugging the code. I don't understand why you would make a datum a child of mob, was there anything in particular you were attempting to accomplish with that move?

Okay this works but is this necessary for it to work? Is this technically the right way to do this or am I making it complicated.
mob
> var/Join/J =new()
> Login()
> .=..()
> J.Join(src)



For what you're doing, I would say this is the best way. (If you insist on using a datum for it, that is.)

Your last method was flawed in a number of ways:

- As Lummox stated, don't use 'usr', use src. This is almost always the better choice, unless you're dealing with the client.

- Always be mindful that src refers to the object that initiated a procedure. In this case, since you used src (In the original program) in datum, that means src would only call itself. See image below:

https://i.imgur.com/suqHV2p.png

- Also, don't needlessly set a datum's parent type to an atom. Try to keep datums as simple as possible. In this case, it was a bad move.

Anywho, take a look at what Kaio posted. It has tons of good information for understanding datums.
Ok thanks. Another question, ever Datum I make I have to make it as var/Datum/datum under whatever /mob ,/obj, etc I want to have use it?
In response to Kidman90
Kidman90 wrote:
Ok thanks. Another question, ever Datum I make I have to make it as var/Datum/datum under whatever /mob ,/obj, etc I want to have use it?

It depends on what you want to use it for.

If you intend to use a datum to manage character/object attributes, you attach it to a mob as a variable.

Alternatively, if you wanted to just create an object to manipulate data, there would be no need to attach it to a mob.

http://www.byond.com/forum/post/35530


The second example shows how to use datums for teams.

EDIT: Pardon me, this example actually does attach it to a mob. I've given you slight misinformation.
In response to Kidman90
It all depends where the datum is used.

Some datums are singletons stored in global vars. An example would be /world, kind of. I've had a "seasons" datum manage seasonal cycles over time, stored in a global "Seasons" variable.

Some datums are created and destroyed in the span of a single proc call. Examples of this are /matrix, /icon, /sound, /image, /mutable_appearance, /savefile, /regex, /database, /database/query, /exception, /list (though /list is not technically a /datum, but that's just DM being overly complicated)... I'd say most built-in types are actually datums used in this way. I have a library for 2D vectors, which are datums of type /vector2, and many of those can be created and destroyed in the span of a single expression for the sake of clean 2D vector math.
mob
proc/Save()
// a savefile is instantiated by new/savefile()
new/savefile("players/[ckey].sav")["mob"] << src
// and now the savefile is destroyed

proc/PlayFootstep()
// sound() creates a /sound object
view() << sound('footstep.ogg')
// and now it's destroyed

proc/ShowEffect()
// image() creates an /image object
overlays += image('effects.dmi', "fancy")
// and now it's destroyed (overlays doesn't store it directly after all)

And some datums keep references to other datums. Clients have a variable called "mob" which is the /mob they're controlling. Mobs have a variable called "client" which is the /client they're being controlled by. Atoms have a variable called "loc" which is the /atom they're contained by. They also have a variable called "contents" which is a list of atoms they contain. These are all examples of datums referring to other datums.
Best response
A lot has gone on in this thread and I wanted to put to concreate the main points here that need to be gone over..

It seems in your initial question.. you are curious about how to use datums for "stats". I won't go over what a datum is as I believe Kaiochao and Lummux's post ref above do that well enough.

I just want to simplify this by saying a datum can be created in two ways.

stat
var
lvl
exp

Which is a a datum containing nothing but what we create it too.
stat
parent_type = /obj
var
lvl
exp

Here using parent_type we are able to create a new type that is a CHILD of the /obj class.


In your post/example though it seems you go over trying to log in a player using a temporary mob class.

This has been done in dm for years. The issues people come with Login() is that it is called ANYTIME a CLIENT connects to MOB by setting the mobs key = client.key or clent.mob = mob. Which when you use Login() to indicate a new client connection.. issues arise when trying to "control" or swap the clients controlled mob during runtime.

You can easily do..

mob
Login()
world << "This wont happen!"

world
mob = /mob/Login

mob/Login
Login()
//Unique stuff.

The same can be achieved by doing like in your example..
login
parent_type = /mob
Login()
world << "I Joined!"

world
mob = /login


The part of having a Join() proc that is called on the "Join" class is useless if you just have the Join class use Login() as it is a child of mob. Like we just went over.