ID:2244866
 
Resolved
Many hard-coded procs such as Move() did not handle arglist calls gracefully. This has been rectified for movement-related procs but still needs changing for some other built-in object procs.
BYOND Version:511
Operating System:Windows 7 Pro 64-bit
Web Browser:Chrome 57.0.2987.133
Applies to:Dream Daemon
Status: Resolved (512.1396)

This issue has been resolved.
Descriptive Problem Summary:
runtime error: undefined proc or verb /list/Enter().


I have two environments: one uses pixel movement, the other uses tile movement, but both use the same hooks for atom/movable/Move() handling (with minor editing for pixel vs. tile movement).

Here's the problem section of code:
. = (moving_flags & MOVE_FLAG_FORCE) ? (args) : (can_move(newloc, dir) && on_move(newloc, dir))
if(.)
// using this line produces the run-time error posted above,
// but ONLY in ONE project.
. = ..(arglist(.))

// using this line poses no problems
//. = ..(.[1], .[2])

if(.)
on_moved(oloc, odir, move_source)


In my project that uses pixel movement, no run-time error is produced using the above setup. However, the tile movement project produces the error consistently.

Important to note though, it doesn't matter, pixel or tile movement, as I was able to reproduce the issue in a fresh environment using both pixel and tile movement.

In short, I don't know what the problem is exactly, only that there is some inconsistent behavior present here that's beyond the soft-code.

What I do know, though, is that arglist() is supposed to work with Move() according to the reference, as the latter accepts named arguments.

You can find a fresh demo here.

Expected Results: For Move() to return successfully without producing a run-time error despite parameters being valid.

Actual Results: Move() produces the run-time error posted above.

When does the problem NOT occur? Avoid using arglist() and instead directly input the arguments.

Workarounds: Avoid using arglist() and instead directly input the arguments. None.

In response to Ter13
Yeah, definitely.
Could we get this looked into in the near future? It's turning out to be a major pain. I just came across an issue where my obj that has a bounds larger than 32 (world.tile_size) cannot move at all due to Move() being broken unless I do one the following:
  • Remove all passed args to the parent call to Move(). Problem: I'd then have no simple way of tracking move metadata changes on a move-per-move basis.
  • Reduce the obj bounds to 32 (world.tile_size). Problem: I'd have to use multiple objects to act as a single object covering the necessary area... undesirable to say the least.
Here's a test case for the issue described in my last post (related to the original problem)...

Here

Just run the environment and use the "test" command. You'll notice the created object doesn't move when it should.
I've got a tab open for this and do plan to look into it.
In response to Lummox JR
Did anything ever become of your investigation?

I found myself encountering this issue again and thought I'd revisit this topic.
Lummox JR resolved issue with message:
Many hard-coded procs such as Move() did not handle arglist calls gracefully. This has been rectified for movement-related procs but still needs changing for some other built-in object procs.
That's wassup! I'll keep this in mind when I got some more green to spare.