Home   Help Search Login Register  

Author Topic: Game Logics  (Read 2834 times)

0 Members and 1 Guest are viewing this topic.

Ram TN

  • Guest
Game Logics
« on: 01 Sep 2002, 12:09:14 »
Yeah yeah, I know I probably ask a stupid question here, but: what are the game logics? What are they used for?

DeusRich

  • Guest
Re:Game Logics
« Reply #1 on: 01 Sep 2002, 12:28:38 »
well
apart from any real practical use, you can place one down and use it while scripting ie: tell someone to go to gamelogic, rather than a huge coordinate of the whole map, which is very difficult.
So it is used as a marker - an invisible marker that nobody can see and isnt counted as west or east, so you can create units, tanks or whatever at that position.
If you are new to all of operation flashpoint dont worry too much because you can use waypopints instead of domove commands and you probably arent going to using the createvehicle command just yet.  8)

Gameer_77

  • Guest
Re:Game Logics
« Reply #2 on: 01 Sep 2002, 12:28:54 »
**Darn you DeusRich!  ::)  20 secs between us...ooooh :o**

They're kind-of invisible units. :-\ You can use them to get the opistion of somewhere, or use them as a prop (? player distance GameLogic1:titletext ["I don't see this so called 'Game-Logic'","PLain"]

Geddit? No? You can put them in vehicles to occupy a space in them so you can sit at the back of the bus now!  :D

You can do most things with them that you can do with normal units (bar switchmove and playmove)

Now, could i possibly ask a question?

No? well im doing it anyways.  ;)  What does the _ do to a variable? Ie. _name and name?

Sorry about intruding RAM but i didnt feel this was worthy of a new thread and its kinda embarrassing after making missions for 8 months now.  :-[

 8)PEACE
« Last Edit: 01 Sep 2002, 12:33:09 by Gameer_77 »

DeusRich

  • Guest
Re:Game Logics
« Reply #3 on: 01 Sep 2002, 12:39:59 »
it makes it local. Im not 100% sure about the difference between a local thing and a global thing, but from what I have picked up, if you call something to a script, and change it to a local variable/argument/thingy:

_localunit = _this select 0

this means, that if you make a trigger and what every unit that goes into it to do a pushup, you would type in the trigger:

anyone
condition:this
activation: [thislist select 0] exec "local.sqs"

so any units in the trigger, would be changed in the script, to _localunit, so you can do what you want to any unit that enters the trigger, not just specific ones. Because if you had Jon in your script, it would only work for Jon. Anyway, I always use underscores in scripts because it is good practise as you can see what things are units and not commands.

Hope this helps ;)

Gameer_77

  • Guest
Re:Game Logics
« Reply #4 on: 01 Sep 2002, 12:44:51 »
Hmmm...Yah! ok, so theres really no big diff then, no?  ::)

Ok, :)

 8)PEACE
« Last Edit: 01 Sep 2002, 12:46:38 by Gameer_77 »

Ram TN

  • Guest
Re:Game Logics
« Reply #5 on: 01 Sep 2002, 12:52:23 »
hehe... no prob gameer  :)
So, from what I've figured out, I - as a novice mission maker - do not need the logics. Am I right?

Demoniac

  • Guest
Re:Game Logics
« Reply #6 on: 01 Sep 2002, 12:58:55 »
About the _ before the variable name:
When you put a _ before a variable's name, it is a local (or private, as it's called in Visual Basic) variable. This means that it can only be seen by the script in which you use it (that's also why you can't use local variables with triggers etc.). So you could start 10 scripts which all declare a variable _Unit, but they won't overwrite each others values.
When you don't put the _ before a variable's name, it's a global (or in VB: public) variable. This means the variable can be seen (and modified!) by everything in your mission. So when you set the On activation field of a trigger to BaseUnderAttack = true you can put a line in your init.sqs @BaseUnderAttack and the script will continue when the trigger is activated.
I don't know if you understand it like this, I have had programming lessons at school so I already have some experience with the domain of a variable (domain = which parts of a program can see the variable)

Demoniac

  • Guest
Re:Game Logics
« Reply #7 on: 01 Sep 2002, 13:04:05 »
hehe... no prob gameer  :)
So, from what I've figured out, I - as a novice mission maker - do not need the logics. Am I right?
They're not required, that's sure. But they're nice helps when you have to set cameras or units to a certain position.

Offline Chris Death

  • Former Staff
  • ****
  • Finally Death's gonna get ya
    • OFPEC
Re:Game Logics
« Reply #8 on: 01 Sep 2002, 13:56:36 »
Well, in my opinion, gamelogics are the most powerful
things in OFP editor. You can do all, what can be done
in a script, with a gamelogic aswell.

Here's a tutorial (it's from the old ofpec forum), i can't
really remember by whom, but i think it was SEFE:

Code: [Select]
Game Logics

You may have asked yourself what's the use of the game logic units. Most mission designers use it to get positions on the map (eg. Position = GetPos NameOfTheGameLogic).

But the game logic units have a much higher potential! You can use them to implement complex conditions to your missions without using any scripting. But you have to understand the behaviour of game logics:

1. Game logics have a position and can activate triggers just like any other units. Take a look at the condition box of a trigger. There you will find the option "game logic present". You can also group the game logic and the trigger and set the condition to "vehicle present". In this case the trigger will only be activated by the presense of this game logic.

2. You can define waypoints for a game logic unit. The waypoint type can be AND or OR (unlike the waypoints for a 'regular' unit that can be MOVE, HOLD, SEEK AND DESTROY etc.). I'll come to the waypoint type later. As soon as the mission starts, the game logic will go from waypoint to waypoint. But unlike all other units the game logic will not move to the waypoint but 'jump' immediately to it's position.

3. Like for all other waypoints you can define a condition, a timeout and an OnActivation code for a game logic waypoint. When a game logic reaches a waypoint it will perform these actions (in this order):

Wait until the condition is TRUE

Wait until the timeout is passed

Execute the OnActivation code

Jump to the next waypoint


4. Like all waypoints you can synchronize a game logic waypoint with a trigger. That means that the game logic will not proceed to the next waypoint until the trigger condition is TRUE. Now we'll return to the type of the game logic waypoint (AND or OR). If you synchronize more than one trigger with the waypoint, the behaviour of the trigger will depend on the waypoint type. If it is an AND waypoint, the game logic will only jump to the next waypoint when all triggers are activated. If it is an OR waypoint it will proceed to the next waypoint when any of the triggers is activated.

5. Like all other waypoints you can also synchronize a game logic waypoint with any other waypoint. The game logic and the other unit will not proceed to their next waypoints until both of them have reached the synchronized waypoint. This is absolutely the same behaviour as if you would synchronize two non-game logic units. Of course you can also synchronize two game logic waypoints.

But what is that all good for? I'll give you some examples showing the whole potential of game logic units:

Example 1: Establishing radio conversations

To establish a radio conversation you would probably write a script that would look like this:

Alpha1 SideRadio "Message1"
~5
Bravo1 SideRadio "Message2"
~8
Alpha1 SideRadio "Message3"

Without a script you would do it like this:

You'd create a game logic and four waypoints

You'd synchronize the first WP with the trigger that will start the conversation

In the second WP's OnActivation field you'd write: Alpha1 SideRadio "Message1"

In the third WP's OnActivation field you'd write: Bravo1 SideRadio "Message2". Since this radio message has to be sent five seconds after the first, you'd set the timeout to five seconds

In the fourth WP's OnActivation field you'd write: Alpha1 SideRadio "Message3". You'd set the timeout to eight seconds.


As you can see, we can use the timeout of the game logic WPs to time events without having to call a script. While the timeout is equivalent to the ~-operator, the condition field is equivalent to the @-operator.

You can use this method also to create cutscenes without any scripting. In the attachment you will find an example mission that demonstrates a cutscene (radio Alpha) and a radio conversation (radio Bravo).

Example 2: Combining triggers to complex condtions

Now it's going to be a little more complex. What if you had three triggers. The third trigger should be activated if one of the two other triggers are activated. You could also express it like this:

Trigger3 = Trigger1 OR Trigger2 [do not use this syntax in OFP, it's just to describe the boolean correlation of the triggers]

To achieve that you can use a game logic unit:

Create a game logic and define two waypoints. Place the first waypoint outside the third trigger's area and the second one inside the area.

Set the first waypoint's type to OR.

Synchronize the first and the second trigger with the first (OR) waypoint

Draw a group line [F2] between the game logic and the third trigger. Set the trigger's condition to "vehicle present"


The whole thing will work like this: At the beginning of the mission, the game logic will jump to it's first waypoint. Since it's outside of the third trigger's area, it doesn't activate it. The game logic will wait at this OR-waypoint until either the first or the second trigger will be activated. As soon as this happens, the game logic will jump to it's next waypoint. This waypoint is inside the area of the third trigger and so it will be activated. That will cause exactly the effect we wanted.

Finally, let's get really advanced. This time you have four triggers. The fourth trigger should be activated on this condition:

Trigger4 = (Trigger1 OR Trigger2) AND Trigger3

Let's go to work:

Create a game logic, define two waypoints. The first one must be an AND waypoint. The second waypoint must be inside the area of Trigger4. Group Trigger4 and the game logic and set the trigger condition to "vehicle present". This is all similar to above (except that we now use an AND waypoint).

Synchronize Trigger3 with the first waypoint of the game logic.

Create a second game logic with two waypoints. Set the first waypoint to OR. Synchronize the second waypoint with the first waypoint of the other game logic.

Synchronize Trigger1 and Trigger2 with the first (OR) waypoint of this game logic.


But how the hell does this work?

The second game logic will proceed to it's second waypoint if either Trigger1 or Trigger2 is activated. That's the same as above. You could also say:

GameLogic2ReachedWaypoint = Trigger1 OR Trigger2

The first game logic will reach it's second waypoint and activate Trigger4 when Trigger3 is true and the second game logic has reached it's second waypoint:

Trigger4 = GameLogic2ReachedWaypoint AND Trigger3

If you combine these expressions, you'll get:

Trigger4 = (Trigger1 OR Trigger2) AND Trigger3

Voilà!

You can even create more complex condtions in your mission when you combine three or more game logics.

~S~ CD
Dont argue with idiots....they will bring you down to their level and beat you there with experience.

How to use Waypoint type Scripted

Ram TN

  • Guest
Re:Game Logics
« Reply #9 on: 01 Sep 2002, 16:17:32 »
A good tutorial. Thanks Chris!

Offline Chris Death

  • Former Staff
  • ****
  • Finally Death's gonna get ya
    • OFPEC
Re:Game Logics
« Reply #10 on: 01 Sep 2002, 17:32:39 »
Quote
A good tutorial. Thanks Chris!

Thank goes to SEFE (if it was him)  ;)  :)

~S~ CD
Dont argue with idiots....they will bring you down to their level and beat you there with experience.

How to use Waypoint type Scripted

Gameer_77

  • Guest
Re:Game Logics
« Reply #11 on: 01 Sep 2002, 18:17:50 »
About the _ before the variable name:
When you put a _ before a variable's name, it is a local (or private, as it's called in Visual Basic) variable. This means that it can only be seen by the script in which you use it (that's also why you can't use local variables with triggers etc.). So you could start 10 scripts which all declare a variable _Unit, but they won't overwrite each others values.
When you don't put the _ before a variable's name, it's a global (or in VB: public) variable. This means the variable can be seen (and modified!) by everything in your mission. So when you set the On activation field of a trigger to BaseUnderAttack = true you can put a line in your init.sqs @BaseUnderAttack and the script will continue when the trigger is activated.
I don't know if you understand it like this, I have had programming lessons at school so I already have some experience with the domain of a variable (domain = which parts of a program can see the variable)

Oooh, thought it was something like that, just didn't know which way round it was. Thanks Demoniac  ;D

 8) PEACE