Jump to content

Main Page: Difference between revisions

From Open Simulator Technical Help
Jwbshaw (talk | contribs)
top level
Jwbshaw (talk | contribs)
formating
Line 5: Line 5:
Maintained by Jagga Meredith. Contributions welcome.
Maintained by Jagga Meredith. Contributions welcome.


----


== Overview ==
== Overview ==
Line 10: Line 11:
OpenSimulator has two main components:
OpenSimulator has two main components:


'''ROBUST.exe''' -- handles grid-wide services: user accounts, inventory, assets, presence, and region registration. Multiple simulators connect to a single ROBUST instance.


'''ROBUST.exe''' -- handles grid-wide services: user accounts, inventory, assets, presence, and region registration. Multiple simulators connect to a single ROBUST instance.
'''OpenSim.exe''' -- runs one or more regions. Handles objects, avatars, physics, scripting, and terrain. In standalone mode both processes are combined into OpenSim.exe.
'''OpenSim.exe''' -- runs one or more regions. Handles objects, avatars, physics, scripting, and terrain. In standalone mode both processes are combined into OpenSim.exe.


The database layer is split to match: ROBUST owns the grid database, each simulator owns its own region database. Both live in the same database server instance as separate databases.
The database layer is split to match: ROBUST owns the grid database, each simulator owns its own region database. Both live in the same database server instance as separate databases.
Line 19: Line 19:
In standalone mode the connector calls the service directly in-process. In grid mode it makes an HTTP call to ROBUST. Same interface either way.
In standalone mode the connector calls the service directly in-process. In grid mode it makes an HTTP call to ROBUST. Same interface either way.


----


== Contents ==
== Contents ==


* [[OpenSimulator Internals/Architecture Overview]] (stub)
* [[OpenSimulator Internals/Reading the Code]] (stub)
* [[OpenSimulator Internals/ROBUST Services]]
* [[OpenSimulator Internals/Data Dictionaries]]
* [[OpenSimulator Internals/Connector Architecture]]
* [[OpenSimulator Internals/GridService]]
* [[OpenSimulator Internals/AuthorizationService]]
* [[OpenSimulator Internals/GroupsService]]
* [[OpenSimulator Internals/Code Map]] (stub)


[[OpenSimulator Internals/Architecture Overview|Architecture Overview]]
----
[[OpenSimulator Internals/Reading the Code|Reading the Code -- What to Skip]]
[[OpenSimulator Internals/ROBUST Services|ROBUST Services]]
[[OpenSimulator Internals/Data Dictionaries|Data Dictionaries]]
[[OpenSimulator Internals/Connector Architecture|Connector Architecture]]
[[OpenSimulator Internals/GridService|GridService]]
[[OpenSimulator Internals/AuthorizationService|AuthorizationService]]
[[OpenSimulator Internals/GroupsService|GroupsService]]
[[OpenSimulator Internals/Code Map|Code Map]]
 
 


== Status ==
== Status ==

Revision as of 10:08, 22 June 2026

OpenSimulator Internals

This wiki documents the internal architecture of OpenSimulator for developers and contributors. It covers the database schema, service architecture, connector design, and code structure. Written from code and verified against developer discussion -- where the wiki and the code disagree, the code takes priority.

Maintained by Jagga Meredith. Contributions welcome.


Overview

OpenSimulator has two main components:

ROBUST.exe -- handles grid-wide services: user accounts, inventory, assets, presence, and region registration. Multiple simulators connect to a single ROBUST instance.

OpenSim.exe -- runs one or more regions. Handles objects, avatars, physics, scripting, and terrain. In standalone mode both processes are combined into OpenSim.exe.

The database layer is split to match: ROBUST owns the grid database, each simulator owns its own region database. Both live in the same database server instance as separate databases.

In standalone mode the connector calls the service directly in-process. In grid mode it makes an HTTP call to ROBUST. Same interface either way.


Contents


Status

This document is a work in progress developed from code review and developer meeting notes. Where the existing wiki disagrees with the source code, the source code takes priority. Discrepancies are noted.

Contributors: Jagga Meredith