[v1.20] Tutorial 4: Logic
Welcome to tutorial no.4.The following tutorial will discuss on ways to extend and manipulate the simulation and the plugin using the Logic mechanism.
The tutorial will cover the following topics:
The tutorial will cover the following topics:
- Introduction to Logic.
- How and where can we use Logic elements.
- Introduction to the Dataref Logic elements.
- Gather and define Dataref Logic info.
- Add Logic to Mission.
- Operative Logic Elements - <ApplyLogic>, <LogicForSuccess> etc...
- Let's add some challenge.
- Meet the <Then> element.
- Logic to add more finer touches to the Mission.
- <LogicForSuccess>
- Exercise: How to implement LogicForSuccess
- Finishing Words
Introduction to Logic
Logic is one of those features that I guess there is much to say but not enough space to write about. The ways you can implement logic is versatile and limited only by the plugins rules.
The primary reason I created the Logic mechanism, is the understanding that a plugin that wraps datarefs behind elements, can never include all the possibilities that a designer needs. From 4000+ dataref, the plugin is currently allows a designer to modify between 40-70 datarefs which is not bad, but there are many datarefs that the designer might need for his/her mission.
Please be advice that this was the main idea behind the Logic element, to allow the designer more flexibility with datarefs that are not exposed through the plugin XML elements or to allow the designer to extend the plugin capabilities which have not exclusively implemented.
The primary reason I created the Logic mechanism, is the understanding that a plugin that wraps datarefs behind elements, can never include all the possibilities that a designer needs. From 4000+ dataref, the plugin is currently allows a designer to modify between 40-70 datarefs which is not bad, but there are many datarefs that the designer might need for his/her mission.
Please be advice that this was the main idea behind the Logic element, to allow the designer more flexibility with datarefs that are not exposed through the plugin XML elements or to allow the designer to extend the plugin capabilities which have not exclusively implemented.
How and where can we use Logic elements
The restriction where Logic can be implemented is published in the designer guide document, and should be consulted all the time since all features are modified every build.
As of this writing, Logic was implemented under the Objective and Area elements. These locations are good enough for Objective wide logic or for a specific event logic. You are also need to take into consideration that there are few types of logic that have their own special role to make this process streamlined for the designer.
Before delving into the "art" of Logic, I would like to state that we will discuss Dataref logic and not Inventory Logic in this tutorial, but the implementation is quite the same.
As of this writing, Logic was implemented under the Objective and Area elements. These locations are good enough for Objective wide logic or for a specific event logic. You are also need to take into consideration that there are few types of logic that have their own special role to make this process streamlined for the designer.
Before delving into the "art" of Logic, I would like to state that we will discuss Dataref logic and not Inventory Logic in this tutorial, but the implementation is quite the same.
Introduction to Mission-X Logic
Mission-X is not a programming language, nor a scripting language. Therefore when I tried to implement a Logic mechanism I knew that there would be restrictions that will make this feature less flexible as it could be, but remember that this is my first implementation so there might be other extensions in later versions.
The Logic in v1.20 try to mimic the following Logical syntax:
The Logic in v1.20 try to mimic the following Logical syntax:
IF (X=N) [ and (X1=N1) and (X2=N2)....] [Brackets means optional]
THEN
do event
ELSE
do event
THEN
do event
ELSE
do event
If you are familiar with programming/scripting you can see the limitations in the current implementation, if you do not see it, then I'll just say it out loud, there is no OR in this logical statement. All evaluated statements are in the form of AND, so all of them must return a true to execute the "success" statement/s.
Though limiting in this current state, it is flexible enough to allow you to test enough info for your Objective and set others as a result.
The other limiting factor is the datatype you can query/modify.
By datatype I mean the kind of values. As of v1.20 the values you can query/modify are:
Now that we are aware of how logic is implemented and its restrictions, it is time to define it.
Though limiting in this current state, it is flexible enough to allow you to test enough info for your Objective and set others as a result.
The other limiting factor is the datatype you can query/modify.
By datatype I mean the kind of values. As of v1.20 the values you can query/modify are:
- Integer
- Float
- Double
Now that we are aware of how logic is implemented and its restrictions, it is time to define it.
Introduction to the Dataref Logic elements
There are three main steps that we need to define in order for the plugin to correctly evaluate the Dataref Logic.
- First there is the Dataref key the plugin need to be aware of.
- Second, there is the Logic Statement that need to be constructed.
- Third, implement the Logic into one of the events in our Mission.
<LOGIC>
This is the Main container of the Logic Metadata elements.
By Metadata I mean to all descriptive elements, but not for the Operative ones.
By Metadata I mean to all descriptive elements, but not for the Operative ones.
<DataRef ...>
The DataRef element creates a parameter that will hold the value and the correct datatype derived from the key that defined by X-Plane.
For example, if we want to ask about mixture, we can define the key: "sim/cockpit2/engine/actuators/mixture_ratio_all"
For example, if we want to ask about mixture, we can define the key: "sim/cockpit2/engine/actuators/mixture_ratio_all"
<DrefCheckSet ...>
This element holds the statements we want to evaluate and which event to call if the statement is evaluated as success or as failure.
These three elements represents the DatarefLogic Metadata implementation. They will not execute themselves without being triggered.
In our first example, we will use the Logic mechanism to test if the plane has flew above 5000 feet MSL, and we will feedback the simmer if so.
In our first example, we will use the Logic mechanism to test if the plane has flew above 5000 feet MSL, and we will feedback the simmer if so.
Gather and define Dataref Logic info
Gathering Dataref Logic is quite simple. You need to find the correct key that is published and implement it. But, it become less simple when you find out that there are more then 2000 of them.
For our purpose, we need to get the planes elevation ( from sea level ). The key that define this value is: "sim/flightmodel/position/elevation" and it returns the elevation in Meter and not feet.
Next we need to decide how to formulate our Logic "statement":
Our next step is to add the logic elements into the mission file.
For our purpose, we need to get the planes elevation ( from sea level ). The key that define this value is: "sim/flightmodel/position/elevation" and it returns the elevation in Meter and not feet.
Next we need to decide how to formulate our Logic "statement":
- IF ( plane > 5000 )
THEN
broadcast - "You are flying above 5000 feet..."
ELSE
do nothing...
Our next step is to add the logic elements into the mission file.
Add Logic to Mission
<MISSION>
...
<LOGIC>
<DataRef drName="ref_elev" key="sim/flightmodel/position/elevation" />
<DrefCheckSet csName="check_elev" resultEvent="eventOver5000" elseEvent="" >
<If drName="ref_elev" cond="gt;" testValue="1524" /> <!-- if elevation greater then 1524Meters = 5000feet (We use Meters because dataref uses Meters) -->
</DrefCheckSet>
</LOGIC>
</MISSION>
...
<LOGIC>
<DataRef drName="ref_elev" key="sim/flightmodel/position/elevation" />
<DrefCheckSet csName="check_elev" resultEvent="eventOver5000" elseEvent="" >
<If drName="ref_elev" cond="gt;" testValue="1524" /> <!-- if elevation greater then 1524Meters = 5000feet (We use Meters because dataref uses Meters) -->
</DrefCheckSet>
</LOGIC>
</MISSION>
Explanation:
There are many definitions that need to be combined to one coherent statement so try to follow the steps:
There are many definitions that need to be combined to one coherent statement so try to follow the steps:
- <DataRef>: First step, defines the Dataref Key we need to evaluate in X-Plane. give it a simple and meaningful name.
- <DrefCheckSet>: Second step: This holds the evaluation statement and outcome events.
The evaluation is described with the sub element "<If>". We can define many <If> statements, but we need to remember that their logical operation is AND.
In example one, we have "only" one <If> element meaning one evaluation statement. - <If>: Points to a dataref key, and evaluates its value against the designer wish. You can see that I did not used the sign ">" since XML will not parse the line correctly, this is why we need to use replacements. The XML replacement is: "gt;" = greater then.
You can find the replacement to other logical signs in the designer guide ( you must use these ones ).
Operative Logic Elements
Operative Logic Elements, basically allow the designer to call Logic statements. The simplest form will execute the outcome of the Logic (without the test) while the more complex, will need to evaluate the logic statement prior to executing the resulting event.
Here is the list to the Three operative logic we have so far:
Here is the list to the Three operative logic we have so far:
- <ApplyLogic>: One time logic apply. It is the simplest form of logic call. It executes the <Then> part of <DrefCheckSet> without evaluating it.
- <LogicToMonitor>: Evaluates the logic defined under <DrefCheckSet> and execute the event that result with it.
- <LogicForSuccess>: This is a special case of LogicToMonitor. It is defined only under an Objective, and it is part of Objectives success evaluations (will be discussed later).
Between these three logic operatives element, the logical one to pick is "LogicToMonitor". We need a continues test, we need it do stop once it was fired and it should be placed in the first Objective.
There are two places where we can set "LogicToMonitor", under Objective's <Rule> element (we did not discussed this one yet) or under an AreaZone element - which we already have implemented.
In this tutorial we will use the AreaZone definition, and add the Logic test as long as the plane is in its boundaries.
I'll add the LogicToMonitor to AreaZone defined under first Objective:
There are two places where we can set "LogicToMonitor", under Objective's <Rule> element (we did not discussed this one yet) or under an AreaZone element - which we already have implemented.
In this tutorial we will use the AreaZone definition, and add the Logic test as long as the plane is in its boundaries.
I'll add the LogicToMonitor to AreaZone defined under first Objective:
<Areas>
<AreaZone rule="enter" failCanCont="1" elevMin="0" elevMax="0" radius="0.0" timer="0.0" restrictElev="0" groupId="" stopOnReach="0">
<Point lat="47.305233" long="11.311460" />
<Point lat="47.402592" long="11.703875" />
<Point lat="47.597572" long="12.112749" />
<Point lat="47.507298" long="12.216961" />
<Point lat="47.272873" long="11.644159" />
<Point lat="47.234184" long="11.311676" />
<Event id="1" type="onEnter" >
<Msg repeatMsg="1" ><![CDATA[Remember to keep the plane path above the valley...]]></Msg>
</Event>
<Event id="2" type="onLeave" >
<Msg repeatMsg="1" ><![CDATA[You left the desired path. Please return and fly over the valley path !!!]]></Msg>
</Event>
<!-- ---------------------- 8< ----------------------------------------------------- -->
<Event id="3" type="eventOver5000" >
<Msg repeatMsg="1" ><![CDATA[Your plane has just ascend over 5000 feet...]]></Msg>
</Event>
<LogicToMonitor csName="check_elev" repeat="1" fireOnce="1"/>
<!-- ---------------------- >8 ----------------------------------------------------- -->
</AreaZone>
</Areas>
Explanation:
We added two elements to our AreaZone. The first is LogicToMonitor, and the second is the "result" event of the dataref Check element. You can see that the event name is same as the one defined under the <DrefCheckSet>.
The main attributes are highlighted in red.
For the LogicToMonitor, we need to use the "csName" we want to evaluate. Its value, must be one of the "DrefCheckSet" we defined under <LOGIC>.
I also added the attribute "fireOnce". This is important since if this value would not have been set, the event would have triggered all the time, and the Queue Message would have got filled with the eventOver5000 message.
Therefore, every-time you design a logic in an area and the logic fires event with <Msg>, you should strongly consider setting fireOnce to "1" which means, execute the event only once.
For the Event element, we defined type name that is same as the "resultEvent" of the "DrefCheckSet" we evaluate in "LogicToMonitor"
The Operative elements and the events are combined much as a puzzle, but a simple one. you do not need to re-envent the names and rules, only define the pointers to the Logic to be evaluated and the outcome events.
You can define simple logic to complex ones in order to achieve your goal.
You can download the following example which demonstrates <LogicToMonitor> operative element. I place the <LOGIC> element at the end.
We added two elements to our AreaZone. The first is LogicToMonitor, and the second is the "result" event of the dataref Check element. You can see that the event name is same as the one defined under the <DrefCheckSet>.
The main attributes are highlighted in red.
For the LogicToMonitor, we need to use the "csName" we want to evaluate. Its value, must be one of the "DrefCheckSet" we defined under <LOGIC>.
I also added the attribute "fireOnce". This is important since if this value would not have been set, the event would have triggered all the time, and the Queue Message would have got filled with the eventOver5000 message.
Therefore, every-time you design a logic in an area and the logic fires event with <Msg>, you should strongly consider setting fireOnce to "1" which means, execute the event only once.
For the Event element, we defined type name that is same as the "resultEvent" of the "DrefCheckSet" we evaluate in "LogicToMonitor"
The Operative elements and the events are combined much as a puzzle, but a simple one. you do not need to re-envent the names and rules, only define the pointers to the Logic to be evaluated and the outcome events.
You can define simple logic to complex ones in order to achieve your goal.
You can download the following example which demonstrates <LogicToMonitor> operative element. I place the <LOGIC> element at the end.
tutorial04_v120_exp1.zip | |
File Size: | 2 kb |
File Type: | zip |
We have covered the basics of Logic, and used it to send a simple message to the simmer, once we ascended certain elevation.
I'll repeat the main Logical Parts:
I'll repeat the main Logical Parts:
<LOGIC>
<DataRef drName="".../>
<DrefCheckSet csName="" ...>
<If drName="" ... />
</DrefCheckSet>
</LOGIC>
<DataRef drName="".../>
<DrefCheckSet csName="" ...>
<If drName="" ... />
</DrefCheckSet>
</LOGIC>
We Call the Logic statements using operative elements, for example:
<LogicToMonitor csName="" ... />
Let's add some challenge...
Our first implementation of Logic, was really simple and did not done much, we could easily use an area to do this job, and it would have done it even better.What we did not done yet, is change a Dataref as a result of Logic test.
In our case, we will modify out first example, and add an engine failure once the plane passes 5000 feet.
There are two ways to do that,
First Option: will broadcast a message and trigger the engine failure.
Second option: will just fail the engine, without broadcasting a warning.
The main reason I presented these two options, is to describe two solutions that result in the same outcome with different complexities of "code".
So where do we start:
In our case, we will modify out first example, and add an engine failure once the plane passes 5000 feet.
There are two ways to do that,
First Option: will broadcast a message and trigger the engine failure.
Second option: will just fail the engine, without broadcasting a warning.
The main reason I presented these two options, is to describe two solutions that result in the same outcome with different complexities of "code".
So where do we start:
Meet the <Then> element
The element <DrefCheckSet> was named so, because it allows us two things:
Evaluate Dataref keys and Set Dataref values.
The <Then> element, allow us to set a DataRef value. Its syntax is almost identical to the <If> element, only it assigns a value.
Let's modify our <LOGIC> part to add the <Then> outcome that will trigger the engine failure.
Evaluate Dataref keys and Set Dataref values.
The <Then> element, allow us to set a DataRef value. Its syntax is almost identical to the <If> element, only it assigns a value.
Let's modify our <LOGIC> part to add the <Then> outcome that will trigger the engine failure.
<LOGIC>
<DataRef drName="ref_elev" key="sim/flightmodel/position/elevation" />
<DataRef drName="ref_eng1Mag_fail" key="sim/operation/failures/rel_magLFT0" />
<DataRef drName="ref_eng1RMag_fail" key="sim/operation/failures/rel_magRGT0" />
<DrefCheckSet csName="check_elev" resultEvent="eventOver5000" elseEvent="" >
<If drName="ref_elev" cond="gt;" testValue="1524" /> <!-- if elevation greater then 1524 Meters ( 5000 feet ) -->
<Then drName="ref_eng1Mag_fail" newValue="6" />
<Then drName="ref_eng1RMag_fail" newValue="6" />
</DrefCheckSet>
</LOGIC>
You can see I added a new Dataref that points to Engine 1 failure (This is a GA mission, so there should be one or two engines ).
The <Then> element was added to the same <DrefCheckSet>, and since we only have one, it makes designing simpler.
Let's start with the first option:
This designer will keep the same event path, but will add a call to the <Then> part to trigger the failure.
The trick is to add another logical operative element to the "eventOver5000" event. And this time I mean: <LogicApply>. We need a one time failue call when the event is triggered.
Here is the implementation snippet:
The <Then> element was added to the same <DrefCheckSet>, and since we only have one, it makes designing simpler.
Let's start with the first option:
This designer will keep the same event path, but will add a call to the <Then> part to trigger the failure.
The trick is to add another logical operative element to the "eventOver5000" event. And this time I mean: <LogicApply>. We need a one time failue call when the event is triggered.
Here is the implementation snippet:
<Event id="3" >
<Msg repeatMsg="1" ><![CDATA[Your plane has just ascend over 5000 feet... You feel that something is wrong with the engine...]]></Msg>
<LogicApply csName="check_elev" />
</Event>
<Msg repeatMsg="1" ><![CDATA[Your plane has just ascend over 5000 feet... You feel that something is wrong with the engine...]]></Msg>
<LogicApply csName="check_elev" />
</Event>
Using this logical element, I ask the plugin to execute all <then> elements under <DrefCheckSet> with the name "check_elev" .
In our example there are two "Then" elements which fails the first engine by setting the value 6 to the relevant dataref.
We can vision the Logical events as follow:
This might seem complex, but it allows higher flexibility, if needed.
In our example there are two "Then" elements which fails the first engine by setting the value 6 to the relevant dataref.
We can vision the Logical events as follow:
- Check if plane is over 5000 feet.
- If yes, then call event "eventOver5000"
"eventOver5000" will execute "LogicApply" (which is defined in it). The logicApply will set all values defined in "Then" elements under "DrefCheckSet" by the name: "check_elev". In our tutorial they are: "ref_eng1Mag_fail" and "ref_eng1RMag_fail"
This might seem complex, but it allows higher flexibility, if needed.
The other way to implement this logic, is without broadcasting a message to the simmer, Therefore we can skip the event: "eventOver5000"
Let's look at the following snippet:
Let's look at the following snippet:
<LOGIC>
<DataRef drName="ref_elev" key="sim/flightmodel/position/elevation" />
<DataRef drName="ref_eng1Mag_fail" key="sim/operation/failures/rel_magLFT0" />
<DataRef drName="ref_eng1RMag_fail" key="sim/operation/failures/rel_magRGT0" />
<DrefCheckSet csName="check_elev" resultEvent="onSelf" elseEvent="" >
<If drName="ref_elev" cond="gt;" testValue="1524" /> <!-- if elevation greater then 1524 Meter -->
<Then drName="ref_eng1Mag_fail" newValue="6" />
<Then drName="ref_eng1RMag_fail" newValue="6" />
</DrefCheckSet>
</LOGIC>
<DataRef drName="ref_elev" key="sim/flightmodel/position/elevation" />
<DataRef drName="ref_eng1Mag_fail" key="sim/operation/failures/rel_magLFT0" />
<DataRef drName="ref_eng1RMag_fail" key="sim/operation/failures/rel_magRGT0" />
<DrefCheckSet csName="check_elev" resultEvent="onSelf" elseEvent="" >
<If drName="ref_elev" cond="gt;" testValue="1524" /> <!-- if elevation greater then 1524 Meter -->
<Then drName="ref_eng1Mag_fail" newValue="6" />
<Then drName="ref_eng1RMag_fail" newValue="6" />
</DrefCheckSet>
</LOGIC>
The second way to implement the Logic, is to just apply it once the plane reaches 5000 feet, in other words: once the <DrefCheckSet> is evaluated to true.
In this example, I used a pre-defined event by the name: "onSelf" which means, execute all <Then> statemenets that defined under the current CheckSet element.
In this example we do not need to add an Event to the <AreaZone> that will handle the success or failure of this Logic.
You can download the following files, that demonstrate the implementation of Logic with Event in Area, or without using the "onSelf" pre-defined technique.
In this example, I used a pre-defined event by the name: "onSelf" which means, execute all <Then> statemenets that defined under the current CheckSet element.
In this example we do not need to add an Event to the <AreaZone> that will handle the success or failure of this Logic.
You can download the following files, that demonstrate the implementation of Logic with Event in Area, or without using the "onSelf" pre-defined technique.
|
|
Logic to add more finer touches to the Mission
Since I added the Logic mechanism to the Mission-X plugin, I started using it to make some of the objective more realistic, therefore more elegant in the way they where concluded.
Here is an example:
When I wrote my first mission, "Alaska Mission", the last objective was to land in "Ketchikan Intl".
The objective ended once your plane touched the runway, and the speaker announced "Objective Accomplished... bla bla bla..."
When I designed Norway02 mission, after landing at ENSG you where asked to reach "GA Ramp 1" and "turn off mixture".
The first condition is evaluated by coordinates - simple to implement.
The second condition is done by Dataref, and this is the beuty of Logic as I see it in a day to day ( or should I say mission to mission ) use.
Our last piece in the Logic department ( for this tutorial anyway ) is the <LogicForSuccess>.
Here is an example:
When I wrote my first mission, "Alaska Mission", the last objective was to land in "Ketchikan Intl".
The objective ended once your plane touched the runway, and the speaker announced "Objective Accomplished... bla bla bla..."
When I designed Norway02 mission, after landing at ENSG you where asked to reach "GA Ramp 1" and "turn off mixture".
The first condition is evaluated by coordinates - simple to implement.
The second condition is done by Dataref, and this is the beuty of Logic as I see it in a day to day ( or should I say mission to mission ) use.
Our last piece in the Logic department ( for this tutorial anyway ) is the <LogicForSuccess>.
<LogicForSuccess>
The last operative logic element was design especially with Objective in mind.
The idea was to add a Logic layer to the way Objective evaluates its completion. This logic should always be implemented with at least "onSuccess" Event for a feedback message to the simmer.
In a nutshell, a LogicForSuccess is a special case of LogicToMonitor. It should only be implemented under the <Rule> element of the Objective (see designer guide), and it needs "onSuccess" event.
The idea was to add a Logic layer to the way Objective evaluates its completion. This logic should always be implemented with at least "onSuccess" Event for a feedback message to the simmer.
In a nutshell, a LogicForSuccess is a special case of LogicToMonitor. It should only be implemented under the <Rule> element of the Objective (see designer guide), and it needs "onSuccess" event.
Exercise: How to implement LogicForSuccess
The simplest, though useful, example is to finish an Objective or the Mission when plane is shutdown. I use the mixture Dataref, but you can pick any Dataref or set of datarefs you see fit (like a check list).
This time I'll write how to implement <LogicForSuccess> in the Objective level, while your task is to implement the Logic part.
I'll attach a proposal solution.
This time I'll write how to implement <LogicForSuccess> in the Objective level, while your task is to implement the Logic part.
I'll attach a proposal solution.
Here is the implementation snippet of Objective Two modified with mixture cut off to finish Objective and Mission
Pay attention to the "csName" attribute value.
Pay attention to the "csName" attribute value.
...
<Objective id="2" >
<Targets>
<AreaTarget id="1" groupId="100" lat="0" long="0" elev="0.0" needToLand="1" name="EDNV" />
....
</Targets>
<Desc>
....
</Desc>
<Feedbacks>
....
</Feedbacks>
<Areas>
....
</Areas>
<Rules>
<LogicForSuccess csName="check_mixture" />
<Event id="1" >
<Msg id="1"><![CDATA[You cut off the mixture....]]></Msg>
</Event>
</Rules>
</Objective>
...
<Objective id="2" >
<Targets>
<AreaTarget id="1" groupId="100" lat="0" long="0" elev="0.0" needToLand="1" name="EDNV" />
....
</Targets>
<Desc>
....
</Desc>
<Feedbacks>
....
</Feedbacks>
<Areas>
....
</Areas>
<Rules>
<LogicForSuccess csName="check_mixture" />
<Event id="1" >
<Msg id="1"><![CDATA[You cut off the mixture....]]></Msg>
</Event>
</Rules>
</Objective>
...
Use one of the examples files introduced so far, to be the base of your mission file.
TIP!!!
If you want to test an exact Objective, you do not need to fly all the previous objectives in order to test it, all you need is:
- [Since v1.20.14] Tick the " ** Designer Mode ** " under Options Widget.
- Add to the <GlobalSettings> element:
<Developer forceObjectiveId="{N}" />
Replace "{N}" with the Objective number you want to test.
Next time you start the mission it will start from that Objective.
To tackle this exercise, we need to do two things:
- Implement a Dataref that will point to the Mixture of the plane.
- Add a <DrefCheckSet> that will check for the correct status.
There is no need for set directive ( <then> )
Suggested Implementation
<DataRef drName="mixture" key="sim/cockpit2/engine/actuators/mixture_ratio_all" />
and
<DrefCheckSet csName="check_mixture" resultEvent="onSelf" elseEvent="" >
<If drName="mixture" cond="=" testValue="0" />
</DrefCheckSet>
and
<DrefCheckSet csName="check_mixture" resultEvent="onSelf" elseEvent="" >
<If drName="mixture" cond="=" testValue="0" />
</DrefCheckSet>
tutorial04_v120_exp3.zip | |
File Size: | 2 kb |
File Type: | zip |
Finishing Words
There are many ways to write a mission. A simple yet entertaining one does not have to include all features that available through mission-x, it is a good practice to start with simple and basic abilities and only add the more complex ones when it really add to the overall experience.
Logic, is one of the complex features that can add a lot to a mission, even if it is done sparingly.
Other uses of Logic, is handling storage (inventory) as part of the Objective ( we did not touch this subject, but it is described under the designer guide ), The good part is that it uses same technique as Dataref logic, so it should be simpler to get use to.
Overall, Logic, if uses correctly, can really help the designer to add more realism to the mission, but it should not be on account of the fun factor of the simmer and the simmer needs to be aware of what needs to be done for success, like cutting the mixture after landing.
Enjoy
Snagar
Logic, is one of the complex features that can add a lot to a mission, even if it is done sparingly.
Other uses of Logic, is handling storage (inventory) as part of the Objective ( we did not touch this subject, but it is described under the designer guide ), The good part is that it uses same technique as Dataref logic, so it should be simpler to get use to.
Overall, Logic, if uses correctly, can really help the designer to add more realism to the mission, but it should not be on account of the fun factor of the simmer and the simmer needs to be aware of what needs to be done for success, like cutting the mixture after landing.
Enjoy
Snagar