Welcome, Guest Wednesday 23rd April 2014, 12:49:55
   Home   Help Search Login Register  

OFPEC Forum

Author Topic: What is a "Gamelogic"?  (Read 1321 times)
0 Members and 1 Guest are viewing this topic.
Bahger
*
Offline Offline


« on: 27 Feb 2010, 19:31:01 »

Sorry but I'm having a little trouble wrapping my brain around this concept.  I looked at the Beginner's Tutorial here but, good as it is, I still don't quite get it.  What is a "Gamelogic" and how can I understand its application in mission design?  Could somebody give me an example?

As always, thank you.
Logged
Krieg
Mission Maker
*
Offline Offline


Who dares wins.


« Reply #1 on: 27 Feb 2010, 19:44:21 »

Although ArmA2 is far out of my OFP realm, I think I can answer this one.

Gamelogics are basically invisible objects that can have multiple purposes in missions, like for example, scripting unit to move to the gamelogic, making them useful for precise movement. They also can be used to createVehicle a unit at their position, etc. They are basically useful with any script that needs certain position in order to function.

The other kind of gamelogics I've encountered are the ones used to load certain scripts/functions at beginning of the mission, making them similar to init.sqf (or init.sqs if you are still playing ArmA/OFP).

That's pretty much all I know about them.

Hope that helped,
Krieg
Logged

If you see a light at the end of the tunnel, then it's probably an enemy tank.
Wolfrug
Addons Depot
Administrator
*****
Offline Offline


Official OFPEC Old Timer


« Reply #2 on: 28 Feb 2010, 10:30:53 »

Gamelogics can also be used for any number of applications, it's really up to the designer to figure something out Cheesy For instance, they can be put inside vehicles (gamelogic1 moveincargo car1) to fill up cargo spaces - say you want everyone in the squad to sit in the back of the truck instead of in the front, you simply fill up the front spots with game logics and they're inaccessible!

Or you can use them to create directional sounds, for instance an owl hooting in a nearby tree - simply have them "say" the sound and it will issue forth from their position.

Finally, you can also use them for various forms of in-editor scripting - their waypoints are different than regular ones, being a progression of "AND"s and "OR"s. Frankly I'm not entirely sure how the AND and OR thing works, but I -think- that if you synchronize more than one waypoint or a trigger with the AND waypoint, it means all three conditions have to be fulfilled (the AND waypoint's and the synchronzied WPs/triggers) for the waypoints/triggers/etc to activate, whereas if you synchronize it with an "OR" waypoint it means just ONE of the conditions need to be true. But don't quote me on that.

 I sometimes use the the Game Logic waypoints as a way to create longer conversations - I add a string of AND waypoints with different "Timeout" values, and then I add the conversation in the On Activation field (creating a back and forth). But they could equally well be used to monitor just about any other thing that would normally require a lot of triggers (say you have to finish three objectives in a certain order, you could just have a single GL and three waypoints with different Condition statements leading up to the completed mission, instead of several triggers).

GLs are a versatile and powerful tool for the editor, and one I suggest you use your own imagination to make work. Wink I've for instance created unmanned turrets capable of engaging enemies using gamelogics in the past, which was a bit of a hoot.  Good

Oh, and as Krieg noted: GLs are also often used to initiate scripts and the like (such as the "Modules" or NIM weather). This is basically just a matter of it being convenient to use GLs for this - there's nothing stopping anyone from using ANY object as a way of initializing a script, GLs are just useful since they're indestructible, invisible, and take up no resources. Smiley

Hope that helped!

Wolfrug out.
Logged

"When 900 years YOU reach, look as good you will not!"
Bahger
*
Offline Offline


« Reply #3 on: 01 Mar 2010, 01:43:17 »

Very helpful, gents, many thanks.
Logged
Mandoble
Editors Depot
Administrator
*****
Offline Offline



WWW
« Reply #4 on: 01 Mar 2010, 10:12:25 »

And a last note, unless created with CreateVehicleLocal, gamelogics will be local to the server.
Logged

bardosy
Honoured Contributor
***
Offline Offline


campaign designer


WWW
« Reply #5 on: 01 Mar 2010, 10:18:18 »

Quote
they can be put inside vehicles (gamelogic1 moveincargo car1) to fill up cargo spaces - say you want everyone in the squad to sit in the back of the truck instead of in the front,

It doesn't work in my missions at ArmA2. It worked for OFP/ArmA1, but doesn't for ArmA2... Sad
Logged

Fix bayonet!
nominesine
Intel Depot
Administrator
*****
Offline Offline


I'm NOT back!


WWW
« Reply #6 on: 01 Mar 2010, 17:07:24 »

And a last note, unless created with CreateVehicleLocal, gamelogics will be local to the server.

Wich is VERY useful for MP scripting. Refering to the game logic is a foolproof method of running server side scripts.
Logged

OFPEC | Intel Depot
RETARDED Ooops... Retired!
Mandoble
Editors Depot
Administrator
*****
Offline Offline



WWW
« Reply #7 on: 01 Mar 2010, 19:48:33 »

While in A2 to make sure a script is run server side the correct way would be
Code:
if (isServer) then
{

};

BTW, that's correct, GLs in A2 cannot board vehicles and sadly the global ones must be created with createUnit instead of createVehicle. Only createVehicleLocal works with GLs.

A "known" and global GL might be also a good way to pass info between all the clients and server, or even commands:
Code:
my_director_gl setVehicleInit "hint ""HELLO EVERYBODY EVERYWHERE""";
processInitCommands;

Also to transmit values:
Code:
my_director_gl setVariable ["common_value", 123, true];
Logged

Pages: [1]   Go Up
  Send this topicPrint  
 
Jump to: