A few curiosities.

ID:272153
 
Apr 14 2008, 2:46 am
First one.

I know that it is always safe to not use usr in procs and most people say to use src. But I never use src either. I always pass whoever is effected by the proc as an argument, an example would be.
mob/proc/MyProc(mob/M)
    M.level++
    M << "You leveled up!!"

And then to call that proc I'd use something like MyProc(usr) in a verb or something.
Is this a good or bad thing to do, and does it have any kind of effect on a games preformance, BYONDS limits and so on?

Second one is abot Datums.
Is it possible to abuse and over use them? At the moment I use them for status effects, each type of datum is a different effect, when the status effect is created it is added to a list that it attatched to the appropriate mob and then it does whatever (calls 3 procs, one for when it starts, one for if and when it loops and one for when it ends).
I also use them in a similar fashion for magical effects on equipment. There is a bunch of datums to represent magical effects, when a magical weapon is created it has a list created and any effect datums added to that list. These datums work similar to status effects, they have several procs (on equip, on unequip, while equipped and on hit) which are called when needed.
I also intend on doing something similar for useable items such as potions (with each datum representing an effect) and for ingrediants needed to make these items.

Systems like these are easy to use and offer a lot of customization and flexability in the actual game. But, am I abusing and over using datums, and are systems like these right are wrong to use and if they are not good systems to use then what is a better method to use?

That is all for now.
Apr 14 2008, 4:36 am (Edited on Apr 14 2008, 4:42 am)
The Magic Man wrote:
I know that it is always safe to not use usr in procs and most people say to use src. But I never use src either. I always pass whoever is effected by the proc as an argument, an example would be.
mob/proc/MyProc(mob/M)
>     M.level++
>     M << "You leveled up!!"

And then to call that proc I'd use something like MyProc(usr) in a verb or something.

No, no. You're right that you shouldn't use usr. But what you should use instead is both src and arguments.
First I need to tell you about a Dream Maker feature. Since the src variable, the source of the current proc, is the most often used variable in DM, and a central variable, if you type a proc or variable without relating it to an object (with the '.' operator, like in M.level) then if it isn't a local proc/var then it will take if 'src' has one, and if so, it will compile it as "src.var" or "src.proc()".
Therefore, in your example you said you'd use MyProc(usr) to call the proc. But in actuality, you're using src.MyProc(usr).
So following the unwritten rule of wasted up variables in programming, you look in this line. You (kind of) pass 2 variables to MyProc(): usr, and src. But you're only using the 'usr' one, therefore 'src' is wasted. What you should do, is call the proc with src.MyProc() and use src instead of the argument in the proc itself.
The 'src' variable isn't just another argument, however. It is a special variable and has certain 'properties', if you will. A running proc that has an 'src' is tied to it - if 'src' is deleted the proc is stopped. There is more to it than that.
src is the 'source' of the current proc - who this proc belongs to and who this proc "works for" - the originator.
The src variable is always defined properly of the type of the source object, ie in a mob/player/proc 'src' would be defined as a /mob/player and would also contain one. This is very useful, for example in verbs where src==usr, src is more useful to use (because of several more reasons, however) because usr is always defined as only a /mob type, so you couldn't directly access mob/player vars from it etc.

Basically, if you're making a proc that has a main 'subject' object, that should be src. Otherwise, it should be a 'global proc' tied to no specific object.

Examples: 
mob/proc
    Attack(mob/victim)
        victim.HP -= src.strength
        victim.DeathCheck(src)
    DeathCheck(mob/attacker)
        if(src.HP <= 0)
            world << "[attacker] just killed [src]"
            attacker.exp += 5
            attacker.LevelCheck()
    LevelCheck()
        while(src.exp >= src.maxexp)
            src.exp -= src.maxexp
            src.level++

//global (object-less) procs:
proc
    get_steps(ref, dir, dist=1)
        . = ref
        for(1 to dist) . = get_step(., dir)
    text2list() //...
    list2text() //...
    random() //...


Is this a good or bad thing to do, and does it have any kind of effect on a games performance, BYONDS limits and so on?

Like I said, it isn't quite right to do. Do not ignore the src variable.
It is more robust, safe, and efficient to utilize object-oriented procs, which should use src. So yeah, it would end up affecting your game's performance in the end. :P
Affects limits? No, not really. But remember there is much more to worry about in programming than limits.
Some documentation, food for though, more information, otherwise called as related links (:P):
-The DM Guide on procs
http://www.byond.com/docs/guide/chap06.html

-The DM Reference on src
http://www.byond.com/docs/ref/info.html#/proc/var/src

-The DM Reference on usr (I recommend reading this too. It is just below on the page of the above link).


Second one is abot Datums.
Is it possible to abuse and over use them? At the moment I use them for status effects, [...]
I also use them in a similar fashion for magical effects on equipment [...]

I also intend on doing something similar for useable items such as potions (with each datum representing an effect

And then you can have different potions and magic using the same effect datums flexibly without needing to write them again specifically, etc. Read below-

Systems like these are easy to use and offer a lot of customization and flexability in the actual game.

Object Oriented Programming is all about flexibility, and the use of tangible /atoms isn't the only way to use OOP! Use the datums, Datums Are Our Friends.

But, am I abusing and over using datums, and are systems like these right are wrong to use and if they are not good systems to use then what is a better method to use?

Until "recently" (I believe it was changed in BYOND 4.0.0 but I don't remember exactly) the limit of /datums was
65535, like /objs /mobs /lists and the rest of the objects.
Theoretically, this was already more than enough. I mean, most the people exceeding limits are doing it by using improper designs that require too many objects than really needed, or otherwise doing stupid mistakes like: 
turf
    var/list/something = new()

I don't think you are going to be coding in 60,000 different effects into your game no matter how awesome variety you are to have in it. But as I was saying, this limit was changed.
Now, the limit of datums (and the limit of turfs, although that has been before as well) is 16,000,000 (16 million)!
So you have much less to worry nowadays. Not that it means you shouldn't design systems properly and use datums for everything, but status/magic/spell/potion - I mean, effects in general, are okay candidates for being implemented by objects.