ACF

Please could the infantry 'Behaviours' (CARELESS, SAFE, AWARE, COMBAT, STEALTH) be tweaked to give them the same variety present in OFP? CARELESS and SAFE: Issues: units walk at all SpeedModes. In OFP, NORMAL & FULL Speedmodes were the same jog but LIMITED was a walk. Suggestions: distinct SpeedModes, e.g. LIMITED = amble, NORMAL = a brisker walk, FULL = jog. AWARE: Issues: in SpeedMode LIMITED, units move too slowly and too deliberately - weapons are 'up' most of the time making the Behaviour too similar to COMBAT. NORMAL is a jog and FULL is a run but it's not a great difference in actual speed. (This is in 1.09 Beta - it seems to have been tweaked already from earlier versions.) On the plus side, anims are better than OFP which was always 'jog' in AWARE. Suggestions: AWARE LIMITED should be a walk with weapons 'down' most of the time. AWARE NORMAL could be a touch slower. AWARE FULL is OK. COMBAT: Issues: no noticeable difference between SpeedModes. Leader moves too far ahead and tends to remain standing at WPs. Suggestion: same tactics with distinct SpeedModes: LIMITED at walk, NORMAL at jog, FULL at run. Keep leader back and down when stationary. STEALTH: Issues: there are different SpeedModes but leader still gets too far ahead. He does stay down at WPs. Suggestions: keep leader back. I have tried not to be too wishful with the above. Personally, though, I think there is scope for a Behaviour for general tactical movement where units move as AWARE but use COMBAT anims when stationary (with different SpeedModes, of course). My gut feeling is that this would be more useful than the AWARE we have where units stand at halts.

Now here: A Touch of Frost v1.11

I'm trying my hardest not to sound sarcastic so forgive me if I fail, but isn't this demonstrating an acceptable level of collision detection? What real intelligence would attempt to balance or impale itself on a cone? Â OK, I admit I'd rather it wasn't an obvious 3m detour but that's the lesser of the two evils IMHO. Waypoint completion is fuzzy and always has been. The more WPs & object you place in a small area, the more they will conflict. It is a pain in cutscenes, but that's the challenge. The bottom line is that you cannot rely on an AI actor to hit the same mark time and time again. If placement is that critical, use one AI for the moving scene then cut away to a preplaced, SetFaced double. This bug is the same feature we had in OFP. I can remember lots of 'WTF OMG how do I get loons to drive down the road?' type posts to which the answer was always 'put them in SAFE'.

There was some suggestion somewhere that SQF format scripting is the way forward. Will ArmA 2 support SQS and SQF, or SQF only?

I've just dipped into the 'Voting - Ticket System' thread and formed the opinion that a bug that's been labelled as a 'metabug' is never going to be addressed, let alone resolved, however much extra work is put into it. I can see the logic of this in terms of filtering out woolly, vague and non-specific reports. I further see how it relates to the importance Q attaches to 'steps to reproduce'. The problem I see at the moment is that the metabug label is very hard to remove. Using 2337 as an example (again), the amount of waffling I've done to substantiate the problem seems to have obscured the point that it's [probably] a consequence of one identifiable bit of the config (where anim groups are mapped to behaviours). It was never meant as a generic 'everything about the AI is rubbish' report. Maybe the initial report deserved its metabug flag but the report has been refined a lot since. It's also an issue where it is, perhaps, easier to define the cause than the symptom. In summary, I'm proposing that 2337 to be changed to metabug = no because it is a specific config issue. Even with my new 'updater' powers I can't change it! As for all the other metabugs out there, I do think other reporters ought to have a chance to review and revise their reports to lose the metabug labels. I recognise that it would be a lot of work because reports develop in the notes. I don't know what the options are for granting permissions to update one's own posts and requesting a metabug status review. Incidentally - and by no means the point of this post - the 'solution submission' approach would avoid the metabug issue because the fixes would be specific, the only judgement would be whether they are good or bad.

Thank you, Q, for your reply. I agree that the information in 2337 could be rearranged, the problem is that there is no option for the author to edit the issue as far as I can see. Are the BTS admins able to edit the issues? I don't see a problem with this as long as there's some feedback to the author to make sure the point isn't lost. Personally, I don't think 2337 is really a 'bug' - ArmA unit behaviours have been designed and configured that way (for reasons I fail to understand). Then again, it's not a feature request because I believe that the engine can already do what is required. Against the benchmark of OFP, it's simply a configuration 'error'. My problem is that I have a little knowledge - I can make a reasonable guess at the problem but I'm not clever enough to actually solve it. If 2337 can be re-presented in a way that makes it more likely to get assessed then please PM me and I'll see what I can do to help. My assumption was that the BTS admins would be acting as some sort of filter between the community and BIS, performing triage on the issues: - Bugs: bits of the engine that are broken; - Tweaks: things that the engine can do but configurations that are wrong or not as good as they could be; - Features/wishes: things the engine can't do and, realistically, isn't going to do any time soon. Someone then has to make the decision which bugs/tweaks to fix first on some sort of cost-benefit basis... but maybe it doesn't work like that. Given all the config tweaking that's going on out there, I'm actually wondering if there's any benefit in having somewhere to submit 'fixes' rather than bugs? Why create problems when we can create solutions? People could post their clever config snippets with a brief descriptions of their effects, advantages and disadvantages. A knowledgable dev could then make a judgement as to its worth and choose to use it or not. So much work is already being done to 'fix' ArmA but it's probably being done many times over in dozens of 'ultimate realism mods'. Surely it would be better to try to channel that effort back into vanilla ArmA?

Q, could you please explain why this issue: http://bugs.armed-assault.net/view.php?id=2337 has been downgraded to a feature request - again? I can't really dispute a lowering of the the severity; after all, it's obviously not a major issue for many people. However, this isn't a new feature I'm asking for, it's a feature present in OFP that has been degraded in ArmA. I'm pleased to see some updates to the BTS but it would be better if there were a few words of explanation for some of these mod changes.

I have a couple of bugs to report but there appears to be no means of creating a new account on the BTS in order to do so. The screenshot on the Biki BTS Guidelines page is not what's on the BTS main page. What might have been the signup link on the BTS main page is inactive. Am I missing something obvious? Thanks

I beg to differ - I had no visual feedback that the LTD was on whilst crosshairs were disabled. With crosshairs on, I could toggle the diamond cursor/crosshair/whatever on and off. I accept you don't need a 'game' crosshair because the LTD optics already have a crosshair for aiming. Though I looked for it, I was bug-gered if I could see a dot. I simply assumed it was simulating a non-visible wavelength laser! I don't know if you actually looked the bug up, but it was nothing to do with GBUs, but I suspect that it might explain difficulties that others were having simply because a vet wouldn't know whether the LTD was on or off.

I should have emphasised the 'FEATURE'. The BTS isn't just for bugs now, you can have 'wishes' if you give your report a severity of 'feature'. But you might want to check what's already in there for sniping-related things.

I had the same issue with the Laser Designator - no lock diamond when 'fired'. The engine sees this as a 'crosshair' and disables it in Veteran. I suspect that's what's happening with the missiles. If anyone wants to add anything to BTS bug 2241, please feel free - it doesn't look like it's been picked up yet.

No, 'people' should add it as a feature request on the Bugtracker. Someone from BIS will then notice it and deal with it one way or another.

And the IW was originally developed as a 4.85mm calibre weapon (off the top of my head). Truly a case of history repeating itself: 0.280" and 4.85mm getting steamrollered by NATO (= US) 7.62mm and 5.56mm. It's worth pointing out that calibre isn't the whole story, the original US 5.56 and the later UK 5.56 had different ballistic and terminal characteristics. This doesn't seem to have been mentioned above: I was under the impression that the defining characteristic of an assault rifle was its use of an 'intermediate cartridge' (SMGs using larger calibres with even smaller cartridges are the other end of the spectrum). Â 'Small calibre' was a fashion that came along later. The FG42 used the current full-power 'rifle' round before the StG44 was developed around a new round - same calibre but a smaller cartridge. The main reason for doing this was to reduce recoil (anyone fired a FAL full auto (I haven't but have fired SLR and can extrapolate)?), but the background was that most nations appreciated that their 19th Century rifle ammo was overpowered for 'normal battle ranges'. Other arguments for small calibre ammunition are that less recoil but higher muzzle-velocities and flatter trajectories makes shooting easier and therefore better. Secondly, Instead of carrying more rounds of small calibre ammo for the same weight, the same number of shots weigh less - one of the many attempts to reduce the weight borne by the infantryman. Also, curved mags are a consequence of cartridge shape, not wannabe assault rifle fashion. Bren mags are curved because the .303" rounds have rimmed cases, so the rounds don't lie next to each other. More-cylindrical rimless cases stack fairly straight (e.g. 7.62 NATO) but more-conical/tapered cases create a curve (and be less prone to jamming due to easier extraction).

That's not meant as a cheap shot (excuse the pun), but that's how the thread's been interpreted. But the lead-up and fall-off are not features of a missile's whoosh sound, they are the engine rendering the position and volume of a looped sound that's moving. I don't believe that example is analogous to the crack. All of the sound samples in game are mono (2D if you prefer), the engine creates the stereo effect based on where the sound event is placed relative to the player. One of the 'reasons' I believe that bullets near the player trigger the crack at the player's position is that the same routine might be used by AI to detect incoming fire. Assuming that the position of the bullet can be captured when it is detected, there's no reason why the crack can't be played back there instead of at the player's position. This would give the crack stereo directionality. It can even be argued that if the game copes with 3D placement of every thump and every impact then it should be able to cope with the small proportion of cracks heard by the player? Perhaps the performance hit won't be much after all... but I stress I don't know that.

The 'crack' is the shockwave of the supersonic bullet missing you and, yes, it ought to be directional in the sense that it should reach one ear before the other. But, although you might be able to perceive whether it went to one side of your head or the other, it wouldn't tell you where it came from. The best analogy I can dream up is that you're sitting blindfolded in a canoe at sea... If a noisy ship is moving past you, you should be able to judge its position. If, however, the ship is silent (or you're blindfolded and earplugged) the only thing you would sense is it's wake passing under you (ship = bullet, bow wave = shockwave in this scenario). The vertical motion you feel wouldn't relate much to the position or direction of the ship but you'd know something had missed you. On that basis, I'm happy that the crack doesn't and shouldn't contribute to the pinpointing of gunfire. It's the sound of the weapon firing that does this - the 'thump' as it is/was known in the British Army. Going back to the real world of ArmA... I did a test: a squad on a 'Never Fire' waypoint against a single rifleman/sniper/MG'er on the opposite side of a valley with me in the middle as a captive. As I'd expect, I heard the cracks before the thumps. The thumps & impacts (when you can hear them) are stereo/directional - they are sounds that occur at the positions of the events. The cracks do seem to be equally balanced (mono). I'm guessing that they are sounds 'played' at player's location, triggered by nearby bullet objects. I don't think it's a bug, just a compromise because you can't attach the crack sound to the bullet itself (because the bullet wouldn't know where to play it). As Daikan suggested, there's also a performance advantage if cracks don't have to be computed for AI. The thumps are the key to pinpointing the firers and they do seem to be placed correctly. I think the difficulty issue is because ArmA does a much better job than OFP at damping distant sounds; the gunshots are simply harder to place because it's harder to hear them.

It's on the Bugtracker - Issue 2249. Feel free to 'vote' for it as it doesn't appear to have been picked up yet. I don't think it should be left for Addons/Mods to fix as they can bring all sorts of other 'balance' issues in; it needs to be done at source.

C:\Documents and Settings\... is your problem, I think. wav2lip.exe doesn't like long filenames and pathnames or spaces in filenames and pathnames or all of the above. So I suggest you avoid them all: .lip files by numbers... 1. Open up a window that shows your C: drive. 2. Create a new folder on the drive and call it LIPFILES to avoid confusion. It's path should be C:\LIPFILES\ Â Note that there are no long file/pathnames or file/pathnames with spaces in. 3. Put wav2lip.exe (the file, not a shortcut) in C:\LIPFILES\ 4. Put your .wav sample in C:\LIPFILES\ 5. Drag the .wav sample onto wav2lip.exe ... Regulation pause of 2 - 3 ... 6. The .lip file should appear in C:\LIPFILES\ Once you have it working, just create a shortcut to the folder so you an open it in a window to work in.

The variety of terrain on Sahrani is great and BIS have done well to make it look nearly believable. Now the but... Â my only real gripe is that there are too many steep bits. Mountains are all very dramatic but they are quite limiting as battlegrounds - they're a bit of a waste of good manouevre space. Even the smaller ridges tend to restrict approaches to towns so we will gradually get used to fighting along the two or three available axes. To be fair, the original CWC islands suffered from this 'exaggerated relief' as well. It's nice to see that Sahrani has got some 'real' farmland areas and, personally, that's what I'd like more of.

Just updated to 7.3 on an X1950Pro 512MB and I'm experiencing problems with shadow detail. Shadows are stepped/pixellated - even on non-grass surfaces and walls - rather than smooth & diffuse. This occurred with original 'High' shadows setting and is still there on 'Very High'. Anyone else?

Returning a few favours, the best detonator I've found so far is "WeaponHolder": it's invisible, stays where it's put and doesn't explode when damaged. When wholly damaged it does produce the same flame & smoke effect as "Bomb" so still needs to be deleted. I've changed Mandoble's technique to create the two objects apart then bring them together: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_burst = _ammotype createVehicle [0,0,200] _detonator = "WeaponHolder" createVehicle [0,0,100] _pos = [_posx, _posy, _height] ~0.01 {_x setPos _pos} ForEach [_det,_burst] ~0.1 DeleteVehicle _det Airburst height must be greater than twice the shell/rocket/missile's IndirectHitRange to avoid the groundburst effects (known from OFP and seems to hold true for ArmA). Shell class ammo types are all nearly identical in their [lack of] explosive effect and all sound the same. The most useful round, for me, is the "R_80mm_HE", its occasional tendency to miss the detonator and shoot off into the distance is outweighed by its 'just right' power.

In OFP I could create a nice, functional airburst with something like: {_burst = _x CamCreate [_x,_y,30]} ForEach ["HEAT120","GrenadeHand"] This took advantage of a useful property that ammo classes would detect each other and mutually detonate leaving no temporary objects that needed to be deleted. Unfortunately, the same does not seem to be true of ArmA ammo classes - two CreateVehicle'd shells will not set each other off - they both drop to the ground and detonate there. Is anyone aware of an object that could be used as a 'detonator' for a CreateVehicle'd projectile?

If you've tried to setdammage the missile, I assume that you have been able to identify it. You could try something like: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_mymissilepos = GetPos mymissile _detonator = "WeaponHolder" CreateVehicle _mymissilepos // just in case the missile's going a bit too fast: _mymissile SetPos _mymissilepos sleep 0.1 DeleteVehicle _detonator I personally prefer "WeaponHolder" because it's a 'solid' invisible object, but "Bomb" is an option if you want a bigger bang. Just be aware that it can be a bit unreliable...

The best bet is to put wav2lip.exe in a folder in your root directory, say C:\wav2lip\ then do all your conversions inside it: One of several OFPEC threads

Phew - was worried it was a bug... Many thanks.

In the spirit of 'don't ask, don't get': Vary/improve infantry Behaviours - see: http://www.flashpoint1985.com/cgi-bin....t=59510 Assuming that global skill (via editor slider or SetSkill) equally affects situational awareness, tactical ability & marksmanship, could these factors be weighted differently (and simply) in the engine? e.g. Situational awareness proportional to sqrt Skill (relative increase) Tactical ability proportional to Skill (norm) Marksmanship proportional to Skill^2 (relative decrease). The intention would be to make units react better but shoot worse. Improved anims for prone infantry – when changing direction units should ‘lift’ the weapon round, not do a ‘flat spin’. Reduce range & power of grenades – seems excessive. AI AFVs are too aware of infantry close in – model blind spots. AI infantry should engage turned-out AFV crews with small arms but not AFVs with turned-in crews. Destroyed vehicles should not always burn, explode or change textures. The hitpoint system is simplistic but is probably too deeply-rooted in the engine to change easily... Simple shadows on map objects at longer ranges to increase the ‘depth’ of the landscape. Reduce abruptness of HDR glare effect changes with azimuth – it ought to be defined by direction relative to the light source, not the edge of the screen. AI minimum engagement time could be shorter (was 20s in OFP, not seen ArmA config yet). Encouraging AI to reassess threats more often should cause them to snapshot at different targets, rather than concentrate on their first threat to the exclusion of all else. This could prolong firefights & simulate suppression. Scripting commands to return position arrays from cursor objects and point of aim. Better mix of civilians - male & female - and guerilla/resistance units (though I sense that provides scope for an expansion...) Seasonal foliage. Winter, autumn & the existing spring/summer textures could be initialised at mission start by date or by scripted command – no requirement to change during the mission. Less mountainous terrain on future islands = more space for manoeuvre. Most importantly: BIS to keep ArmA on the path from super to superb!