Datum

ID:2720586
 
Sep 30 2021, 9:16 pm
(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!
Sep 30 2021, 10:45 pm (Edited on Sep 30 2021, 11:05 pm)
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.
Sep 30 2021, 10:47 pm
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.
Sep 30 2021, 10:51 pm
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.
Sep 30 2021, 11:01 pm (Edited on Sep 30 2021, 11:06 pm)
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?
Sep 30 2021, 11:12 pm
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)
Sep 30 2021, 11:14 pm
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
Sep 30 2021, 11:22 pm
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!"
Sep 30 2021, 11:23 pm
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.
Sep 30 2021, 11:33 pm
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?
Sep 30 2021, 11:35 pm
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.
Sep 30 2021, 11:54 pm
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.
Oct 1 2021, 9:27 am
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.