Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
submodels [2026/07/11 22:38]
hermann 		submodels [2026/07/26 14:39] (current)
hermann
Line 34: Line 34:
  
 [{{:​submodels:​submodel_types.png?​900|Different Types of Submodels}}] [{{:​submodels:​submodel_types.png?​900|Different Types of Submodels}}]
 +
 +==== Access Scope ====
 +
 +The four submodel types differ in who can see and use them, from narrowest to broadest:
 +
 +  * **Local Submodel** — scoped to the single model it belongs to. It is not automatically visible from any other model, not even other models owned by the same user; to use it elsewhere, it must be explicitly copied into that other model (see [[#​copying_importing_a_local_submodel_between_models|Copying (Importing) a Local Submodel Between Models]]), becoming an independent copy in the process.
 +  * **User Submodel** — scoped to the user account that created it. It is automatically available across all of that user's models, with no import step needed, but it is not visible to other users of the same machine.
 +  * **Store Submodel** — same per-user scope as a user submodel (available across all of that user's models, not visible to other users), but its content comes from the shared online [[#​the_submodel_store|Submodel Store]] rather than from something the user authored. The distinction from a user submodel is about origin, versioning, and storage, not visibility.
 +  * **System Submodel** — the broadest scope: bundled with the Dinamica EGO installation itself, so it is available to every user on every model, and cannot be modified by any user.
 +
 +This scope ordering is also why local submodels take precedence over user submodels, which in turn take precedence over store submodels, when names collide. A local submodel can be widened to user scope by [[#​turning_a_local_submodel_into_a_user_submodel_publishing|publishing]] it; there is no equivalent operation to widen a user or store submodel into a system submodel.
  
 ==== Where Submodels Are Stored ==== ==== Where Submodels Are Stored ====
Line 72: Line 83:
  
 {{youtube>​YvoteWC_lnI?​size=853x480&​rel=0|Creating local submodels }} {{youtube>​YvoteWC_lnI?​size=853x480&​rel=0|Creating local submodels }}
 +
 +==== Creating a Submodel Directly as a Script ====
 +
 +A submodel does not have to be created through the GUI: any ''​.ego''​ file that declares the right set of ''​@submodel.*''​ properties (name, description,​ group, and its input/​output port declarations) is a valid submodel. See [[ego_script#​submodels|Submodels]] in the EGO Script reference for the full property syntax.
 +
 +Whether a hand-written submodel script becomes a local or a user submodel is determined entirely by where the file is placed, following the same [[#​where_submodels_are_stored|storage locations]] used for submodels created through the GUI — the ''​@submodel.name''​ property, not the filename, is what identifies the submodel.
  
 ===== Instantiating Local Submodels ===== ===== Instantiating Local Submodels =====
Line 101: Line 118:
 First, click on the functor whose inputs or outputs will be exported. First, click on the functor whose inputs or outputs will be exported.
  
-Select //export functor inputs and outputs// on the [[model_presentation#​functor_action_bar|functor action bar]] and choose the inputs or outputs that will be exported. It is possible to define the input and output names and their corresponding descriptions. It is also possible to mark an exported input as advanced or optional. Optional inputs can also define an optional value that will be assigned to the port if no explicit value is provided.+Select //export functor inputs and outputs// on the [[model_presentation#​functor_action_bar|functor action bar]] and choose the inputs or outputs that will be exported. It is possible to define the input and output names and their corresponding descriptions. It is also possible to mark an exported input as advanced or optional. Optional inputs can also define an optional value that will be assigned to the port if no explicit value is provided. A submodel'​s input ports cannot be declared nullable; a caller-optional input is only made available through this //​optional//​ marking and its associated default value, not by accepting a null value directly.
  
-Choose //Submodel Options// on the model toolbar and then click //Apply Changes / Edit Submodel Properties//​. That brings up the submodel editor dialog where you can define a new name, description and icon for the submodel or reorder its inputs and outputs (or even remove some of them). Clicking //Ok// propagates the changes to all parts of your model (and dependent submodels) where the submodel is used.+> **Note:** Any port from the integer family of types can be declared a light enum, which presents it in the GUI as a labeled dropdown instead of a free-form numeric field, via the //Make port available as an enum value// control. This is not specific to submodels — it can be set on any carrier functor of an integer value type in any model, provided the carrier has an editor. When such a carrier'​s port is exported as a submodel input, its light enum configuration carries over into the submodel'​s interface. 
 + 
 +Choose //Submodel Options// on the model toolbar and then click //Apply Changes / Edit Submodel Properties//​. That brings up the submodel editor dialog where you can define a new name, description, documentation URL, and icon for the submodel, or reorder its inputs and outputs (or even remove some of them). Clicking //Ok// propagates the changes to all parts of your model (and dependent submodels) where the submodel is used.
  
 The submodel editor dialog also lets you set the submodel'​s **group**, which controls where it appears in the [[functor_library|Functor Library]]. A group name can contain subgroups by separating them with a colon (''":"''​);​ for example, ''"​Elevation Graph:​Tools:​Debug"''​ places the submodel in a //Debug// subgroup, itself inside a //Tools// subgroup, inside an //Elevation Graph// group. This is specific to submodels: an ordinary functor'​s placement in the Library is fixed by its own definition and cannot be changed by the user, but a submodel'​s group — and therefore whether it appears in a subgroup — is under the control of whoever creates or edits it. The submodel editor dialog also lets you set the submodel'​s **group**, which controls where it appears in the [[functor_library|Functor Library]]. A group name can contain subgroups by separating them with a colon (''":"''​);​ for example, ''"​Elevation Graph:​Tools:​Debug"''​ places the submodel in a //Debug// subgroup, itself inside a //Tools// subgroup, inside an //Elevation Graph// group. This is specific to submodels: an ordinary functor'​s placement in the Library is fixed by its own definition and cannot be changed by the user, but a submodel'​s group — and therefore whether it appears in a subgroup — is under the control of whoever creates or edits it.
Line 215: Line 234:
   * [[model_presentation|Model Presentation]]   * [[model_presentation|Model Presentation]]
   * [[dinamica_console|Dinamica Console]]   * [[dinamica_console|Dinamica Console]]
 +  * [[ego_script#​submodels|EGO Script — Submodels]]
 +