Osiris Overview - Revision history

Tinkerer: /* Program Execution */

2019-02-22T08:02:30Z

Program Execution

← Older revision		Revision as of 08:02, 22 February 2019
Line 336:		Line 336:
	* User queries can only be called from action blocks of other procedures, user queries or rules. Procedures can also be called from INIT and FINI sections of a goal.		* User queries can only be called from action blocks of other procedures, user queries or rules. Procedures can also be called from INIT and FINI sections of a goal.

	This means that there is no ''main'' or other procedure at which an Osiris story (= program) starts executing. Story ~~merely~~ reacts to events thrown by the game engine and actions by the player in the game world. That said, the game engine does throw events such as [[Osiris/API/RegionStarted\|RegionStarted]] and [[Osiris/API/GameStarted\|GameStarted]] that signify the game may have entered a different phase.		This means that there is no ''main'' or other procedure at which an Osiris story (= program) starts executing. Story primarily reacts to events thrown by the game engine and actions by the player in the game world. That said, the game engine does throw events such as [[Osiris/API/RegionStarted\|RegionStarted]] and [[Osiris/API/GameStarted\|GameStarted]] that signify the game may have entered a different phase. Additionally, the top-level goals (see next section) are intialised as soon as a story becomes active. Note that this happens before the game has fully initialised, so do no perform any game-related queries at that point.

	== Goal Initialisation and Completion ==		== Goal Initialisation and Completion ==

Tinkerer: /* Program Execution */

2019-02-22T07:59:37Z

Program Execution

← Older revision		Revision as of 07:59, 22 February 2019
Line 334:		Line 334:
	Osiris execution is completely event-driven:		Osiris execution is completely event-driven:
	* Rules can only be triggered when an event is thrown, or when a database is defined or removed by the action block of a procedure, user query or rule, or by the INIT/FINI section of a goal		* Rules can only be triggered when an event is thrown, or when a database is defined or removed by the action block of a procedure, user query or rule, or by the INIT/FINI section of a goal
	* ~~Procedures and user~~ queries can only be called from action blocks of other procedures, user queries or rules.		* User queries can only be called from action blocks of other procedures, user queries or rules. Procedures can also be called from INIT and FINI sections of a goal.

	This means that there is no ''main'' or other procedure at which an Osiris story (= program) starts executing. Story merely reacts to events thrown by the game engine and actions by the player in the game world. That said, the game engine does throw events such as [[Osiris/API/RegionStarted\|RegionStarted]] and [[Osiris/API/GameStarted\|GameStarted]] that signify the game may have entered a different phase.		This means that there is no ''main'' or other procedure at which an Osiris story (= program) starts executing. Story merely reacts to events thrown by the game engine and actions by the player in the game world. That said, the game engine does throw events such as [[Osiris/API/RegionStarted\|RegionStarted]] and [[Osiris/API/GameStarted\|GameStarted]] that signify the game may have entered a different phase.

Tinkerer: /* Program Execution */

2019-02-22T07:58:48Z

Program Execution

← Older revision		Revision as of 07:58, 22 February 2019
Line 333:		Line 333:
	= Program Execution =		= Program Execution =
	Osiris execution is completely event-driven:		Osiris execution is completely event-driven:
	* Rules can only be triggered when an event is thrown, or when a database is defined by the action block of a procedure, user query or rule		* Rules can only be triggered when an event is thrown, or when a database is defined or removed by the action block of a procedure, user query or rule, or by the INIT/FINI section of a goal
	* Procedures and user queries can only be called from action blocks of other procedures, user queries or rules.		* Procedures and user queries can only be called from action blocks of other procedures, user queries or rules.

Tinkerer: /* Procedures */

2019-02-22T07:57:18Z

Procedures

← Older revision		Revision as of 07:57, 22 February 2019
Line 293:		Line 293:

	=== Procedures ===		=== Procedures ===
	Procedures are collections of actions that you may want to execute from multiple action blocks. Or, they may be a number of related actions of which some must only be executed under certain conditions. In this sense, they allow you to have extra condition checks in an action block.		Procedures are collections of actions that you may want to execute from multiple action blocks. Or, they may group a number of related actions of which some must only be executed under certain conditions. In this sense, they allow you to have extra condition checks in an action block.

	The format of a procedure is:		The format of a procedure is:

Tinkerer: /* Rules */

2019-02-22T07:49:59Z

Rules

← Older revision		Revision as of 07:49, 22 February 2019
Line 109:		Line 109:

	== Rules ==		== Rules ==
	A '''''Rule''''' consist of one or more [[#Trigger_Conditions\|trigger conditions]], a number of optional [[#Extra_Conditions\|extra conditions]], and finally one or more [[#Actions\|actions]]. A rule is evaluated whenever one of its trigger conditions ~~get~~ becomes fulfilled. If all trigger and extra conditions are fulfilled at that point, the actions of this rule are executed.		A '''''Rule''''' consist of one or more [[#Trigger_Conditions\|trigger conditions]], a number of optional [[#Extra_Conditions\|extra conditions]], and finally one or more [[#Actions\|actions]]. A rule is evaluated whenever one of its trigger conditions becomes fulfilled. If all trigger and extra conditions are fulfilled at that point, the actions of this rule are executed.

	The structure of a rule is as follows:		The structure of a rule is as follows:

Tinkerer: /* Databases */

2019-02-22T07:49:07Z

Databases

← Older revision		Revision as of 07:49, 22 February 2019
Line 100:		Line 100:
	</pre>		</pre>

	As the last example shows it is possible to overload databases: you can have multiple databases with the same name. The only requirement is that they have a different number columns (parameters). Also note that this last example only includes a ''(CHARACTERGUID)'' typecast for the first row. That is sufficient because the compiler uses the first occurrence of a database in story to determine the types. It will then typecast the values in any further occurrences of this database to the type it determined from the first declaration. Since a GUIDSTRING can be typecasted into a CHARACTERGUID, this works fine here. This is an important rule to keep in mind, as it is a frequent source of type errors when you're just starting out.		As the last example shows it is possible to overload databases: you can have multiple databases with the same name. The only requirement is that they have a different number of columns (parameters). Also note that this last example only includes a ''(CHARACTERGUID)'' typecast for the first row. That is sufficient because the compiler uses the first occurrence of a database in story to determine the types. It will then typecast the values in any further occurrences of this database to the type it determined from the first declaration. Since a GUIDSTRING can be typecasted into a CHARACTERGUID, this works fine here. This is an important rule to keep in mind, as it is a frequent source of type errors when you're just starting out.

	Removing database facts can be done using the NOT-operator:		Removing database facts can be done using the NOT-operator:

LarIlya: /* Rule Evaluation State */

2019-02-04T12:50:16Z

Rule Evaluation State

← Older revision		Revision as of 12:50, 4 February 2019
Line 414:		Line 414:
	You may wonder whether removing the ''DB_Overview_KillOriginByName(_Name)'' will abort further execution of the rule in case there would be multiple ''DB_Overview_Origins'' facts for which ''_Name'' matches. That is not the case. The reason is that the execution of a rule occurs by generating a temporary internal table of the valid possibilities every time a condition is evaluated. Afterwards, Osiris keeps referring to this table.		You may wonder whether removing the ''DB_Overview_KillOriginByName(_Name)'' will abort further execution of the rule in case there would be multiple ''DB_Overview_Origins'' facts for which ''_Name'' matches. That is not the case. The reason is that the execution of a rule occurs by generating a temporary internal table of the valid possibilities every time a condition is evaluated. Afterwards, Osiris keeps referring to this table.

	For example, in the above rule, at the second step Osiris will create an internal table that contains all matching ''DB_Overview_Origins(_Origin, _Name)'' facts for the specified ''_Name''. Then it will start evaluating all subsequent conditions (and actions) using this temporary table, rather than starting at the first condition again every time. The same ~~happen~~ with the second, third, ... condition.		For example, in the above rule, at the second step Osiris will create an internal table that contains all matching ''DB_Overview_Origins(_Origin, _Name)'' facts for the specified ''_Name''. Then it will start evaluating all subsequent conditions (and actions) using this temporary table, rather than starting at the first condition again every time. The same happens with the second, third, ... condition.

	=== Rule Trigger Evaluation ===		=== Rule Trigger Evaluation ===

Tinkerer: /* Queries */

2018-10-20T07:50:36Z

Queries

← Older revision		Revision as of 07:50, 20 October 2018
Line 286:		Line 286:
	</pre>		</pre>

	Our ''QRY_Overview_CharacterIsIncapacitated'' query does not actually need to do anything if its conditions succeed. However, you cannot have condition checks without an action. For this reason, we define a dummy database fact (''DB_NOOP(1)'' by convention) if all rules succeed. So, our rule calls ''QRY_Overview_CharacterIsIncapacitated(_Char)'' ~~then~~ Osiris will evaluate all definitions of this query in the entire story (so not just in the current [[#Program_Structure\|goal]]!) and if one of them succeeds, it will consider this query/extra condition to have succeeded.		Our ''QRY_Overview_CharacterIsIncapacitated'' query does not actually need to do anything if its conditions succeed. However, you cannot have condition checks without an action. For this reason, we define a dummy database fact (''DB_NOOP(1)'' by convention) if all rules succeed. So, when our rule calls ''QRY_Overview_CharacterIsIncapacitated(_Char)'', Osiris will evaluate all definitions of this query in the entire story (so not just in the current [[#Program_Structure\|goal]]!) and if one of them succeeds, it will consider this query/extra condition to have succeeded.

	Just like with databases, only the first encountered definition of a query needs to specify the parameter type(s). It does not hurt to repeat them though. You can also see that parameters use the same syntax as [[#Variables\|variables]].		Just like with databases, only the first encountered definition of a query needs to specify the parameter type(s). It does not hurt to repeat them though. You can also see that parameters use the same syntax as [[#Variables\|variables]].

Tinkerer: /* Actions */

2018-10-20T07:47:35Z

Actions

← Older revision		Revision as of 07:47, 20 October 2018
Line 197:		Line 197:

	=== Actions ===		=== Actions ===
	All statements in the '''INIT''' and '''FINI''' sections must be actions. Additionally, at the end of [[#Rule\|rule]] you must also put at least one action. Every action ends in a semi-colon (''';''').		All statements in the '''INIT''' and '''FINI''' sections must be actions. Additionally, at the end of a [[#Rule\|rule]] you must also put at least one action. Every action ends in a semi-colon (''';''').

	Actions can make changes to both the Osiris program state and the game state:		Actions can make changes to both the Osiris program state and the game state:

Tinkerer: /* Extra Conditions */

2018-10-20T07:47:06Z

Extra Conditions

← Older revision		Revision as of 07:47, 20 October 2018
Line 191:		Line 191:

	''CharacterIsDead'' is a query that takes two parameters: a CHARACTERGUID and an integer. The integer indicates whether the character is dead (1) or not (0). If all parameters match, the query condition will succeed. This means that the above rule succeeds in case ''CHARACTERGUID_S_Player_Ifan_ad9a3327-4456-42a7-9bf4-7ad60cc9e54f'' is not dead at the time he first appears in both the ''DB_IsPlayer'' and ''DB_Avatars'' databases. As mentioned earlier, it does not matter in which order he gets added to these databases. As soon as both facts are defined, the rule triggers and the extra condition(s) will be evaluated. If these extra conditions succeed, the actions in the rules section will be executed.		''CharacterIsDead'' is a query that takes two parameters: a CHARACTERGUID and an integer. The integer indicates whether the character is dead (1) or not (0). If all parameters match, the query condition will succeed. This means that the above rule succeeds in case ''CHARACTERGUID_S_Player_Ifan_ad9a3327-4456-42a7-9bf4-7ad60cc9e54f'' is not dead at the time he first appears in both the ''DB_IsPlayer'' and ''DB_Avatars'' databases. As mentioned earlier, it does not matter in which order he gets added to these databases. As soon as both facts are defined, the rule triggers and the extra condition(s) will be evaluated. If these extra conditions succeed, the actions in the rules section will be executed.

			On the other hand, if both database facts would already be defined and then Ifan gets resurrected (so '''CharacterIsDead(IFan, 0)''' would now succeed if it were called), the rule will not trigger. The reason is that it only get (re)evaluated when all of the trigger conditions become fulfilled (in this case, Ifan gets added to both databases). This also demonstrates the main difference between queries and events:
			* Events are triggered when the game state changes, but you cannot call them yourself.
			* Queries allow you to request information about the game state at any point, but they never get automatically triggered/(re)evaluated.

	=== Actions ===		=== Actions ===