Metal Heart

The fretboard markers are in the wrong places after the 12th fret and the bridge pick-up is way too far from the bridge.

Doesn't it work if you just do something simple like: onmapsingleclick {resgroup move _pos; true}

Well, there's plenty of videos of the bridge that has "destruction animation" (it falls down in little pieces when a blackhawk shoots it with rockets). So maybe that's why some people think that ArmA will have destructible buildings.

It's short for level of detail. What it means in models is this: The simpler lods of the model are drawn when the vehicle is far away because it would be a waste of performance to draw the original model when you can't see the details anyway.

Wordpad adds something to the end of file that ofp parser doesn't understand. Use notepad or try adding a semicolon and a line change after the exit command.

Because they've all been pre-configured to use the same frequency/signal to detonate obviously. Well, that's not exactly true since you can have more options if you have some AI under your control. Just use the action command menu to have them detonate satchels you've ordered them to place. Anyway, I think the extensive use of radio controlled satchels in OFP is rather unrealistic itself. Maybe wire, fuse or timer controlled explosives would be more common in reality.

This would be a problem with weapons that have very high range, like a tank. You would see your self hidden behind a hill but the enemy might see right trough it. Or you would see your self in a nice tank sized hole while the enemy far away would see only flat ground on that spot, making you invisible even though you'd have line of sight. Of course you could make it so that this merging doesn't happen near units but then the sudden change would give you away, especially when you move etc.

I don't think he is trying to replace the A10 but adding a weapon to it. So you would use addweapon and addmagazine commands after the createvehicle command if the torpedo is defined as a weapon or follow the instructions of the addon maker if it's a script (you would probably execute some script, like [vehicle, numberofrounds] exec "coc_torpedo.sqs" or something in that case).

New patch wouldn't make much sense since OFP is soon replaced by ArmA anyway. They really should be focusing on making ArmA as bug-free as possible instead of patching OFP, right?

This is going on: no wonder nothing works. Get resistance for christ's sakes, the goty bestsellers costs like 5-15 euros and it has opf+resistance+red hammer. Resistance expansion has updated engine and more scripting commands and stuff.

Ok, if you just count the units from a group it doesn't work because dead units are not removed from the group instantly when they die. This definately works, I just tried it in the editor: 1. In every westsoldier's init line have: westgrp=group this 2. In trigger condition have: ({alive _x} count units westgrp) < 1

AS_XBow and AS_XBowMag

Use count units westgroupname instead.

Or more accurately the sun. If it's in east, changes are very good that it's the morning

Surely that can't be true? Nothing that's available can handle, handle with playable fps that is, the best addons (not including the ridiculously heavy addons ment for screen shots only) combined with graphics settings maxed. Please, can you describe the exact specs, ofp settings and mods/addons used and missions that you play with this setup? By the way, you can't max out everything through the video settings screen because terrain detail 'very high' is not available when you set view distance over 3000m, so which is it 5000m VD or very high terrain detail or did you edit the config file to get both?

Can you mod or make addons to America's Army? How about missions? Does it have a single player campaign? I don't see how it could be compared to ArmA really because the two are so different game play wise.

I just noticed when fooling around with the addon a little that if you use the mortar reload action (reloadAction="ManActReloadMortar"; in config.cpp) you can reload instantly when prone by tapping 'R'. This bug is also in BIS original mortar. But the animation it self fits a bow kind of weapon better and you could use it with a script like it is now.

Cool. Would be nice if the reload wasn't automatic though so you could keep looking through the scope after a shot to see where it lands. And maybe add some variants with different sights.

I'm not whining about the release date, and only a very few people are. And the delay is not caused by anybody whining about anything, it's because they don't have a publisher.

It stays on the same spot because the setmarkerpos command was not executed on the client, only on the server or another client. If it's a trigger, chances are that network lag caused the client not to see that the conditions were true until they were already false again. You should only use server side triggers for important stuff and then transmit the information to clients. Here's a simple example for a server side trigger: 1. Make a game logic named server, declare variableC=0 on it's init line or the init.sqs or anywhere you want to 2. Trigger condition: local server AND conditionA AND conditionB (this will only activate on the server, because game logic 'server' is only local to it) 3. Trigger onactivation: variableC=1; publicVariable "variableC"; 4. Now the clients see that variableC is 1 and can execute a local trigger or a local script accordingly. Note that there is no error checking on publicvariable command so packet loss can cause the changed value not to be seen on all clients, you might want to do it a few times in a delayed loop or have some means of detecting that a variable was not transmitted. The same idea works for a single client (instead of server) changing some variables and transmitting them to others. So, to move a trigger you could make two variables markerposX and markerposY, then publicvariable those values to others when they change and they move the marker accordingly with a client side script. Or if it's something like a unit position, just make every client run a looping script that updates the position every second or so.

Is that your best argument in favor of the toy compass?

It's not lag, it's inertia. And it's not fixed, it's broken. At least on the videos of the demo. You see, most people are not robots that can do 100% precise movements instantaneously or hold a rifle 100% steady in any position etc. Jeesh, maybe you should go play some generic shooters (like Unreal Tournament or CS) with l33t controls instead of trying to turn ArmA into one.

That's just utter bullshit. It's very useful to have accurate numbering on a compass, even in a game. Like accurately reporting enemy positions, triangulating a position, giving targets for mortar and so on. WTF is your problem anyway, it almost seems that you would want a compass that looks like a *****ng toy. Would it be cool to have the guns look like super soakers too? Without scopes and ironsights of course, it's good enough since you see that it represents a gun and see what direction it's generally pointed at, right?

Stopping immediately would also mean that you could start going the other way immediately. While that may fit some reflex & hand-eye coordination based corridor shooters that aim for very fast paced action and "strafing" gun fights, it would look so crappy in a realistic game like ArmA. It would also suck if there was no acceleration and deceleration when turning around and aiming, like it seems on the videos.

Perhaps it reminds of Descent because it happens more in 3D than a normal fps. Like you can walk on these paths on walls and ceilings as if they had gravity. Or walk around a miniature planet that has gravity. The levels seem as linear as a rollercoaster ride though, Descent levels were more like 3D mazes.