Dream Maker Map Icons in Bug Reports

ID:97992
 
Jul 3 2010, 5:34 pm
Not a bug
BYOND Version:471
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Internet Explorer 8.0
Applies to:Dream Maker
Status: Not a bug
This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND Developer forums.
Descriptive Problem Summary:
Changing the icon_state of an image in a *.dmi that is over 32x32 pixels does not change any placed in the Map Editor.

Any new obj/turf you create on the map of that type will have the new icon_states but any ones placed before the changes wont update at all. You have to delete them.

Numbered Steps to Reproduce Problem:
Add a turf or object to the map. Compile. Then change its icon state in the code. And compile again. It wont update.

Expected Results:
The icon_state of the obj/turf to change accordingly after compile.

Actual Results:
Nothing happens. It stays as it was.

Does the problem occur:
Every time? Or how often? Everytime.
In other games? Expect so.
In other user accounts? Yes.
On other computers? Yes.

When does the problem NOT occur?

Using any version prior to v471.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked?

This did not happen in versions prior to v47x.

Workarounds:

Delete the object/turf on the map and re-add it.

#1 Jul 4 2010, 9:06 pm
Can you narrow this down more specifically? Mapping behavior did not change in 470 so I think it's likely that this would have been an issue before that.
#2 Jul 5 2010, 7:21 am (Edited on Jul 5 2010, 7:47 am)
Well with v470 changing any icons over 32x32 resulted in the icons looking currupt & displaying incorrectly on the map. But im pretty sure it updated the icon_states on the map when u changed the code...

I'm sure id have noticed this issue before now, because im not doing anything special (new) with my game.

In v471, if you change the icon_state of an object/turf over 32x32 (and its already placed on the map) it wont update it. The icon state on the map remains the same as it was. If you place a new object/turf of that type down, it shows the updated icon_states.

It's not a *major* issue but its quite annoying and time consuming if u make changes to icon files and adjust their states.

I will try v46x and just confirm the issue did not affect it.
#3 Jul 6 2010, 7:58 am
I can't confirm this in a test project. Taking a large-icon turf in an isometric world, I changed the icon_state for the turf. As soon as I recompiled, the turf on the map changed its appearance.

However, you didn't mention what map format you were using. I was using standard isometric, which is a large-icon format. Are you using TILED_ICON_MAP? Given the lack of other information to go on, a (small) demo project would be helpful if you have one.
#4 Jul 6 2010, 4:18 pm
Yes TILED_ICON_MAP not isometric. I am in the middle of recovering my PC at the moment (things always happen at bad times) but will get something posted ASAP.
#5 Jul 11 2010, 7:59 am
http://www.youtube.com/watch?v=NILxKkEC00Q

Before I try this with v46x. Thought a video might help demonstate this.
#6 Jul 14 2010, 7:16 am
That does show the bug in action, although it does not substantiate your claim that this didn't happen in older versions. I'd like you to retest that because frankly I think that information is incorrect and it helps to have valid info to work with.
#7 Jul 15 2010, 11:40 am (Edited on Jul 15 2010, 11:49 am)
Lummox JR wrote:
That does show the bug in action, although it does not substantiate your claim that this didn't happen in older versions. I'd like you to retest that because frankly I think that information is incorrect and it helps to have valid info to work with.

I tried v469.1074, v468.1072 and v467.1069 and this issue is actually worse. Which shocked me because id have assumed that id notice such a huge problem over so many versions hummm.

In these versions it does not change the icon_state of the ones on the map, and also any new ones! Even though the icon of the object you are placing in the side panel shows the correct state.

Once you place down, have the old state on them.

EDIT: Just incase it makes any difference, the icon file in question is 215 x 95 pixels.

EDIT #2: Curious. I just noticed that TURF changes seem to be working. But OBJ/ fail to update. Will check this out in the current version.

EDIT #3: No, TURFs fail to update in v47x. Not the case in v467.1069 though. TURFS seem to update but not OBJs.
#8 Jul 16 2010, 6:33 am
I made a test environment of this, things worked fine for me in both TOPDOWN and TILED_ICON map_formats.
#9 Jul 16 2010, 5:12 pm
Falacy wrote:
I made a test environment of this, things worked fine for me in both TOPDOWN and TILED_ICON map_formats.

Thats because you are using *.png files directly. Which have no states to change.

I have changed the src to reflect the issue.

http://www.megaupload.com/?d=J9FKA10Y

If you open that 'as is' and look at the map, the placed obj/ that is red actually has a "blue" state.

It will show as much at the side in the object/turf tree as well. Place a new one and it will be BLUE. The only way you'll get the RED one to change is to delete it or edit its state manually tile by tile.



#10 Jul 20 2010, 2:28 pm
It doesn't make sense that you'd see different behavior between turfs and objs in 467. I think however things are being clouded by the fact that there's no default fallback turf in your project which shows the special big turfs separately. When I tested in 467 I found the behavior to be identical to the current version, as expected.

From what I can tell, this problem is not easily solvable, but neither is it new. The reason the icons don't change is that the state has to be set specially for each instance when it is placed, because it's not just the original atom but one being broken up into constituent pieces. Because this behavior generates new instances with specific icon states, the behavior I'm seeing actually makes perfect sense and therefore is not a bug. Having the instances change for you in these cases would, I think, represent more of a feature request.