Repost: http://www.byond.com/developer/forum/?id=740474
If you have a multi-tiled atom, using something like tree.png, and you edit a portion of it, like say the trunk to be dense for example, while the rest isn't; this no longer creates a new instance in the object list.
It'd also be nice if there was an option to delete all parts of a multi-tiled atom at once.
This is all in reference to the TILED_ICON_MAP map_format.
Also if there was a "reset to default" option in the right click menu on the map editor. Since as it is now there's no way to do that - manually resetting values does not produce the same results.
ID:97664
 Jun 28 2010, 12:35 pm
|
|||||||||||||
| |||||||||||||
|
Jun 29 2010, 8:59 am
|
|
Lummox JR
   |
I'm not sure I really follow what you mean here. Could you elaborate on this issue or perhaps provide a demo to describe what the problem is?
|
Uh, I think I explained it pretty well...
If you edit a single tile tree object (a regular 32x32 .dmi icon_state) through the map editor, that edited tree will be listed in the object section under the mini-map in the map editor. If you edit a multi-tile tree (like one made with a 96x96 Tree.png) in the same way, then it won't be listed, only the original will ever show. However, it used to in previous versions of BYOND. | |
In what way was this previously listed differently? Did editing a sub-tile create a brand new full set of instances, or did it just create an instance for the single edited tile? A lot more information would help here, although I'm not so much concerned about the change in behavior as long as whatever new behavior we use is workable. If there's something even more convenient than the old way, or any ideas in that direction, that would help too.
| |
Lummox JR wrote:
In what way was this previously listed differently? Did editing a sub-tile create a brand new full set of instances, or did it just create an instance for the single edited tile? Whatever you edited in a single group of atoms would create a new instance with matching settings. So if you had one tree with a dense trunk, and another tree that was entirely dense, while the original wasn't dense at all, you would end up with 3 listed. A lot more information would help here, You could try installing an old version and seeing exacts, though I'm not sure which version this changed in. Probably the one where TOPDOWN map_formats were added. If there's something even more convenient than the old way, or any ideas in that direction, that would help too. Not particularly, the old way got what was needed done, and I can't really think of any improvements atm. Basically I would code the tree object, with density 0 on a layer like 5 or so. Then place that default tree on the map, and edit the trunk of the tree to density 1 and its layer 3 or so. Then that would create a new tree listed in the object section, which I would select and use for the placement of all future trees to they had proper density and layering. The only thing I can think of, though its mostly unrelated, is being able to mass edit/reset/delete/etc multi-tiled atoms from the map editor. | |
As a note here, the old behavior apparently was that when editing sub-tiles, edits made to those affected the entire instance. The ideal behavior would be to create a new instance.
| |
Because this is not trivial to solve, this issue is being deferred until a later date. As a workaround, you do have the option of using Copy and Paste to copy several tiles at once, so in effect this creates a virtual instance.
| |
You can't effectively copy/paste trees over eachother
| |
Another possible workaround is to add the density at world startup.
| |
Indeed. That's what I do now, along with changing their layer.
| |