ID:195058
 
//Title: Independent Movement and Turning
//Credit to: Jtgibson
//Contributed by: Jtgibson


/*
This demonstrates a way of making an obj keep its current facing no matter which
direction it moves in. This gives you full control over adjusting src.dir as
you'd like to control facing.

You can, of course, replace the object type with any other type.
*/


obj/floating_thing
Move(loc, dir=0)
//Save the direction that the object moved in
var/tmp/argdir = dir

//Next, override that variable so the object does not turn while moving
dir = src.dir

//Call the default proc, which will not rotate the object at all thanks to
// what we've done. Read the Move() reference to see why this works.
. = ..(loc,dir)

//Now, we have src.dir which has not changed as a result of the move, and
// we have argdir which contained the direction of movement.
//You can now manipulate src.dir however you like if you want to make it
// face a direction of your choice.
Why would you need all the variable stuff? Can't you just override the <code>dir</code> arg?

mob/Move(loc,dir)
return ..(loc,src.dir)


Am I overlooking something?
In response to DivineO'peanut
This was designed to break down the entire process into individual steps to describe what exactly is going on, for the benefit of someone on Developer How-to. Your version is a compact version of the same thing (with the exception of the return blah instead of the . = blah), yes. Notable is that the bottom comment was intended as a "write additional code here" concept.
In response to Jtgibson
I understand what you're saying, but your code is repeating a default action of Move() (changing the atom's direction). While this has no impact on the actual result, it isn't a very good habit to learn so I don't think it should be in an example. You can cover the individual steps using comments.
In response to DivineO'peanut
DivineO'peanut wrote:
I understand what you're saying, but your code is repeating a default action of Move() (changing the atom's direction). While this has no impact on the actual result, it isn't a very good habit to learn so I don't think it should be in an example. You can cover the individual steps using comments.

It's copying the variable before using it, so you have two clearly-marked variables:

* argdir was the direction provided
* dir is the current direction after moving (src.dir is also the same)

Without those variables, you would be left with

* dir was the direction provided
* src.dir is the current direction after moving

The second one is very error prone, and not nearly as clear as the first.

This whole trend of over-optimising code drives me crazy. Every moderate or talented programmer around here thinks that if their BYOND program isn't compressed down to the size of a thimble then they're doing something wrong.

I can't stress enough: never optimise code that does not need to be optimised. Clarity is always more important than compactness and efficiency. The only time you ever want to optimise at the expense of clarity is in an inner loop for something that will be called many thousands of times per second. Remember the 90%-10% rule -- 90% of the time, 10% of your code will be being executed. Optimise that 10% only. Optimising the other 90% will be a waste of time.

If anything, my tendency over the past eight years of programming has been to add more whitespace, more comments, and more temporary variables than I used to.
In response to Jtgibson
I don't think my code is more error prone or less clear (although that may be because I'm used to programming like this)... but, point taken. My own philosophy is that code should be optimized when it's simple enough, but I guess it is stupid to criticize you because of it. It's probably my stubborness.