-
Notifications
You must be signed in to change notification settings - Fork 2
Understanding the Codebase
- bin - Contains the executable when built, and resource folders accessible by the application.
- CoreData - Core resources used by Urho3D. Copied directly from Urho3D and trimmed down. Don't mess with this folder.
- Data - Folder for resources necessary for OSP to operate, or temporary resources for development purposes. Contains many assets left over from Urho3D (remove them soon).
- OSPData - Folder for addons. Each folder in here is used as a resource path.
- Default - Resources for the default game. Any asset related to Parts, the Editor, UI, Planets, etc, goes here.
- src - The C++ source code.
TODO
The program starts in src/main.cpp. The main function is generated at the bottom of the file with URHO3D_DEFINE_APPLICATION_MAIN.
- A new
OSPApplicationclass is created - Its
Start()method is called by Urho3D.- UI and Loading screen is initialized
- An
OspUniverseclass is initialized, namedm_osp - An empty scene is created
- AngelScript Subsystem is initialized
- All directories in
OSPDataare listed, and processed bym_osp
In the OspUniverse class (src/OSPUniverse.cpp), each directory in bin/OSPData is scanned for resources in the process_directory function. Parts and scripts are loaded here. More functionality should be added to make this class more useful. So far, it does the following:
-
Load Parts:
- Recursively scans the
bin/OSPData/*AddonName*/Partsfolder for any .sturdy.gltf files. - Start loading them in the background as
GLTFFileresources.
- Recursively scans the
-
Load scripts: (this is inflexible and needs improvements)
- Scan the top level of
bin/OSPData/*AddonName*/Scriptsfor any .as files. - Start loading them in the background as
ScriptFileresources.- If a script has a
loaded()function, then it is called immediately after it's loaded.
- If a script has a
- Scan the top level of
AngelScript is used for non-intensive parts of the project, such as UI. Once bin/OSPData/Default/Scripts/Main.as is finished loading, its loaded() function is called.
- Loads menu screen from
bin/Data/UI/MenuUI.xml, and adds it to the UI root, making it visible - Subscribes to the "Released" event for the DO SOMETHING WITH ROCKETS button
Pressing DO SOMETHING WITH ROCKETS creates a script object of CraftEditor.
The editor scripts are located in bin/OSPData/Default/Scripts/CraftEditor/, CraftEditor.as containing the CraftEditor class. Through UIController (not important right now), CraftEditor implements ScriptObject, which means it can be added to nodes through an Urho3D ScriptInstance. When CraftEditor is added to the scene, it will automatically setup the UI and nodes required to edit spacecraft.
TODO: Editor needs its own page. just assume that the editor has a list of function pointers each known as "EditorFeatures"
CraftEditor.as contains an EditorFeature with the function LunchTime, bound to SPACE of course.
- The craft is combined into a single rigid body through the
SolidifyBlueprintfunction. -
OspUniverse::debug_functionis called (src/OSPUniverse.cpp), This part is when the universe starts existing.- Defines a new "solar system" of just a single planet
- Creates a
PlanetTerrainassociated with that new planet - Creates a large temporary sphere collider, as planet collisions aren't there yet
- Creates an
ActiveArealocated just above the planet
Handles lots of the beefy stuff. TODO
src/ActiveArea.cpp
An ActiveArea is a component that can be added to a Scene. A single Scene cannot represent an entire solar system, which can be billions of kilometers wide. ActiveArea acts like a small window into the large virtual universe defined elsewhere. ActiveArea handles floating origin, and should determine which objects are close enough to the viewer, so that they should appear on the scene. It should also be possible for the application to handle multiple ActiveArea instances (multiple far-away crafts active simultaneously).