Ok, I think we're almost there.....
So, all it really does is start scripts at the start of a mission....
No, game logics have some very special functions (in waypoints, for example), which are all nicely laid out in macguba's tutorial that he points to in his first post. It is also very useful to use as an 'invisible unit' in many scripts, which is what most people use it for.
....and save the mission editor the hassle of putting exec lines in the init script of the mission?
Okay, I get the feeling you want the complete (read: long) explaination about why you would do this.... so here goes:
Now, as far as ddons that have game logics in them: there is nothing special about the fact that they are game logics. You see, in a unit's config, you can code eventhandlers, just like the ones you add via scripting. However, there is a handy little EH that runs when the unit is created--basically, it is like an "init field" that you add into the unit's config. From this init field, you can run scripts that are inside the addon (or do any other scripting you want).
This is nice because, like I said, it makes things seem easier for the mission editor. Yes, you
could just tell the editor (in the readme) to paste a certain line into his init.sqs. So at first, it doesn't seem like it is really making anything easier. That's what I thought when I first saw this technique. But there are some really good reasons to do this if you have lots of scripting (such as the Unified Artillery or Zombie addons).
I'll take my Vampire's Undead addon, for example. Not because I'm taking credit for the idea of using game logics like this (I learned it from depboing the UA and Zombie addons), but, well, because I made it, so I know why/how I did everything. If you want, you can download the addon (link in my sig), de-pbo it and check everything I'm gonna say.
When I first started the addon (back when I was just developing it for one person), I had no logics. Actually, I didn't know how to make units run scripts automatically at all. So I had to tell the editor, in the readme, to do a bunch of stuff, like make a trigger covering the whole map, then put this in it's activation field, then make an array of units called X, etc. Okay, that's doable for most editors, but if you forget something, you're in trouble.
But there were more problems than that: when I would update/add to the scripts, I often had to change the instructions on how to get the addon working. So then I learned how to make units execute scripts when they are created. Now every unit would run it's own script (hellhounds run the hellhound script, skeletons the skeleton script, etc). But I still needed a script that would be only run ONCE, which would do a bunch of setup work for the unit's scripts. I'll call this script init_once.sqs.
It IS possible to have a hundred identical scripts running, and then to have ONE of them execute init_once.sqs (you just use some random delays and a global variable), which I originally did. But later, due to some technical issues I won't get into, I decided it would reduce CPU load if I just had a unit that the editor manually placed one on the map, which would run the script.
Now, like I said at the beginning, this could have been ANY type of unit. But since it was so important, and it wasn't really to be used as a
unit in the mission, I wanted it to really stick out, but at the same time, not get in the way, in the 'add unit' menu. The "game logic" side really works well for this, because there is almost nothing there. I think that is why that is where you usually find this kind of stuff.
Okay, yeah I could have had the editor copy and paste something into his init.sqs. I also had a bunch of global variables that would set things like how much damage the vampires did, how many spells the player got, etc. These I originally told the editor to manually set in his init.sqs, if he didn't like the default values. That works fine, except, again, people often don't like to read the readme, so they might not even know about that stuff.
Taking a hint from the Zombie addon, I decided to add in some logics that would set the "strength" of the vampires, by automatically adjusting those global variables for you. That way, the editor only has to plop one little thing down, and "I" do the rest of the work for him.
You still may be thinking, "so you're STILL saying, it is just to make life easier for lazy/illiterate people?!" But the answer is no, and I've been hinting to the reason why all along.
Taking another example from personal experience, lets say that, in my vampire addon, I wanted to add some more global variables into the mix, to further let you customize the strength of the undead. Lets say I add a true/false variable that says whether the vampires can cast a new spell, which is false by default. That's no problem if you are in the middle of making a map when I update my addon--you just download the new addon, see the changes, and adjust the new global variable in your mission. But what about those thousands of missions (yeah right) that have already been made using my addon?
Well, when someone plays the mission, they will be getting the default value of that new variable, which means the vampire's won't cast that spell. But now let's say that the mission editor was lazy, and just plopped down a "strong undead" game logic. In my new version of the addon, I will have updated the script that runs off that logic, so that it adjusts the new variable. Now, when you play the old mission with the new version of the addon, the undead will cast the spell, which makes them harder than normal, which was what the author intended for the mission.
Now imagine that little example, if you have LOTS of changes in a new version, and you can see that there is something to running scripts from game logics, other than just helping lazy editors. Long explaination I know, but you asked for it.
--------------------------------------------------------------
Okay, now about making this in your addon. Here is an example config:
class CfgVehicles
{
class All{};
class Logic: All{};
//logic used to initialize scripts
class GENB_Vamp_Patch : Logic
{
displayName = " *Initialize Undead* ";
vehicleClass="GENB Vamps";
class EventHandlers
{
init = "[] exec {\GENB_vamps\scripts\init_once.sqs}";
};
};
};That's all there is to it. The important part is right here:
class EventHandlers
{
init = "[] exec {\GENB_vamps\scripts\init_once.sqs}";
fired = "hint {fired!}";
};Here is where you add the eventhandler's in to the unit. You can add any EH here that you can add via scripting. See the tut in the ed depot for more info on eventhandlers. I've added in a "fired" EH here for an example. the only important note is that you are writing your script between quotes ( " " ), so make sure you don't use any quotes! Use curly braces { } instead of quotes, as in the above example.
Just to make it clearer, to refer to a script inside an addon, it looks like this:
[whatever] exec "\pbo file name\script.sqs"
Or if you had folders inside of your pbo, it could look like this:
[whatever] exec "\pbo file name\folder\subfolder\script.sqs"
Or how ever many number of folders you want. This syntax, like all scripting, is the same whether the script is inside an addon, or inside a mission. So techinically, the scripts inside of one addon can reference the scripts inside of another addon (assuming they are there). You can even reference scripts that ARE NOT inside of any pbo (mission or addon), meaning the script is just sitting in your OFP directory, editable by anyone. The ECP does this so that you can change the settings of the mod. I think you could do some cool stuff similar to this with missions or other addons as well, but I've never tried anything specifically.
Topic: Game Logic (Read 858 times)