Rune

I stumbled on this by accident, don't really keep up on OFP and havent done so for a couple of years. Both SoW 1 and 2 were for OFP SoW 1 worked, but had a lot of problems, one being very slow loading and saving times. 2.0 was a big improvement but still was incompatible with "super AI" IIRC. SoW 2.1 is the oldest version anyone should be using and I believe we had at least a 2.2 release at some point but it is so long ago I can't be sure. Anyway, anything from 2.1 and up is far better and solved many problems and is both faster, safer and more maintainable. I've looked through my old backups of OFP stuff but I can't find any version of CCE, unfortunately I think I binned some OFP CDROMs not so long ago and the latest CCE and SoW releases may have been in there...Too bad the SoW site is down, all references point to it

Unfortunately we at SoW couldn't imagine ArmA not eventually giving us even better options for saving in multiplayer than OFP ever had and abandoned OFP for ArmA. But saving in multiplayer never came to be in ArmA and we grew tired of waiting for the game to be 'fixed'. Eventually we just gave up on editing entirely since ArmA never really matured to be of much editing use to our corner of the community, unfortunately I think that is also part of the reason why this sort of mission is much rarer for ArmA than it was for OFP, the editors simply weren't given the right tools to make them and any progress made seemed to be more about flashy addons and effects Â

Community is fairly small on the player side of things, but you will still meet a lot of new people every day online. The main strength in terms of size is of the modding and mission making community, which is huge compared to all the games I know that someone might call similar, and this means that ArmA is a totally new experience every time you want one. It's been a while since I looked at AA, but when I did the differences where huge in online play and I was pretty disappointed by it after the quite immersive training. The general attitude in online games is much better in OFP/ArmA, games are much much more varied, much bigger scale and much more realistic. One thing that helps a lot in getting good experiences in online play with ArmA is that fact that the community is more mature in their behaviour, not everyone but most. And another thing that helps a lot is that there are more missions and more dynamic missions, this helps people not to get bored and behave like idiots and it helps them not become overly adapted to particular missions - AA was from memory a circus of beyond visible range machinegun fire and total inability to hide by camouflage because everyone knows exactly what that particular bush is supposed to look like and so on, ArmA is none of that - unless you seek it out

Since OFP came out I have gone through several periods of 100% playing and others of 99% mission making. As OFP matured I was around 95% editor for a couple of years until ArmA came out. With ArmA out I started as I had been going with OFP at 95% editing, but quickly got fed up with it...it needs some stable time after getting some bugs fixed, features added, a few addons to fill in some gaps as well as the community to realise that not all missions are supposed to be Evolution-killers - I miss the times when there was always something new and interesting going on for the small co-op crowd, or maybe I am just missing a good place to find missions... - anyway I am only a player these days, but one who really really misses editing

I am using almost the default AWSD setup, if I remember it correctly, with A/D for roll, W/S for pitch Q/Z for collective and X/C for tail rotor. I did change one thing though, since at least the default I started with, had the A/D keys asssigned to something called 'Left Turn'/'Right Turn' or somesuch nonsense that combines tail rotor input with cyclic roll input, but I could not do anything useful with that setup. So I reassigned A/D to 'Bank Left'/'Bank Right' instead and that works out very nice About time spent training I can't really say precisely, but I am pretty sure I have spent a good deal more than 20 hours of extremely risky flying and crashing offline mainly playing around with the littlebirds simply because I enjoy flying them so much and at least twice that flying online with passengers in Evolution in a much more conservative manner...

Have you ever seen a dog in a yard that keeps on barking aggressively every time someone walks past. Why does it do that when they just walk past. Well, maybe because it assumes it has caused the person to leave again. If so, the dog is barking because it has made a bad assumption, just like you have if you assume that flying well means someone is using a joystick ...so I must ask, have you asked all the people you see flying well what controls they use? If you saw me flying online you might simply conclude that I was flying with a joystick, but I am actually flying with mouse and keyboard...and that is despite the fact that I have a high-quality HOTAS hooked up that I use, among other things, for flying planes in ArmA and helicopters in FSX, but never helicopters in ArmA - because I find the mouse + keyboard extremely good for flying helicopters in ArmA. I can pick up or drop off people at the top of roofs, scafolding or smokestacks, if need be, and be in and out in less than a minute. I can fly consistently at 3m altitude between bushes, under bridges and under powerlines when flying NOE and I can fly max speed consistently under 20m when contour chasing. Slowing down without balloning and landing accurately is very very basic stuff compared to all that so don't tell me I couldn't possibly fly as well as the people who use sticks...just like the good joystick flyers don't want to be judged based on how I fly with a stick I don't want to be assumed to be using a stick just because YOU can't fly like that without one... I AM, of course, affected by the 'impulse' movement with the mouse and it did take some getting used to coming from OFP, but I hardly notice it now. I am also somewhat limited by the on/off nature of keyboard keys, but the mouse + keyboard control setup is worth all that for me. When ever I do hard maneuvers like a roll, loop or hard break turn to slow down I use the keys for roll and pitch control and the mouse is used for the finer maneuvering. I also use keys to tie-over when I have to lift and center the mouse for a moment allowing me to fly much smoother circles with mouse and keyboard than I can with a joystick. I tested out flying with mouse and throttle controller because someone suggested this setup, but I found that the lack of access to the pitch and roll key-controls made it impractical for me...I would try putting that on the HOTAS throttle hat switch if it worked with ArmA, but sadly it doesn't at the moment. About changing the impulse mouse control system, I don't neccesarily think it is a bad idea, but I would ONLY find it a benefit if it truely did not change the way the helicopters fly. I know people will think this is part of the flight model that should no be changed, but changing the controls CAN introduce problems on their own, like having controls in an extreme position at takeoff with no way of knowing where the cyclic is before you are in the air and opside down...A mouse has no natural center and this makes it a fundamentally different controller than either a joystick or the real life flight controls and people don't seem to appreciate that it could need special treatment to work well.

I have written a .pdf document to serve as an introduction to finite state machines in Armed Assault. It covers just about everything we know at the Sinews of War mod, the only things not included are some very recent testing from ArmA versions 1.06/1.07 that I have yet to absorb and play around with before I can write about them, but that information will be included in the future. The document also has a couple of FSM example missions with thorough walkthroughs that should be quite informative to beginners and experts alike. These are the main goals of the document: 1) To provide the easiest possible way into the world of FSMs for someone new to FSMs. 2) To quide people to make more dynamic and varied missions. 3) To provide a look up, fact sheet or memory refresher-style ressource for more advanced users. Right now the FSM material included, that is relevant to addons makers, is limited. This is because of a general lack of available information and the fact that my testing has started 'at the opposite end' of the FSM spectrum. That is I have been trying to learn the information that is more relevant mission makers first. Everything needs to be tested before anything much can be written and it is a lot of work. But the intention is to cover all ArmA FSM material eventually. But to do this I need your help to fill in the blanks, please help me improve the document, even if just by asking questions that makes inspire someone to perform a test that could uncover something interesting. The document can be downloaded at Sinews of War under Downloads -> Tutorials. I hope you find it useful... And you can email me at rune@sinewsofwar.com or PM me in this forum if you have any comments

This bit made me remember how little I liked the ArmA helicopters for the first couple of hours I was flying them. Maybe players with 0 to 2 hours of flying time in ArmA were somewhat overrepresented in your 'sample group' when you formed your impression about how many people genuinely and permanently dislike the ArmA helicopters ...anyway, just a thought.

Warning - might be a boring read for some... Actually, as long as we are not talking about something overly fancy, like relativistic effects of rotation or the gravity field produced by the helicopter or consider the earths gravity field to be in-homogenous the "center of mass" is the same thing as "center of gravity", only "center of mass" is less ambiguous and more correct in most respects. Yeah the good old Sir Isaac, poor simple-minded git(sarcasm) - I disagree since many people have a general idea about basic mechanics and their common sense as well as mine include that... I am sorry, but it sounds like you got the basic physics wrong, the torque is never in the 'plane of the rotor disc' save for the unlikely case of the center of mass being in that plane also - in the rotorhead - no manned helicopter I've seen could possibly have that. What happens is that the +A and -A forces you are talking about effectively break up into seperate components. Some acting as torque against the moment of inertia to cause rotation, this is the portion perpedicular to the line passing the center of mass and the point at which the force acts on the helicopter. And then the remaining componet of translatory force that acts against the inertial mass of the helicopter to cause translatory motion. Like said before anyone can claim to be anything so I can't expect anyone to trust me on this based on what I claim to be, but rather from my arguments and whatever knowledge I am displaying in the process. I do consider myself fairly decently schooled in the newtonian mechanics involved in the rotation discussion. If I didn't I would not have posted about it...I do not know nearly as much about aerodynamics though, BUT I DO KNOW that no possible content of aerodynamic science can overule or void the truth in newtonion mechanics, aerodynamics is a specialisation, not a different field as such....It all comes down to how accurately you want to model something. If you break it down into increments where each increment makes the model match the real thing a little bit better you would have the first bits included in EVERY further increment going towards more complex models - you don't start over as you start to use aerodynamics, you ADD the effects by putting more detailed forces into the original(newtonian) model of motion. In essence, if you have three flight models of differing complexity and detail, say, "simplistic"(1), "slightly more advanced"(2) and "very detailed"(3): (1) would consist of basic newtonian motion, including rotation about the center of mass. It would include the force of gravity and the forces exerted by the rotors corresponding to command inputs obviously. (2) would consist of (1) possibly with more detail in the composition of the forces and add on some aerodynamic effects such as drag and tail-'fin'-forces. (3) would consist of (2) and detail or add on even more of the more exotic aerodynamic forces involved in real flight, like the dynamic lift of the fuselage and rotor disc at speed, ground effect and so on. - Through all of this, ALL motion would be most accurately modelled and described as a combination of rotation about the center of mass and translatory motion of the center of mass. Only reserveations are, one, that the center of mass of a real helicopter may change with fuel state, load and utimately with where the pilot is looking if you take explicit account of his nose being displaced from it original position And, two, that rotation may still APPEAR to be around other, un-fixed in terms of 3D model, points in practice because of the effect of counteracting forces or forces that break up into force vectors that mix translatory-motion inducing and torque-inducing forces - the percussion center effect mentioned. But the percussion center effect will not need to be explicitly programmed, it follows from the laws of motion, if the forces are detailed enough. In the end there is no sane way to model all this 'correctly' by picking another point of rotation than the center of mass - that is why I conclude that the rotation about the center of mass is just about the most basic thing to get right in any decent flight model. And it would be a bad mistake to build an 'improved' flight model on the wrong center of rotation - assuming still that the point of rotation is a fixed position that is part of the helicopter 3D model and assuming that BIS has contructed the flight model with some basis in real physics rather than approaching it from an 'animation' point of view EDIT: By the way I have not really noticed all this center of rotation business from inside the helicopter...is everyone complainging about it sure it is not just a matter of where the camera is pointing from the outside views

Overall I agree with what Plaintiff1 said in the previous post, I cannot echo the impression that a high proportion of players are unhappy about the overall changes in flight model from OFP to ArmA at all. Most people seem to be either happier with it or unhappy with a few very specific and fixable things - like the tail rotor 'power'. Or they have spent less than 2 hours flying helicopters in the more recent ArmA versions... Other than that I feel the urge to sum up the discussion of rotation more clearly as I see it, because it seems the above post does not reach or use the correct conclusion. If BIS were indeed to move some fixed rotation-point built into the 3D model of the helicopter to ANY other position other than the present one, it would HAVE TO BE - EXCLUSIVELY the best guess for the real life center of mass of the helicopter and nowhere else...the impression that the rotation occurs at a higher point is caused by the effects of gravity acting against lift of the rotor when the forces are not parallel. In fact, the present, dodgy, rotation modelling could be cause by the model CG being placed at the rotorhead from what I've seen, making it appear even higher up...

Unfortunately it seems the old OFP multiplayer saving trick does not work in ArmA Let's just hope the reason is that BI are going to provide proper saving in multiplayer in some later patch and want to spare us the grief of switching to a new implementation when that happens...

In OFP you could go quite a long way, through scripting alone, towards making a system to prevent bad pilots from ruining other people's fun. But it requires saving and loading data in multiplayer, which currently does not work in ArmA (except for using some sort of external tool and a process that could well break down with each ArmA patch) If there was some scripting option like in OFP, you could do it in many ways, like the suggested certification-missions that you had to pass before flying online in missions that supported the system. Or you could use some direct performance based system of blocking players from acting as pilots if they crashed too much. You could even make a voting system, open only to passengers to rate their pilot, potentially grounding him based on that rating. You could also just make a simple hint that pops up as you board a helicopter, letting you know how many passengers have died flying with this pilot, on average, per hour of flying or something like that... Obviously such a system would be a nicer and better integrated feature if it was developed as a 'real' feature of the game itself by BI, but they only need to open up a couple of commands for use in multiplayer to allow some form of community-made solution so for them that should be the easiest way to make their game much greater... ...Yet another reason to want saving in multiplayer to work in ArmA

Absolutely true and it will work that way in a flight model automatically if the right forces, corresponding to the real ones, and the right center of gravity position is used to compose the fligh model About the difficulty level, I really don't see why you can't have a 'real' simulation of helicopter flight and make it easy for the guys who are not sim geeks or real life pilots. There is no need to compromise between the two in my opinion...all you have to do is add the 'easy mode' on as a sort of control limiter system... Falcon 4: Allied Force has something like that for aerial refuelling, where they 'filter' the control input from the player before applying it to the simulated plane to gain maximum realism while also making it possible for more than a handfull of people, who practice it every other day, to do aerial refuelling - and it works beautifully For ArmA helicopters this might be done by adding a series of small 'limiters' not unlike what you have in some aircraft using fly-by-wire control systems. You could prevent bad pilots from loosing altitude unexpectedly and crashing by filtering out control inputs that lead to getting the rotor at an angle where it cannot support the weight of the helicopter. Or you could prevent people from crashing due to retreating blade stall by filtering out control input that will lead to too high speeds. Same principle applies to other strangenesses of helicopter flight, you could assist the pilot in cancelling them out or staying within parameters where they do not occur when applicable. You could even introduce the automatic terrain following cyclic behaviour if that is deemed helpful for players without the skills to fly the realistic mode. The benefit of doing it this way are several, for one you only have one flight model to tweak to perfection, the easy mode would work on top of it without much attention, if the limits are built with enough margin in them - that is, if they are 'limiting enough' to keep you well out of trouble even after a flight model tweak. There would be no silly discussions about which flight model to put in this or that addon or use on a particular server because everyone would fly with the most realistic one, but some would just choose to fly in the safe subset of control possibilities. This would mean that the truely skilled pilots could fly faster and make rougher maneuvers and such things, making their skill truely useful without taking away the option for everyone else to fly the helicopters.

You were somewhat unclear then I took what you said about 'transmitting' to mean that running setPos on one machine would not update the others. Not that it would do nothing locally. The scripting I suggested was to work around the bug I understood it to be...sorry to hear that it is an even worse bug than that

For a scriptbased solution like the original one, though: If Celery is correct that this is only about not transmitting the new position after a 'setPos' in multiplayer, then all you have to do is randomize the number on the server and publicVariable it to clients before working out which position has been selected. For instance like below in your init.sqs(disclaimer: untested code and requires logic on map with name "Server"). <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">... MyTag_aleatiore = -1 if (local Server) then {MyTag_aleatoire = random 25; publicVariable MyTag_aleatoire;} @(MyTag_alaetiore != -1) if(MyTag_aleatoire < 5) then {_x setpos getpos pos1;} if(MyTag_aleatoire < 10) then {_x setpos getpos pos2;} if(MyTag_aleatoire < 15) then {_x setpos getpos pos3;} if(MyTag_aleatoire < 20) then {_x setpos getpos pos4;} if(MyTag_aleatoire < 26) then {_x setpos getpos pos5:} lieue=true publicVariable"lieue" ...