Batstat

64bit is not only for more adress space >4GB, but it also give you higher precision in math without clever workarounds. If you ned 64bit precision then you are better off with 64bit os and application. I don't know many non science application that need this kind of precisison, weather forcasting moddeling and, huge sim applications, and alike -hmm is Arma a sim @ch_123 According to this article, Arma do allready utilize workarounds related to the 32bit adress space boundary. http://www.bistudio.com/develop....en.html A transition to 64bit would have get rid of the implementet workaround. For what I know, 64bit could also have other impact not pursused for now, because it's outside the dev envelope. - bigger world and more objects maybe? - a weather model hehe - just kidding.

I switched to W7B64 4GB RAM and Arma plays like a charm. I can Alt-tab all day long and still continue to play. A lot more stable than XP32 and 2GB RAM. Some problem did arise: Unbpo don't work (I have tried two different utility, and none of them worked). I can't Alt-tab when in Team Fortress, TF2 hangs (black screen, no sound). UT3 will hang after 30 - 90 minutes gameplay. Before launching UT3 reports problem with W7B64 GPU drivers. Most important ARMA is smooth. I use 1 GTX8800, no SLI

Can I suggest a easier way to do this. 1. Keep the old forum "as is" but read only. 2. Use Fast or some other indexing sw to make the search function to work. Optional provide new search URL and/or gui. 3. Decide the new strukcture for the new forum (already done I suppose). 4. Convert only the user name,mail, password etc - forget the sign, and other non important stuff if it is difficult. 5. Let the users inside the new forum. It will cost close to nothing (exept nr 2) and it is very fast to do. Nr 3, 4 and 5 is not dependent of 2.

Whats the problem, you can have both. Designer scripted AI and AI doing things for them self. But what is scriptet, mostely it's the goal for the AI, normaly you dont want to micro managment via script how the AI reach the imposed goal. Guard, defend, move etc, etc.. You dont want to code the AI to go one more step forward, and then anoterher step, reload if emtpy etc.. (normaly). There is tons of tons of AI behavoiur you take for granted, and you dont want to think about it, and less code it. Form time to time you want to override som small part, put mostley you give them the ordres (obejctives). Or I do when i make missions.

I agree with second and others when they state that AI has some flaws, and in some respect the flaws are majors. How to address that? Well in my opinion BIS has allready done the most important part. They have in some degree made an “open†framework to control the AI behavior (FSM). Also and thanks for that, the AI is not COD-hard coded, if it had been, some of us, not all, would not have been playing Arma at all. One obstacle with the exposed part of the FSM, it do not contain BIS default AI behavior, witch raise one big problem, the community cant extend the BIS default work in a good and integrated way. If you code your own AI behavior with the FSM you don't know how or when it will be overrided by default BIS made AI behavior, only by looking at the code. You need to test it, to find out the basic principles, and you need to test it to understand when this will be overrided. This involve heavily use of time, with a uncertain outcome. I'm not aware of any good mission, or addon heavily based on community made FSM code. One last thing, and as I see it, thats also good news, I belive BIS default AI behavior also are based on a framwork, not sure what they call it maybe BisFSM Why not expose all the AI behavior to the community. My guess – property protection, but really I don't know. If it had been exposed then next version of COD could have been released with something similar to intelligent AI. Do BIS want to play out that card for free? Use of FSM to code AI behavior is not uncommon, http://www.gamasutra.com/php-bin/article_display.php?story=1862 and in spite of all the different property protection schema's running around, slowly the different companies are learning to control AI in some semi intelligent way. One day this could be common knowledge – maybe. I would have liked more dynamic AI, and I very much praise DAC in this respect. I also believe it is possible to get the best from both word. I don't belive it is rocket science to code and make the AI and use of FSM, influenced bye editor exposed attributes. Note: All my statement is based on reading, browsing and playing. I have newer coded any FSM og HFSM by myself. Worst case – all the above is nonsens Regards Batstat

Two and a half year ago I bought a crossfire rig to play Arma on. It did scale very well with all Valve games and some others, but Arma did not utilize it. I sent a request to ATI and asked if they could do something. Ati newer responded. Today I tried to find out if something had improved. Nope. Then i tried to find out if there had been made an app to configure low level Bios parameteres, to improve performance. Nope - nothing there. Then I went over to ATI forum with the goal to find out why do this not work. Several mouse click later I found in the dev area (witch need registration) several articles about how to utilize the AMD crossfire. The article I will quote point out that the steeps needed to scale with multiple Nvidia and Ati GPU's for the most are the same. One important note is: And thats what this topic is all about. Arma may behave in an AFR unfriendly behavior. NB There is no proof, and there could be toons of good reasons for that. Quoting is from Harnessing the Perforrmance of CrossFireX, only some snippets from the article is quoted. Hopefully I have not broke any copyright rules / laws. Some other issued and examples with figures are described. But as you notice, there is a lot of stuff to avoid if you want your game to scale with Crossfire or SLI. If you don't avoid this pitfalls, slow down and graphics errors could occur. I do not know if Arma is implemented with any of the described pitfalls, or if there is some other reason for the lack of scaling with mgpus, but I do know that i would not research this more in hope of fixing the problem until BIS or someone state that it works Happy Christmas Everyone. Batstat

a) I have tried it, renamed arma to fear.exe and a bunch of other alternatives, the performance got both way, under some condition it did go up, and under other condition it was the same or poorer. But I also got constant and annoying flickering and the scene was much darker. This was 1 year ago and I have not tried it with 1.14 Â b) Point taken, no I Â don't belive the rendering engine is 10 years old. Neither do i know how much the architecture behind the engine is rewritten or witch goal you tried to accomplish. I also don't belive your priori ting is the same as Epic and I'm happy by that. c) Yes and as Kegetys point out - support or standardization for mgpu's in dx certainly will change the game. GPU shared memory architecture would also helped a lot, but it is no existent, between mgpu's. But and to use your words, "do you really belive" ATI/Nvidia forums can point out what to do if Arma not are coded for mgpu's. According to a) and partly b) and c) you indicate that arma is coded for mgpu's? Working mgpu's in games don't happen by it self or? So you have coded for it avoiding all the major pitfalls, and now you only lack driver support from ATI/Nvidia? Then I rest my case.

Today yes I agree, but two years ago a decent modern cpu by todays standard was a high cost pice of equipment. I'm not going to argue your point. The BIS defense I did put together in my head when i wrote post 1 was somthing along this lines. The BIS engine has evolved from a concept you guys architected aprox 10 years ago. To my knowledge you could not in any way foresee witch steps you should have taken if you wanted to avoid mgpu's pitfalls. Avoiding the pitfalls need a desire to do so, and will not happen by itself or by accident. Your point Marek can explain why BIS not have given this issue a high priority. I also understand BIS do not give away "secrets" about weakness in design and architecture, same goes for the hidden strongholds maybe. But I also belive (I'm never sure of anything) that you could have told us: sorry guys, don't waste your money on mgpu's for Arma, it's not supported, and will not work because of <list>. It's not supported you said that allright, but that often doesnt mean anything, if you don't know why it not will work. But again company  seldom is this honest, if it can stop revenue. ATI's statement "all game can benefit from crossfire is more to blame". The tiny writings is hidden in "hard to get" dev documentation, and that is not very honest either. Community ranting and making a big points of everything that is not perfect don't help either Regards Batstat

They did when we testet it yesterday, but there are some issues with JIP yes. Awesome mission, and great patch thx BIS and Mike

We first noticed the error above in 1.11

This error seems to happen when we are more than 5 players 7+ maybe. When starting the briefing we got: No entry 'bin\config.bin/CfgWeapons.TR_Throw'. with a green button OK to press. Exept from this error, the missions seems fine, all players can start the game. Next ting that seems to happen is that more or less all ppl with this error get thrown out when they try to enter a vehicle. First we believed this was some addon problem, and we quit using @mapfact, no we are not so sure because the error still comes, Last week we used only @ECL and beta and no one got the error. @ECL together with beta and QG, the error are hitting us again. When I'm testing alone or with 1 or 2 others, I'm unable to recreate the error. I can not guarantee  that my report here is 100% accurate. And I'm sorry if it's far off or posted in wrong forum. My search did not shred any light on the subject. Is there any one who has similar experience? I will try to nail this error further, and if I can pinpoint it I will post a update, maybe in the right addon forum Â

DAC is a script OFP/ARMA framework, not a addon. Translated - DAC is embedded in the mission and tells you as a mission consumer some hint about what to except from the game play. DAC V2.0 is for Arma and V1.0 is for OFP.

Thx for your missions Igor Drukov. I support NoBrainer in the fact that there is to much AI spawning close to where you are. Ok if AI spawn in "cleared" area, but you could pretend they reoccupied the area, if they spawn farther 100 or 200 meters away from the players. When using the @spect addon you also can observe that the AI spawn inside houses, and then are coming out from the walls. This can be seen in game without the addon also. Ok if they spawn inside houses, but maybe not to obvious from houses without doors. The combination out from houses, then 5 meters in back of you is frustrating. Else keep the good missions coming

With JIP not working there was two thing I noticed 1. Revive script error when entering (after you first was dead) 2. Enemy chopper reinforcment arrive also when radio mast is taken down before they send distress signal. Happen also when we prevent the UH60 to take off<-- after sec tought this may not be related to JIP. 2 placement of tower - ok we did not look for the second place. All the next to tower structure was in place, only the tower was missing, my fault. Â

We played your mission today at our NoPryl server. First we used the normal addon layout, result the revive script did not work. We disabled all the server addons, same result. My addon at the moment was QG, Beta, FDF_sound and  Mapfact. Are you using norrins newest review script, or ....? Else the mission seems promising, but there may be some JIP script error also. If you disconnect and log in, using another slot, it seems to mess up a bit. Normaly you dont do that, but when revive dont work it is tempting. Edit: Forgot to tell, in 2 of 10 times, the radiotower did not spawn.

It may be connected to a radio trigger where you can get up information about how many tanks and officers are killed. Not sure because I has not cheked it, but it seems logical

I play ARMA once i a week, and last monday we played Black Sword 3.1. Best mission ever, not often you identify yourself with the avatar, but in Black Sword - you do! After we was done, I used http://stats.swec.se/game/list to check for updated versions, and found one unofficial version ...(halo) 3.2. With winmerg I noticed 3 difference, 3 minor one. Two text change and one update of the class Header in description.ext, where maxPlayers where corrected from 8 to 12. As I understand, this change only reflect MP gamespy browser window. No big deal. I also understand from your statement Igor, 3.1 is final and you work on other projects. But if you for any reason should reconsider and make adjustment to the mission I has one request. Make the mission for more players, we will often be between 12 - 20 players. And it is a shame not to be abel to play your mission then. For adjusting balance accordingly, I suggest you could use a mission admin start parameter 01 - 08: Number of AI reduced to best suit up to 8 players 09 - 16: Number of AI adjusted for up to 16 players 17 - 24: Number of AI adjusted for maximum number of players 24. OK this may be simplified, the resistance you meet in the mission consist of more than the number of AI. One bug we noticed: We did call for air support, 1 pilot bailed out in a parachute when his air plan was shoot down. He landed not far from us, and when he later was killed, we all got a script error. At this moment only one of us was alive, but as I remember we all got the same error. Sorry i can't remember the error, but it was something about a pilot...pd3 file not found. Anyway: great great mission, keep up the good work Igor.

BH is?

Thx for the reply My q: A and B is answered One more to go: c) @GMJ_SightAdjustment and @NWD_ScopeFix do not have any meaning on the server, other than maybe verify the clients files (Anti Cheat Purpose)?

So if installed on the server it will only affect AI on server?

I belive Jack-UK generally spoken is right. Beside that, this is an apple - banana compare. It can be my lack of understanding, but how can you be sure you compare the same thing, ingame and driver vise is not a 1:1 relation. Anyway my 4 runs and numbers, fraps benchmark of ingame video 60 sec. 1: Driver AA and AF to sw controlled. Ingame AA to very high amd ingame AF to very high. Avg: 23.867 - Min: 5 - Max: 41 2: Same as above Avg: 23.867 - Min: 10 - Max: 40 3: Driver AA Override SW - 16x, AA transparency - Multisampling, AF Override SW - 16x Avg: 21.167 - Min: 5 - Max: 34 4: Same as above Avg: 22.217 - Min: 10 - Max: 37 Not sure what this answer? The difference is there, it is minimal, but is it the same picture you get? I don't think you can be sure of that. Screen 1280x1024 Note that the ingame video always play out slightly different so there will always be some result difference also.

If I understand this right. a) When NWD_Ballistics v1.53 - @NWD_Ballistics  - Addons    - files is installed on the server and activated with the -mod= param, then no client need to use the same addon? It's optional or for your own singel mission? b) If used by client only, the addon will not affect the ballistics for other players, and it will not affect you either because then the vanlilla server will override your config? c) @GMJ_SightAdjustment and @NWD_ScopeFix do not have any meaning on the server, other than maybe verify the clients files (Anti Cheat Purpose)? Or has I understood this all wrong? Anyway awesome just awesome.

Negative, My test with fraps benchmark from the ingame campaign video for 60 sec. Run 6 times - this way: 1. no override (this is the default) 2. same as above 3. pixel & vertex shader 2.0 forced 4. same as above 5. pixel shader 2.0 foreced (vertex to no override) 6. same as above My result show no difference what so ever. If there had been a difference I would have been suprised. Arma use pixel shader 2.0 as default, so forcing it should not magical do anything. How did you measure your framerate improvment? Links: http://en.wikipedia.org/wiki....Shaders My spec E6600 clocked from 266 to 333FSB GTX 8800 2GB ram edit typo

I havent played Shark Attac's missions with others yet, but my first impression of the missions is very good. Only one nag, why is there an addon tag "@" in the pbo filename. In the readme it is stated that the missions do not requiere addons of any kind. Example: "c12@-Especas-Commando-v3.Sara" Check out Celery's Mission name standard: http://www.flashpoint1985.com/cgi-bin....t=65344 Ok following the standard is not mandatory, but it keeps the OFP and ARMA gaming life simpler. Keep the good missions coming Shark Attac Â

Hi community, To ensure the quality of coop missions, I like to share the  criterias my clan NoPryl try to review missions after. It's difficult to say a lot about what a good mission is. It’s easier to state what a good mission normally not contain. It may help in making better missions. I will update the list, if new good point comes in. I also will consider deleting from the list if good arguments come forward. Criterias: 1. No Kill Them All: A good Coop mission should not be based on "the kill them all" concept. * Running down AI solders who has fled the area is a show stopper. * The need for checking large urban or forest areas for living AI soldiers is also considered unnecessary. 2. Clear objectives The missions should have one or more clear objectives, described in the mission plan. Normally it should be known where in the map your team start from. 3. Working triggers A finished missions should not have serious trigger errors. This is crucial for objective ending triggers. In public beta maps this should also be considered a bug who deserves attention. 4. Transport time/distance It should not be required to be in transport for more than 10 minutes before the action starts. 5. Dynamic AI AI behavior should be dynamic. If more than 50% of the AI stays in one spot during the mission, it will normally be considered "not good". 6. Loadout Mission where you can choose from all the weapons produced in the game will normally be considered to have a serious design flaw. 7. Cutscenes Don't make Long unskippable cutscenes (esp in MP) - Orlok Template for validating: Info Mission name pbo name <file name> Description Number of players & side Criterias 1 - 6 passed or not 1. passed 2. passed 3. etc .. 6. failed ... Conclusion The mission is ..... The option to choose between all weapons in this mission is considered a nice feature, because... Passed"" YYYYMMDD - <name>