ID:272689
 
I dont know where i must put this but i dont understand this part of the DM guide


Chapter 2
Navigating the Code Tree

The real nature of this cosmic tree cannot be known here, nor its beginning, nor end, nor foundation.

--Bhagavat Gita

The previous chapter was a quick introduction to give you a taste for DM programming. This and the next few chapters will cover the same basic ideas in greater detail.

A DM program begins at the root of the tree and descends along multiple branches. Each branching point (or node) is given a name to distinguish it from the other branches at the same level. Names are case-sensitive (so apple and Apple are different). They may be any length and may contain any combination of letters, numbers, and underscores as long as they do not start with a number.

Consider the following code:

turf trap pit quicksand glue
Perhaps you could elaborate by telling us what part of that text is giving you trouble.

Most of that text is really just an introduction to some new concepts, so if you just skip past what you don't understand I think you'll begin to get the bigger picture.

Lummox JR
This would go in Developer How-To, not BYOND Features.

It means that there are objects in DM branching off from different paths. At the top of the tree, you have /datum, as well as some more unique types, such as /world, /savefile, /list, and /client. Below /datum (the others can be viewed as branches of a tree, rather than a trunk) you have some more primitive data types, such as /icon (which can also be viewed as branches), and /atom (which is still part of the trunk). Below /atom, you have /turf, /area, and /atom/movable. Below /turf and /area, you have all the objects you define on your own! Below /atom/movable, you have /obj and /mob, which you can probably consider the most advanced of BYOND's built in types. These, like /turf and /area, are above all /obj's and /mob's you define.

Like a family tree, everything inherits from it's ancestor, yet it can be completely different in a sense.

datum/var/number = 3

mob/New()
..()
world << number/*the mob has a number variable, because
it is a descendant of /datum. This
will output "3" because the value of
the variable also carries over*/


mob/proc/Explode() //define a proc called Explode() under /mob
world << "Boom!" //output "Boom!" to the world when Explode()
//is called

mob/player/Explode() //because /mob/player is a descendant
//of /mob, it has the Explode() proc
..() //do the default action (the parent proc) In this
//case, it will output "Boom!" to the world
del(src) //then delete the src after outputting "Boom!"
//this is inheritance, a major plus to
//object-oriented programming languages!


EDIT: Difference example
mob
icon = 'person.dmi' //set the default icon for /mob to person.dmi

player //they will inherit the 'person.dmi' icon var

monster
icon = 'monster.dmi' //this can be viewed as a
//"mutation" of sorts, along
//the object tree things can
//change.



Note: The word "node" is pretty much used the same as "object" here.
In response to Jeff8500
So this:
turf 
trap
pit
quicksand
glue


Is a example?
In response to B-Blast
Yeah, just make sure to indent properly with tabs. Just keep in mind that this not only applies to type paths (/obj/something etc.) but variables and procs, like in my example.