st_dux

Your view in ArmA II, as it is in any FPS, is made to have a field of view that is substantially larger than what a window the size of your monitor would actually provide in real life. A side effect of this is that your view will appear "zoomed out," so it's more difficult to notice details at a distance than it is in reality. You can make up for this somewhat by looking down your sights and holding the right mouse button; this will bring your field of view down to the correct level and remove the zoomed out effect, allowing you to see detail more-or-less like you could in the real world. Of course, the flip side of this is that you'll have tunnel vision.

This entire forum section is essentially a repository for wishes and ideas, and that thread is an unfocused mess. Besides, the OP specifically asked for feedback on how this feature could/should be implemented.

@Falcon: DMarkwick is correct. Ordinarily, the screen field of view is made artificially wide so as to make up for the fact that you are looking into the world through a tiny window (your monitor). This creates an unrealistically zoomed out view; the detail you see x meters away is less than what you would experience in reality. This has to be done, though, because the alternative is an unrealistically restricted view (in fact even zoomed out you have less field of view than is available in reality, but a compromise must be made somewhere). In order to allow you to aim with realistic clarity despite this compromise, you are able to "zoom your eyeballs," but as DMarkwick pointed out, this really only brings the zoom up to 1x. If you directly compare this zoom level with, say, an ACOG, you will see that the ACOG, a 4x optic in reality, is zoomed in exactly four times more. As you can see, forcing a zoomed out view even when looking down your gun sights is actually less realistic than allowing for "eyeball zoom." It's true that cover and concealment are far less prevalent in ArmA than is generally the case in reality, and this makes it far easier to spot targets at long range than it should be, but this is a separate issue.

How do you know this? If not from the media, where are you getting your information?

While this new technology looks promising, I do not foresee wind power ever fully supplanting more reliable energy sources (e.g., nuclear).

I'm not talking about armed rebels; I'm talking about civilian protesters. Gaddafi ordered the military to fire on them, which is one of the reasons why a large chunk of his military deserted and joined the rebel cause. And I don't think the rebels are saints. I'm sure they're lynching most anyone they suspect of having been a Gaddafi loyalist right now. There is no good vs. evil here (or anywhere, for that matter). My only point was that painting Gaddafi as some sort of benevolent dictator isn't really accurate.

There is proof that Gaddafi was ordering his military to kill dissenters. Whether or not this constitutes "mass murder" is a matter of definition.

I don't think you can restrict slot selection before a mission starts.

Many people, particularly in sim communities for some reason, have an irrational fear and/or hatred of Steam.

You know you can always change your Steam nickname to anything you want at any time, right?

This is the case with closed bolt weapons, not open bolt; there is no bullet in the chamber prior to squeezing the trigger in an open bolt weapon. The rest of your list looks pretty good, though. I would add that if a closed bolt weapon is reloaded while not empty, the round left in the chamber should be recognized (e.g., if you reload an M-16 with a 30-round clip after firing only 15 shots, you should have 31 bullets ready to fire after reloading: 30 in the magazine and one left in the chamber from before).

So it is admittedly arbitrary? OK, lol. Thanks for the response.

What is the criteria by which threads in the ArmA 3 section are closed with OPs redirected to the ArmA 3 Wishlist thread? Seeing as most of the threads in the ArmA 3 forum are essentially wishes or the discussion thereof, why aren't most of the threads locked? The ones that are chosen appear to be utterly arbitrary, and it's killing some good discussion potential. For example, why is this thread closed while this one is not? What about this one? There are many more examples, but I think you get the point.

Zoomed in compared to what? Compared to an actual 1:1 representation of what you would see in real life, ArmA II is quite zoomed out by default. Zooming all the way in with iron sights gives you mostly proper FoV; obviously, given the limitations of monitor size, it would be silly to attempt to play at this FoV constantly.

The default field of view is not zoomed in. If it was, you could barely see anything on a normal monitor.

@galzohar: Fair enough, but I don't think it's accurate or fair to say that there is no polished custom content made for ArmA. There are many mods and missions that have been playtested by many people and are in quite a nice state right now. Look at ACE for example, or Domination if you'd like a mission. PR may turn out quite polished and well supported as well, but I don't see this as being some sort of revolutionary first within the community. In my opinion, this community has a long history of creating great content. Sure, there might be some things that aren't as well-polished as others, but when everything is free and freely shared, a bit of inconsistency isn't such a high price to pay.

This is where much of the community seems to fundamentally disagree. It's a mod: It doesn't really offer more than any other total conversion mod (though what it offers may indeed be novel), and most importantly, it requires another game (ArmA II) to play. Really, calling it a new game is just disingenuous. @galzohar: Let me see if I got this right: The entire ArmA community is not a large enough testing base for the production of quality missions/addons/whatever, but a subsection of that community, the PR players, somehow will be. How does that work?

No one is up in arms because a mod is doing things differently, nor does anyone care that PR comes from a BF2 background. This community has always embraced creative modification of the ArmA engine. We might not all like all of the mods that are offered, but by and large, this community recognizes the value in the free exchange of ideas, missions, addons and mods; it is this exchange that enriches both the content that is available to players and the knowledge that is available to developers to create even more. The problem is not the freedom of the exchange of ideas; it is the attempts to restrict that exchange through draconian license agreements and mandatory exclusivity. This runs counter to the spirit of openness that has been the hallmark of the ArmA/OFP community and the mechanism by which mod developers have shared knowledge and combined efforts leading to the robust set of content and resources we all enjoy today. I believe this attitude of exclusivity, more than anything, is what rubs people the wrong way when it comes to PR in ArmA.

Did it ever occur to you to just take one of the base AK models that doesn't have any lasers or flashlights? You can customize gear, you know.

+1. I would much rather BI focus on improving core mechanics than worry too much about purely cosmetic stuff like this. An improved animation system is important, but not because of trivial things like reload animations.

Put all of the moveInDriver, etc. stuff in the global section of your init.

That really is strange. If it's not a locality issue, then it must be a problem with the dedicated server software itself. Perhaps you could try using a different method to see if the dedicated server deals with that any better. For example, try a normal Get In waypoint rather than a Get In Nearest. If that doesn't work, try a scripted solution instead, i.e.: civi1 assignAsDriver car1;civi2 assignAsCargo car1;[civi1,civi2] orderGetIn true There's no good reason I can see why your original method doesn't work, but sometimes the dedicated server client doesn't operate in exactly the same way as a normal client. One of these alternative methods may work.

Interesting. I've never seen that syntax before. It looks to me like the public parameter of your setVariable statements isn't working. According to the Biki, only object- and group-type data can be broadcast in this way, and you're trying to broadcast boolean-type data. This wasn't a problem when you were testing as the host or solo because the action script was local to the server (you) anyway, but with a dedicated server, it isn't. The easiest way to circumvent this issue, I think, would be to scrap using object variables and just make a couple of global variables instead; publicVariable will be able to broadcast the change of just about any data type, boolean included. But if you insist on using those object variables, you could probably get them to work using setVehicleInit, like so: civi1 setVehicleInit "this setVariable [""GetOut"",true]";processInitCommands This will globally set the variable to true, and you can do the same thing for your other object variables. If you want to change more than one, you only have to use "processInitCommands" once at the end.

I honestly don't know how this is working at all because you are using getVariable incorrectly. It should be: civi1 getVariable "GetOut" && civi2 getVariable "GetOut" and civi1 getVariable "clearToGo" && civi2 getVariable "clearToGo" I have no idea how getVariable deals with arrays, so this may be the root of the problem. Try it this way and see if the problem persists.

Oh, really? I must have been thinking of a different function. In any case, I wouldn't worry about list causing massive performance issues, but I'm sure both methods would work well. Thanks for the correction.