Radic

Bugger!

Fair enough, and I do apologise for sounding off - in reality I have to admit there's more good about ArmA than the bad - but you have to understand that probably the two WOW!! things for me in OFP are the Helicopter flight modelling and the fantastic way mouse control of ground vehicles is implemented - and in ArmA both are different and not for the better IMO - and SP AI seems shockingly bad in ArmA compared to OFP. Also - I'm not a some noob BF2 kid cracking a hissy fit - I've had OFP on my system for several years and have been a regular player for all that time.

:-) That occurred to me last night - so I'll progressively try lower values.

Thanks Synide - your info is much appreciated!! re: my note - I take your point - I was basically just ranting out of frustration.

Okay, I have been a long time player and very basic level modder of OFP:res for years. In OFP and the ECP mod I have edited both the native config.bin of OFP and then the much easier to work with straight up config.cpp of the ECP mod. Now, in ArmA I simply want to play around with recoil values for weapons and perhaps some of the AI settings - so to do this I used the same tools etc. that I've used for OFP in the past and ended up with syntax error problems when I run the game with my modded config - not errors with my modding - I only alter values, not code - but errors with the pre existing code sections. QUESTIONS: 1. Is it workable in ArmA to convert the config.bin to .cpp and then just use the .cpp back in the bin.pbo?? - ie. rather than rebinarise the modified .cpp - I have thought ArmA would use either .bin or .cpp?? 2. Is WinPBO ok to use for unpacking/packing ArmA .pbo's?? 3. What tool should I use for debinarizing config.bin - and then what editor should I use for editing the .cpp ?? I have tried armaunbin utility and then notepad but this is what's giving me syntax problems when I try to use the .cpp file back in ArmA's bin.pbo Note: as usual you guys are failing to make some VERY BASIC info available straight up to novice editors - need to make a sticky that very clearly and basically outlines the mechanics of the game - what it's configs and data sections are, what tools to use on them and then FINALLY - HOW to edit them. There is instead heaps of discussion about code editing etc. which means nothing to people who don't even understand yet WHAT code to be editing and how!

Thanks Q - so my process is: 1. copy the dta folder to my own one - ie. @radic 2. Unpbo bin.pbo 3. Unbin config.bin to config.cpp (rename config.bin to config.bk) 4. Edit the values I'm after in config.cpp with notepad and save changes. 5. Put @radic into the main ArmA folder and add the -mod=@radic command to the game shortcut. edit - ok, the problem seems to be that syntax errors are being generated in the process of converting the config.bin to config.cpp - what utility should I be using to do that conversion as the one I'm using is evidently flawed.

You know, I've had ArmA for about a week (have played OFP for about 5 years) and I'm really thinking that this CWR thing is all the wrong way about - we should be porting the ArmA Island/s and Campaign across to OFP!! That way I for one could actually enjoy the experience... :-(

No, you'd be surprised how little useful info a search yielded - that's why I posted.

Sorry to jump in here with a bit of a tangent question.... - but just how different are the mechanics of ArmA flight models to the ones in OFP??? I ask because I would very much like to simply transplant OFP helo flight characteristics into ArmA as I personally find OFP perfect already in this respect whereas ArmA just has something not right. I also have the same problem with vehicle control - using mouse to steer trucks, jeeps etc. in OFP is a dream but in ArmA it just isn't working right - very frustrating.

Don't know if this will help you, but in OFP I edited the engine sound volumes of various vehicles and shot sound volumes of many weapons so that the overall game volume could be turned way up (to make environment more immersive). This I did in the config.bin sections relating to the weapons and vehicles - ie. what I'm getting at is that perhaps to increase the volume of fires in ArmA maybe you don't need to increase the volume of the fire sound itself within the sound file/s - but instead look at the config/s of the burning vehicles/buildings etc. where the flames are used and in those configs you might find the volume variable for the fire sound effects??

Been playing for several hours more - the recoil definitely needs to be smaller and/or sharper (quicker) - IE. LIKE IT ALREADY IS IN OFP!!!! - certainly for assault type rifles. I've unpacked the bin.pbo and in there there's the familiar OFP style config.bin which I copied and then made a converted config.cpp - but when I repack the bin.pbo with the config.cpp used to replace the .bin version the game comes up with what look like syntax errors of all things from within the config.cpp (comments like: "" instead of = )

[Suma:2007] Point taken - in fact I think setting that HDRprecision value to zero just dials right down the HDR effect as I still get glare when facing the sun etc. yet at night it does make NVG view of consistent intensity (values such as the default 8 cause complete darkness in certain direction of view with NVG's at night). I might try the read only attribute approach - and also I think it's possibly being set to 8 whenever I alter ANY ingame video option settings - ie. which subsequently cause the game to write to that .cfg file.

rune: "...So one major advantage to helicopters in ArmA could then be said to be the fact that mouse and joystick flyers now fly the same flight model. I personally like that I can change the controls to have pure bank in the sideways motion of the mouse, this enables me to fly sideways properly, something I could never do in OFP " Hmmm - that makes a lot of sense and I agree that it could well be that the mouse cyclic behaves very differently in OFP - I'll have to try it .... - ok, just got back from trying to fly the Apache in single mission: Ground Attack using mouse and keyboard for cyclic and tailrotor and joythrottle for collective - and it all works as it should! I had no dramas with flipping behaviour etc. The default control setup I found my OFP to have is: Mouse forward / back is cyclic forward / back, mouse left / right is tailrotor left / right and keyboard A / D is cyclic left / right. Also W and S on the keyboard respectively double as cyclic forward / back. I had no drama flying sideways using A and D - the only peculiarity I've found is that with the Ah-64, A and D don't work with zero fwd speed - whereas with the joystick it can fly sideways. All the other choppers fly the same as with joystick - tho of course the experience isn't the same - you've gotta use a joystick to really enjoy it

Flying with mouse and keyboard is NOT an incorrect control setup I thought the OFP flight model was pretty good actually, but the ArmA one is way better, and you missed a few important differences in my opinion. For instance an OFP helicopter would become radically unstable and flip around chaoticly under some circumstances at high bank angles or backwards/sideways flying causing it to flip inverted at unpredictable times unless you stayed well clear of the limits - basically to fly with a reasonable degree of safety you had to keep the rotor fairly horizontal at all times and only fly  backwards or sideways extremely slowly if at all. Also some real life manuevers where almost impossible to do in OFP(possibly again only when flying with mouse and keyboard) like popping in and out from cover behind a building by sideslipping, in fact the whole hovering experience seems much more responsive now.And murderous, ANY aircraft rotates about it's center of gravity while flying, always, even in a barrel roll - it's elementary physics likewise you REALLY wouldn't want BIS to double the gravity as a helicopter is slowing down, it would be much more sensible to reduce the lift at minimum collective Dont' get me wrong though, it makes a lot of sense to me what you are saying apart from that... I never implied that mouse / keyboard was incorrect - what I'm saying is that if you're seeing terrain following behaviour then there is something NOT RIGHT about the way your cyclic control is configured - whatever that may be. As I've said before: my OFP helicopter flight has NO TERRAIN FOLLOWING BEHAVIOUR - the choppers behave loosely the same as they do in ArmA except that the collective has a much greater / more rapid effect (both ways), altitude gain and loss with cyclic forward or back is much greater (read murderous's comments about cyclic reaction/response - THAT's what I have in OFP - it's the one aspect of chopper flight I have in fact experienced in real life and OFP behaves EXACTLY as that real helicopter did) and the tailrotor has IMO better behaviour - ie. more effect overall plus loss of effect is properly progressive with forward airspeed - again, in line with murderous's description and the way I've felt the real thing to behave - or as well as I could from the left hand seat (ie. as a passenger) - unfortunately I didn't get to try the pedals and collective - just the cyclic. Also, I have no idea what this instability you describe is all about - I don't get any of that in OFP. Altho grossly improper control inputs (ie. unrealistically high bank angles or excessive backward cyclic) will of course result in CRASHING - I can quite comfortably sideslip to peek from behind buildings etc. - as well as fly backward (at a relatively low speed) - in exactly the way I would expect to be able to in the real thing - it just doesn't do it like a drunken donkey the way ArmA does (the MI17 at least). Hovering is not the piece of cake in OFP - in my experience - that people are saying either - it requires practice and concentration to do skillfully and it's very challenging and rewarding to land on a precise spot and to carry out maneouvers like Chopper Assault type landings. I keep coming back to the fact that to me the OFP FM behaves pretty much like my theoretical understanding and personal hands on experience lead me to expect it should. Murderous's comments only serve to strengthen that conviction - and these other descriptions I keep reading are simply not my experience in OFP - so all I can suggest is that there must be control config issues - in the case of the cyclic and terrain following behaviour I know it for a FACT. Perhaps the FM does default to some arcade mode when non joystick controls are assigned???

Hi murderous, GREAT to see someone like yourself here - and i agree wholeheartedly that hopefully BIS will be taking note of your comments. As a matter of interest, have you played OFP and flown the choppers in it? - if so, what do you think of that FM in general? Keep in mind that if you're seeing terrain following behaviour in OFP then your control setup needs to be sorted out - ie. I use my joystick throttle lever for cyclic and it behaves properly - ie. as in ArmA but with different (more correct) rate etc.. I ask because your description of how the choppers should fly in ArmA sounds spot on - and as they are in OFP - which I've always maintained gives a pretty decent representation of what flying the real thing must be like - particularly with regard to "cyclic lift" behaviour.

hehehe, spot on for a gaming perspective yes. Not even close to the real thing!! I should know Firstly I need to point out that as discussed in another thread here - my experience of the OFP helicopters does not include the totally unrealistic "terrain following" tendency that many others have reported. I found that I too could duplicate the bogus terrain following behaviour by using my shift key to increase height - but using my joystick throttle, the collective control works correctly. Those that have been experiencing that terrain following business due to incorrect control setup have been missing out BIG TIME!! So when I say the FM is spot on I am speaking from the perspective that there is a very real difference between realistic BEHAVIOUR and realistic FEEL. It is impossible for these helicopter representations to FEEL like the real thing as we're in front of PC's not in cockpits in flight, but inasmuch as the helicopters can be made to do what the real things do and in pretty much the same way the real things do (ie. correct responses and relationships between the various controls - innacuracies such as not having to constantly ballance tailrotor against collective and power etc. notwithstanding) then that is the context in which I use comments such as "the FM in OFP is spot on" - yes, I mean spot on for a GAME. My point is that the knocking of the OFP FM as being "the old flawed one" is ridiculous and misguided in light of the fact that the ArmA FM is - as I've said - actually virtually identical. All they did by comparison was: make cyclic a little sloppier (a LOT for the MI17), the collective a fair bit softer, build in a faulty yaw/roll coupling (that has been fixed I gather) and bugger the tailrotor authority (soon to be fixed I gather). I actually went off initially in a big way about how crap the ArmA FM was - but I do admit that I was wrong - I had been flying the MI17 exclusively in the demo - then when I tried the Blackhawk I realised it was in fact prety much the same FM - or at least acheives the same result - excepting the obvious mistakes - which - hats off to BIS - are being sorted out.

I haven't compared 256 vs 512 video memory for ArmA but I did so a while ago with Boiling Point, Far Cry, Call of Juarez demo and Fear: Comparing a 6800GS512 card to 7800GS256 I found that unless HDR is implemented (man what a performance HOG!!! ) I had no change in frame rate or performance generally between the two in any of those games except Boiling Point - where the frames stayed the same but "halting" - ie. whilst driving around on the roads - was drastically less with the 6800GS512. Amazing stuff considering the 6800GS 512 cost AU$270 and the 7800GS 256 cost AU$430 - you pay AU$160 more just to have HDR - whoop-dee-doo!!

Oddly enough, in the final analysis the ArmA helo FM is VERY similar to the OFP one - this I feel particularly when flying the Blackhawk. The differences / errors as I see them: 1. Yaw (tailrotor) / roll coupling - just not right - this might have been fixed in 1.05 from what I'm reading?? 2. Tailrotor authority not great enough - Suma has stated they're working on this - I'm VERY happy to hear that!! 3. Cyclic lag / slop - THIS is the biggie that bugs me - however I have to make it clear that the Blackhawk I have no problem with in this area so in effect I'm saying the cyclic lag in the MI17 is ridiculous - but even then, perhaps the real thing is just a total pig to fly??? With the Blackhawk if you improved the tailrotor authority and increased the collective's effect then it would fly and feel almost identical to OFP - which is good, because the OFP FM is pretty spot on.

You'll find I think that the light level IRL was MUCH lower than is apparent in the video - hence the tracers are very nicely contrasted. I recall a friend who owned a Trike (powered hang glider) and video recorded a DC3 landing at the country airfield he used to operate his little machine from - it was very late in the day and he'd finished flying and was putting his machine to bed when the DC3 showed up. In the video it LOOKS like it's maybe 4pm - everything clearly visible including the lovely old DC3 tho obviously no bright sunshine was visible - in fact it was close to 7pm and he said that IRL that DC3 was just a set of Navigation/Position lights to the naked eye!

I agree - but the really bizzar thing about it is that it's not like they haven't had experience with all this before - once again, it was already done pretty damned decently in OFP so why the heck is it al screwed in ArmA? To be clear: what I mean is that the sight settings in OFP I have always found to feel natural and make sense and therefor good to work with - but in ArmA (Demo) I've been having all sorts of problems pretty much along the lines that mailor is.

I find it odd that the game "simulates" the player being a total novice to using the firearms depicted - I'd rather my ingame character be handled as if he/I were a reasonably well trained and experienced soldier - thence I'd expect to be able to hold my sights fairly well (excepting of course when firing on automatic) - again, the way it was all handled in OFP was pretty decent so I don't understand why they didn't just do it the same.

Sort of a tangent to this topic, but: IRL I have fired: Â FN/FAL (ie. SLR - Aussie Army rifle) M1 Carbine M1 Garand M14 Ruger Mini 14 (open and with scope) Enfield .303 CAR15 Colt M1911 Pistol .22 target pistol .38 Revolver (don't know what type - medium length barrel) And IMO recoil in ArmA is too great / overemphasised - particularly when using scopes / aimpoint sights - it is UNREALISTICALLY ridiculously extreme AND done the wrong way round - ie. when you fire using the cursor sight - ie. not selecting optic - THEN each shot should result in a fairly huge jump of the sight reticle/cursor but it stays pretty much rock solid (for this reason in ArmA I can kill way many more enemies WITHOUT using the optic/sight selection) - but using the optics/sight selection (ie. the scope, aimpoint or ironsight) then each shot makes the sight jump a ridiculous amount. EDIT: ok, just looked at the new ironsight video and that all looks much better.

I've used the early trial XP64 Pro on my system (A64 3700+ and at that time 5900U256 Gfx card) and found HDD access across the board increased heaps - this was reflected in games - even 32 bit ones - having very noticeably quicker load times (and Windows was blindingly fast to open new windows and apps). The only game I tried with it that was an actual 64 bit game was the 64 bit version of Far Cry - and it ran shitloads faster - under 32 bit windows I had to compromise on various settings for smooth frame rate but the 64 bit version I could have everything balls to the wall PLUS the "Extra Content" and it was smooth as silk. So from EXPERIENCE I can asy that 64 bit can potentially be much faster. As a matter of interest, OFP was noticeably smoother under XP64Pro trial - by I'd estimate about 5 frames/sec - most significantly, increasing view distance had less of a frame REDUCTION than it did/does under 32 bit windows - and the load times were hugely decreased - almost instantaneous in fact. Bad news: That was all with as I said - the early trial version - I've since tried the current trial version of XP64 and it is NOT the same animal as that early version - ie. the early trial was definitely based on XP Professional wheras the current trial (and presumably the full version) seems to be based on Server 2003 or some such POS - and it doesn't work the same/as well at ALL!!!! (it actually even looks different) - thank god I decided to try the latest trial before going ahead and buying XP64 full version (which had been my initial intention) - so I spent the money on a new graphics card instead - so Microsoft did themselves out of my $$$ by screwing that pooch. I don't know about Vista 64.

I haven't of course played the full ArmA with 1.05 yet so perhaps the following is all moot, but in Joint Ops: Typhoon Rising don't they have a concealment ssytem for grass - how does that work? And in a broad sense this whole grass issue is close to my heart - for a long time I've been pondering editing the islands in OFP campaigns to place fields and much larger areas of scattered "grassy bits" - ie. in OFP there are those reed type clumps as well as small shrubby things and also some poppy looking things - 'm pondering making fields and large zones of these. Slow ups is the unknown issue. Back to ArmA - within half an hour of starting the Demo I had the following thoughts about the grass and distance visibility: 1. From prone position (in the grass) the viewpoint needs to be just a tad higher - that's all it would need to enable proper looking thru the stalks. 2. The general visibility rules seem not quite right - ie. when looking toward open areas - ie. ungrassed terrain and on streets etc. your character doesn't "see" things (ie. as reflected in spotted objects calls and then shown on the map) properly - even when pressing the reveal button.  Ie. in the co op mission, if I'm on the slope near the road looking down that main street - I'd expect that all the soldiers I can visibly see right there running about on the road should be showing up as targets on the map - especially if I'm centering them in view and pressing reveal - but they don't - they only show up really close - in fact they can even be very close with me watching them quite clearly on my screen creeping in and my character won't call them. This is important in context of what follows. 3. Further to 2 above IMO the whole visibility issue should be handled fundamentally within that "seeing things" mechanic that already exists (reflected by "man", "soldier", "vehicle"  calls and their subsequent appearing on the map) - ie. If you can't register a badguy within the "visibility" / shown-on-map rules then they should be invisible entities - BUT ONLY WHEN THEY ARE WITHIN A GRASSY AREA - ie. in the case above if you just arbitrarily applied that rule then there'd be a whole heap of badguys that would be running about on that street but totally invisible (ie. not even rendered) to the player.  I gather the visibility rules alter according to the object/man firing and also there must be some tie in as far as infosharing  amongst each side respectively and along the lines of within a radius etc. - so an opponent could be invisible either far away or even relatively close - and then pop into visibility when they open fire - then fade out again as time passes and they don't fire (ie. exactly inline with the way the little "Q" signs on the map fade as object visibility is "lost").  That way you could be in cover - see someone pop into visibilty as they fire, then fade out again - but have the option of staying under cover but you'd know that altho they're not visible there is a badguy in that area (or there was when you saw them at that occasion) to be dealt with when the time is right - just like real life situation. Not sure if I'm being clear on what I mean? - hopefully so. All this might well be how it's done in 1.05 I guess? (hope).

I absolutely second this! - well done!!