kegetys

The aviation musem (Letecké muzeum Kbely) is worth a visit if such things interest you. It's free, quite easy to get to and has alot of planes from different eras.

I'm quite cautious about this, doing the future aspect _right_ is something that is going to be extremely difficult compared to some "realistic" era. It would require extensive research into current day weapons systems, what is being developed and what of those are realistically going to make it (My impression is that a lot of the "coming soon" high tech gadgets end up being cancelled as they are not practical or the resources for their deployment is not there). Too often these future based games go all "cool factor" and forget practicality and the fact that militaries do have limited resources. For example I hope there is some pretty well thought out and believeable story as to why and how the Comanche was digged out of it's grave in this scenario (Where did the budget for it come from? Why is it better than a cheap UAV solution? What does it do better in practice that some upgraded Apache could not do?). If it's put in just for the cool factor and all the reasons for it's original cancellation are ignored then it's an entirely wrong approach for a game that is supposed to be taken as a serious milsim. That said I do hope the game will be good and I'm looking forward to it. :)

For a "civilian" sim like this, I hope it will be full-on realism at least on the flight dynamics side (DCS Black Shark level) and with realistic ATC, weather and navigation. Without full detail avionics (button/switch mashing) however I'm not sure how interesting it will be. It also sounds a bit odd that this would be left out, as I dont think the full detail systems of a civilian helicopter would be that hard to implement as there's no weapon systems to worry about. I'd say a clickable cockpit is definately the absolute minimum requirement for today's flightsim standard though. (IL2COD, DCS series, Combat Helo, Jet Thunder, etc. all have it, and those are combat sims)

I wont vote since I didn't test the RC, but from the videos and description it looks & sounds completely wrong. There are some animations like the grenade throwing and pistol/rifle change that feel sluggish in game, but even for those just speeding them up is not going to work. If they are going to be fixed then the animations should be re-captured with a real person doing them faster. If that's not possible then leave it as it is, just speeding the animations up for gameplay's sake makes it look bad and is against what the game is supposed to be about. True, I'd much rather see this fixed (maybe just much slower reloading if you're moving).

No. I simply have had way too much problems with Steam, ranging from issues with the application itself (cant count how many times I have needed to delete clientregistry.blob when Steam decides to break itself) to problems with the service (downtimes or very slow startup times, slow downloads). It is very annoying when I just want to play a game, but there is some issue with Steam and I have to start troubleshooting that. Or when it takes an extra minute to start the game when steam is connecting and then "preparing" the game. The auto-patching is nice though, except it being forced on you can sometimes be a bit annoying. Especially when the download speeds are absolutely terrible when big updates come out and you can't play the game until the update is finished. I also do not like the fact that it adds an extra dependency on running the game (Valve goes bust, there goes all your games) and the fact that Valve can, according to the subscriber agreement, terminate your purchases at any time without notice or refund. Ever since the "euro=dollar"/zone based pricing change the standard price of games in Steam are also ridiculously high here (Finland). It is almost always the most expensive option I can find, even more expensive than the already high retail prices at supermarkets. Though there are some very good sales every now and then. Also, I believe the steam subscriber agreement disallows game modding for any non-valve games without written permission from Valve (IANAL though so this may be wrong). As a whole, the service just doesn't feel reliable or friendly to me and I dont want my purchases to rely on such. Of course I dont mind BIS, or any other, games being available there but as an only option its a big no.

Looks quite nice, though for some reason there is a horizontal scrollbar when the page is less than ~1200 pixels wide. The content itself seems to scale properly though and on the overflowing space there is only white. edit: now it is gone

Here's a little project I have been working on for a while calle "ArmAlib". A bit similar to fwatch, it adds new scripting capabilities to the game which allow, for example SQLite database access. It works on ArmA v1.14 client and Windows dedicated server. Linux dedicated is not supported. The documentation is a bit poor at the moment because writing it is rather annoying but hopefully you can figure it all out. New features it allows are: - Access to two SQLite databases with SQL syntax (for saving and loading data) - HTTP GET support to retrieve data from the web - Windows clipboard access (set and get string) - Setting mouse cursor position (same as ArmA function 'setMousePosition' which does not work) - Retrieving mouse information, including cursor position, "relative" positions and button states - Setting TrackIR X,Y,Z and roll axis freedom for "6DOF" support - Retrieving the current viewdistance, camera X/Y FOV, current screen resolution and arma command line - Night vision goggles effect detection - 'ScriptLink' feature, which allows real time communication with external applications using a Windows named pipe - Debug output Download the installer package from my ArmA site There is also a samples package with a few simple missions for testing some of the features I have tested it quite alot, but there still can be some nasty bugs left. If you get crashes when using it, dont bother BIS with the crash reports, its propably not their fault :P I have tested it on Windows XP SP2 client & server and Windows 2000 pro server, other OS might or might not have some unknown problems. ArmAlib is activated by a "proxy" DSOUND.DLL file which is installed into the ArmA directory. If you have some serious problems (Such as the game not starting) removing this file will disable ArmAlib permantently. '-noarmalib' parameter can also be used with arma.exe to disable ArmAlib loading. edit: Updated to version 1.01, download from the same location edit: Updated to version 1.02, to support ArmA v1.15 beta. download from the same location

It was just a quick update from the Armed Assault launcher to ArmA 2 as some people kept asking for it and it was simple enough to do. It is a bit lacking in features nowdays so I didn't make that much noise about it... The code is very old (I think I made the first version in 2001) and made with Delphi 5 so its not very nice to work with anymore :P

There is nothing like that in the exe, the FDFmod.exe's only purpose is to "intelligently" select wether it will launch flashpointresistance.exe or the beta patch exe with the appropriate mod parameters. A long time ago I posted the source of the exe somewhere on the fdfmod forums when someone else wanted to do the same thing, but I'm not 100% sure if it is there anymore. The RAR SFX installer, being based on HTML "pages" has an iframe that grabs the latest news from the fdfmod website, purpose being that if you're installing an old version it can tell you that there is an update available etc. edit: Here's the source of the exe:

I hope the expansion would fix some of the long standing realism issues that have been there since OFP, for example: - Proper weapon magazine/chamber simulation (ie. you can have a round in the gun separate from the magazine attached to it, and you need to pull the hammer if you fire it completely empty) - Adjustable rifle sights, barrel heating for machine guns, removal of rounds remaining from HUD and replace with more realistic system - Better vehicle damage system, no total destruction of a car for example no matter how much it is fired at with non-explosive rounds (and no magical everyone-inside-immediately-dies feature even if hit by an explosive) - Improvements in the weapon systems (FCS for tanks, some improvements in the radar systems and guided weapons) - Many other things I cannot remember now :) Typical fps games have many of these features today, even "arcade" shooters that have better weapon simulation than ArmA 2. They were issues with OFP already, but understandable since the game was otherwise so revolutionary and it would really be the time to fix at least some of them

It shouldn't be compatible with 1.02 either :) It is unlikely that I'd update it as since 1.02 you can disable the postprocessing effects from the video options.

We already had that a few years back :)

Here is the first version of DXDLL, with the following features: - Reflective water - Postprocessing effects (hard light, desaturation, glare) - Forcing of trilinear filtering - Screenshot saving, also with "No UI" feature - "Black & White" night pixelshader effect override - Mipmap LODbias adjustments, including an "UI Sharpen" option - FPS meter & other stats Download from here (516KB). Remember to read the readme! So far it seems to work fine on newer video cards, Geforce 3 cards seem to have problems with the water reflections however. Feedback on how it works on different card/driver combinations is welcomed to this thread. Some screenshots: Without postprocessing: full version With postprocessing: full version Reflective water (and postprocessing): full version Special NV goggles postprocessing effect: full version feersum.endjinn: Please note that Geforce4MX and most Geforce 4 Go cards are technically GeForce2 cards and do not support pixel shaders, so postprocessing effects will not work on these cards. Reflection might work, but it's not guaranteed.

zoom in and zoom out :)

The limit is 2GB in normal applications (You can use 3GB of memory but a single application can only use 2GB), with the large address aware setting it can be increased to 3GB but I guess ArmA2 doesn't use that.

I have heard there is some odd feature in Vista/Win7 where it will stop cpbo from extracting the files where they belong and instead they end up extracted in some kind of "virtual" program files directory under your user home dir. I dont know how it works since I use XP, but I would assume there is some way to disable that from Windows. (Though it should only happen if you are trying to extract PBO files under Program Files).

RoF sounds very interesting, but judging from impressions on simhq forums it seems quite incomplete and seriously lacking content. The fact that it is (apparently) going to be sold as a full priced game, yet you need to still buy the extra planes etc. separately means its propably going to be rather expensive... And it uses some online-only system where you cannot play the game even on singleplayer without logging in to their service first. I'll propably wait a while and see how it progresses, seems a bit risky investment now :)

What I find annoying is that the fps varies so much when playing - I can get over 60fps when flying or looking at open terrain, and then suddenly have the FPS drop to 30 when looking towards some bushes. 30 FPS would be enough for me for the game to feel smooth, but the drop from 60 to 30 makes it seem worse than it actually is. Even worse, the mouse speed seems to vary alot as the FPS goes up/down. To cure this I made a simple FPS limiter DLL that I use to limit the FPS to 40, playing feels a bit better with it (not a big difference though). The DLL is available here in case anyone wants to try it, put it to the ArmA2 directory and then add -fpslimit=40 parameter to the shortcut to use.

np, I am glad you cant get it working :)

Can I buy only the completely free postcards & map? :)

Making it work properly is currently not possible due to changes in the scripting system (The game can interrupot script execution at any time which breaks many things from the script). Hopefully some future ArmA2 patch will fix it.

A better system in my opinion would be that the server would enforce the maximum viewdistance, and clients would be allowed to use a lower one if they want. It would allow everyone to use a reasonable default viewdistance which works for majority of the players, but allow people with lower end system still play without having 5fps.

The download rate should be pretty much irrelevant for the game, only cases where it makes a difference in practice is with SoftTH or if you record (high resolution) videos with fraps or similar app. Games very rarely need to transfer anything large from the card back to the system memory, which is also propably why it doesn't seem to be highly optimized for ATI cards with D3D. Even the upload speed typically doesn't have a very significant effect unless something is badly wrong with it. What matters most for the bandwidth is the card, drivers, bus speed, motherboard chipset and RAM speed.

I hope there will be a briefing editor implemented as well, and maybe some a script editor also.

I think one possible fix for the HDR exposure going into nonsense values* could be to limit the amount the aperture is allowed to go up/down based on the current amount of light from the the sun/moon. In the game there really never is any other light levels than either being lit, or being in the shadows, so there should always be well defined limits to how high/low the aperture needs to go in order to be able to see everything. Currently (it seems) the HDR aperture automation only considers what is currently on the screen no matter what the actual environment lighting conditions are and because of this it often goes completely wrong. A special case would be when neither the sun or the moon is up, but there no limits would maybe be ok. * Refers to the HDR wildly cycling between excess darkness and excess lightness, often seen when walking in a forest for example. Sometimes the bright sky makes everything on the ground appear almost pitch black, and when you look down then the exposure adjusts to everything being much too bright. Like in this example: In this case for example the HDR automation should take into account the amount of light coming from the sun and not let the aperture go into these extreme values.