Metal Heart

Yeah, you are absolutely correct about the 0.01% and stuff, that is the case when the enemy is like a mile away. But sometimes they are quite a bit closer, especially when fighting in house to house or room to room ranges, in a dense forest or by night etc. In some forces it's even instructed to throw a hip shot while diving for cover when being surprised by enemy fire so it can't be complete bollocks. Of course a player or AI in a computer game won't be as intimidated by the quick return of fire as a real soldier would so the supressing effect might be quite useles in ArmA. Anyways, shooting without aiming has saved my virtual ass in OFP single player and multiplayer more than a few occassions. Sometimes being the first to fire is more important than 100% accuracy. And you can easily point a rifle forwards while running in real life. Don't take my word for it, try it out your selves.

What Mandoble meant was to group the trigger with the unit/vehicle. Press F2 and drag a line between the two with left mouse button.

One really nice feature in OFP (and most likely arma too) is that the bullet is actually fired from the 3D model of the barrel. So if you see the gun pointing to your left in the animation, that's where the bullet will go. With the proper animations, you can run, shoot and hit the broad side of a barn (or a loon just behind the corner) at the same time in OFP. So folks who absolutely hate shooting while moving or think that it's unrealistic can use an animation that has the gun swaying and jumping like crazy even when you're just cautiously creeping forwards.

This should work: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class RscStdText { type=0; idc=-1; style=2; colorBackground[]={0,0,0,0}; colorText[]={1,1,1,1}; font="TahomaB14"; size=1; }; class RscTitles { titles[]={pic1,pic2,pic3}; class pic1 { idd=-1; movingEnable=0; duration=2; fadein=2; fadeout=2; name="intropic"; controls[]={"Pic"}; class Pic : RscStdText { style=48; text="pic1.jpg"; x=0.25; y=0.25; w=0.5; h=0.5; }; }; class pic2 { idd=-1; movingEnable=0; duration=2; fadein=2; fadeout=2; name="intropic"; controls[]={"Pic"}; class Pic : RscStdText { style=48; text="pic2.jpg"; x=0.25; y=0.25; w=0.5; h=0.5; }; }; class pic3 { idd=-1; movingEnable=0; duration=2; fadein=2; fadeout=2; name="intropic"; controls[]={"Pic"}; class Pic : RscStdText { style=48; text="pic3.jpg"; x=0.25; y=0.25; w=0.5; h=0.5; }; }; };

There's nothing wrong in avoiding the use of too many triggers but I think you've taken it just a little bit too far You can access a trigger's list from a script with list triggername, just have it covering the whole map with civilian present in the condition box and there's your list. But that marker example of yours will not work anyway for a couple of reasons: setmarkerpos doesn't create copies of the marker, it just moves it, so you'd just have a single marker on the position of the last civilian on the list correct syntax is "markername" setmarkerpos position

Yuch... OFP at it's worst: looking and sounding like it's year fucking 2001 all over again and reduced to a shitty close quarters deathmatch.

It's not a resolution, it's the size (aka grid or the number of cells) of the map. 256 x 256 is the default size. Each cell is 50m x 50m so the default maps are 50m*256 = 12.8km per side. I think the maximum practical size for a map in OFP is 512x512 cells which is the size of Tonal. You can also use a smaller grid size but I guess it's just too heavy to be useful or causes some problems with the engine. In ArmA there's this feature called terrain streaming which basicly means that you don't have to have all of the map in memory because it can be "streamed" when you move around so the map might not be limited to some arbitrary size at all.

I don't know, no matter how much I'd like to, going through the shots I can't come up with the same conclusions. There's some steep hills but they seem to be based on a large even-spaced grid just like OFP instead of free form. I would guess that the buildings are aligned to match the edges of this grid, not the other way around. Maybe I'm watching the wrong shots but whenever I see a building on a slope, it's either sinking into the ground or has a huge base in the model instead of having the land beneath it deformed to form the base. Maybe the 'bulldozer' keys are just for some developement feature that will be disabled later or for accurately positioning objects in the mission editor? Bulldozer certainly does sound like it might have something to do with deforming though

Uh... What do you mean, like non-destructive editing of terrain data with the mission editor to alter the terrain for each mission invidually, manipulate terrain via scripting on-the-fly or that there's a built-in island editor? I'd also really like to know what exactly made you think so because to me, all of that seems very unlikely.

To add custom images you define them as something known as cut resources, they are somewhat tricky to use. However, there's an easy way, just pinch the description.ext from some mission that uses custom images, change the pictures and fiddle with the values a little and that's it. If you want to know what you're actually doing I suggest this tutorial from ofpec.com: http://www.ofpec.com/OFPResources/tutorials/cutrsc_tut1.zip (note that the images must be jpg or paa and the dimesions 2^n as in 256x512, 512x512, 1024x256 etc)

If it's true that ArmA requires pixel shader 2.0 support then I think no, it wouldn't be good enough. Even if it didn't, I guess you'd have to tune down ArmA to look just like OFP or have it running at slideshow pace.

I was assuming you already had two boolean variables (variable that is either true or false) for each flag. Like for 1st flag you'd have westhere1 and easthere1 variables set by the triggers and for 2nd flag westhere2 and easthere2 and so on. Quite messy but simple. So if you'd have 4 flags you'd have a trigger for west: condition: 4 == {_x} count [westhere1,westhere2,westhere3,westhere4] onActivation: hint "West holds all flags" and for east: condition: 4 == {_x} count [easthere1,easthere2,easthere3,easthere4] onActivation: hint "East holds all flags" If there was 11 flags you'd change the 4 to 11 and have more variables in the arrays (between the square brackets)

If you have a variable for each flag you could count them like: {_x==true} count [westhere1, westhere2, westhere3, westhere4] or for short (since the variables are booleans): {_x} count [wh1,wh2,wh3,wh4] Count can be used to count how many elements of some array meet certain conditions, like in this case, how many of the flag variables are true. {} inside these is the condition, like {_x > 10} or {not alive _x} _x is the current element that is being tested [wh1,wh2,wh3,wh4] is an array of the variables

Go ahead and try that script in OFP. It doesn't really help.

That's like wondering if teh Fa5t 4nd t3h furryouz ep.V will hurt the sales of some obscure masterpiece of russian art film that tells a heartwrenching 9-hour story about farm-life in the 1800s or something.

That doesn't prevent others from using it against you or some moron going rambo to get the best scores in a coop. You shouldn't magically know who you killed or get a confirmation if you killed someone behind a bush or so far away that you can't really tell. Or know exactly who, when, how many and what kinds of targets the opposing side have killed or destroyed. That's just bullshit.

http://www.ofpec.com/COMREF/comref/letterS.html#setMarkerType "empty" = invisible

What's wrong in grouping the trigger with the group, it does the job just fine as far as I know. That's how I would do it. Or if I was worried about some bug or bad performance I'd have a script like: #loop ~5 ?{_x distance glName < 100} count units grp1 == 0 : goto "loop" "1" objStatus "done" exit

That is the usual way to define a name for a certain group. To be on the safe side you could have grp1=group this on every unit's init line that belongs to the group in case a slot gets disabled. Join command works with a unit or a group so you can just command: [civ1, civ2] join grp1 or units civgroup join grp1 And that's pretty much it.

There was a remake of the main theme in igromania's arma clip btw.

It is certainly possible and I don't think that it counts as bypassing copy protection (that would be illegal in some countries) because you will be installing with the goty cd-key and then just change the encrypted key in the registry to your old one afterwards. At least I've recovered OFP that way after reinstalling windows.

Uh... That can't be right. Source? Wouldn't be that big of a deal to me though, just another reason not to buy Vista.

I think otherwise. Unless you've already reinstalled you can export (or write down) your old encrypted key from windows registry and then put it back there after you've reinstalled from the goty disks. Or you could just copy the data manually, updates might not work though.

According to command reference createUnit doesn't return anything so it shouldn't work.

This line you have apparently already copy pasted from somewhere: _delay = _time + 20.0 this is the time when the loop is supposed to end (_time returns seconds since script started, add 20 and that's 20 seconds later since the loop started) But you also need a condition on the goto "loop" like: ?_time < _delay : goto "loop"