Donnervogel

it's nice to see someone doing some Swiss weaponry but when you aim the Stgw90 (I think SIG 550) with iron sights it will look somewhat like this (forgive my horrible photoshop skills). I tried to make pictures with my rifle but my camera can't be persuaded to focus on the right spot

What about the fact that the game is too demanding for it? Nah seriously. I don't know if you have vewidistance at max or not but considering it took about 3 or more years after the release of OFP until computers were available that could play the game with max settings (including maxed out viewdistance) and even then the performance was rather bad I would not assume arma has been developed so that you can play it fluently with everything maxed out with any computer currently available.

For new type scripts this limitation shouldn't appear anymore since build 5134. i can confirm that with ArmA version 1.05 (build 5136), the limit is either gone, or much much more higher. I succesfully tested it with 2000000 iterations (could do much more, but i am happy with 2000000). oh that is cool.

does anyone of you actually try not playing on high or very high settings? I just wonder because I play on a computer barely reaching the minimal specs for arma and those sorts of things I get when I set my graphical settings too high or when there are too many units in an area. I know this is not a permanent "solution" but you might be able to play the game with 1.5 (and thus online) it just won't look as pretty until those performance issues get sorted out.

well the while command has a limit of 10000 iterations then it will exit automatically. With an FPS count of about 20 this will run about 8 Minutes then. To overcome this limit use either double while loops (will exit after 10000^2 iterations --> about 58 days with 20 FPS) or use a for loops like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">for [{_i = 0},{_i < 1},{_i = _i}] do { }; (I don't know for sure if this for loop will exit at one point or not but I never played long enough to reach such a point so it seems to run forever)

well the performance drops are most likely due to graphical engine changes. You can't edit those normally since they are hardcoded. Same for the weapon sight movement I would assume. They certainly don't have anything to do with the new weapons/units. I don't know about the new weapon sights but you can disable it by putting the "floating zone" setting in your controls option all to the left. But I never noticed any performance difference when adjusting that setting so it most likely isn't the root of your problems.

I noticed the sound (especially volume) of all sounds in Arma depend A LOT on your sound hardware and if you have enabled and disabled hardware acceleration. For some people it gets louder with hardware acceleration and for me it gets less loud then. For me it sounds best with hardware acceleration disabled. (I don't have EAX at all so that is disabled too). I suggest you play around with these settings if you have trouble. Especially with the volumes of the sounds. Btw. I love these sounds

I tried to add new entries in the config but as expected they have no effect. The possible key bindings (in the controls menu) seem to be hardcoded. What Kegetys used is displaySetEventHandler but afaik they only work when there is no user input on the unit one is controling (like when there are dialogs).

heh I get barley 23-25 FPS on rahmadi... with everything very low --> 20 FPS on sahrani = joy

Well the 'problem' is that most people that have seen better performance or no noticeable change do not spam the forums with it I have seen much better performance compared to 1.02 on my very low end system (I barely reach the minimum requirements). compared to 1.04 the performance is slightly worse when loading the game or loading islands but nothing noticeable ingame (I mean performance is crap for me anyway but it got better than with 1.02 ) I have heard a number of reports from people that say 1.05 increased their performance a lot. IMHO you just hear a lot of people posting here that have problems while the people being happy with the patch usually stay out of here because they are busy playing the game. Personally I'm very happy with the latest patch. Obviously there's still much to do but I am happy to see BIS addressing the issues and introducing new features like the new iron sights which made it almost a completely different game for infantry.

well it is exactly the point. It is solving your problem in a (slightly) different manner. Instead of passing the variable names to script you would be passing the data (may it be whatever you wish it to be) to specific location that the child processes check for information. You can fully control dynamic numbers of child processes and it's easy too once the system is in place. You have a control script and various executing scripts. Each script can run independently and in many parallel instances. It is just important that the control script keeps track of all running processes so it can pass out the data accordingly. EDIT: but it is rather complex to set up so if you don't need such flexibility you can pass variable names as strings directly to the scripts as others have suggested.

well the method with global arrays containing the information and a control script managing the array worked flawlessly in MP with the according publicvariable stuff. Haven't tried it in Arma yet but I see no reason why it wouldn't work. It's just rather complicated to write such a system.

If you enter animations into the init line they don't work. I assume it's because your animations get overwritten by the default animations for the unit during the init-phase. It should work though if you give the unit a name and execute the animation from a trigger or a waypoint. Give the unit a move waypoint on it's position and enter the code into the on activation field of the unit. then the unit won't move and the animation will work. You need to refer to the unit by it's name then and not with "this" though.

There are no reference variables (pointers if you will) in ArmA scripting language to my knowledge. If you don't want tons of global variables and want them to be expandable use global arrays (arrays can be of mixed type and contain other arrays as well and the arrays can be asymmetric). If you have dynamically created processes you will need to write a control script to manage the array accordingly and pass the script the elements of the arrays that are reserved for them. I have done this in OFP already so it is certainly doable. But it's not the easiest thing to do. Maybe someone else has a better solution. EDIT: Oh forgot this. Array indetifiers contain a reference to their array. Maybe you could exploit this for your needs. I haven't tested this yet fully but if I remember right then when you do _a = [1,2,3]; _b = _a; and then you edit _b the changes also affect _a and vice versa.

I have done the testing with both objects that respond to ingame physics and such that don't. The problem applies with them all. Besides the extreme situations would even with the physics lead to great changes in position so it should be visible anyway. I have tracked down the situation when the problem applies pretty well I think so BIS knows what to look for. I don't see any difficulty there. What indicates a bug is that you *can* set the up Vector to [0,1,0] but you need to set it to some other z-value directly before or it it won't work. This IMHO is a clear indication of a bug because I can't think of such a behaviour to be wanted. concerning vectorUp. It returns normalised vectors. Those are (ignoring rounding errors) equivalent values to what you set.

ok so today I was playing around with those commands and I came across some weird things. I'm not 100% sure if they are bugs and which of them would be bugs so I thought I'd discuss it here first. Problem 1: when I use the command setVectorUp [0,1,0] from what I know about this it should result in an up vector that points straight along the y-axis, translated ingame, it should set the object rotated 90° along the x-axis. Now in effect nothing happens. This puzzled me. Then I discovered if I use the same command twice after each other it works as it should. I'd guess this is a bug. Problem 2: [EDIT]: Ok the second problem has solved itself, it was an error on my side still the first remains.

yes you need to add the line <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">myUnit playMove "AmovPercMstpSnonWnonDnon_talking" to a Waypoint in the on activation field. When the waypoint is activated the unit named myUnit will start the animation. it works the same way for a trigger

yes according to the list. I did not test it myself so I can't say if the list is correct But that's the way to read it.

Biki: switchMove the command: unit switchMove "nameOfAnimation"; the list of available animations is here The description you are puzzled about is simply telling you, that a "p" in the table indicates to use the animation with the command playMove and an "s" indicates to use switchMove.

Accurately rotate an object, around all three of it's axis, is trivial? The functionality provided by those commands, has been request\sought almost constantly prior to Arma. I appreciate it might be boring for you, seen as you find the concept trivial and of an intermediate level. But why don't you drop by that thread and fill us in, on the details of 3D transforms and all the Maths behind it all? I’m sure everyone would appreciate your advanced knowledge on the subject. No, I don't think it is a bug I would prefer to be able to control objects properly in all directions, rather than just slap in a couple of numbers via the editor, like [0,0,1]. Perhaps you should just add a request on the wish list, for some simple commands like PointObjectUp PointObjectDown e.t.c ? eh what is wrong with you? I didn't say the other thread was stupid. I said trivial because it is trivial. That doesn't mean it's stupid. It's good actually so people can inform themself about how it works. I just didn't want to clutter up the discussion about how it works with a discussion about some very special things that I have not confirmed totally yet. Perhaps you don't understand what I am saying. I don't want a command to point an Object up, down whatever. I want to find out why the scripting command does not work as I would expect it.... hence why some values don't seem to work and if it is a bug. I am rotating objects all the time and it seems to work properly with all values in between. But I ran into those anomalies with the extreme values under some conditions. I think this is a bug and if it is it would be good if BIS would fix it, don't you agree? Or do you want a command to not work as it should?

I did not miss that thread. That thread discusses how setVectorUp/Dir works and deals with trivial things about vector geometry. I was asking something else here. Trying to find out if this is a bug. Anyway I reported it already as a bug so let's see what BIS does with it. I found those three things: - you cannot seem to set the up vector to [0,0,1] at all. - you can't set the up vector to [0,1,0] but there is a workaround by setting it first to some value that has a z value other than 0 ([0,1,z!=0]) and right after this setting it to [0,1,0] then it does work for some unknown reason. - you can set the up vector to [1,0,0] with no problem. Note that the 1 can be any value other than 0.The problem appears with the cases when the vector is pointing straight along one of the axis' of the coordinate system. Also note that the command vectorUp doesn't return the values you have set but always a value between -1 and 1 which seems to represent the equivalent values on the unit circle.

Which is what I did not say. I think I have said it in previous postings already that you need to differ from financial returns made from the investment (which are not calculated because they are generated in a foreign economy) and financial compensation for "exporting" a "service" (which is calculated because the service is based in the domestic economy). But I really don't have the time to start repeating myself over and over again. Stop laying things in my mouth that I did not say please, because it kinda "forces" me to respond. Anyway if we can't agree I suggest we drop it. It is not serving any purpose to the current discussion here and as I said I am busy with other things. Actually I just drop by to see if they finally released the Arma patch...

"you might notice" that you didn't understand it - again. Anyway I'm in the middle of my exams atm. I don't have time for this now. Have fun.

I'm not so concerned about US servicemen/women that at least had the free choice of becoming puppets of their government. I'm more concerned about the people that died and had no choice to avoid the situation.

this only proves that you found one entry that was - according to your undocumented statement - wrong. Drawing conclusions from this on the reliability of Wikipedia as a whole is totally wrong. Having said that. Did you correct the entry and documented the sources of your information? If no I strongly suggest you to do so or at least start a discussion about the topic for that article. That Wikipedia can be edited by anyone is both its strength and its weakness. However I have made the experience that the majority of articles I visited contains reliable information and an increasing number of articles is documenting its sources. Now I cannot draw conclusions from this on the reliability of Wikipedia as a whole but when the articles fulfil certain quality conditions I must say that those articles can be used as sources without problem. I have seen scientific papers with much more shady sources... Also a source doesn't mean it must be correct. A source simply shows others where your information comes from. Be it wrong or false. Therefore I strongly encourage everyone to provide sources. Also Wikipedia sources. The advantage of this is that others can check this information - also by following the sources of the source.