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

Here is what I know about it so far, mostly from posts on this forum by Crashdome from Sinews Of War and some from my own experiments... I have learned surprisingly little searching the forums, which I admit could be me not finding rather than posts not existing... Everybody is always complaining about not having 'join in progress', especially for CTI and RTS. I've also heard many people complain that there is no campaign play in multiplayer. And then there is the problem of long co-op missions where you cant go back to the lobby to pick up people because it means starting all over... All of which might actually be possible. Saving information from one multiplayer game to the next IS possible no matter what is said officially. I'll take the optimistic point of view by assuming that all the problems can be fixed eventually - If anyone knows why any of this will not work please say so and why...That'll save us all some time. I know that this will never be 'perfect' to the degree of saving snapped trees, bullet holes and dead bodies lying at the same place, position and with same equipment present. But how important is that really? Could we reach something acceptable between that and restarting a CTI after 2 hours? These are the answers I have: The way it works is by exploiting the fact that some scripting commands that according to BIS do not work in multiplayer, actually do work - the useful one is saveStatus. saveStatus saves various pieces of information about a unit...Normally this is how the singleplayer campaigns remember stuff from one mission to the next, but it will not work the same way in multiplayer because only a few bits of it still work there. Damage can be saved, so can skill, but since super AI sets ALL skill to 100% that erases the data you are trying to save - leaving only damage really useable. Damage is stored as a real-number value ranging from 0-1 - which can easily be made to hold a positive integer up to 999999. SOW uses logic units to store data, but it should be possible for any unit. Check out Sinews Of War which as far as I know is the only thing out there that has any of this implemented. I'm looking for answers to questions like these: -Most importantly! Why has this not been done - Is it impossible? -Do logic units slow the game when used for this? -Is there a limit to the amount of data that can be stored? -What is the best way to load and save?(most efficient) -How would you encode vehicle types? -Encoding someone being mounted in something? -Encoding text(not that I know why it would be needed)? -What other things might we need to save? Anyone who has any facts on this please post them here to make them availabe in one place. ...Anything else?

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 [email protected] 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" ...

Sorry but I actually meant to say 'collective' keyboard input, like I said I never tried flying with mouse and a joystick throttle, but I'll try that in ArmA next time I'd test it myself also in OFP now that I am getting myself confused about it lol, but I unstalled OFP about a week ago to make space. And I suppose it is not impossible, if the instablility I am talking about is not reproducable for you, that I could have simply not flown anywhere near the 'danger zone' for a while in OFP and that the issue was fixed in a patch by OFP 1.96...

About the "I never implied that mouse / keyboard was incorrect", I think you sortof did because for someone not owning a joystick and keeping in mind that a joystick is not required for OFP, how would you 'correct' their control setup without them getting and using a joystick?...if they only have mouse and keyboard the use of keyboard cyclic(EDIT: was supposed to be collective) ensures the terrain following behaviour...or did I miss something? But I was just joking anyway, I didn't understand your post to mean that you seriously believed using any particular setup was wrong so just ignore my stupid comments  Anyway, Radic, I see what you are talking about I think, and you definitely have a point. Tell me, did you actually fly with joystick throttle and mouse, that setup possibility never occured to me until just now. I didn't do a lot af flying in OFP with a joystick, but I do remember now that you mention it, that the Kiowa in particular was less likely to flip over when flying with joystick. And the same was actually true of all planes, they would be VERY dangerous to go inverted in if you were flying with mouse and keyboard. So I guess it could well be that a lot of the difference I am feeling and that others are feeling is mainly due to a problem with the mouse controls in OFP ...So one major advantage to helicopters in ArmA could then be said to be the fact that mouse and joystick flyers now fly the same flight model. I personally like that I can change the controls to have pure bank in the sideways motion of the mouse, this enables me to fly sideways properly, something I could never do in OFP

Try using "moveTo" instead there is a known problem with "doMove". EDIT: "moveTo" is not "implemented yet" according to the wiki, but it is working for me in my very limited testing today... You can also try "setDestination".

Yeah, sorry Well it is just a guess at how it could seem to move from an aerodynamical point of view, or even when calculating aerodynamic stuff. The 'timescales' thing was about how long you observe something before making a conclusion about how it moves. The center of gravity point I made was, in principle, about very short periods of an object being subjected to torque - in such a case you can ignore all other forces acting on the object and say it rotates about the center of gravity. If on the the other hand you make, say, a long term averaging of a hovering helicopters motion, by 'drawing' a line in 3 dimensions directly along the main rotor axis through the rotor hub at each millisecond over an hour of hovering over a fixed point. you would then be able to average out some point above the rotor hub as a 'center of rotation' by virtue of it being the most frequent point of intersection of those lines...the helicopter would, on average have to tilt 'into' the desired hovering position a little or else it would float away, somewhat like a pendulum. BUT if you instead averaged the interections of the lines only with lines that were recorded 1 millisecond apart, then you could find that to be very near to the center of gravity - it is in that sense I say that timescale can be a factor

That sounds about right I objected only because you changed the frame of reference for the barrel roll exclusively. It is about the frame of reference and Newton's second law of motion and the timescales involved, like murderous did above, you can choose a coordinate system to put the center of rotation whereever you like, but for basic rotation to occur about something other than the center of gravity you would need to anchor it like a pendulum at the pivot point...needless to say air doesn't work like that What is happening at higher speeds in relation to the aerodynamic center is more a case of looking at longer timescales, and greater aerodynamic forces in relation to inertial mass, that make the the center of gravity point get lost in the more or less random drifting about that other forces cause...erm...I think  Haha yeah I know, it would be quite a different game if the gravity changed for everyone whenever a helo was slowing down

Flying with mouse and keyboard is NOT an incorrect control setup I thought the OFP flight model was pretty good actually, but the ArmA one is way better, and you missed a few important differences in my opinion. For instance an OFP helicopter would become radically unstable and flip around chaoticly under some circumstances at high bank angles or backwards/sideways flying causing it to flip inverted at unpredictable times unless you stayed well clear of the limits - basically to fly with a reasonable degree of safety you had to keep the rotor fairly horizontal at all times and only fly  backwards or sideways extremely slowly if at all. Also some real life manuevers where almost impossible to do in OFP(possibly again only when flying with mouse and keyboard) like popping in and out from cover behind a building by sideslipping, in fact the whole hovering experience seems much more responsive now.And murderous, ANY aircraft rotates about it's center of gravity while flying, always, even in a barrel roll - it's elementary physics likewise you REALLY wouldn't want BIS to double the gravity as a helicopter is slowing down, it would be much more sensible to reduce the lift at minimum collective Dont' get me wrong though, it makes a lot of sense to me what you are saying apart from that...

This is not really a general multiplayer mission thing in my opinion, it is a big/public server issue - in smaller games, with people you know, time limits can be pretty annoying. So I would suggest that rather than this plea being about all multiplayer missions, it is mainly about those intended for the bigger public servers without admins present...But I sort of agree in that many mission makers don't make up their mind about where their mission is supposed to be played, and many servers have missions on them that would work better in a different setup. It might be a good idea for mission makers to be more aware of the way their missions are intended to be played and include timelimits, or optional timelimits, when applicable.

You are entitled to your opinions, nihilistic and conflicting with common sense as they seem And you can speculate all you want about the numbers of people who would welcome multiplayer saving and the difficulty of implementing it, but in the end I see no reason, having read your posts carefully, to believe you have even the slightest clue about what it would take or indeed what I am even talking about in the first place...like I said 'communication issue'.

What a strange comment....true I suppose...but very strange and ideed true for quite a few things - like realism or fancy looking graphics for instance. We all want something, I happen to belong to a group of people who want better multiplayer campaigning... I am talking about giving mission makers more freedom to make the missions they want, plain and simple, why is that wrong I am wondering... ...'reasonable level of abstraction to be believable' is the key here. I may be pedantic in this area but I can't replace tank battles with chess and find it realistic, I can't believe in a long campaign of logistics or attrition if the world effectively resets everything every time I turn my back on it. Things can be made extremely open-ended in OFP/ArmA and there should be no reason to settle for less, the great thing about OFP/ArmA is that not being stuck in the tube, not performing a preset story like a lab rat, promotes creative thinking in tactical and strategic terms and also makes the game much less predictable - lots of running away in order not to get killed And if you are having an easy time you have done your tactics well and/or are about to be surprised - is that not the good life we all want Sorry you lost me with the rest of that post. It seems to me that we have some communication issue...Anyway, I just thought up a 'CTI-like' game-type for you who find dissimlar things to be so ...err...similar : Divide the island up into some number of possible frontlines, then make each fronline location a mission and 'number' the center one 0 and the others something like W1, W2,... and E1, E2,... and such to indicate how far back one side has pushed the other...each mission is then a meeting engagement with both sides starting a way back from the front but able to reach it in similar time, on average. Each time a mission is won by one side the frontline is moved correspondingly by selection of the next mission. The campaign winner would be the one that forces the other side all the way back over however many missions it takes...each mission could be balanced and all that. I'd play it and enjoy it I am sure, but the center missions could get quite boring after a while if they are not made to be pretty dynamic, and it would still not be a real campaign, without some form of saving, in my mind, because I've had much better already in OFP