weedomatic

Your description.ext needs to define the CfgSFX class containing your chicken sounds. You'll find an example below -- the example sound would be accessed as TLpPMc1 in the trigger's "trigger drop-down menu". <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class CfgSFX { class sfx_TLpPMc1 { name = "TLpPMc1"; sounds[] = {"sound1"}; sound1[] = {"TLpPMc1.ogg",1, 1, 0.98, 0.0, 0.0, 0.0}; titles[] = {}; empty[] = {"", 0, 0, 0, 1, 5, 20}; }; }; Wrt. to attribute-parameters, the following explanation (by "bloodmixer") might help: Source: tutorial

I know you problem seems to be solved, but as a general note: A condition can either be true or false, hence the expression/variable in the condition field has to return such type of value (via e.g. comparison operations) or the variable has to be of type boolean. Loops don't return anything per se.

Did a quick test and it works with custom skins. W.r.t. "path problem", this is what I wrote in the face-classes texture-attribute defined in CfgFaces (check code above) : <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> texture = "\MyModFolder\data\custom1.jpg"; Naturally, this assumes that this folder hierarchy plus the jpg exist. Maybe you put CA or something as the root in your path?!

I hope the code "highlighting" is self-explanatory. Units set to MyFaces config will randomly select one of the defined faces in the CfgFaces class. Have not tried using custom faces, though. Not much time, here I/you go. /* *************** CODE *************** */ class CfgVehicles {  class SoldierGB;  class MySoldier_A: SoldierGB  {   // …   faceType = "MyFaces";   // …  };  class MySoldier_B: MySoldier_A  {   // …   // Inherits faceType from MySoldier_A if faceType is not overwritten   // …  }; }; // … class CfgFaces {  class MyFaces{   class Default   {    name = " MyFaces Default";    texture = "\ca\characters\hhl\hhl_33_CO.paa";    east = false;    west = false; // racs..   };   class Face1   {    name = " MyFaces 1";    texture = "\ca\characters\hhl\hhl_26_CO.paa";    east = true;    west = true; // racs...   };   class Face2   {    name = " MyFaces 2";    texture = "\ca\characters\hhl\hhl_27_CO.paa";    east = true;    west = true;   };   // …  }; };

Correct, not only folder structure plays a role in this case. That's what I somewhat implied with directionality. You access BIS addons via an interface (not that GUI-stuff), which in this case can only be the root "ca". Being able to use e.g. "weapons" as the root would make custom addons indistinguishable from BIS addons. Well, I guess you know that already.

During the pbo-process of the addon (e.g. myAddon.pbo) the necessary header is created automatically (just a semi-intelligent guess). Hence, folders created inside the addon's working directory will be used to access files inside them later (in missions, other addons) by using myAddon as the root of the path you provide, e.g. "myAddon/sounds/eek.ogg". No more "ca" as the root, since your custom addon is not nested inside ArmA/addons and the association to ca is mono-directional, i.e. custom addon -> ca.

unitCounter is the name of the trigger you would have typed in manually in the trigger's name-field. Talking about getDammage ... you could also attach event-handlers to the enemy units. One of them events that can be attached and handled is "killed", others are "dammaged", "hit", etc. There is some documentation wrt. to this in the BIS wiki. I personally would not go the EH-way this time.

How many "root" or rather biological fathers do you have on the same level? Hopefully noone else did, too ...

I remember many NPC-names from CWC and colleagues, but not even one from the ArmA campaign. Might be I am getting old, but that certainly is not the main parameter here.

You could place a large enough trigger (called e.g. unitCounter) above the enemy camp and have it "Activated by OPFOR" -- if your enemies are OPFOR -- at the beginning of the mission. In the onActivation-field you can then count the units and store the initial count to a global variable, e.g. like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> unitCount = count (thislist unitCounter) Another trigger would now be needed to check if the initial unit count is changed, i.e. if one of them gets killed, it will be less than before. That is exactly when your alarm/reinforcement would come into play ... with just a bit more coding. Maybe there's a more elegant or shorter version. Anyway, hope you got what I was trying to say. Good luck.

Edit: Wrote total nonsense in this context, apologies. You don't find these inside ca.pbo. The "things" you put behind the root-element ca are to be found under addons: Just use the addons' file names. To find out the rest in order to reuse BIS stuff you can unpack the addon-pbo's to check the contained folder hierarchy/-ies for correct pathing in your custom addons or missions. My guess is that ca stands for combined arms, which would at least make sense as a root element here .

a) Why not pass the vehicle as an arg to the script? b) Did you declare chopper, i.e. in the init.sqf|-s if you're within a mission-context? Edit: Meant declared, not initialized.

Sic!

Put a one of them little portable radios on a map and shoot it several times with a rifle, pistol, whatnot. It will flipflopflippidflop, i.e. do some wierd spinning and jumping, only to get back to its original state with its bottom glued to the ground as if it has some super-magnet on that side. Physics? Hm.

Ty Q, hooray DM. Forgot to ask: What was/solved the last problem? Missing inheritance (added by Q in last code-snippet) or passing the complete handler-array (mod' by Q)?

What I could think of is that such top-classes are read-only -- if you mean it is not working as in "nothing happens". Could as well be other (minor) issues (your script(-s), the config, ...) which I did not spot ad hoc'ly or I do not know. Someone else? Cannot test anything atm.

Link: BI-wiki

Minor syntactic and semantic correction: class Man: Land { class EventHandlers { killed = "_this execVM ""\WGLEvents\onPlayerDeathBlack.sqs"""; }; };

Edit: I should have payed more attention to the contents of this thread and not how to do what I want. Apologies, got it wrong then, my ideas won't help ... at all. Â Edit 2: Mh, wait a moment. You want sound to be bound to a unit, e.g. the vehicle. The sound should be emitted from the car, bystanders would only hear it from exactly that source, directional. Is that correct? Or do you mean you want sound only to be heard by the driver in, i.e. inside, the car only? Then again, I do not know how even my code snippets will work in a cutscene environment. Good luck

Did you change yourSound to ... er what was it .. ah ... Radio?

Try this: Init-line of the vehicle (name is car): <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">this addEventHandler["GetIn", {(_this select 0) say "yourSound"}]; Init-line of the unit (name is driverUnit, could as well replace with this) to get in as driver: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">driverUnit action ["GETINDRIVER", car] Works for me. Naturally, you don't have to use my unit namings. Let me know if that's what you wanted and if/not it worked.

Wrong. I did it and it certainly works. Why don't you try attaching an event handler to the car in its init-line, e.g. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> this addEventHandler ["GetIn", {this say "yourSound"}] I have only tested it successfully with an init-event handler and as part of an addon (within the config file). The GetIn-event, however, might not even work, but you might try and/or find a tiny workaround nevertheless (quote from biki):

Oh man, I don't know whether to laugh or cry. I'll try both.

What do Kebabs and announcments such as BIS' and CM's have in common? They both leave this strange, nasty, bitter-bad taste in your mouth after you have swallowed and enjoyed it during the first moments of consumption. I have become highly sceptical about products that can "only" shine with screenshots or some hollywood-style teaser. Moreover, as it is pretty obvious why BIS actually had to post anything about game 2, that taste just doesn't want to go away. Chewing gum anyone? Edit: It's Kebab, not Kebap. Apologies to all Turks and the like.

What do Kebabs and announcments such as BIS' and CM's have in common? They both leave this strange, nasty, bitter-bad taste in your mouth after you have swallowed and enjoyed it during the first moments of consumption. I have become highly sceptical about products that can "only" shine with screenshots or some hollywood-style teaser. Moreover, as it is pretty obvious why BIS actually had to post anything about game 2, that taste just doesn't want to go away. Chewing gum anyone? Edit: It's Kebab, not Kebap. Apologies to all Turks and the like.