baddo

That script is definitely not written correctly... First mistake: you are assigning values to _west and _east two times for each in the start of the script. I don't know what you pass for the script but it is gone pretty quickly. Second mistake: you try to compare the distance of the _west and _east arrays. That won't work. You must compare the distance of individual objects (soldiers). Third mistake: you are trying to make the arrays _west and _east say something. That won't work. You must make an individual unit say something. I think the thing that you have missed here is how to pick stuff from an array. Let me give you a short example: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _west = [w1, w2, w3] (_west select 0) say "us01" (_west select 1) say "us01" (_west select 2) say "us01" This piece of code will make first w1 say "us01" and then w2 and w3 do the same thing. First item in an array is selected with 0. So with select you use an index number of 0...n-1 where n is the number of items in the array.

Well the Official ComRef says for OFP 1.85, that where a boolean value is expected, undefined value(variable) results as false. That can be understood only in one way, and that's what I explained in my previous post. I can say for sure when testing for a true condition this works in OFP. The trigger will not execute until the variable is introduced and given a value of true. I can't access ArmA now but I will verify this to be true for ArmA too when I have the chance to do so. About looking at other peoples' scripts: it is, from time to time, great to look at what other people are doing. But about initializing all global variables in mission start, it really is not necessary for me to start learning about it from others. It is a good practice (sometimes even technically required, but not always) and I actually learnt how to do that without reading it from some other peoples' scripts. I've written all mission-specific global variables into top of init.sqs and by the way, I put comments next to them about where their values are changed and where their values are checked. That makes editing a mission quite a lot of easier, as I can look at the mission one year from now on and immediately know where the global variables are used.

Oh, sorry I didn't notice you actually said your CD drive broke before you got OFP. One possibility: can you temporarily attach an external CD drive to your laptop? You could then install OFP, patch it to 1.96 and you wouldn't need the CD drive after that. Another possibility would be to take the hard disk drive out of your laptop, attach it to some other computer, install OFP & patch to 1.96, then put the hard disk drive back to your own laptop. This is for sure not going to be as easy as the first possibility and can actually have problems like your laptop's operating system and the hardware on the other computer not playing well together. I can't comment on making images out of the original CD's.

Yes in SQS put it into one line and it works. If you don't want to do that then just use SQF. This "one line" style is very okay for relatively short statements, I've used them like that many times and it can even be better for readability to not spread a short statement to multiple lines, even if using SQF.

Upgrade your legal copy of the game to version 1.96. Patch can be found from http://www.flashpoint1985.com/

Official Command Reference for Operation Flashpoint 1.85 states that if a boolean variable used in a condition statement is undefined, the result is false. And it actually works like that in Operation Flashpoint. I bet, without specifically testing it in ArmA, that it works the same in ArmA too as I see there is no reason for BIS to change this behaviour. And global variables can be initialized in triggers. We don't know if this is for single player or for multiplayer as the topic starter doesn't say it. If we get more information from the topic starter we could maybe see where the problem is. Now that I look at the first post, I really can't say what is going wrong.

Event handlers are in general believed to be more efficient but they can be misused so that performance can suffer greatly. An example of misusing event handlers is to execute a long and heavy script from a "fired" event handler every single time the event handler executes. Think about what happens when all the units that have this kind of event handler engage in a firefight with their weapons on automatic fire mode... In this kind of case it is not the fault of the event handlers if you don't get good performance, it is the fault of the person who scripted it so. I must add that you can in many cases put all the code directly into the event handler itself, so you need not to execute a script from the event handler. If your code is compatible with the function style scripting, you can try putting it in place of the code in the event handler line where you execute the "hide" script. I have a strong feeling that this must be more efficient than executing a script (but no research done to prove it).

Vilas, what happens if you leave everything as is but take their ammunition away? Do they still keep targeting? That would solve your problem if it works.

The Yugoslav wars of the 1990's would be interesting to experience in ArmA. Actually something that doesn't have USA in it would be good and refreshing. I voted for modern. But I have nothing against WW II -based mods. In OFP's FDF Mod there are modern-era and WW II -era troops. I enjoyed both but favoured more the modern theme as it is much closer to my time in the FDF.

Hehe, hehe. Hehe hehe, heh-hehe. Why some people get so uptight on these forums? Well one reason I can think of is that many people here think they didn't buy a game, but they bought something else instead, like a "almost VBS" simulation. Like they got a $1,500 product for only $40 or so. If you go and translate the word "game" into something completely different, then it is not a wonder anymore if you get annoyed and uptight and whatever else, as you have failed to see what kind of product you have bought. Yes there are plenty of bugs in ArmA that shouldn't have been there in the time of release. But that doesn't change the targeted nature of the product one bit. Get more revenue from annual license fees from gamers? Well it's a plan. Another thing is how would it work. I know for sure I am not going to pay any continuous fees for these kinds of products. I do that for the newspaper I read but not for computer games like ArmA. I know for sure I will keep on reading about what is going on in our society, but I am not at all sure if I will keep playing computer games for the rest of the year (there is, thankfully, so much more to life). I am sure people would be even more uptight here at these forums if they even payed an annual fee and then the game still does not satisfy their needs and unrealistic expectations. Concentrate on a smaller-scale game and do it better? Well that could work in reducing the number of bugs in the released version, but it could also shrink the games to a level where they are thrown away after 3 months of playing. That's not what we want, I think we can agree on this. So again, this could cause people getting even more uptight here at these forums, as they thought they were buying a game of the same scale as OFP, or even better (as ArmA actually is). Just imagine the outbursts of people who played OFP/ArmA when they would realize BIS changed drastically their vision of what kind of games they develop, how uptight would that make people here? I made a quick and rough calculation of how much community members we have compared to the sales of OFP. According to http://www.codemasters.com/, OFP was sold at least a million copies. As of today, Bohemia Interactive Forums, OFPEC Forum, OFP.Info Forum and Armed Assault Info Forums have a total of 69,401 registered members (this value is inaccurately high as it includes many members that have registered to more than one of these forums). Now by doing a calculation we can find that out of the one million OFP copies sold, under 7 % of the buyers have registered themselfs onto the mentioned forums. That is a very small minority and it even doesn't take into account all the sales of the OFP series and the sales of ArmA. Even if we double the number of registered members in this calculation, and keep the sold copies at only one million, we are still under 14 %. I think we can say to a good accuracy that this means that a significant majority of people who bought OFP have not been involved in creating content for the game or modifying it. So, when you speak about creating content and modifying the games, bear in mind that you belong to a very small minority. This should put into some reasonable proportion your wishes and the wishes of the rest of the people who do not want to see the technical details. From now on, we should concentrate on how to make this forum a better place instead of arguying why it doesn't feel like a good place. How to reduce the uptightyness. How to make people smile more. How to make people actually feel that this is a friendly place to be. I am starting this movement by going outside my house, there is a nice flower growing there. I will look at the flower for at least 5 minutes and only then I allow myself to come back and, perhaps, use the computer. I recommend others find some similar means to reduce their uptightyness.

...and BIS is one of them. They are selling a game to us via publishers. They are not selling just a game engine in the package that says "ArmA". There is a significant difference and to be honest with you, I think you didn't yet understand this difference. It's quite radical to tell BIS to fire their workers, don't you think? They are creating a game, their primary target is not to provide you a game engine + documentation which you can then use to build a game. I want a game that can actually be used for playing and having fun as first priority, right out-of-the-box, and I am absolutely sure the majority of people who buy ArmA agree with this. You are telling BIS to fire their workers who create content, and concentrate on the game engine and on the tools? For sure they will lose a lot of customers if they do that. It's great to be able to modify a game and even better if the developers of the game (or the copyright owners) are cool with it, and even provide support for the people who want to modify the game. BUT I want the game first, with content. A suggestion to fire the people who create the content is... not a good suggestion in my humble opinion. It would be interesting to see statistical analysis of how many of the people who bought OFP or ArmA have actually created content for them. My bet is that the portion who create content is a small minority of the total number of people who bought these games. Most people just want to play and have fun without going into the technical details of the game engine and the content.

I am sure you can buy a game engine from somewhere and develop a game on top of it as you wish. Go ahead and do it but don't drag me into it.

Well they are at war with each other, what do you expect them to do? Not fire when they feel threatened by the enemy? Luckily there is solution for your problem as was already described. This belongs more to Mission Editing than to Troubleshooting...

I am not disappointed. I have an old and slow computer and I didn't expect ArmA to even work on my computer. I was surprised that it even runs. So. I bet much of the crying on this forum is due to people buying top-of-the-line hardware, having their expectations skyrocket as a result, adjust graphic settings to high, then disappoint when their expectations of high frames-per-second were not fulfilled. Please notice, I left the numerous bugs in ArmA out of the previous paragraph. Just talking about performance problems not caused by bugs.

It will work. I play on 1.4 GHz, 768 MB RAM and GF 6600 GT 128 MB VRAM. It can get slow at times but in general it is playable. Just don't expect to be able to use the highest settings.

How animals are killed in Western countries? Yup the video is disturbing, cruel etc. But apparently the people do it for a living, not just for fun unlike in some Western sport fishing: Think about how cruel it is to catch a fish with a cruel, for sure painful method and then throw it back to the water. And then do it all over again. Now that is definitely something I have a problem with. I wouldn't have a problem with it if the fish were actually eaten but doing it for just fun, that is cruel. Then it's not about survival of the human beings anymore, but only about having fun.

I bet you put that script line into the initialization field of a unit. You should try to execute the script only for the unit (on your computer only if you are the cameraman) that should have it. I am sure currently you execute it for all participants. There are scripting commands that can help you with this.

Please familiarize yourself with http://www.ofpec.com/ too.

The most basic problem I have noticed here is that people read from other peoples' posts something they did not write into them. All fighting over something that even doesn't exist I am sure there are many, many other people too who feel that many of their posts have been misread or misunderstood, thus leading to completely unnecessary personal attacks and ridiculation. What can we do about it? I try to do my best to write in a style that cannot be misunderstood. Sometimes it is enough, sometimes it is not enough. I try to do my best to understand what others mean. Sometimes it is enough, sometimes it is not enough. One thing that adds to this problem is the fact that this is an international forum. I am sure the people who can use their native language have much easier time to read and write posts in English. They should be aware of this and be careful when they read posts that were written by people whoms native language is not English. Text can also have "colour". Often it unintentionally happens so that the colour we think our post has is not the same colour the native English speakers see. Please forgive us that.

If you have a problem with the design of Nvidia's SLI technique, inform Nvidia please, so they can make it better. It is true SLI does not double the amount of video RAM for applications. But I can only wonder how you can come up to a conclusion that this means SLI is a rip off? You must know the SLI technology very well if you start to claim such thing... Hmm... again, I wonder how you can draw such direct relation... OpenGL engine means at least 60 frames per second with your hardware? It doesn't matter what the application does? How much data is being pushed into the graphics card to render? It doesn't matter what else than graphics is being run at the same time? I think you are just angry now and make up angry statements without giving them much thought. Please cool down so people here can help you tune your settings so that you become more satisfied with the performance you get

...but I have a very slow computer, and you know what? I am happy that I can run ArmA at all! Maybe this has something to do what your expectations are and what the reality is. My expectations were very, very low when I got ArmA: I knew my computer does not fulfill min. requirements, then I was positively surprised that I got ArmA even running! And I thought i would have to buy a new computer! Maybe I will save my money for something else now, if I can play ArmA with this old and slow computer... You were negatively surprised as you have a monster computer and your expectations were much higher than mine, thus you are disappointed while I am not. Cheers, Baddo.

Yup that surely helps One way I used a while ago in OFP to research the tide: just put a floating object to the sea and watch its height position change. In OFP you could set up a script that uses fwatch so you can write the height position value to a file, for analysis in for example a spreadsheet application (after a little cleaning for the data). For ArmA I am not aware of a working fwatch equivalent (maybe fwatch can easily be tweaked to work with ArmA). Better would be if BIS gave us some nice documents where this analysation has already been done.

Hi bardosy Well I actually came to the conclusion that your program requires JRE after trying the program on Linux/Wine (no JRE installed) and I got an error message: "Java Runtime Environment not found." After that I tested your program on Windows XP which has JRE installed, and the program worked. Now I confirmed that your program requires JRE on Windows XP by removing the Java Runtime Environment from Windows XP and tried your program again, and I get an error message, exactly the same that I got on Linux/Wine: "Java Runtime Environment not found." So, to sum it up: if I don't have JRE installed, your program won't run. When I installed JRE, your program runs. I noticed you have used program jar2Exe to create the executable file. From a quick read from http://www.regexlab.com/en/jar2exe/support.htm, it seems that the conversion made by jar2Exe does not remove the requirement of a JRE: I agree that it is ideologically better not to require people to install all kinds of runtime environments for small tools, but I also think that this is nothing big you should worry about. I just wished you would mention the JRE requirement to people who download the program so that there will be no negative surprises when trying to run the program. So to something else then. In my opinion this program can be useful to many people but only if it processes all files that can have localizable strings and it processes all string output statements. Otherwise the program is only useful if you follow some strict rules. This is understandable as you wrote this program initially for your own needs and didn't have to worry about what others are doing, until now. As a general rule, the program should look into every possible place where the localize command can be used. For starters, at least these string commands should be processed, as I think they are quite common: hint hintC hintCadet titleText cutText groupChat sideChat vehicleChat That would be a good start if you can cover those. Then there is the commands that can be used for dialogs. Now looking at this, I think it is not a small task to cover all the possible places where localizable strings can be... Also notice the comment about description.ext. Best Regards, Baddo.

So what kind of compatibility problems are you trying to fix?

There is an example in the OFP Grouplink II script pack.