-=seany=-

nice, glad you got it sorted :)

You mean these? localVRAM=919994368; nonlocalVRAM=1878282240; These settings are showing you what memory the game has detected in your system, not to let you tell the game what to use. If you change these numbers, they will be ignored. Which kind of lag are you getting? FPS loss/bad performance that results in a crash? If that's the case I would say try to run with Video memory set at Default, setting this to other settings seems to cause crashes for some people. I would use the default Malloc also. If your getting network lag, is it happening on every server? What was the kind of mission you where playing online? There is an issue with Arma where if the server your playing on is running too many AI and their server is struggling etc, everyone on the server will get bad FPS even though you can run fine offline. All clients performance is dictated by the server in my experience. That could point to a problem, I generally see 3-4 digits here.

That is odd, I'm out of ideas I'm afraid. :(

Yeah most are at 60hz when running at native res, but I have seen quite a few that will go to a higher hz if the resolution is lowered. Your HP monitor for example will do many resolutions lower than 1680x1050 @75hz (they just wont look that great, eg Blocky). http://h10010.www1.hp.com/wwpc/ca/en/sm/WF06b/382087-382087-64283-444767-444767-3296952-3296956.html?dnr=1 That's what makes me guess it is the resolution changing that is the problem rather than the refresh rate, that is just a "side affect" of a lower resolution. Though I still can't think of reason Arma would just suddenly want to change the resolution. Perhaps other multi monitor users may know. Have you tried using each monitor on its own, one at a time to see if that fixes it? =========================== Just had another thought. Perhaps it is the going to windowed mode that is messing up the fullscreen res when you switch back. Have you tried just Alt tabbing to get back to the game, or ctrl del to switch task that way? Also, you could go into your Arma2.cfg and change the window resolution settings to your native res (1680x1050). Maybe that would help?

Are you sure that it is not the actual resolution that is changing to lower (eg 1024x768, making it look "blocky"). At lower resolutions the monitor is capable of higher refresh rates. So that would increase also with the resolution changing lower, but would not be causing the "blockyness" Either way, I'm not sure what could be causing that behavior. What model monitor is it? (You might as well post other stuff like, version of windows, gfx card, Arma gfx options etc this will help others who may be able to help you.)

Is your monitors native refresh rate 60hz? What refresh rate is your windows desktop? What do you mean by "wreck the graphics?" You should be able to run at the maximum refresh rate for your monitors native resolution. This is recommended for best performance and gfx quality too.

One other note, not really related but handy to know. If you set the Shadow setting to Low or Normal, shadows will be rendered by the CPU. If you set Shadows to High or Very High, they will be rendered by the GPU. (you should definitely use one of these)

Maybe try with ATOC off. It could have conflicts with user made islands. Just a guess, but no harm in trying. Also, you could turn up Anisotropic filtering to it's highest. That will sharpen up the textures a bit more. You could even force it higher by going into nvidia control panel and setting it to x16. It will cause no FPS loss on your hardware. It's also worth noting FXAA adds a slight bit of blur to textures, I don't think that is the cause, but it all adds up. Finally, I personally prefer to set 3D Resolution and Interface Resolution to the same as my monitors native resolution. I find this gives the best clarity.

You realise I suggested this as a final compromise (of many) I have given to fix a problem caused by the CCP? And KJU ignoring me when I ask about these very issues in this thread helps how? That is why I asked here on the forum, but he wouldn't even respond to that. So I went ahead and made the ticket. You are really going to tell me that it is ok to make a Change that inadvertently breaks another feature and the way fix that broken feature is for us to use a mod? Do you realize how ridiculous that sounds? And exactly how will that work online then? Maybe the people who want to get rid of TAB lock so badly should be the ones using a MOD....? I don't see why a compromise can't be reached, but anyone who doesn't like me objecting to this change doesn't want to know about compromises.. Why not? I don't know, maybe I have just rubbed you all up the wrong way with the way I defend my corner/argue my point. Maybe beacuse once, I flagged a change KJU wanted and Suma agreed it was problematic and removed it. KJU pretty much blamed me for that...yeah right....As if I could really change the mind of a developer....I wish. Sickboy, I'm pretty sure you are savvy enough and open minded enough to know that the issue I'm raising about the broken FCS is worthy of discussion and possible compromise by the project leader? Ignoring helps no one and may even come back to bite BIS. Others may feel the same way I do who don't even use these forums, or know about the CCP. It is simply bad practice to introduce a change that inadvertently breaks something else and then stick your head in the sand and ignore it. As an excellent project manager and programmer yourself, I know you realise this. I have done nothing but try to highlight a valid problem I found in a civil manner and been dismissed, repeatedly. IMO blatantly ignoring some one is the height of arrogance. And anyone who thinks this is being blown out of proportion, you can blame KJU for that. If he had of discussed and acknowledged the problem 10 pages ago, we could have gone with out all this "arguing". Which I, believe or not, hate. Anyway, like I said. I have done all I can.

So, I posted the Suggestion on the DevHeaven CCP to include Q1184's FCS and KJU has basically dismissed it by moving it to the main Arma CIT, where it will most likely just sit gathering dust...nice. Why wait for me to post the report, then move it? He knew I was going to make the report and could have easily said here on the forum that there was no point and it would just be moved...but no..ignored..again. Well I guess that's as much as I can do, he wont engage or discuss in the way he is supposed to be doing for this project. He is deciding on what is and is not discussed for inclusion based on his own biased views, with no explanation on reasons for changes or discussion of compromises raised by others. Or even fully explaining/acknowledging when a change to be implemented will break some thing else (such as the AutoGuideAt change breaking the FCS), just say nothing and hope no-one notices and if they do, ignore them. Not exactly what I'd call professional project management. Sorry to anyone else who actually cares about how others play the game, I tried. I can only hope the BIS developers flag the change when they are implementing the CCP additions officialy Here is the Ticket for anyone interested: https://dev-heaven.net/issues/68092

Welcome to Arma! You should also be aware that the red targeting circle is a bit buggy, sometimes it just disappears after you have been assigned a target, but have not yet killed it.

And here is me thinking I had explained what my problem was to death...obviously not.. I'll make it really simple Tab lock On or Off :- I could care less. Loss of Vehicle Fire Control system :- I care a lot ----------------- It is an interesting point about locking into the fog with Tab lock off though, I'll grant you. With TAB lock gone it could be a lot harder for a gunner (in AH64 for example) who knows there is a target out there (in the Fog) to actually lock onto it. That would be when I would most use TAB lock. But, like I said my main problem is with loosing the FCS, I don't really use Tab lock that much, not online anyway.

I was just trying to come up with a nice solution for everyone. But....if we are getting into technicalities, Isn't the removal of TAB lock a feature? Being able to TAB lock isn't a bug either...so...? If you think it would be good to see a full FCS implemented GuessWho, then why bother to go off on a tangent about what is a feature and what is not etc? Why not just support it, go with it and see what happens? Anyway, since KJU ignored me yet again, I'll just submit the suggestion to the CCP Devheaven. Maybe he will give some input there?

The big Operation Arrowhead map runs better than Chernarus also, Takistan. I find the biggest performance killer on Chernarus is near the cities/built up areas. They take up a lot of CPU.

I'll try to come at this from another angle, a fresh start perhaps? So...AutoGuideAT=Disabled will be used to remove the ability to Tab Lock. That is fine. But, so no one has to lose The Tank Fire Control System, what about adding in the Tank Fire Control System that Q1184 designed for ACE? I would be very happy with this, anyone who has used it most likely would too. In fact, I think it is far better than the BIS method of "box locking". This would suit everyone and make the game more realistic. The AutoGuideAT change could stay as is, TAB Lock would be gone and everyone gets to have a nice (and realistic) Tank Fire Control System. How difficult would it be to implement in the A2CCP, would it be too complex, also would you need permission from Q1184? It works pretty much flawlessly in ACE, it isn't at all buggy or glitchy. Here is a link from the ACE wiki about how it works: http://wiki.ace-mod.net/Tank_Fire_Control_System?view=open Here is a YouTube video Showing how it works: Bo5UnOhUrbY Please discuss, I am trying to be reasonable...this about my forth suggestion/compromise. It bothers me quite a bit that I'm being ignored. We are all fans of the same game aren't we? I'm not bringing up this issue to be awkward, believe it or not.

In that vid the tank is actually firing HEAT rounds, so that's why the wall is gone. I'm not sure what a SABOT would do to a HESCO wall. Might just get buried in it, or go straight through even.

Good luck with that. Seems if you question anything that they want to see implemented into the game, you will just be ignored. No explanation, no reason, no discussion.

I think the OA sounds where very good ( especially the helos). I do prefer JSRS though and use it when ever I can.

Thanks for the update. Take your time, get it right! I'm happy to wait a bit longer.

Welcome to the forum, There is a sticky at the top of this forum for questions about hardware.

So no developer KJU, Suma, Maruk has any time to address the concerns I and others raised about side affects of the changes to AutoGuideAT? All I want is a possible compromise, I don't even mind what the fix is trying to achieve, just it's side affects. I thought it was a community project and we where able to discuss problems and raise concerns we had with changes. So I guess I don't count as part of the community then? It's pretty arrogant and not very professional to just ignore me. If I had a developer explain to me why they think it's an acceptable change (with the fact it's unintentionally(?) breaking another feature) that made some sense I would accept it. I am not completely unreasonable you know... And please don't get annoyed that I am bringing it up again...what do you expect if you keep ignoring me? https://dev-heaven.net/issues/29024

I'm sorry if i sound over agitated. I don't mean to, I am just a bit to enthusiastic when I m trying to get my point across, I guess. :confused_o: I tested the CCP and assigning targets to the AI while commanding still works ok using the mouse etc. The NLAW still works fine too, it has a lock box. The main reason for this fix is to have a way to get rid of tab locking, I am fine with this. The problem is that the change unintentionally breaks some thing else, the FCS. Couldn't there be a compromise? Is it not possible to disable tab lock and still allow us to right click and "Lock" or designate targets so the Auto range/lead FCS still works? Or would it be possible perhaps, to have this change as it is now but moved to a new difficulty setting called "Basic Fire Control" or some thing, and leave it disabled by default? Rather than piggy backing the AutoguideAT option. There must be some compromise possible?

Well thanks to some one for answering my concern. So I just tested a T55 (never use them much). And that has pretty much confirmed what I was worried about. This change is going to break a perfectly functioning Feature that BIS added with operation Arrowhead. Come on guys, please can you not do this? Don't break things that work fine just to fix an aspect of the game you don't like. Why is that so hard to do? This CCP is a great opportunity to get more bug fixes in the patch that BIS don't have time for...NOT to make GAMEPLAY changes to the game that break existing functionality, that OTHERS use. Have you people adding these changes no empathy to other players? I appreciate what is trying to be changed with this fix, but the downsides are unacceptable, sorry. Re work it or leave it as it is please. The M1, Bradley, Warrior, MGS stryker etc are not T55s, they are modern armor with Fire control systems and laser range finding and auto computing range/lead, this "fix" destroys all of this kind of vehicles ability to do this. And for what? I don't know really. For a few people who play PVP? And what about those who like this in coop, or who just like this perfectly valid feature? They don't matter I guess. Not even a vote, not even a thread in the main forum to ask If any one minds such a big change....just slipped in via the CCP and hope no one will notice...not cool. And the answer is not to play with Auto Guide AT enabled, as no server I play on ever uses such a low difficulty level and I cant make a sever change their difficulty level any way can I? I would like a top dev, Suma, Maruk etc to comment on this and state that they feel the consequences of this change are acceptable. I still am also unaware how this change will affect assigning targets as a tank commander, will I have a box that I can right click assign targets with? Or will I be forced to use the key commands? And the NLAW is now going to function Like a Javelin with Auto Guide AT Off? Confirmation? For such a big change none of this seems very clear. Are changes like this really even necessary with Arma 3 around the corner? The whole Auto lock/ tab lock/ lock box/arcade thing is so complex, is it not more logical to wait for Arma3 to overhaul this system? ========================================== Here is the report : https://dev-heaven.net/issues/29024

Firstly I think the CCP is a great initiative. And thanks to KJU for taking it on. Also, bare in mind I don't care who the person organizing or submitting these bugs are, so don't take post like this personally please, I have already expressed before how much I appreciate what you do for the community KJU. With this CCP you have to be prepared to deal with questions/ oppositions to changes you would like to see or ideas you have. I do think these changes have to be thought out very carefully and time and thought must be given to players who raise concerns about changes. Also Changes should not be made that BIS themselves would not make. And I'm sure there are procedures in place to check that this can't happen anyway? ------------------------tldr--------------------------- Most of the fixes I see listed are great, but I do have some concerns/questions about changes like; "Disable locking of all non guided weapons with AutoGuideAT disabled." Maybe it's just me not understanding fully how the change will affect various weapons, but this looks to me like one of those kind of things BIS would not change...not with out some major overhaul of this entire system. The problems stem from making a change to fix an apparent problem with the game (eg Auto guide AT is too arcade like) but as a side affect, breaking features that are fine and have no problems. If my understanding is correct this change would mean that if you played on a server with Auto guide AT off, then your Tanks Fire control system would no longer work. In other words you would no longer be able to lock a target with the BIS lock box and have it auto compute the range and lead to hit a target. To me this is an example of breaking something that works as intended to try to fix some thing else. This would affect many vehicles like the Warrior's and the Bradley's cannon and the Stryker MGS main gun etc. What about commanding AI from in a tank with this Disabled? Would that mean I could no longer assign targets to the AI by "locking" them with my Command cursor? How would launchers like the NLAW be affected by this I wonder also? This is guided though, so it would still work I guess, but would you have visual on what you where locking? I'm not sure. I don't use it that much, I'm just wondering about other players here. ----------------------/tldr--------------------------------- Even if you have an idea to make a change to the game that you feel very strongly about, you can't implement it if it breaks things other players might use or expect to behave a certain way. For me, if you wanted to properly implement this fix it would involve changing (among other things) the entire FireControlSystem to the way it is handled by ACE, where no magic lock boxes are required at all. I think changes like this are beyond the scope of the CCP. Anyway, as I said I think the idea of the ACCP is great, but I really don't want to feel like I have to keep hovering over the CCP change log to make sure that things arnt "slipped in", as it where, that will make big game play changes or affect existing, perfectly functioning game mechanics that people are used to and use regularly. Being in control of this project requires extreme care and consideration of all types of players. Changes should not be taking lightly