Editing Map Object Instances in Bug Reports

ID:120336
 
Oct 22 2011, 4:01 pm
BYOND Version:493
Operating System:Windows 7 Home Premium 64-bit
Web Browser:Firefox 7.0.1
Applies to:Dream Maker
Status: Deferred
This issue may be low priority or very difficult to fix, and has been put on the back burner for the time being.
Descriptive Problem Summary:
Editing certain new variables through the map editor (step_x/y) will not properly save as a new "instance" of the object. It won't show up in the available instance list under the mini-map, nor will the values themselves properly save. If you right click > Make Active Object and place a duplicate of the object, the edited variable will be marked as edited with bold text, but it will be set to the original value. If you edit an additional value, like the object's name, then it will properly show up in the instance list, but the step_x/y (and possibly other vars?) still won't be loaded properly.

Numbered Steps to Reproduce Problem:
Place an object on the map
Right Click > Edit its step_y to 16
Right click > Make Active Object
Place another copy of the offset object
Right Click > Edit > notice step_y is bold, but set to 0
#1 Oct 23 2011, 7:07 pm
This also causes problems when you change default step_x/y via code
#2 Oct 26 2011, 4:29 pm (Edited on Oct 27 2011, 6:14 am)
After doing a bit of mapping, its probably best that these values aren't saved for the instance list, since it would quickly get spammed with offset objects. However, I think right click > make active object should still properly duplicate the step_x/y. If possible. And its still buggish how it incorrectly saves the values as edited to default.
#3 Jul 13 2012, 6:04 pm
Tom changed status to 'Deferred'
#4 Jul 13 2012, 8:45 pm
We were able to reproduce and correct this behavior. However, I'm tentatively going to stick with the current system because it seems more desirable in common cases (that is, if you use ALT+click to offset an object on the map, and later make it the active object to replicate it, it doesn't seem like you'd want the step offsets to be copied as well, since the placement is usually instance-specific).

We'll probably revisit this system at some point. I think placement would make a lot more sense if we graphically showed the position of the atom(s) before placement rather than using a selection box. This kind of ties into the report because my main gripe with the proposal is that when you offset an instance and later try to place it, it doesn't fall where you want it to. Resetting the offsets to their base values (as it is in the current implementation) makes more sense here.

Hiding the step/pixel-offset instances is by design, so it doesn't spam the list, as you noted.

The part about the instances being created even when they are simply copies of the original (with the step vars reset to their initial values) is indeed a bug, but it's pretty minor.