Skip to main content
A view is a named map: its own markers, camera limits, look, interactions and interface. A resource registers one, then opens the map with its id. Use a view for a map that is not the world map, such as a property viewer, a job board or a delivery selector. For adding markers to the standard map, use AddBlip instead. See Exports. Nothing is resolved when a view is registered. Everything (the configuration, the views it extends, the parameters it was opened with) is worked out when the map opens, so a reloaded config or an edited parent view reaches every view built on it without anyone registering anything again.

Calls

RegisterView answers whether the view was accepted. A view whose fields are of the wrong kind is refused, with the reason in the server console, rather than being carried into a map that then fails to open. The standard map is registered under the id world. Registering a view with that id replaces it. When the resource that replaced it stops, or removes its view, the standard map comes back, so the menu always has a map to open. A view belongs to the resource that registered it. Only that resource can update it, register over it or remove it; UpdateView, RemoveView and RegisterView answer false to anyone else and say why in the console. The standard map is the exception: any resource may replace it, and the replacement then belongs to that resource.

Fields

extends

A view listed in extends is applied first, and this view’s own fields are applied over it. Camera and look groups merge key by key, capabilities and interface fields are replaced one by one, marker layers are matched by their id, and the handlers of both run.
Each view in extends brings the views it extends itself, however deep that goes. In a list, the view written first has the last word among them: extends = { 'a', 'b' } applies b, then a, then this view. A view reached twice, because two parents are built on it, is applied once. A chain that loops back on itself, or that names a view which is not registered, is reported and the missing level is skipped; the rest of the chain still applies.

show

What this view keeps in sight while hideWorld hides every other ped and vehicle. Each entry is a target, the same table AddWorldException takes, and applies only while this view is open.
A list is fixed when the view is registered. A function is called about four times a second while the view is open, so a unit that comes on duty appears without the view being opened again; keep it cheap. A list that does not read is refused with the view. An entry a function returns that does not read is left out, and the first reason is printed once. PatchView({ show = ... }) replaces the list on the open view and takes effect at once. A function that raises an error is reported once and not called again until the view is opened or changed again.

focus

Where the map opens, instead of over the player.

Marker layers

blips is a list of layers drawn together, each with an id of its own. A view that mirrors the world map and adds markers of its own is two layers, not a choice between them. filter(ctx, blip) returns whether a world marker reaches the map at all. decorate(ctx, blip) returns marker information (the same fields as SetBlipMeta) layered over what the marker’s own resource set. The blip it is handed has handle, coords, type, sprite, color, alpha, display, shortRange, route, entity, name, icon and category. refresh is a number of milliseconds. Left out, a layer is built once per open. A layer is also rebuilt on demand with RefreshView, or from a handler with ctx.invalidate(layerId).
A view mirrors the world map once: a second world layer is refused. Markers added with AddBlip, by any resource, belong to the world map too. A view without a world layer does not draw them, so it shows its own layers and nothing else; they come back when the view closes. The player’s arrow, the waypoint and points of interest are drawn on every view. A marker a layer returns that cannot be added, such as one without coords, is left out and reported once. The rest of the layer is drawn. A provider that calls done again replaces the markers it gave before.

Capabilities

Every capability is on unless the view turns it off. A capability is either a switch or a function asked again on every frame, which is how one depends on where the camera is or on what your resource knows at that moment.
The on-screen prompts follow the answers, so the player is never told about a control the view does not have. A view that turns exit off must close itself: from a handler with ctx.close(), or from your resource with Close.

Surface

What the interface draws around the map. Every field defaults to the panels set in Map, so a view that says nothing looks like the standard map. A page the view does not list is neither drawn as a tab nor opened by OpenPage. instructional as a function is handed the prompts the capabilities produced, so a view adds to them rather than restating them.

Parameters

Open takes a second argument, passed through to the view. A view that declares params checks it and turns it into what its handlers receive; returning nothing refuses the open, which is how a view states that it cannot be shown without being told what to show.
SetViewParams changes them while the map stays open: the markers, the rules and the interface are all worked out again. The new value goes through the view’s params first, the same as on Open. When params returns nothing, the view keeps the parameters it has and SetViewParams answers false.

Handlers

Handlers live under on and are all optional. Each is given the context first. Returning anything other than true, including nothing, lets the map’s own behaviour run as well. That is how a view adds to a behaviour rather than replacing it. A handler that raises an error is reported once and is not called again until the view is opened or changed again; the map stays open. The same holds for a capability, a marker filter and every other function a view supplies. Handlers of a view and of the views it extends all run, this view’s own first, and the first one to return true ends the interaction.

The context

Following a view from another resource

A view’s on handlers belong to whoever registered it. Everybody else is told what happened through events, and can refuse one thing through a hook. An event carries the view’s id, not its context. To act on the view from a handler, use the exports: SetViewParams, PatchView, RefreshView and Close. The hook is beforeOpen, registered with the map’s RegisterHook export. It is called with the view’s context before the camera moves, and returning false stops the map from opening.
The context is the one the view’s own handlers are given, minus any knowledge of what its parameters mean.

What happens

RegisterView returns true when the view was accepted. It is available to Open from that moment and stays registered until the resource that registered it stops, or until RemoveView is called. Opening a view calls canOpen, then the beforeOpen hook, then raises el:pausemenu:open and el:pausemenu:view:enter with the view’s id and calls onOpen. Once the camera has arrived, onReady is called and el:pausemenu:view:ready raised. Closing calls onClose and raises el:pausemenu:view:leave and el:pausemenu:close. See Events. Registering a view that is already on screen applies the change to it: the limits, look, rules, interface and markers are taken from the new definition without the map closing. Removing it closes the map, because there is nothing left to show.

Errors

Opening an id that was never registered opens nothing, and says so in the console. A view whose parameters are refused, whose canOpen says no, or whose beforeOpen hook is refused by another resource, also opens nothing. The player is left where they were. SwitchView asks the same questions before it closes the map on screen, so a switch that cannot happen leaves that map open. PatchView and ctx.patch check the patch the way RegisterView checks a view. A patch with a field of the wrong kind is refused whole: nothing changes, PatchView answers false and the reason is in the console. When a patch or new parameters take a page away from the view, a page that is on screen is closed and the player is back on the map. A hook that raises, or that does not answer within its deadline, counts as agreement: the SDK’s hook dispatch reports it and carries on, so the map is not another resource’s to break by failing.

Example

A property viewer: its own markers, no destinations, opening over one house, and a title that follows what it was opened with.
Adding to the standard map instead of replacing it. The destination is still set, and the resource is told about it: