Quests and Objectives

[663633e8a73daMrTrip]

Quests and Objectives

(This could use some expanding. This was taken from the shocktut and is a good starting point, and explains what the qb filters do.)

Depending on how you view it, the way in which ShockEd handles quests and objectives is either a blessing or curse. Unlike Thief DromEd, there is no separate scripting commands for adding quests. In Thief DromEd, you would create a specific quest type which could be viewed on your objectives screen, "Get The Bafford Scepter" for example. ShockEd doesn't use this victory checking system, instead goals are handled via the object system. Certain markers have scripts on them which allow custom variable flags to be set. These flags are accessible through the entire game, irrespective of what actual 'level' the player is on. There also exists triggers on these custom variables. The general idea is that you have a trigger waiting to do something when a variable is set. For example, turn elevator on when ElevatorON is 1. You then would have a set trap that sets ElevatorON to 1 when the player did whatever was necessary to turn the elevator on. This system is more versatile than convict, but is perhaps harder to learn.

The actual goal notes displayed on screen has to be done separately. If you did set up a system that disable the elevator like this, then there wouldn't be a corresponding note - you would have to create it yourself and toggle it complete the same time as the elevator started working.

The collection of objects which perform these checks are known as "QuestBits" in the hierarchy, and exist under Traps. There are six of them: QB Set, QB Filter, Anti-QB Filter, QB Trigger, Anti-QB Trigger, and Simple QB Trigger. Like all other traps they work on switchlink signals, and they all make use of the properties Script->QBVal and Script->QBName

A QB Set is the one you would use when a quest would be complete. On an incoming TurnOn signal through a switchlink they set the variable defined in QB Name, to the number in QB Val.

A QB Filter acts like an AND gate. They only allow signals from the incoming switchlink to pass if the variable named in QB Name satisfies the value in QB Val. Useful when you want a device to only work when an objective has been completed. Remember that it doesn't actually produce a signal, it only allows one to pass.

An Anti-QB Filter allows the signal to pass when the condition is not satisfied, for example to keep spawning monsters until you click a switch. Remember that it doesn't actually produce a signal, it only allows one to pass.

A QB Trigger is different from a simple trigger. It takes an incoming switchlink signal and executes any relevant property on the marker if the variable named under QB Val is satisfied, ie, displays a message such as "Computer Online". It does this by using the UseMessage: MessageName property, which displays the corresponding message from usemsg.str in the strings.crf file.

An Anti-QB Trigger is the same as a QB Trigger, but activates the message when the variable is not set.

A QB Simple Trigger seems to send a TurnOn signal when the variable changes. We are guessing this, as the examples that we have looked at in-game do not have a QB Val setting.

[663633e8a783fRocketMan]

This topic is an excellent candidate for a visual demonstration, either pictorial or video.  I can't stress how many times I've read the definitions posted above in one form or another but have been unable to execute them in any meaningful way in the game.  I've concluded that I'm either missing some brain matter or this feature of ShockED does not lend itself to a written explanation.  The former is entirely possible as I don't learn the way most do but then again, ShockED isn't the most user-friendly thing ever conceived.

[663633e8a793aMrTrip]

Split this up to stick to the editing rules.

[663633e8a7a7cRocketMan]

Crap did I violate some very explicitly stated rule again?  I'm really bad at that I've noticed.

[663633e8a7b83MrTrip]

Lol no you're fine, in fact I'm revising them. Nothing in stone contribute away!

[663633e8a80f6RocketMan]

Since I have *FINALLY* been able to decipher the enigma that is quest bits (actually so far only qbset and qbfilter) by random experimentation, I thought I'd post my interpretation of how they work for like-minded people because for the life of me I couldn't understand the explanations that were already available.  Call it a learning disability but it just didn't compute.  So here goes:

Suppose you want to accomplish some sort of goal or mission in the game.  Say you want to have a door open itself when you cross over a tripwire in the hallway leading to it AND ONLY IF a button has already been pressed, enabling this all to happen.  In this case pressing the button is your mission!  Shodan is being a bitch and she locked the door on you so you have to go on a mission to override the door lock using the super magic override button.  Let's ignore the fact that this doesn't require the quest system to accomplish.  If you like, think of the door being on a different level, as this would then require the quest system.  Anyway, you want to have it so that you walk down a hallway, cross a tripwire in the hallway and then have the game decide whether to open the door or not based on whether a button has previously been pressed (say the button is a "MASTER DOOR LOCK OVERRIDE" or some such nonsense).  To put this a different way, IF (Button Press == TRUE & Tripwire Activation == TRUE) THEN (Open door).  This'd be kind of how you'd logically code such an event.  Since this isn't yet how the quest system works, let's write it another way  (just some shitty pseudo-code): 

Button Press == 0;
Tripwire Activation == FALSE;

IF ((Button Press > 6) & (Tripwire Activation == TRUE))
THEN (Open Door)

So you see that we have some essential ingredients.  We have 2 variable declarations, we have an IF/THEN conditional check and we have an action that results if the condition is true (if both conditions are true)

In ShockED there are entities which do the same job as each of these but I didn't know until now because they're somewhat camoflauged.

First of all your Button Press variable is basically a switchlink from "a button".  If you don't click the button, it doesn't fire If you click the button, it fires.  As for the tripwire, once again, if you don't cross it it won't fire (FALSE) and if you cross it, it will fire (TRUE).  These OBJECTS in ShockED, the button and the tripwire are your variables.  Your IF/THEN statement is a QB Filter.  This is part of the quest system.  The QB Filter, like an IF/THEN, compares 2 values to each other and if the comparision is TRUE, it executes an actiion.  In the case of QB Filter, the only action it executes is to permit a signal to cross it.  Therefore it is a bridge between 2 other objects that are trying to send and recieve a signal.  You must create a link FROM the sending object (the tripwire) TO the QB Filter and then FROM the QB Filter TO the door.  Now the QB Filter, unlike a generic IF/THEN statement seems to only be capable of checking if a variable is greater than a specified value.  The variable it compares is defined in QB Set. 

So let's back up and go back to the fact that we consider pressing a button to setting a variable TRUE.  This is one of the prerequisites to allowing the door to open.  in order to use the button as a variable, we have to create a QB Set object and then create a variable name (by adding the property QB Name) and also telling that variable what value to take when initialized (by adding the property QB Val).  Since we want this variable to be TRUE when the button is pressed, we choose something greater than 6 in the above example, like 7 and put that in QB Val.  Now we switchlink the button to the QB Set object and pressing the button will create a variable and assign the value 7 to it. 

Now that we have configured the machinery to create a variable with the value 7, at the press of a button, we need to feed that into the IF/THEN statement (the QB Filter).  So, as stated, make a switchlink from the tripwire to the QB Filter and from the QB Filter to the door.  Now inside the QB Filter, create your conditional statement by adding QB Name and QB Val, QB Name being the same as the one in QB Set and QB Val being the number 6 because that's what we want to compare our variable to.  Since our variable is 7, it's greater than 6 so this is TRUE and when we cross the tripwire, that will also fire TRUE thus satisfying both conditional requirements and permitting the switchlink to cross the filter and hit the door.

To summarize:

You want:  IF A = TRUE and B = TRUE,  THEN allow a signal to pass and do some shit
Here, A is some sort of mission, and B is some sort of triggering entity that does some shit

The label A is the QB Name property in QB Set
The value of A is the QB Val property in QB Set
There is no label for B, it's just an object that sends a signal like the tripwire above.
The value of B is going to be TRUE when you activate it and FALSE before that.
The value you want to compare A to is QB Val in QB Filter.
The comparison is always IF A > (the value in QB Filter) THEN don't block signals from linked objects

So you portalize and launch your level.  You cross the tripwire.  It fires a signal to the door but gets blocked by the QB Filter because the button hasn't been pressed.  So you go back and press the button.  The button fires TRUE to the QB Set and creates a variable "George" with value "7".  Now you cross the switchlink again and the filter checks "Is George > 6?"  "Yes it appears to be" "Ok you can pass a signal now" and the switchlink passes the filter and hits the door.  The door opens.  Shodan is very displeased.