Add live Ariane to MTA:SA Neon mapping bridge

[Dryxio]

Problem

Ariane can edit San Andreas maps and test supported changes through ariane.asi, while MTA:SA Neon can load custom models, SA-MP maps, runtime collision, materials, 2DFX, and extended/native worlds. The two workflows are currently disconnected.

A mapper must export files, package or update a resource, reload it, and manually recover useful diagnostics before seeing each iteration in multiplayer. That feedback loop is too slow for creators who want to build directly against Neon.

Goal

Add an optional, developer-only bridge from Ariane to a running MTA:SA Neon client so edits made in Ariane can be previewed immediately in game.

The desired loop is:

1. Open a San Andreas project in Ariane.
2. Start a live Neon preview session.
3. Place, move, rotate, duplicate, or delete content in Ariane.
4. See the same changes in the connected Neon game within one short update cycle.
5. Receive validation and runtime errors back in Ariane.
6. Export a normal, portable Neon resource when the scene is ready.

The editor project remains the source of truth. A live preview must not silently modify permanent server data.

Proposed MVP

• A versioned and documented bridge protocol shared with Dryxio/mtasa-neon.
• Explicit connect/disconnect controls and visible session state in Ariane.
• Full initial scene snapshot followed by incremental create/update/delete diffs.
• Live synchronization of object model, position, rotation, scale where supported, interior, dimension, draw distance, and LOD relationship.
• Support for stock objects first, with a clear path for Ariane-imported DFF/TXD/COL assets and Neon runtime model IDs.
• Material overrides and collision reload once the object-transform path is reliable.
• Ariane undo/redo reflected in the preview.
• Validation responses for missing models, invalid transforms, allocation failures, collision failures, and unsupported properties.
• Reconnection with a session generation so stale edits cannot overwrite a newer preview.
• Export to an ordinary Neon resource/manifest that works without Ariane or the bridge.

Security and isolation

• Disabled by default and available only in an explicit developer mode.
• Bind to localhost by default.
• Authenticate each session with a short-lived random token displayed or exchanged by the two applications.
• Reject arbitrary remote clients, untrusted resource commands, and filesystem paths outside the selected project.
• Scope every preview entity to the bridge session and clean it up on disconnect, resource stop, server change, or Ariane exit.
• Keep the protocol open and portable; it must not require a hosted Ariane or Neon account.

Suggested ownership split

Ariane

• Editor UI and connection lifecycle.
• Scene-diff generation.
• Asset/project identity.
• Error presentation.
• Final resource export.

MTA:SA Neon

• Developer-mode endpoint and authenticated session.
• Preview resource/runtime.
• Runtime model allocation and element creation.
• In-game validation and diagnostics.
• Cleanup and server/resource isolation.

Repository: https://github.com/Dryxio/mtasa-neon

Acceptance criteria

• Moving a selected stock object in Ariane updates it in a running Neon client without restarting the resource.
• Create, duplicate, rotate, and delete operations are mirrored.
• A complete resync recovers correctly after either side reconnects.
• Undo and redo produce the same final scene in Ariane and Neon.
• Invalid or unsupported data is reported in Ariane without crashing or corrupting the preview.
• Disconnecting removes every bridge-owned preview element.
• A scene can be exported as a standalone Neon resource and loaded without the bridge.
• The protocol and trust boundaries are documented.
• The workflow is verified with a representative multiplayer map, not only a one-object test.

Non-goals for the first milestone

• Collaborative multi-user editing.
• Editing arbitrary production servers.
• Replacing Ariane project files with server state.
• Supporting every Neon world system before object transforms are robust.