The DM Guide [edit]

Page: 1 2
ID:135161
 
Jan 8 2005, 11:14 am (Edited on Jan 8 2005, 2:00 pm)
Don't get me wrong: I think that most of the blue book is great. However, parts of it are simply wrong. Here's a sample but of code from the chapter on verbs, for example:

mob/verb/commune(M as mob in world,txt as text)
   M << "[usr] communes to you, '[txt]'"


What's wrong here?

Instead, it should be "mob/M as mob in world". You might say "Why do we have to type cast here?". We don't. Not oin this situation. But in DM, it's always important to give as much information about a variable as possible:

var/obj/thing/T=new()//Information is good

is much, much better than
var/T=new()

or
var/obj/T=new()
Jan 8 2005, 11:18 am
The "eat" verb is also nasty...
_>
What?
Jan 8 2005, 1:31 pm
No, it's not "simply wrong". It will work fine for what it's intended to do. This isn't on the level of usr misuse or anything.

If they wander into these forums wondering why it doesn't work, good! Maybe they'll learn something from the experience.
Jan 8 2005, 1:33 pm
In response to Crispy
Crispy wrote:
No, it's not "simply wrong". It will work fine for what it's intended to do. This isn't on the level of usr misuse or anything.

If they wander into these forums wondering why it doesn't work, good! Maybe they'll learn something from the experience.

So it's a bit like Honeytrapping? (or whatever the word is).

Forcing people to go wrong to see the light?
Jan 8 2005, 1:53 pm (Edited on Jan 8 2005, 2:00 pm)
In response to Crispy
Crispy wrote:
No, it's not "simply wrong". It will work fine for what it's intended to do.

True, but it's definately misleading. In DM, it's very important to give as much information as possible about a variable. ie:

var/obj/thing/T=new(src.loc)


is better than

var/T=new(src.loc)


This isn't on the level of usr misuse or anything.

I disagree. The only difference is that usr misuse would generally compile, while this wouldn't:

mob/verb/Eat(M as mob in world)
    src << "You eat [M], who, by the way, is [M.gender]."


If they wander into these forums wondering why it doesn't work, good! Maybe they'll learn something from the experience.

Crispy, No. Misleading and/or generally bad information shouldn't be found in the DM Guide. Saying that misleading information should be left in there so that beginners will have to wander into the forum is probably one of the most ignorant things I've heard in a while.
Jan 8 2005, 2:24 pm
In response to Wizkidd0123
Wizkidd0123 wrote:
I disagree. The only difference is that usr misuse would generally compile, while this wouldn't:

See, you've just proved my point. =P If it doesn't compile, then they'll KNOW that it doesn't work; unlike usr misuse. Compilation errors are always preferable to subtle runtime bugs.

Crispy, No. Misleading and/or generally bad information shouldn't be found in the DM Guide. Saying that misleading information should be left in there so that beginners will have to wander into the forum is probably one of the most ignorant things I've heard in a while.

Wizkidd, I'm going to be honest with you. You seem to think you know everything about DM programming, and quite frankly that attitude is very grating. You're not bad, but you're not as good as you think you are (that would be impossible). Anytime someone disagrees with you, you call them ignorant, or stupid. And you know what? I'm fed up with it.

You know, I would have agreed with you in the first place, if it wasn't for your "THIS IS WRONG I AM RIGHT END OF STORY AND IF YOU DON'T AGREE YOU'RE IGNORANT" attitude. Changing it wouldn't be a bad idea, but it's nowhere near as urgent as you seem to think it is.

Besides, I doubt that the Blue Book is going to be remade just for one niggling little error that hardly matters anyway.

Oh, and this isn't a bug, as such, so it really doesn't belong in this forum.
Jan 8 2005, 2:38 pm
Wizkidd0123 wrote:
var/obj/thing/T=new()//Information is good

is much, much better than
var/T=new()

or
var/obj/T=new()


That's not true. Sometimes you only want a /obj, not a /obj/thing. I understand your point though. That's just a bad example. A better example might be:

var/obj/thing/T = new()

Is better than:
var/T = new /obj/thing ()

But even that might have exceptions.
Jan 8 2005, 3:47 pm
 
mob/verb/commune(M as mob in world,txt as text)
   M << "[usr] communes to you, '[txt]'"


Nothing is wrong with this. They already declared M as a mob hence the "as mob" so there is no need to put mob/M but you can put it if you want. Here's another way you can also do it which uses mob/M but not the "as mob".

mob/verb/commune(mob/M in world,txt as text)
   M << "[usr] communes to you, '[txt]'"
Jan 8 2005, 3:59 pm (Edited on Jan 8 2005, 4:06 pm)
In response to Crispy
Crispy wrote:
Wizkidd0123 wrote:
I disagree. The only difference is that usr misuse would generally compile, while this wouldn't:

See, you've just proved my point. =P If it doesn't compile, then they'll KNOW that it doesn't work; unlike usr misuse. Compilation errors are always preferable to subtle runtime bugs.

That's no reason not to fix the DM Guide.

Crispy, No. Misleading and/or generally bad information shouldn't be found in the DM Guide. Saying that misleading information should be left in there so that beginners will have to wander into the forum is probably one of the most ignorant things I've heard in a while.

Wizkidd, I'm going to be honest with you. You seem to think you know everything about DM programming, and quite frankly that attitude is very grating. You're not bad, but you're not as good as you think you are (that would be impossible). Anytime someone disagrees with you, you call them ignorant, or stupid. And you know what? I'm fed up with it.

I don't call people ignorant or stupid very often. Still, not agreeing with me isn't even my problem here. My problem here is that you said that the guide shouldn't be fixed because if beginners screwed up, then they would have to go to the forums and get help.

I really don't think I know everything about DM. I know that there's plenty to learn; there always is. However, I think that saying the DM Guide shouldn't be fixed since if it was fixed, people wouldn't need to ask for help, is, in my opinion, pretty ignorant.

You know, I would have agreed with you in the first place, if it wasn't for your "THIS IS WRONG I AM RIGHT END OF STORY AND IF YOU DON'T AGREE YOU'RE IGNORANT" attitude. Changing it wouldn't be a bad idea, but it's nowhere near as urgent as you seem to think it is.

I never said I thought that it was urgent.

Crispy, you're a forum mod. You should know that the forums aren't the place for arguments like this.

Besides, I doubt that the Blue Book is going to be remade just for one niggling little error that hardly matters anyway.

It's online. Remaking a book would be one thing, but I don't see what's so hard about modifying an online document.

Oh, and this isn't a bug, as such, so it really doesn't belong in this forum.

Actually, it is. Straight from the forum help:

"BYOND Bugs
This board is where you report errors with BYOND. Anything that does not function as it properly should in the documentation is a bug. If a BYOND program crashes, or if it otherwise causes ill effects to your computer, that is also a bug. Errors with your code are not bugs unless you are certain it cannot be a problem with your code. For example, an error message that you don't understand is not a bug, but a misunderstanding. Most of the time, people will be forgiving if you mistakenly report a bug."
Jan 8 2005, 4:05 pm (Edited on Jan 9 2005, 1:03 am)
In response to Vizuke
Vizuke wrote:
> mob/verb/commune(M as mob in world,txt as text)
>    M << "[usr] communes to you, '[txt]'"
>

Nothing is wrong with this. They already declared M as a mob hence the "as mob" so there is no need to put mob/M but you can put it if you want. Here's another way you can also do it which uses mob/M but not the "as mob".

> mob/verb/commune(mob/M in world,txt as text)
>    M << "[usr] communes to you, '[txt]'"
>


Nope. See, the "mob/M" part tells the compiler to think of M has a mob, while the "as mob" part tells the compiler to actively restrict M to being a mob.

Of course, since we don't need to access any mob-specific functions, technically, you're right; there's nothing wrong with

mob/verb/commune(M as mob in world,txt as text)
   M << "[usr] communes to you, '[txt]'"


However, in a guidebook, it would be much better to have:

mob/verb/commune(mob/M as mob in world,txt as text)
M << "[usr] communes to you, '[txt]'"

In DM, it's usually better to have as much information in a variable as possible.

The example, in the guide, for example, could lead a beginner to do this:

mob/verb/commune(M as mob in world,txt as text)
   M << "[M.key] communes to you, '[txt]'"


Since the compiler doesn't know that M is a mob in that example, that actually wouldn't even compile.

[edit]
In my uncompilable example, I accidently put usr.key instead of M.key, so it would have compiled before <_<.
Jan 8 2005, 4:43 pm
In response to Wizkidd0123
Wizkidd0123 wrote:
That's no reason not to fix the DM Guide.

If it ain't broke, don't fix it.

I don't call people ignorant or stupid very often.

Perhaps not, but I do find your superior attitude grating sometimes.

Still, not agreeing with me isn't even my problem here. My problem here is that you said that the guide shouldn't be fixed because if beginners screwed up, then they would have to go to the forums and get help.

But what would they really learn from having the Guide handfeed them everything? Better to run into an easily detected and easily fixed problem and learn from the experience than to do something "just because".

I really don't think I know everything about DM. I know that there's plenty to learn; there always is. However, I think that saying the DM Guide shouldn't be fixed since if it was fixed, people wouldn't need to ask for help, is, in my opinion, pretty ignorant.

That was not the intent of my comment. You appear to have misinterpreted it.

I never said I thought that it was urgent.

You said it was "simply wrong", which implies that it's very very wrong, meaning that it urgently needs to be fixed. It may not be ideal, but it's not "simply wrong".

Crispy, you're a forum mod. You should know that the forums aren't the place for arguments like this.

Oh? Then where, pray, is? Email? Your email address isn't publicised. If you want to take this conversation off the forums, then that's your prerogative; I can't do anything about it. My email address is public for a reason.

Forgive me for not being a pillar of wisdom and patience ALL the time. I do my best, but I'm not a robot.

It's online. Remaking a book would be one thing, but I don't see what's so hard about modifying an online document.

Point. Still, it's a pretty minor thing.

Actually, it is. Straight from the forum help:

"BYOND Bugs
This board is where you report errors with BYOND. Anything that does not function as it properly should in the documentation is a bug.

But it DOES function as it properly should. A certain modification to it may not function, but the modification isn't in the DM Guide, is it now? =P Still, I guess it's close enough, so I'm not going to argue the point further. =)
Jan 8 2005, 4:43 pm
those examples of yours do different things. making it mob/m or m shouldn't change the behavior.
Jan 8 2005, 4:48 pm
In response to Wizkidd0123
Wizkidd0123 wrote:
> mob/verb/commune(M as mob in world,txt as text)
>    M << "[usr.key] communes to you, '[txt]'"
>

Since the compiler doesn't know that M is a mob in that example, that actually wouldn't even compile.

that wouldn't? try it =P
Jan 8 2005, 7:06 pm
If you don't like the way its written, then I suggest you rewrite it and send it to the relevent people. I'm sure they wouldn't mind, busy as they are.
Jan 8 2005, 7:18 pm
Wizkidd0123 wrote:
But in DM, it's always important to give as much information about a variable as possible:

In DM, it's always important to give as much information about a variable as is necessary. In the example you cited, the << operator performs the correct action regardless of whether the compiler knows that M is a mob. The fact that M is a mob is completely irrelevant, and therefore unnecessary to specify.

Indeed, because of the "as mob" declaration, M is guaranteed to be a mob whenever commune() is called as a verb. However, what if you decide later to allow players to commune to their entire team. You could reuse the commune() verb as is, but call it as a proc, passing in the team as list:

mob/var/team[0]
mob/verb/commune_group(txt as text)
    commune(team, txt)


The important thing for a newbie to learn is that you should never specify too little information about a variable's type. That can always get you into trouble, especially if you start using the : operator to avoid compile errors. But at the same time, there's no reason to specify more than you need to.
Jan 9 2005, 1:02 am
In response to OneFishDown
OneFishDown wrote:
Wizkidd0123 wrote:
> > mob/verb/commune(M as mob in world,txt as text)
> >    M << "[usr.key] communes to you, '[txt]'"
> >

Since the compiler doesn't know that M is a mob in that example, that actually wouldn't even compile.

that wouldn't? try it =P

That was slow of me <_<

I meant to say:

mob/verb/commune(M as mob in world,txt as text)
    M << "[M.key] communes to you, '[txt]'"


That wouldn't compile.
Jan 9 2005, 1:05 am
In response to Crispy
Crispy wrote:
Crispy, you're a forum mod. You should know that the forums aren't the place for arguments like this.

Oh? Then where, pray, is? Email? Your email address isn't publicised. If you want to take this conversation off the forums, then that's your prerogative; I can't do anything about it. My email address is public for a reason.

Actually, I was thinking Chatters =P. My email address isn't public, because when it was, people would actually email me for programming help sometimes, and it got annoying enough for me to make my email private.

But it DOES function as it properly should. A certain modification to it may not function, but the modification isn't in the DM Guide, is it now? =P Still, I guess it's close enough, so I'm not going to argue the point further. =)

Good point.
Jan 9 2005, 6:09 am
In response to Wizkidd0123
Wizkidd0123 wrote:
> mob/verb/commune(M as mob in world,txt as text)
>   M << "[M.key] communes to you, '[txt]'"
>

That wouldn't compile.

right, but M isn't the person talking =)
Jan 9 2005, 10:31 am
In response to OneFishDown
OneFishDown wrote:
right, but M isn't the person talking =)

What if M has schyzophrenia =P?
Jan 9 2005, 12:13 pm
In response to Crispy
boy i wish BYOND had some sort of communication system that was separate from the forums but wasn't e-mail, so that you could communicate with BYONDers by only knowing their key.

P.S. and they should call it the pager
Page: 1 2