The manifest

Each resource folder contains an omx-resource.json:

omx-resource.json

{
  "id": "my-company",
  "name": "My Virtual Company",
  "version": "2.1.0",
  "apiVersion": "2.0",
  "permissions": ["network.events", "network.metadata", "storage", "ui.hud"],
  "configuration": { "defaultLine": "76" },
  "client": { "assembly": "MyCompany.dll" },
  "server": { "assembly": "MyCompany.dll" },
  "dependencies": [{ "id": "shared-fleet", "version": ">=2.0.0 <3.0.0", "optional": false }]
}

Field	Meaning
id	The resource’s identity and namespace: up to 32 ASCII letters, digits, _, - or .. It prefixes every metadata key and network event the resource owns (my-company:status).
name	Display name.
version	The resource’s SemVer version.
apiVersion	The SDK version it was built against. Currently 2.0.
permissions	Privileged actions it needs. See Permissions.
configuration	Any JSON. Read it with Storage.Configuration, or Storage.ConfigurationAs<T>() with camelCase property names.
client	The assembly holding the client entry point. Optional.
server	The assembly holding the server entry point. Optional.
dependencies	Other resources, by id, with a SemVer range. Dependencies start first and stop last. An optional dependency that is missing does not stop this resource from loading.

Entry points

client and server are each optional. OMX looks for exactly one public, non-abstract class derived from ClientResource (or ServerResource) in the named assembly. Add "type": "Namespace.ClassName" only when an assembly deliberately contains more than one candidate.

Both entry points can live in the same assembly. This is the recommended layout for a resource with two halves: one project, one build and one folder to install on both the client and the server. OMX starts only the half that applies to the current process, so a dedicated server never starts the client class. The VirtualBusCompany example uses this layout.

Loading and isolation

Each resource gets its own collectible assembly load context. Private dependencies resolve from the resource’s own folder, while every resource shares OMX’s copy of the SDK assemblies so SDK types keep their identity between resources.

Missing, incompatible, duplicate and circular resources fail on their own without stopping the others. Start and stop each have a time limit. When a resource unloads, OMX removes its subscriptions, timers, exports, HUD items and held input before releasing its load context.