turf/DblClick()
// works
reach_angle(usr, 32, 0, 96)
// does not work
reach_angle(usr, "1,1 to 32,32", 0, 96)
proc/reach_angle(atom/ref, size = 0, angle, reach = 0)
try
var/turf/ref_loc = ref.loc
// cp for collision particle
var/obj/cp = new/obj {layer = 9; alpha = 160; icon = 'pixel.dmi'; color = "red";}
cp.bounds = size
cp.SetCenter(Cx(ref), Cy(ref), ref.z)
var/matrix/m = new
world.log << cp.bounds
world.log << cp.bound_width
world.log << cp.bound_height
world.log << cp.bound_x
world.log << cp.bound_y
m.Scale(cp.bound_width, cp.bound_height)
var/width = 1
var/new_size = floor(width * size)
var/new_translate_x = (new_size - width) / 2
m.Translate(new_translate_x, 0)
animate(cp, transform = m, time = 1)
catch(var/exception/e)
debug("reach_angle() failed: [e.name]\nFile:[e.file] \nLine: [e.line] \nArgs: [list2params(args)]")
Given my snippet above, I'm experiencing inconsistent behavior with the way the bound_* variables are read, I think. You can see from line 1 of the snippet that passing a number produces the expected results when the matrix is applied to visualize the box. However, passing bounds as a string applies this weird offset, despite values reading the same for both input cases. For example, passing the number 32 to reach_angle would produce the following debug output:
32,32
32
32
0
0
The behavior is the same as if bound_x/y were applied to the obj.
Here is a test project.
Numbered Steps to Reproduce Problem:
1. Launch the test project.
2. Proceed to double-click a turf in view.
3. Observe results.
Expected Results: I expect for both bounding boxes to appear the same, regardless of whether a string or a number was the input.
Actual Results: Using a string as an input for the bounds variable produces different results than using a number. The behavior is the same as if bound_x/y were applied to the obj.
Does the problem occur:
Every time? Or how often? Every time.
In other games? Yes; successfully reproduced in a test project.
In other user accounts? N/A
On other computers? N/A
When does the problem NOT occur? It does not.
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.): N/A
Workarounds: Not using a string input.
number (width=1) times a string (size = "1,1 to 32,32")
wut
(this is the problem)