Multiple maps

ID:133642
 
Apr 12 2008, 7:25 am
I would really like a lift of the limitation for multiple maps. I understand there are some complications behind this, so I'll offer my proposed solution for each problem as I encounter them. So far, I think the only issues involve client.screen, client.eye/client.virtual_eye, client.view, and client.statobj. I think I have reasonable solutions for each of these.

The client.screen property imposes the first direct problem, I think. Developers would want to add things to a player's screen, without affecting every map. Whatever new method is introduced needs to be backwards-compatible. My idea is to assign each map control a screen property, that you can do something like the following for:
var/list/s = params2list(winget(client, mapCtrl, "screen"))
s.Add(O)
winset(client, mapCtrl, "screen=\"[list2params(s)]\"")

...or something to that effect. Then if we continue the interface's system of "default" values, like with input controls and such, we can use client.screen to refer directly to the default map control's screen list. So, then, client.screen += O would be roughly equivalent to the above code. Alternatively, here, each map would have a screen value, as would each client, and changing a client's screen property would indirectly update the map's value. This, I think, would work best in situations where the value of client.screen needs to be maintained without a map.

I think the same method of conversion would work well for client.eye/client.virtual_eye, with transferring the values to the map control, and using the client properties as values for the default map control. client.statobj would then be reworked into the actual info controls; the control would keep an object reference, and update its verbs and statpanels based on the object reference it contains.

I imagine I'm proposing a fair deal of tinkering, if this proposition is even doable, but I think that multiple maps would have a great deal of uses, especially in cases where multiple windows are desired to display different graphical information. As well, if you think of the Nintendo DS, placing two maps side-by-side would be a great way to handle the separation of, say, the character's world and a map, or other such information.

Hiead
Apr 13 2008, 12:34 pm
Yeah, my biggest gripe with the 4.0 feature set is the lack of ability to specify a disjointed, seamless screen. Grids come close, but there's always that little one-pixel line to worry about. You can fake it with 32x32 labels and handle all of the drawing yourself, but it is inefficient, resource-intensive, and feature-limited (no mouse clicking).
Apr 14 2008, 9:11 am
The variables assigned to the client object should remain, and they belong to the main screen.

I would however like to see it like this:

client_screen
    var
        pixel_x = 0
        pixel_y = 0
        atom/eye
        atom/virtual_eye //read-only
        list/screen
    attachTo(client/C, id) //built-in proc that does internal stuff here
        return ..()

client
    var/client_screen/screen2
    New()
        .=..()
        screen2 = new //creates a new screen datum.
        screen2.attachTo(src,"default.map2") //binds the screen to the map\
won't work if the selected element id is not a map element or the element is the default
        screen2.eye = locate(50,50,1) //updates the eye immidiately w/o a delay (winset gives a delay..)


-- Data
Apr 14 2008, 12:14 pm
The concept of multiple maps is actually much more difficult. It involves multiple eyes, multiple screens, multiple everything, and new messaging support to deliver them. The way all this is done internally, it's far, far more complicated than it sounds.

Also, I don't think the winset approach would work, because 1) you can't send whole objects that way, and 2) it would require complex parsing, rendering it slow.

Lummox JR