====== How to create a combination lock using XG ======


//Work In Progress: This tutorial is not yet complete. It is published in the hopes that it might be of use but errors and omissions should be expected --danij, 12 October 2007//


===== Overview =====


Chances are, you have felt somewhat limited by [[games:doom]]'s key-locked doors when creating maps. Being continually faced with the same gameplay challenges is pretty un-interesting huh? Have you ever wanted to add a combination lock to secure an area in your map? Perhaps there is a secret laboratory in that deep space research lab with dangerous experimental weaponry hidden inside? This tutorial teaches you how to do just that.


===== Introduction =====


For this tutorial we will be utilizing XG to implement a combination lock. Be aware, that we will be chaining together multiple XG [[xg:line_type|line types]] to create a re-usable lock mechanism that can be used to activate another mechanism (here, we will use a simple door but in your own maps you could [[xg:class:build_stairs|build stairs]], [[xg:class:end_level|end the level]] etc...).

In the process, we will discuss the event-driven nature of XG and how it can be used in different ways to replicate complex mechanisms. As such, this technique may not be suitable for those new to XG.


===== Concept =====


As already mentioned, we are aiming to create a combination lock, which (when the right combination is entered) will open a door. Before we go any further, lets first embelish this somewhat basic concept and try to define exactly the behavior we are trying to create.


==== Requirements ====

  *  The player should be able to manipulate the switches of the combination lock by //using// them.
  *  Each time a switch changes state, we must check whether the current configuration activates the door. 


==== Features ====


It would also be nice if we didn't have to create a tailored set of [[:ded|definitions]] for each instance of the combination lock. Lets outline some features that would improve the re-usability of our combination lock.

  *  Any number of switches should be supported by an individual combination lock.
  *  Any number of combination locks should be able to co-exist within the same map.
  *  We should not have to create a new set of definitions for each combination lock.
  *  The combination should be specified in the map-editor and NOT in the definition.


===== Determining events =====

/writeme


===== The switches =====

/writeme


==== Definitions ====


<code>
Line Type {
    Id = 1000
    Comment = "Combo Lock ON Switch"
    Class = none
    Flags = player_use
    Flags2 = when_act | when_deact | any
    Type = flip
    Count = -1
    Event Chain = 32767
    Act sound = "swtchn"
    Act tag = 1
}
</code>

<code>
Line Type { 
    Id = 1001
    Comment = "Combo Lock OFF Switch"
    Class = none
    Flags = player_use | active
    Flags2 = when_act | when_deact | any
    Type = flip
    Count = -1
    Event Chain = 32767
    Act sound = "swtchn"
    Act tag = 2
}
</code>


==== Explanation ====

/writeme


===== The combination validator =====


The final definition we need is that of the combination validator. Recall that earlier, when defining the switches we made use of the //Event Chain// paramater (**=32767**) to execute another linetype on activation/deactivation? This is that linetype.


==== Definition ====


<code>
Line Type { 
    Id = 32767
    Comment = "Combination validator"
    Act message = "Access Granted";
    Flags2 = any | when_act | line_act | line_inact
    Class = activate
    Count = -1
    Line act lref = act_tagged
    Line act lrefd = 1
    Line inact lref = act_tagged
    Line inact lrefd = 2

    Ip0 = "lpref_tagged_ceilings"
    Ip1 = 7
}
</code>


==== Explanation ====


Notice that there are no [[xg:triggers|(de)activation trigger]]s specified at all (normally, a linetype requires at least one trigger, for example [[xg:triggers#player_cross|player_cross]]). As our switch linetypes are //calling// the combination validator by way of their //Event Chain// paramater, there is no need to specify trigger(s). Furthermore this, means that this is a //virtual// linetype and cannot be used on a linedef in your map directly (note, that even if you //do// use it directly on a linedef - it will have no effect).