Field maps

Field maps are the native world-map panels opened by a map warp tile. daRPC exposes the panel only while an exact FieldMapPane is registered and visible in the supported client. Receiving the server packet alone does not make the resource active. The DLL caches a validated packet that arrives before the client registers the pane, then publishes it when the pane becomes visible. Pane visibility polling begins only after a validated definition is cached and runs at most once every 100 milliseconds. Packet observation remains immediate, and destination selection still validates the live pane before submission. The 7.41 client ignores bounded bytes after the declared destination records; daRPC does the same while still bounds-checking every known field.

Reading the active field map

curl "http://127.0.0.1:2626/clients/ZiLo/field-map"

The response contains observation metadata and a nullable field_map:

FieldMapState {
    revision: u32,
    field_name: string,
    current_node_index: u8?,
    destinations: Vec<FieldMapDestination>,
    selection: FieldMapSelection?,
}

FieldMapDestination {
    index: u8,
    screen_x: u16,
    screen_y: u16,
    name: string,
    checksum: u16,
    map_id: u16,
    map_x: u16,
    map_y: u16,
}

The daemon may reuse a serialized snapshot for up to 250 milliseconds after it is received. This coalesces concurrent reads instead of repeatedly walking client state. The endpoint does not depend on the daemon having observed every earlier state event, which is important because the panel can open and close during unrelated movement resynchronization. The selection endpoint forces a fresh snapshot before validating its revision and destination index.

field_name is the local asset stem, such as field001. The current node is nullable because a malformed or out-of-range server index does not identify a destination. Destination names are not required to be unique, so use index as the stable selector for one revision.

screen_x and screen_y are server fallback presentation coordinates. The client can replace them with values from its local <field_name>.txt asset. They are not guaranteed pointer-click coordinates.

The checksum and travel coordinates are exposed for observation and debugging. They are read-only command inputs. daRPC reconstructs the selection packet from the retained destination so callers cannot forge or mix travel fields.

Selecting a destination

Submit the current revision and one zero-based destination index:

curl --request POST \
  --header "Content-Type: application/json" \
  --data '{"revision":11,"destination_index":1}' \
  "http://127.0.0.1:2626/clients/ZiLo/field-map/select"

The direct Windows command is:

darpc field-map select --pid 1234 11 1

The daemon and DLL both validate the revision and index. HTTP 409 indicates no active panel, a stale revision, or a selection that was already submitted. HTTP 400 indicates that the index is not one of the retained destinations. HTTP 429, 503, or 504 indicates that the bounded live-client request path was busy, unavailable, or did not answer within two seconds.

The client normally delays its native CFieldMap send while the marker moves. daRPC publishes selection_submitted only after the actual outgoing packet is observed. It does not publish a separate selection-started event. Submission does not prove that the server accepted the destination, and it does not close the panel. Later location and map events are authoritative for arrival.

Live events

Every event carries the complete field-map state. closed carries it as previous; the other events use field_map. On an event-stream resync, reread GET /clients/{client}/field-map.

Client ownership and bounds

The injected DLL retains field-map state without depending on the daemon. The server packet is validated and copied into bounded storage on the client main thread, then decoded after transfer to the IPC thread. Pane checks rescan the live bounded event-dispatcher collection and never retain a native pane pointer between observations.

Closing the pane makes active_field_map null but retains the last validated definition inside the DLL. If the client later reopens that cached native pane without another server packet, daRPC publishes a new opened revision and resets its submitted selection. The retained definition is never exposed while the pane is hidden or unregistered.