ID:260754
 
Freaking awesome. I sleep for four, maybe five hours, and I come back to see this.

Still, I have to be nitpicky; how close are we to being able to a 'full' secondary map control? Is it possible to make a simple "MapSet(elem, center, pixel_x, pixel_y)
proc which sets up a second map?

The trouble with this post is that I don't wish to be rude (I *really* like the work you guys have done here) yet I am curious if the above would now be more easily implemented.
Android Data wrote:
Still, I have to be nitpicky; how close are we to being able to a 'full' secondary map control? Is it possible to make a simple "MapSet(elem, center, pixel_x, pixel_y) proc which sets up a second map?

Relatively speaking, the second HUD is much easier, because it's really just a front-end trick to tell elements that always existed to display in a separate control. Being able to support multiple views is not intractable, but quite a bit harder. The server assumes a single view per client, and a lot of functionality (like accessible objects & verbs) relies on this. In a way, the HUD is really a "native" drawing mode for BYOND, because it lets developers code exactly what the client sees without relying on the hard-coded map or view restrictions. As such, it's a lot easier for us to manipulate.

At any rate, we'll continue to think about ways we can open up the map further. We have a number of bigger projects just on the horizon that are tangentially related.
In response to Tom
Tom wrote:
The server assumes a single view per client, and a lot of functionality (like accessible objects & verbs) relies on this.

I don't think accessible objects & verbs should even be a problem, since the MapSet() idea would only cause an area of the map to become visible. Interaction like clicking should continue to work, but verbs aren't really necessary with this anyway (and not really feasible given the new 4.0 architecture).

In a way, the HUD is really a "native" drawing mode for BYOND, because it lets developers code exactly what the client sees without relying on the hard-coded map or view restrictions. As such, it's a lot easier for us to manipulate.

The problem that remains with the hud vs. a view is that when a player moves inside a viewpoint, you can see the player move properly (with animate_movement and everything). With screen elements, this is not the case; players "hop" from tile to tile.

At any rate, we'll continue to think about ways we can open up the map further. We have a number of bigger projects just on the horizon that are tangentially related.

I think it would be cool if there'd be some kind of animate_movement for HUD objects, as well as the ability for HUD objects to Move() to some place within the HUD. Could Move("mysecondmap:4,4") do the trick?
In response to Android Data
Can someone tell me what second HUD is supposed to do, and how to use it, when I might want to use it, and what it has over just simply putting map controls say in the map control, etc...?
In response to Dan0971
You might find this article interesting reading. The Dream Makers articles are a good source in general!