I'd like to confirm that this is a known limitation of the software which is not being addressed any time soon.
I'm having difficulties loading a dynamic map. What I have is a very simple test world.
Downloadable testcase: testcase_src.zip
The test case contains a single .dm file with the following code:
/world/New()
// Calling ..() doesn't work (and is not ideal in my case)
// . = ..()
world.maxx = 250
world.maxy = 250
world.maxz = 1
var/icon/white_tile = new/icon(icon = 'blank.dmi')
white_tile.DrawBox(rgb(255, 255, 255), 1, 1, 32, 32)
for (var/turf/T in block(locate(1,1,1), locate(250, 250, 1)))
T.icon = white_tile
. = ..()
mob/verb/test()
src << "Maximum coordinates: [world.maxx], [world.maxy], [world.maxz]"
// No effect.
// loc = locate(1,1,1)
// Nope.
// client.eye = src
// client.perspective = MOB_PERSPECTIVE
// That's not it either.
// client.eye = locate(5,5,1)
// client.perspective = EYE_PERSPECTIVE
It also contains an icon file with an empty state called "blank.dmi". I already know this is required if you want to make an icon from scratch (creating a new /icon object without specifying an existing file won't work)
Problem description:
When I use the above code executing the "test" verb will tell me that 250x250x1 has been allocated but I don't see the map on the screen.
When I create my own skin file (.dmf) with a default map control the control always shows up blank (black) as if client.eye is not focused on the map.
Any attempt to modify the location of the mob or client.eye does not update the map control, it remains blank/black.
The only workaround I've seen is to include an empty map file (.dmm) with a size of at least 1x1x1. This seems like a crude workaround to me so if there's something I'm doing wrong I'd like to know so I can remove this quirk from my project.
If this is a known limitation then at least this will document it, as I've searched the forum and there was no previous topic about this problem.
What I'd wonder is if the map is actually updating server-side or the variables are just being updated without doing anything, what happens if you output the contents of the turf(s) in question, do they actually exist or do they simply not generate at all?
The first would indicate things being disabled on the client to save resources on worlds without a compiled-in map, the second would indicate things being disabled on the server for the same reason.
Either way this is potentially a bug depending on if there's something deliberate being done with worlds without a map during the compilation process or not. It might just be an oversight in resetting a flag when a map comes into play.
The workaround you noted does indicate that it's definitely coming from something being set when the compiler doesn't find a map, and is probably your best bet for the time being. Doesn't exactly seem 'crude' to me, just a nice simple way of telling the compiler you're using a map.