http://www.byond.com/forum/?post=1718300
this should be fixed while looking at the ref too
In response to Lummox JR
Lummox JR wrote:
Hmm. 3 examples seems like it's probably enough, though. The tag and ref forms of locate() aren't given examples either, so this would probably be overkill.

So I was just reviewing lists and I saw that lists have 6 examples. All of which are helpful and great to have.

Should there be a set limit to the number of examples or like List should we just have as many as could help with the most common cases at the top?
I honestly don't see this thread going very far, ideally something like a mediawiki gets setup as it is FAR more manageable that a forums thread of all things
a properly...well-done Wiki is annoying to set up and maintain. I tried to do something with Nadrew's but I got lazy because there was far too much that needed to be done.

Could probably do a git repo.
In response to Lummox JR
Lummox JR wrote:
Hmm. 3 examples seems like it's probably enough, though. The tag and ref forms of locate() aren't given examples either, so this would probably be overkill.

http://docs.unity3d.com/ScriptReference/Physics.Raycast.html

He's right about the many examples. I didn't know how to do a lot of things until I was shown an example. Although, being presented with params should, in most cases, be enough. With Physics.Raycast() it wasn't. This can surely be applied to some of the procedures in DM. While I think it may be good to have many examples. I do think it'd be best to keep them at minimum for procedures that aren't that hard to understand. Who needs 6 examples on how to output to the world? Things like that.
! operator

See also:
&& operator
operators
|| operator
Format:
!A
Returns:
1 if A is zero; 0 otherwise.

It returns TRUE(1) when the value is empty, doesn't it? Not just numerical.
Should read

Returns:
1 if A is zero, an empty string, or null; 0 otherwise.

In response to Ter13
!A is also 1 if A is "".
In response to Kaiochao
Kaiochao wrote:
!A is also 1 if A is "".

"" is an empty string, so Ter's change reads correct.
I edited in response to his post. Kaiochao, per usual was spot on. Kaiochao: 4446, Ter: 1.
How about throwing something into del() in the reference that makes it clear not to rely on calling it yourself so much? Won't do much good for the existing programmers, but might help future ones avoid that annoying little pitfall.
"Destroy an object and null out all references to it. Procs that are executing with src equal to that object are silently killed, causing execution to return to the caller. If that is not what you want, you should detach the proc from the source object by setting src to null.

When an object is deleted, its Del() procedure is called. Currently, if the Del() procedure does not execute the default action (by calling ..()), then the deletion of the object is aborted. You should not depend on this, as it may change. In other words, be sure to always call the default handler after doing your own stuff."



"Destroy an object and null out all references to it. Procs that are executing with src equal to that object are silently killed, causing execution to return to the caller. If that is not what you want, you should detach the proc from the source object by setting src to null.

When an object is deleted, its Del() procedure is called. Currently, if the Del() procedure does not execute the default action (by calling ..()), then the deletion of the object is aborted. You should not depend on this, as it may change. In other words, be sure to always call the default handler after doing your own stuff.

While manual object deletion is useful in many cases, the search for live references to an object does take some time. The more active objects in the world, and the more variables in those objects, the longer the search will take. For larger projects, this search time can become significant. In these cases, as a best practice, manual deletion should be avoided by ensuring that all references to an object are taken care of when the need for object destruction arises. See garbage collection for more details.
In response to Ter13
I like your last paragraph, so I used it verbatim but with the following additional sentence before the last one:

"Objects that have no references are deleted automatically without the need for a search."
The guide also mentions that you can assign atom.icon to an object (any atom), and it'll copy that icon's icon value.

Not mentioned in the ref under icon var (atom).
The "in operator" page has bad formatting, and should probably also mention it's using in a switch() statement, and with the "to" operator.
I propose a change to 5 articles, and the addition of two articles:

New article: to operator

to operator

See also:
  in operator
  switch proc
  for range proc
  vars

The to operator is not a true operator. It is only meant to be used in combination with certain special patterns as a shorthand for a range of values. See the above linked reference pages for how to use the 'to' operator in each specific instance.


New article: for range proc

for range proc

See also:
  break proc
  continue proc
  do proc
  for list proc
  for loop proc
  while proc

Format:
  for(Var in [Start] to [End] [step Inc]) Statement

Args:
  Var: a variable to sequentially contain each value in the range.
  Start: the first number in the range.
  End: the last number in the range.
  Inc: default 1 if not supplied. After running Statement, change Var by Inc

First set the Var to Start, then perform the Statement. Continue performing the statement until Var is out of the range determined by Start to End. Statement may be a code block or a single statement.

step Inc may be omitted. If the step clause is omitted and Start is less than End, step will default to 1. If step is omitted and Start is less than End, the loop will not operate even once. The loop can be exited early with a goto, break, or return instruction is used to escape the loop. The statement can be prematurely terminated and the loop will move on to the next step if a continue instruction is used.

Example:

var/i
for(i in 1 to 4)
    world << i


This outputs:

1
2
3
4


Example 2:

var/i
for(i in 4 to 1 step -1)
    world << i


This outputs:

4
3
2
1


Example 3:

var/i
for(i in 1 to 10 step 2)
    world << i


This outputs:

1
3
5
7
9



Article changes:

in operator:

In addition, a value can be used to test whether a numeric value is within a range using a combination of the in and the to operator

Example:
var/x = 5
world << (x in 1 to 10) //outputs 1
x = 12
world << (x in 1 to 10) //outputs 0



for list proc

*add a see also link to the new for range proc page

for loop proc

*add a see also link to the new for range proc page

for proc

*add a see also link to the new for range proc page

vars

+add the following section

Atom variables can be assigned a restricted range of values during prototype definition. These are called variable input parameters. This will affect the possible values that can be assigned to an instance using the map editor's instance editor using the as, in, and to keywords. Any parameter specifiers that can be used in verb arguments may also be used here.

Parameter Declaration Format:

mob
    var
        money as num
        strength in 1 to 20
        alignment in list("good","neutral","evil")
        backstory as text


Any instance values entered in the map editor's instance editor menu that do not fit within the parameter ranges will be refused. This is a useful way to allow mappers to have limited control over dynamic changes to your project without having to know anything about programming and without you having to define dozens of variations of the same object by hand.
Might be good to include this information in the range() and view() articles: http://www.byond.com/forum/?post=2029828#comment18307300
The : operator example in the ref

world
mob = :player

(...)


Doesn't compile.
In response to Rushnut
Does it compile if you have /mob/player defined? That's what matters.
Page: 1 2 3 4