madrussian

Curious, I just noted that this thread is no longer coming up when I click on New Posts (but it still shows up in ArmA - ADDONS & MODS: COMPLETE). Â I just saw it in New Posts a minute ago, and there are still tons of topics that I am still seeing that were listed afterwards before. Â There's a blue envelope indicator with a white star on in, which does not appear in the forum legend below (where all the other envelope symbols and the lock symbols are). Anyone have any idea what might be going on? Â I'd really like to get the word out about this addon, but if people do not see it when they click on New Topics... Â edit: Just clicked New Posts again and it shows up... hmmm. Anyhow, anyone have any idea what the blue envelope with the star on it means? edit: Also I saw/see no other topics anywhere I look with white stars on them. Interesting...

Thanks for all the interest! Sorry to hear this trouble, mate. Â PPjoy installed for me just fine. Â (I'm using Vista.) Â First off, I'm assuming you are logged in as Administrator? Â I recall something in the readme about needing to allow installation of unsigned drivers (for XP?). Â I'll bet you that is the problem. Â Because I'm running Vista, I got a prompt on that. Â IIRC, with XP you had to go into your Windows settings and tell it to prompt you. Â Anyone else get it working for XP specifically yet? If you are still having a problem with this after I get off work (just got here) I'll try and install PPjoy tonight on my XP partition. Sounds like either you are not sure what to do in the PPjoy mapping settings or the step where you modify the mapping section of my script. Here are a few quick pointers for both: First of all the reason this part can be challenging is that there are many different types of joysticks out there, so it's not a one-size-fits-all kind of thing (if you are even using a real joystick, that is). Â Believe me, I wish it were... that would make installing this addon a snap. Â But I know everyone can get it set up, with a little patience, that is. For your virtual PPjoy mapping, the first question to ask yourself is if you have a real joystick. Â If you don't, then you really only need the x-axis. Â If you do have a real joystick, then for your virtual PPjoy mapping, just make sure you've covered every function that your real joystick posesses. Â To do so, bring up your real joystick in the Game Controllers from the Windows Control Panel. Â For each axis, throttle, nob, hat, etc, create a mapping for it in PPjoy mapping. Â Extra mappings should not hurt anything, as long as you do the next part correctly. Then in the readme step where you modify the mapping section of my script (which you only perform if you are using a real joystick), use those 15 or so lines of code I've got as a starting point, and create your own one-to-one mapping of all of the remaining joystick functions. Â Remove any excess lines of code I used for my joystick. Â Note that I covered the X-axis for you in the if statement above the comment. Â So your job is to cover everything EXCEPT the X-axis. (I should probably add that part to the readme.) I hope this helps! edit: Thank you zGuba for the excellent explanation of what is going on. Â Sometimes I get long-winded and probably confusing. @all Again, thanks all for the praise! Â Hopefully BIS will add a toggle now for ArmA2, heck even ArmA1 in the final patch, now that there is no denying it can be done. As far as this addon goes, hopefully once we get a few folks up and running we will have acheived a critical-mass and then there will be plenty of different people helping everyone through. Â Mark my words: We will eradicate mouse-auto-center for you and your mates, if you want it eradicated. Stick with it guys, you will get there and I promise you that.

Attention – Please Read Just so interested people are not scared off by the long post here, please be advised:  I think I've figured out a way to defeat the dreaded mouse-auto-center.  Now if I've got your attention... READ ON! (Or if this topic does not interest you, I understand completely... Everyone is different... To each his own! ) Introduction Many of us have been quite annoyed by the mouse-auto-center "feature" experienced when driving by keyboard/mouse since the release of ArmA. For any of you out there who exclusively use the joystick to drive in ArmA or are otherwise unfamiliar with the mouse-auto-center issue, here's a quick step by step: 1. You start driving in ArmA using the mouse/keyboard. 2. You steer either left or right. > Now everything seems fine at this point as you are moving the mouse but suddenly... < 3. As soon as stop moving the mouse, your wheels return to center automatically, even though you wish to continue steering in that direction! As many many ArmA players feel, this makes driving far less precise and it's just darn-right annoying.  The worst part is it is hardcoded and there is no toggle or config entry to deal with it. Now, there was a bug-tracker issue submitted requesting a simple toggle for mouse-auto-center, and it quickly became one of the most voted for ArmA issues in the bugtracking system (top ten IIRC).  Alas, it was never resolved and has kept driving in ArmA difficult for so many of us since ArmA was release.  (btw- It was never a problem with OFP 1.96) Fast Forward to Present Day I think I finally figured out how to overcome the dreaded mouse-auto-center!!! Now, I probably shouldn't be getting people's hopes up just yet, because I have yet to test out my idea, but I'm stuck here at work thinking about it, and needed to let the world know. A little history on my idea before I go and spill the beans.  A few months ago, Kegetys came out with his revolutionary ArmALib program which allows amazing things in ArmA, including communication with external database, the communication with the Windows clipboard, and many other revolutionary things.  Most importantly with regard to the topic at hand, ArmALib provides keyboard and mouse commands. So my idea at the time was to use ArmALib to produce a series of rapid, miniscule manipulations of the mouse input while driving with the keyboard/mouse, thereby interrupting and preventing the hard-coded mouse-auto-center from ever occurring in the first place!  When the idea hit me I was about fall over and pass out from the excitement! Unfortunately, after delving into ArmALib, the best I could discern was that ArmALib was only capable of trapping the mouse status, not manipulating it.  Holy crap, talk about talking the wind out of my sails. All that was a few months ago. Finally, a Solution? So now picture this.  Here I am sitting here in my cube today, turning the problem over and over in my head.  And then it dawned on me. So what if ArmALib couldn’t manipulate the mouse?  Why not use an external program to simply provide this minor manipulation for us?!?  A quick google search on "automatic mouse control program" turned up dozens of programs that appear up to the task.  (Many of them are macro related).  Better yet, many of us (including your truly) know how to crank out a quick purpose built Java program in no time.  I'm guessing mouse-tweaking this is about as simple as it gets. Now I know some of you are thinking, "Great, but I don't want my mouse being constantly moving around like that."  Now I've got the same concern, but there are a few things to consider here.  First off, how much manipulation is required to prevent the mouse-auto-center in the first place?  Based on a bit of in-game experimentation, it sure doesn't seem like much at all.  So with the miniscule amount we are talking about here, perhaps it would be altogether unnoticeable (except of course for the desired elimination of the mouse-auto-center, that is. ) So some experimentation with one or more of the actual external program(s) is required to really know how well this will all work.  If the initial experiments go well, it would be time to go beyond the original idea and put a robust system together that is capable of determining when the player is driving and when he is not. The Robust System What follows is a quick rundown of what I envision for the robust version of the Mouse-Auto-Center Removal System (MACRS).  There are two components, one internal, and one external (internal and external to ArmA, that is) 1. Driver Detection Component (internal to ArmA) Internal script or config based system that detects when a vehicle is boarded by the player driver.  Upon detection this component utilizes ArmALib based capability to send a signal to the external component to begin mouse-auto-center interruption.  This component also detects when the player exits the driver position, and at this time send a signal to the external component to switch off the interruption. 2. Auto-Center Interruption Component (external to ArmA) External purpose-built mouse-auto-center interruption program with two states:  "Off" and "Interrupt".  This program receives the binary command via ArmALib and blocks the mouse-auto-center when necessary.  It is out knight in shining armor, it is our shield!  When it is not blocking, it’s waiting silently for the command.  Think of it like the nuclear “footballâ€.  (ok, bad example probably  Maybe a better one is a emitter that block IEDs from going off.) Indeed, these two components exhibit a classic Master/Slave relationship. (Note - Perhaps the vehicles which require mouse-auto-center interruption could be selectable by the user.  Example-  I mostly drive land based vehicles with the mouse/keys, but always fly helos and airplanes with a joystick.  Other people undoubtedly do things differently.) An Action Plan Now unfortunately, I don't have a lot of free time to spend on coding for ArmA right now.  (RL's a bitch sometimes, no?)  But I will do my best to pursue the idea, reporting back here periodically.  The main thing I want to get across however is, I just want mouse-auto-center dead.  I fully encourage any of you who feel the same way to go ahead, run some experiments with mouse-manipulation programs, etc, etc, etc.  I will collaborate with anyone who is willing and provide whatever time I can.  I do not desire any credit what-so-ever for the idea here. Like I said I just want to eliminate mouse-auto-center while driving in ArmA and I know a lot of other people feel the same way. In summary, I'm quite interested to hear any and all feedback from you guys on this idea… I'm all ears! Special note for BIS BIS if you made it to the end and are still with me, please look on this post and topic as a testement to the lengths people will go to get rid of the unwanted and disruptive mouse-auto-center.  We really do hate it that bad! Alternately you can look at it in terms of how much we love your game!  I.e Putting forth this kind of effort to make it perfect. Please give us a toggle in ArmA2.  Pretty please?

Thanks for all the support guys! Version 1.0 released here.

I have no idea about that... but I certainly hope not. Got the readme done. Â Looking into the transitions between on and off now (mentioned previously). Not long now...

Thanks for the info cr-claw! Is that normally the way it works though? Seems like most of the time people go upload the file somewhere and then Armaholic, etc, swing by, go grab your file and host it for you? (And drop you a comment in your thread to let you know?) Maybe I am naive on this. I agree most people who will use this addon would probably always want the auto-center eliminated while in certain vehicles (such as all ground vehicles). However, while the script is running, the joystick gets overridden by the mouse. Â Indeed, we probably don't want to override the joystick all the time for any number of reasons. Â For instance, some may prefer to drive even ground vehicles with the mouse sometimes and then with the joystick at other times. Â So for right now toggle by keystroke will have to do. Another consideration is that right now the addon exists completely outside ArmA. Â While it wouldn't be terribly difficult to monitor which type of vehicle the player is in inside ArmA and automatically toggle the mouse-auto-center state accordingly and transmit the toggle state to my outside script, that's probably a bit beyond the scope of this initial version anyway. I do envision such a robust system fully configurable by the user. Â But first things first. Quick update: Got the key trapping sorted. Â A bit more to do on the transitions between on and off (so your wheels don't go crazy when you toggle). Â I'm also in the middle of writing the readme. Â Hopefully not too terribly long to go now to get this puppy unleashed.

Alright, back up and at it. Â Thanks for the support, beer, etc! Very close now... everything is working, just need to figure out how to toggle it from a keystroke. Â (There needs to be a way to turn it on and off as you will see.) I think I know what you mean. Â In OFP, iirc you would move the dot around the screen and the vehicle would go toward the dot. Â I wouldn't necessarily call that an auto-center, but I agree it wasn't the most optimal system. Â For all it's flaws though, it got the job done and was head over heals over the way vanilla ArmA has it. The way I've got it working now, the steering wheel just basically maps to the X-axis of the mouse, with no auto-center (or dot-following for that matter). Â So imo it's actually even better than OFP was! @All, this is my first addon (if you want to call it that... more like a fix really)... What's the best (and easiest) place to upload something?

Here's a preview... a longer update tomorrow: // Eliminate ArmA Mouse Auto-Center While Driving by MadRussian // Version 0.9 // RIP - Eliminated on October 19, 2008 // Long live OFP style mouse driving!!! // // Many thanks to alef for pointing me in the right direction. // Ironic that he laid out the roadmap over 2 months before I saw the light! Ladies and gentlemen... Â It's dead! Â I just drove around Rahmadi for over ten minutes and without any bitching from my mouse. Â Yep, ten minutes on an empty island with nothing but me and my Humvee. Â And let me tell you, it was everything I thought it could be. Couple of minor kinks to work out and we're there... So tired after all this problem solving. Â My brain feels like goo. Â Barring any unforseen consequences, I'll fill you guys in on all the gory details tomorrow. Â But for now, time to hit the hay, as they say. Â

Plus if you like, just take Marccom's terminator, and setDammage as desired! (to give it less starting health)

Thank you so much for your addons, Schnapsdrosel. Your city civs are just what vanilla ArmA was missing for woodland and other missions. Â Now how about some more city females? The city females you've got so far are a great addition to ArmA but it's tough to populate a city with just 5 of them. Â Unless you're doing a city of clones, I suppose!

I checked out the changes last night. Â Overall a huge improvement from the beta! However, I did find a few walls you could still walk through and a few floors you fall through. Â Also, I checked out the AI positions and unfortunately, when I ordered my AIs to enter them, they got stuck trying to enter probably 80% of the time and could not enter the buildings. Â Also the fences are a huge problem for the AI. (i.e. They won't go inside). Speaking of the fences, is there a possibility of breaking them out from the models? Â Those buildings would be far more versatile that way. Â Likewise for the miscellaneous outlying objects and debris... plus if you want to build on a hillside, all that stuff ends up elevated above the ground. Keep up the good work though... I have confidence these buildings will eventually get there. edit: You've probably already done this to some extent, but I'd certianly want to dePBO and see how BIS managed it's wrecked buildings, because they work flawlessly.

Can it be true!?! Â I can barely believe my own eyes. Â That LCM3 unloading tanks is just breath-taking.

Now, if only someone could give the same treatment to Simba's building pack (with lods, ai positions, etc)... If anyone missed Simba's excellent pack, you can find it here. Â There are tons of beautifully broken down and derelict buildings in there too. Â IIRC, he gave permission if anyone wished to complete them. Â IMO, both this pack and Simba's are full of jaw-dropping, amazing, completely wrecked out buildings, and I feel they would be a perfect fit for one another. Â I can't thank the creators of both packs enough. By combining this excellent pack with a completed version of Simba's, we could really get some unbelievably wrecked out cities, the likes of WWII Stalingrad... or a post-apocalyptic zombie infested future... or life after WW3... you name it! Thank you so much for all the hard work on your buildings pack, Smersh!!!

Thank you soooo much for these! I loved them in the beta, but figured that it would be way too much work to do all the lods and ai positions. Â Then poof! Â Here they are ready to go. Can't want to check them out again tonight!!!

Here's another article from Eurogamer. Â This time an interview with Clive: http://www.eurogamer.net/article.php?article_id=243347 There some interesting tidbits on getting wounded (dismemberment and even going limp leg ala GR1) and some info on the save system. Sounds like saves will be: 1. Quick-save friendly -or- 2. OFP1-style save punishment based on the difficutly setting. Â Anyhow, I like the fear of death... makes it more immersive.

Anyone see this preview posted today on Eurogamer? http://www.eurogamer.net/article.php?article_id=240873 Skimmed through it... Nothing jumps out initially as earth-shattering, but probably worth the read.

No problem at all, just glad I saw your query and could help! I recently spent literally something like twenty hours myself figuring out how to make similar adjustments (I was just starting out with addons). Â It would be criminal for me not to help others like you along through it. Good to know you got it working.

OK, now I am starting to get excited!

Good deal. Â Yes, the lower the number the slower the speed. Â Usually, you'll want to preserve the original BIS value and simply use a multiplier on it. Â So, for example, if the original BIS setting is: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">speed = 1.2 you might try: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">speed = 1.2 * 0.8 and then fine tune it from there. Keeping the original BIS values in place and using multipliers on then just helps keep everything straight. Also, if you are modifying several animation states that will share the same speed value multiplier, you can use a #define at the beginning so you only have to change the value once, thus saving you huge amounts of time. As far as the which PBO goes, I can tell you exactly which one once I get home from work (just got here), but in the mean time check out the TrueGameplay Mod PBO that lowers all the speeds. Â Use that as a model for your own. Â Yours will probably be around 3-5% as much code as that one has in it. Good luck.

Let's back up just a little bit here to make sure you are on the right track. Step one is to write a simple script to detect the exact  animation state you want to modify the speed of.  Use a loop that detects the animation state of the player like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">#Loop _aminState = animationState player hint format ["_animState: %1", _aminState] ~0.1 goto "Loop" Record the various animation states you wish to modify the speed of. [Keep in mind you may need to modify the speed of several anim states to get the desired result for what you preceive visually as one anim state ingame.  This is because in certain cases two seperate anim state codes often appear identical visually ingame.  (i.e. gun lowered or raised appears with certain codes does not translate visually.)  I did a detailed mapping of the ArmA anim system some time ago when adjusting animation speeds.] Next, in the config, modify the "speed" value for the desired animation states. Always use your animation state detection script when testing out your results.  Setting animation speeds to the desired values is often a matter of trial and error. If you have any further questions, please don't hesitate to ask. I just recently went through a huge learning process getting animation speeds adjusted (and finally all the animation transitions fixed) and I wouldn't want to see anyone else have to go through that!  I am very busy currently RL-wise though, but I'll try to check your thread at least once a day for the next several days until you get it sorted.  I recall how frusterating it was for me.

For those who may not keep up on this sort of thing, there have been major advancements in home Stereo 3D technology lately, both in terms of capability and also cost barrier for regular everyday folks.  To back up a bit further, Stereo 3D (S3D) is when the image actually comes out of and falls back into the screen, as with IMAX 3D movies.  S3D is how we see in real life (unless we've had the misfortune of losing one eye). Two relatively new products are on the market, the iZ3D 22" and the Zalman 22" stereo 3D monitors.  You do need special light-weight glasses for both, and both use passive polarization (as opposed to shutter technology, which can cause eye strain).  A couple months back I bought a 22" Zalman Trimon 3D monitor for gaming purposes ($700 US at the time).  Once I got everything up and running, my jaw hit the floor.  The effect, in a word is amazing!!! I also found the claims of zero ghosting on Zalman monitors to be true.  (Ghosting is also called cross-talk and is when one eye can to some degree see the image intended for the other eye... the iZ3D 22" reportedly has a problem there) Now game compatibility with the Nvidia S3D drivers is an issue (which the Zalman uses, iZ3D has much better support at this time I'm to understand).  Many recent titles have various issues.  However, I found that two of my favorite games work very well in S3D and I was blown away by the effect in Oblivion and Mount and Blade. ArmA, however, at that time did not work in S3D.  The problem was that although the entire image would pop out of the screen, it was still a 2D image.  At the time I figured you can't win em all, and just continued playing ArmA in 2D mode. Fast forward to last night.  I was trying out a number of new mods for ArmA and one of them was the one that disables HDR lighting.  (Great performance boost btw! )  At this point I got a bit curious, knowing that post-processing/lighting can sometimes foul up the S3D drivers, and so I tried toggling on S3D again in ArmA. To my great surprise and happiness, with HDR disabled, stereo 3D works in ArmA!!!   And the effect is very good, with next to no issues what-so-ever.  Everything quickly becomes very real in S3D, darting in and out of the trees, bullets and rpg rounds flying out of the screen, grenades and rpgs going off... Mad Matt's effects and ECS volumetric fog are a real treat here, let me tell you!  Most immersive ArmA experience I have ever had!!! Now there is a small problem, that could turn out to be a big problem.  If you look at the sun, the S3D disables and cannot be turned back on without shutting down the game and restarting.  That of course will kill the experience quickly.  One option is to block out the sun with clouds (not a good long term solution).  But I also think the problem may have something to do with the lens flares themselves.  I intend to disable the lens flares tonight and see if that eliminates the problem. (btw- These types of issues are common in trying to get S3D working on various games, so no big surprise here.) Anyhow, just curious is anyone else has tried ArmA in stereo 3D, or am I the only crazy one here? If not, you guys really should check this out.  It truly completely transforms the experience in ArmA!  You really have to see it to believe. EDIT: btw- If anyone has any questions about Stereo 3D or anything in my post, please don't be shy.  Not very many folks seem to know anything about S3D at all, and I've got a ton of knowledge in this area (mostly due to interest but also based on all the research I did while I was contemplating shelling out all that $ for one of these 3D monitors).  Plus as you can probably tell, I am very passionate about stereo 3D.  So please, any questions, ask away!

I really need to get a trackIR just to see how well it would complement the 3D monitor. Â I suppose my brain may very well overheat and then melt from the maximum immersion factor! Zoom works quite well (right click zoom, can't speak for trackIR yet). There is some calibration required with all S3D, but once you get the hang of it you're very happy to be able to configure, on a game to game basis. Â Two main settings. Â First is depth. Â If depth were set to zero you would have a regular flat 2D image. Â Then as you increase depth, the things furthest back in the picture (i.e. horizon) start to drop backward toward the wall behind the monitor. Â Then the convergence (or is it separation?). Â As you adjust this setting, the closest things in the picture get closer (horizon stays in place), and when you increase this enough, things start to pop out of the front of the monitor. Â Including the aforementioned rpg rounds! Concerning the various views. Â 3rd person works very well, and that's what got me so excited when I first got ArmA working in S3D. Â (I know many of you disable 3rd person, which is understandable for PvP, etc.) When you go into first person, however, there are some issues. Â One of the great things about ArmA in 1st person is that the player sees his body just as it is in the game world, where as many other games replace the player's actual gun and arms with a dedicated alternate 3D (and even sometimes 2D) modeling of them. Â I would take the way ArmA accurately does 1st person any day of the week. Â Unfortunately though, either this does not translate well to S3D, or I haven't figure out how to set it up correctly. Â The problem in that your arms/gun are so close that your eyes cannot combine the two separate images. The good news though, is that 3D mode can be enabled/disabled, at will, so for now I will try setting it up to toggle S3D off when going into 1st person or ironsights, then toggle back on when returning to 3rd. Â The quick way to do this is manually, whenever the switch is made. Â However, the better solution will probably be tricky and may require some ArmALib scripting (thinking about all the combinations). ------ Quick update on finding a solution to the sun problem. Â Good news, I am thinking again it may actually be the lens flares causing the problem. Â Last night, I happened to walk in front of a truck with the lights on and the effect is similar to the sun "bloom" but it did not kill the S3D! I will attempt ro disable the lens flares tonight and see if that sorts the problem. Â The only way I know to do this is by removing the reference to the lens flare texture, like this (got the idea from Flat): <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class CfgPatches { class Flatsun { units[] = {}; weapons[] = {}; requiredVersion = 0.1; requiredAddons[] = {"CAData"}; }; }; class CfgCoreData { eyeFlare = ""; }; No idea if this will eliminate the S3D problem with the sun, but I will try it. Â Anyone know a better way of removing the lens flare? Curious, does anyone happen to know anyone else with a stereo 3D monitor? Â I really think it's going to start catching on quick.

@Meuhey My guess is that trackir would work with S3D in ArmA. Â I don't have a trackir yet though... otherwise I would check it for you. @gL33k By 3D goggles, not sure if you are talking about shutter glasses/CRT combo, or a head mounted display, so here's a bit on both. Years ago, I had a set of shutter glasses and a professional 22" CRT capable of the 120Hz necessary to deliver stereo 3D. Â I had a great time playing some of my favorite games at the time, including Jedi Knight. Â When those blaster bolts flew right out of the screen, sometimes I would actually duck down in real life! Â The good news is that this option is relatively cheap. Â Just have to make sure your CRT can do the desired resolution @ 120Hz. The bad news about shutter glasses, for me at least, is that they cause a LOT of eye strain. Â If you think about it, those shutters are opening and closing 60 times per second for each eye. Â Your poor retina (or is it the iris?) is constantly trying to adjust. Â After just a few minutes, I always felt like I had glass in my eyes. Now, shutter glasses have gotten a lot better since then, and you can always substitute projectors for the CRTs, etc, and have a more comfortable shutter glasses setup. Â Of course the cost goes up as well. Imo, the most promising shutter technology available for everyday joes is to get a S3D-Ready DLP TV from Samsung or Mitsubishi, which actually cost less than the average HDTV now-a-days (b/c it's DLP). Â There are some disadvantages here too (mainly driver support), and not sure if these work for ArmA, but wouldn't it be fantastic to play ArmA is stereo 3D on your 56" DLP?!? As far as head mounted displays goes, I haven't done a whole lot of research in this area, mainly because these are expensive for the resolution you get, and last time I checked, even on the high end models, the resolution was really bad. Â So I think we may still be a few years off here. So to answer your question, would I recommend such a monitor over shutter glasses or head mounted display? The main advantage of these 3D monitors as I see it is that they are a passive solution, and thus very easy on the eyes. Â The Zalman has the additional advantage of virtually no ghosting what-so-ever. Â Also, because the Zalman uses circular polarization (vs. linear), you can tip your head sideways and not lose the S3D effect. Â As mentioned before, the Zalman uses S3D drivers from nVidia, which are a bit lacking compared to the iz3D drivers (though work on them appears to be speeding up). Â As far as the iZ3D monitor goes, their customer and driver support is reportedly outstanding. Â Their devs are always on their forums, taking reports and fixing up the drivers. Â The main disadvantage of both of the these 3D monitors is the relatively high cost. So it really boils down to how much $ you want to spend on a S3D system. Â Haven't done the research on shutter glasses lately, but $50 US for cheap ones sounds about right. Â The higher quality ones run in the hundreds. Â The iZ3D 22" currently runs $600 US on NewEgg (no idea if you Europeans have NewEgg, they are good in US). Â The Zalman runs about $700 US (vender here are more obscure in US, I had good luck with thenerds.net). Â After a thorough evaluation of my 3D monitor, I would highly recommend one of these to any hardcore gamer, if they want to spend the cash. Â It really adds that much immersion. Â Plus it turns out to work in ArmA now! ------ So I checked out S3D water in ArmA... Â Works great! Â You can really get an appreciation for the waves and you can really tell they are actually modelled in 3D. That darn sun is really a problem though (see initial post if you are just joining the conversation). Â Haven't tried to turn off sun lens flaring yet. Â I'm thinking now it simply that when the sun brightens up as you look at it, there is some post-processing effect that kills the S3D driver, and then all goes back to 2D from then on. Â I tried maxing out the cloud level, but apparently enough of the sun peeks through to cause the problem. My workaround for the sun issue right now is to simply set the time to just after the sun is below the horizon, and use a looping script to keep it there. Â There's still plenty of light (btw I personally hate night missions). Â Primitive, I know, but it works! So does anyone know how to disable the sun "bloom" effect when you look at it? Â (It still gets bright and causes the foul up even in spite of using the HDR Lighting=Off mod.) btw- Anyone check out any S3D pictures? Also, you may want to check out the nVidia or iZ3D website if you would like to demo S3D in anaglyph (red/blue). Â I hear there is a way to do this, and of course no special monitor required for that. If anyone tries anaglyph, be sure to report back on whether or not it works for ArmA!

ATTENTION - Please see the note at the bottom before viewing any S3D pictures using the method I mention below Yeah, not really possible to make a video. Â (You'd need a 3D capable device to view it anyway.) To give you a good idea though, check this out: http://www.mtbs3d.com/ Go to Community -> Gallery Choose a game you'd like to see in S3D. Â COD could stand in as a rough comparison to ArmA in this case. Â When you get to the side-by-side pictures that fill up most of your screen, sit way back from your monitor, and allow your eyes to cross and form one individual image. Â (This can be a bit tricky. Â Keep scooting back if necessary, you'll eventually get the hang of it.) Now imagine playing ArmA that way!!! You may note that certain images from certain games do not form completely acceptable 3D images. Â Example - In many games the sky does not appear where it should. Â With ArmA, however, everything looks great! Â (so far that is). iZ3D has S3D drivers that eliminate most of these problems. Â The nVidia S3D drivers are less mature (at present). I should probably note that I haven't checked out any water in ArmA yet. Â Sometimes water (especially if it reflects) can screw up the S3D effect. Â Will check out the ArmA water tonight! edit- Be sure to look at several S3D images to really get a good idea of what to expect. Â Reason being, many of S3D images in that gallery are great but there are some that don't really do S3D justice. Â COD 4/30 and 29/30 are pretty good. Â As well as many of the Oblivion ones (5/17 is a good one) Â Other COD images appear to be before a driver update that fixed a problem where the players gun and arms were in 3D, but everything else was in 2D, so do be aware. ATTENTION Please be very carefull viewing stereo 3D pictures in this manner because you can easily strain your eyes looking at these S3D pictures this way. Â So take many breaks and don't over do it all at once. With an actual passive 3D monitor you should get little or no eye strain. Â (I get no eye strain what-so-ever on a daily basis using my Zalman 3D. Â I did go through a small adjustment period on the first day however.)

IMO, development allocated to fixed wing aircraft is well worth the expense. Actually, I cannot imagine OFP or ArmA without them.