ID:1393580
 
Resolved
The map editor showed objects in the wrong position if their height was not a multiple of world.icon_size.
BYOND Version:500
Operating System:Windows 7 Home Premium 64-bit
Web Browser:Chrome 30.0.1599.66
Applies to:Dream Maker
Status: Resolved (500.1213)

This issue has been resolved.
I am not solid on if this is a bug or not, but I'd rather be safe than sorry. So I have these two simple definitions for two objects:

obj
tree
icon = '\icons/Tree.dmi'

bound_x = 39
bound_y = 5
bound_width = 20
bound_height = 25
density = 1
Computer
icon='\icons/Computer.dmi'
icon_state=""
density=1
bound_y = 1
bound_height = 28
bound_width = 50


Now when I go to place them on the map, the tree works fine:


But when I try to place the computer, this happens:


Once I compile, it fixes itself(sort-of):


The density works fine in game and the object seems normal, but it stays moved down all those pixels from where I placed it. The bottom of the computer just "added itself on" when I compiled.

When I try to delete the object, this is left behind:


And it disappears when I recompile.

This also happens with other objects, such as this bed:


So...yeah.
I don't really have enough descriptive information to reproduce this issue. At the very least I'm pretty sure I'd need a test case, a project I can use to reproduce this, but you're being very vague in your descriptions. Are you saying that when you place or delete an object, part of the map doesn't visually update? "This happens" isn't really all that clear; the pictures help, to the point where I think I see what the issue is, but you need to be as clear as possible when posting a report.

Again, too, I need the full version number, including the minor build. There were issues with the map that should have been fixed in earlier builds. So far it looks like you've posted two bug reports from an old version because you didn't realize you were still using it.
500.1212. I just reinstalled after I said I was in the other thread.

I'm trying to be clear, but it's a bit hard to describe a visual issue better than pictures. I guess all I can say is that certain objects are being "pushed down" when placed on the map. The bottom half of them are cut off, but the half reappears after compiling, however the strange repositioning that happened is retained.

I'll page you a test case, because this is my entry for the contest.
Albro, I don't know if you already know this or not. But, I think it'd help you set bounds better.
obj/object
bounds = "fromx, fromy to endx, endy"

is the same thing as
obj/object
bound_x/y
bound_width/height
In response to Flysbad
Where is that documented? I never saw that anywhere.
In response to Albro1
I don't think it's documented anywhere, but a friend of mine told me about it when I was struggling with setting bounds. I've been using it ever since I found out about it, pretty helpful if you ask me.
It's not documented; but it's been known since the begining of pixel movement. It was Tom and Lummox's initial idea of setting bounds, iirc. I didn't include it in the Red Book because I'm lazy, and none of the other people allowed to edit the Red Book decided to add it.
Flysbad wrote:
obj/object
bounds = "fromx, fromy to endx, endy"

Super Saiyan X wrote:
It's not documented; but it's been known since the begining of pixel movement.

You mean to tell me that I can set all 4 bounds using a single statement?! I'm starting to feel like half of the language just isn't documented at all. Some of this stuff is too important to just sweep under the rug.

Considering that programming is already a very obfuscated subject as it is, I don't think anyone seeking to understand it is going to be frightened by these arcane features. I don't like all these scavenger hunts that we have to go through. It would be nice to just have everything right there on the table.
In response to Multiverse7
Multiverse7 wrote:
You mean to tell me that I can set all 4 bounds using a single statement?! I'm starting to feel like half of the language just isn't documented at all. Some of this stuff is too important to just sweep under the rug.

Considering that programming is already a very obfuscated subject as it is, I don't think anyone seeking to understand it is going to be frightened by these arcane features. I don't like all these scavenger hunts that we have to go through. It would be nice to just have everything right there on the table.

From a prior conversation I had with Lummox:
Yeah. It's just a shortcut for using the others. We didn't document it because Tom felt it would be too confusing on the first pass, just too much to absorb right now, and since it only covers rectangular bounding boxes it wasn't considered important to document.

It was added for when they planned to have like, circular bounds and things outside of just rectangles.

The majority of undoc features are just shortcuts; shortcuts which will definitely confuse new users. A lot of them are documented...just not officially. (See, the past 13 years of the forum, the Bwicki, and the Red Book)
In response to Super Saiyan X
Super Saiyan X wrote:
The majority of undoc features are just shortcuts; shortcuts which will definitely confuse new users.

There is nothing confusing about most of the undocumented features that I have seen. It's really just that fact that they are undocumented that makes them seem that way. The most scary one is 1.#INF/IND The rest would make sense if you just officially documented them. From what I have witnessed, nobody ever really knows about the Red Book, and good luck to those who want to travel back in time to read the Bwicki. As long as this stuff remains undocumented it will be... undocumented.
In response to Multiverse7
Multiverse7 wrote:
The format looks pretty rectangular to me. I don't see how that could relate to other shapes.
Clearly, the feature hasn't been added it; it's there just in case they want to expand the format. As Tom said, "In theory, a text-based bounds format allows arbitrary precision, though."

There is nothing confusing about most of the undocumented features that I have seen. It's really just that fact that they are undocumented that makes them seem that way.
Try explaining the fact that verbs and procs are objects with their own variables, to someone who is new to DM.

From what I have witnessed, nobody ever really knows about the Red Book,
thus why it's stickied in a forum.

and good luck to those who want to travel back in time to read the Bwicki.
http://web.archive.org/web/20061208103304/http:// bwicki.byond.com/ByondBwicki.dmb?UndocumentedFeatures

As long as this stuff remains undocumented it will be... undocumented.
THUS, we document it.

A lot of "undocumented" features are really old features that were moved - or were documented at one point but were removed - some things, were only documented in release notes (like, the for-to-step format, and importing your own font).
Making the Red Book a sticky, or using hacks like the Wayback Machine just isn't the point at all. Nobody should have to rely on such things. It should all be somewhere in the reference, even if a separate section has to be made.

I guess I shouldn't complain though. The official Guide hasn't even been updated in years, and the actual BYOND development team == 2 people, so I guess I can't expect much to be done. I do think it would have been nice to keep the Bwicki though.
Lummox JR resolved issue with message:
The map editor showed objects in the wrong position if their height was not a multiple of world.icon_size.