Mecanismos de lógica

[Sire]

Más allá de los disparadores (triggers) que son aquellos elementos que se activan una sola vez con una sola condición (p.e.: activar al entrar en una zona), en misiones complejas, sobre todo las de tipo sandbox (múltiples opciones a elegir libremente) hacen falta mecanismos (complejos) de lógica para simular situaciones como por ejemplo:
 

• Al activarse disparador, si ha ocurrido previamente tal cosa, sucede un evento aleatorio entre cuatro opciones. (P.e.: A las 10:00h el general IA, si el puente enemigo ha sido destruido, enviará un vuelo de bombarderos con uno de los cuatro objetivos pendientes)

Es realmente complejo hacer estas cosas porque en il-2, a nivel de editor no existen variables, es decir valores programables que otros mecanismos puedan comprobar fácilmente. Imaginemos un valor para PuenteEnemigo vivo o muerto (true o false). En DCS utilizaríamos una bandera (flag) identificada con un número (p.e.: Flag 100) y desde cualquier lugar de la programación podríamos comprobar si la Bandera 100 es cierta o falsa (IF Flag 100 true).

En IL-2 eso no se puede porque, insisto, no hay cosa tal como variables dentro del editor. Hay controladores que pueden estar encendidos o apagados. Iconos de control, con señales de entrada y salida que hay que alimentar y comprobar para que funcione. Por eso DCS es programación e IL-2 se parece más a mecanismos de relojería o de electrónica, con sus cables y circuitos.

Incluso aunque se conozca bien su funcionamiento, crearlos es complicado porque acaban siendo una maraña y cualquier error en una parte estropea el conjunto. La solución es utilizar grupos ya preconstruidos, con entradas y salidas predefinidas y un mecanismo interno que ya no tenemos que tocar. Como las patas de un microprocesador.

No es imprescindible ser consciente del funcionamiento interior del "procesador", pero conocerlo te va a dar una confianza absoluta en la construcción de simulación en IL-2 (no me atrevo a llamarlo programación).

Un recurso fundamental para ello es este fabuloso recurso que SAS_Skylla ha puesto a disposición de todos aquí.

Para preservarlo (por si acaso la fuente original se borra) voy a hacer un corta y pega en inglés directamente. Si tengo tiempo haré la traducción y el detalle de funcionamiento de cada uno de ellos. 
De nuevo recordar que su autor es SAS_Skylla.

[Sire]

De SAS_Skylla:

Hi Gents,

What until now has been missing badly in the BoX ME were some kind of logic components. I have created a few switch and gate groups that should help to get around this.
All these groups are based on a query principle. That means, incoming links set the status of a switch or gate and this status gets saved within the group. The outgoing signal only gets produced on request.
This is due to the fact that incoming signals will only very seldom come in at the exact same time. Also this way you have to chance to "remember" in your mission if a certain signal was already sent or not.

Download:

• Version 1.2:

logic gates and switches: 

http://www.mediafire.com/file/2stkczq80v4wu7a/logic_gates_and_switches_v1.2.7z/file
demonstration mission: 

http://www.mediafire.com/file/jd9i4kuvm87d4o5/logic_gates_demo_v1.2.7z/file

Below you can find a description of the components and how to use them. I hope they will be as useful for your missioneering as they are for mine 


1. Boolean switch
2. Ten way switch
3. Switch concatenation
4. Logic gates
   4.1. General structure
   4.2. Gate concatenation
5. Multiplexer


1. Boolean switch:

The basic idea behind it is pretty simple: When you are building a mission, you might want to base some decisions about what is going to happen next on wheter a certain signal was already sent in the past. For this there is the boolean switch that can either result in a true or a false output.
The switch looks like this:



As you can see, the switch has three inputs and two outputs:

• IN: set true: Will set the switch to state true, but will produce no output signal
• IN: set false: Will set the switch to state false, but will produce no output signal
• IN: query: Triggering this will query the state of the switch and will either lead to a false or a true output signal
• OUT: true: Indicates that the switch state is true
• OUT: false: Indicates that the switch state is false

The switch is based on the fact that in the BoX ME a Timer Trigger can have two states: it can either be activated or deactivated. When the switch is queried and the testfalse timer is active, it will deactivate the true output and trigger a false output. If it got deactivated, the waittrue timer will produce a true output after 10 ms. Cool, huh? 
Please note that the switch will lead to a false output by default.


2. Ten way switch:

Sometimes just two states might not be sufficient to trace what's going on in a mission. That's where the next group, the ten way switch might come in handy (sorry, but I had to leave out the MCU names because it would get messy otherwise):



The switch has eleven inputs and eleven outputs. The topmost row of timer MCUs are the inputs, the lowest row are the outputs.
The leftmost timer queries the switch state and will lead to one of the outputs to fire, depending on the switch state. The other inputs will set the switch state to state 1 ... 10, beginning from the second timer MCU. Please note that those will only set the switch state and will not trigger an output singal.

The lowest MCU row are the outputs. If the switch got queried, they will show the switch state from 0 (leftmost) to 10 (rightmost).
As you may have noticed it is impossible to set the switch state to 0. In fact this state shows that the switch has not yet been used. It will only be active if none of the states 1 to 10 has been set during the mission yet.

The idea behind the switch is again based on timer (de)activation: If a status is active, it's check state timer (middle row) will be activated, all other check state timers will be deactivated and therefore cannot produce an output signal.


3. Switch concatenation:

If you should ever come around an occasion where even ten switch states are not enough, you can also concatenate two (or more ...) ten way switches. It works like this:



We sacrifice the state 10 of switch 1. It's output gets target linked to the query input of switch 2. All set state inputs of switch two get an additional target link pointing to the set state 10 input of switch 1.
Now if you choose a state of switch two and query the overall state (with the query input of switch 1!), switch 1 will lead to a state ten output. This one will query the state of switch 2 which will then lead to the desired state output.
Please note that in- and outputs of state 10 / switch 1 must not be used for any further signal processing!


4. Logic gates:

Now that we have the possibility to save a signal or a signal state, we will also like to process them further. If you make a dynamic mission you will soon come to the point where you will want to base your decisions on whether certain signals have been sent and others haven't, or whether some switch is in one position or  not in another ..
That's where logic gates come into play. Depending on two input signals (each is either false or true) they produce one output signal which can be  false or true.
I have created six logic gate groups: AND, OR, NOT-AND (NAND), NOT-OR (NOR), exclusive OR (XOR) and exclusive NOT-OR (XNOR). You can find their truth tables below:

          

        


4.1. General structure:

The signal processing in the logic gates is a little more complex and differs from gate to gate, therefore I will just discuss their structure in general here:



The basis of each logic gate are two boolean switches as introduced earlier.
Therefore each logic gate has five inputs and two outputs:

• IN: State 1 TRUE: Will set the state of input signal 1 to true, but will produce no output signal
• IN: State 1 FALSE: Will set the state of input signal 1 to false, but will produce no output signal
• IN: State 2 TRUE: Will set the state of input signal 2 to true, but will produce no output signal
• IN: State 2 FALSE: Will set the state of input signal 2 to false, but will produce no output signal
• IN: query: Triggering this will start the query process and will either lead to a false or a true output signal
• OUT: TRUE: Gets triggered if the result is true
• OUT: FALSE: Gets triggered if the result is false

4.2. Gate concatenation:

Just like the switches the gates can also be concatenated - may it be to just allow more input signals for "one" gate or in order to combine different gates with each other. Below you can see how it is done:


 
The outputs of gate 1 are connected to the corresponding signal inputs of gate 2. Furthermore they are connected to a 5 ms timer which will start the query process in gate 2. In this example we therefore get an AND gate that allows three input signals.


5. Multiplexer:

The multiplexer is to be used when more consumers depend on one state switch, but should not receive it at the same time. Example: AI flight on spawn depending its skill on the number of players spawned. Ten minutes later the next flight spawns, it would be bad if the logic of the first flight got called again!

In my implementation the MUX looks like this (shown here is the 5x5 MUX only, the others are too big to really see something):



The 5x5 MUX has 11 inputs and 25 outputs:

1. IN: state[1..5]: Will set the switch state (analog to ten way switch).
2. IN: input[1..5]: Defines which output is to be used for the state signal.
3. IN: main query: Will start the query process to return the state via the defined output.
4. OUT: [...]: According to state and selected output.

The 10x10 MUX has 20 inputs and 110 outputs:

• IN state[1..10]: Will set the switch state (analog to ten way switch).
• The query process is not started.
• IN: input[1..10]: Defines which output is to be used for the state signal. After that the query process is started automatically, which will lead to the display of the state through the desired output.
• OUT: output[1..10] state[1..10]: indicating the state via the selected output.
• OUT: output[1..10] state undefined: indicates that the state has not been set yet via the selected output

The 10x10 MUX has 21 inputs and 110 outputs:

• IN state[1..10]: Will set the switch state (analog to ten way switch)
• The query process is not started.
• IN: input[1..10]: Selects the output gate which shall receive the signal through the next query.
• The query process is not started.
• IN: query: starts the query process.
• OUT: output[1..10] state[1..10]: indicating the state via the selected output(s), or none if none is selected.
• OUT: output[1..10] state undefined: indicates that the state has not been set yet via the selected output. Is not triggered if no output gate was selected.

Please note:

• In the 5x5 MUX, both a state and an input needs to be triggered before main query, otherwise you will get not output signal!
• On the 10x10 multi MUX one input gate needs to be triggered to produce an output signal.
• The normal 10x10 MUX has no such limitations.
• When query is triggered, the MUX will not be able to receive a change of state or input for ~300ms. Any signal incoming during this period will get lost.
• Only one output gateway can be active per query. This does NOT apply for the 10x10 multi MUX.

---
Credits

Idea and implementation: SAS~Skylla

Many thanks to SAS~Storebror for beta testing!