0xDEADBEEF

I am sorry that I am not shoing empathy for those who want features they could get by simply choosing to use OB, but for those who have a ruined MP experience but no choice ... I think you missed my point. I am suggesting for future reference, not complaining that they did it. A fine line but big difference.

The mouse-cursor is very much sim-breaking. While I agree with you on no software is ever bugfree, with all due respect, I also agree with Slider. When I heard the news ED decided to push it to release due to "the results of internal and external testing" my jaw dropped. It was the first open beta i did not update because I had to stay with 1.5.4, but after listening to what the community reported about it I was glad I could not update, and I certainly did not expect ED to fix all that stuff in a week, not even considering the things that pop up as a sideeffect during a good amount of bugfixing. Really, it is better to keep a release in OB a week or two longer than necessary, than the other way around. There is little reason not to. I also agree with you on your second paragraph, the fast progress is amazing and highly appreciated. I can also share understanding that some bugs will crossover. But both don't rule out keeping a release in OB for another week, especially if the previous week had sim-breakers inside. A hotfix for the mouse-cursor during the week would be highly appreciated, to safe the communtiy some gray hair ;) That said, thank you for the work you put into this Bignewy :thumbup:

The _PLAYER_LEAVE unit event is back! Only noticed I am now receiving it, did not get to check yet if the data provided is also valid. Let's assume it is, this rather quick fix is very much appreciated!! :pilotfly:

Yes, I disagree. I do not know. I know this specifically because there was a crash where the pilot put the Helicopter into a 90°-bank right turn at low altitude, which he could not recover from due to this phenomenon. If you do a 90°-bank left hand turn you have enough right-stick-travel to roll out of the turn, if you do it right, you already need some left-stick-travel to compensate for the added collective that is needed to even perform such a turn and thus you end up having insufficient right-stick-travel to roll back out. Once you find yourself in that situation there is no way out. This was explained to me like this by a pilot who was part of the crash investigation team. Well, it sounded like you do. I still absolutely disagree on "not worth simulating". So, what about the Tailrotor not being aligned in the same plane as the rotor disk? Especially on the gazelle it is quite a bit below that, and that alone would cause a roll component even with simple vector math. If you wanna try mastbumping a robinson then yes, he should not even have taken off with you. But an instructor quitting a session after the student looses control should not be an instructor in the first place imho ;)

There you go, very nice info! thanks! Would not even have expected it to be that much roll... I know that pilot, and honestly would suspect that heavy left-bank nose-up attitude during the spinclimb is intentional to make the maneuver more "fun" for his passenger. While pressing right pedal all the way would require left cyclic to compensate for it, if you compensate more than needed, this is what it would look like (center of rotation away from the rotorhead, he does not spin in place and is essentially flying backwards).

Pedal input in any aircraft also induces a roll component, this is not exclusive to helicopters. But if you wanna try: go to your local airfield and try to get a dual-control ride in any helicopter you can get/afford. You will find just that, roll component by adding pedal input. Of course, the more input the more roll. if you barely apply pressure to the pedal you wont even notice your hand compensating for cyclic. If you go full pedal, you will notice a distinct compensation on cyclic very much necessary. Depending on your experience flying choppers your flight instructor may take over at this point ;) On a Sidenote: the Bo105 induces as a right-roll component if you add collective ;)

Please allow me to chime in here. Zeus, I do understand it is loads of work to change this now. However, having two missiles with the same identifier create huge problems for me in the Kaukasus Offensive. I am keeping statistics on everything happening on the server. So, also the Alamos sometimes come with different names ("R-27T (AA-10B)" vs "R-27T"), however, that identifier is always unique to one missile. The Mirage has one identifier (MATRA) for 2 missiles, which already causes problems for me, and I would not be suprised if it would not cause problems elsewhere. Please Zeus, I understand it is a LOT of work, but please please please change it!

I'd like to report this too. Tors are only engaging aircrafts.

The _ENTER_UNIT and _LEAVE_UNIT events are not working/not dispatched for clients. I solved it this way: the _BIRTH event is called once a player enters a unit. You can make sure it is a player by calling aircraftUnit:getPlayerName(), if it returns nil it is AI. As long as you get true on aircraftUnit:isExist() the player is actively in the aircraft. You may also wanna watch for _DIED _CRASHED and _EJECTED events as a substitute for the broken _LEAVE_UNIT event, as it is essentially the same end result.

I am glad you guys are taking feedback on the Flightmodel so serious. :noexpression: Like really, I have no words. I'm completely speachless about this reaction. Edit: Wait, I'll try the humorous approach as well. The Gazelle does not fly like a helicopter, so lets please not compare it to how other helicopters fly, ok?

We are turning in circles, over and over again. I am not saying and never have said "collective does not have inpact on the behavior of the Gazelle", I am saying collective has no influence on the pitch attitude, and pedals have no influence on the roll attitude, people even posted video showing that. I am not going to comment on real gazelle pilots saying it's close to the real deal, as it has been discussed sufficiently in this thread and in others (just look at post #23 in this thread if you're interested in my opinion).

Don't be too quick with you judgement, BST also did not deliver right from the start, Polychop very well deserves a chance to improve, don't forget its early access and their very first release! :smilewink:

Noone who seriously criticized the flightmodel (apart from the braggers) ever said its way overstated or too sensitive, we spent a fair effort bringing up fair points. It just does not behave like a real helicopter. The 3 controls being "syncopated" comes from them being completely disconnected from each other. You can press pedal any direction any deflection without needing to compensate on cyclic, the very same goes for collective, it just is not connected to cyclic - at all. This may be fun for you to fly (nothing wrong with that), but it just does not make it more realistic ;) You may say now: it's a game and it will never reach the real deal. I agree on the latter, but we can get closer and closer, even though we will never achieve 100% realism. Computers are getting faster and more capable, and devlopers get more experience. Unfortunately like I stated in multiple threads, the current FM of the Gazelle is nowhere near as realistic as the competition. I also disagree in this being "just a game", it is a simulator and has the claim to be as near to the real as possible, and I stand the strong opinion that it is possible to get a lot closer to the real thing than it is right now. If there was noone bringing up points about what is wrong with the FM, it would not improve. I personally find it sad when real-life Gazelle Pilots say: "it's just a game, and for a game it is sufficiently modeled", because that is not going to make the module any better. I think the superb systems modeling and work on the 3D-Models deserves a much more realistic FM. But hey, let's give polychop some time and lets see what they come up with. :thumbup: It is called "Pilot Induced Oscillation", and is something every beginner does (not exclusive to simulators at all and happens on fixedwing as well as rotary aircraft). The mean thing in simulators is, you don't have your "butt-meter" helping you with sensing motion, so it is even easier to get into PIO.

I have a similar problem on 1.2.8.1 All Radios are Unknown, regardless airframe. Checked the export.lua, reinstalled, rebooted, checked .net. I feel kinda stuck. :( EDIT: I just rechecked, after uninstall all SRS Files were still in the Scripts folder. I manually removed the lines from export.lua and deleted the other lua files related to srs, did another reinstall and now it works!! Nevertheless Ciribob, I always welcomed the idea of SRS, but now that I've used it a while, I rarely use Teamspeak anymore! Fantastic job, hope we get to sort the problems soon :) Fantastic Job!! thanks! beef

Significantly would be exaggerated, but there were changes quite a while ago. Still, the FM is not finished, as you can read up in various FM-focused threads (Early Access, Beta and stuff, you know, apart from helicopters not being particularly easy to simulate). It may be safe to expect more FM-changes you will have to get used to until it is finished ;)

BUG TEMPLATE: Description: I just coincidentally observed a gazelle spawn inbetween 3 vulcans. They opened fire, the client disconnected after 294 logged hits, likely more (engagement took about 20 seconds full power from 3 vulcans), the Gazelle never exploded, the server went unresponsive until it was finished processing the massive amount of hits. Example: Open ME, place blue Gazelle anywhere, place 5 vulcans around it, press fly and observe. DCS Version: 1.5.4.57288 and earlier Steam: no Map: caucasus SP/MP: mp Reproducible: yes Step to Reproduce: see example Screenshot/Video available: yes Track Available: yes but impractical and easy to reproduce Mission File: not attached Controllers: not relevant OS: not relevant RAM: not relevant GPU: not relevant Any Additional Information: This can cause big problems on mp-servers that intercept shot-/hit- events, because if coincidentally a situation like this happens, the server can get loaded up with a lot of processing-tasks to perform which is likely to have severe impact on server stability. It will also cause loads of lag. Also, if you fire and fire and fire at an enemy, and he only gets down but still stays in the cockpit, it negatively affects the MP experience (see Mirage damage discussion, although not as severe here, as it wont stay airborne like the mirage). I understand why this did not seem important till now, and I do think there are more important tasks. But I'm sure the MP community would appreciate if this could be moved up a little on priority, I don't think this will influence singleplayer much. Thank you! :pilotfly:

Yes this bug was fixed just recently, it is save to turn them off, they will only be displayed on the server to keep the scripts working, but not on clients :thumbup:

Yes. Proxy fuses are bugged since they first published the netcode-extrapolation-changes. Basically haven't seen any proximity-fuse go off ever since then, if the missile passes you by 20cm, it passes you. Guess they will come back when the new netcode is finished ...

I've been working on a bigger quite complex MP-Type mission for the past 6 Months, and I have spent countless tries evaluating what makes a FARP rearm/refuel/repair, and what not. It has apparently to do with what kind of units are near, but I am completely failing to find a pattern of which unit needs to be where that allows what or is required for whatever you wanna do. I FAILED TO FIND A PATTERN FOR THE PAST 6 MONTHS It sometimes works, then you restart the server and it doesnt work anymore, then I restart the server locally with the exactly same settings, and it suddenly works. I would really love to provide you guys with a bug report, with a way of reproduction or whatsoever. I can only tell you: There is no way to reproduce it. If you wanted me to guess I'd say the game just randomly tries to trick us into wrong thinking. I can only beg you ED to have a look into this. I know you are working on 2.5 and this is perfectly fine. Even if you cant fix it, PLEASE at least provide us with an official ideally logical answer on how this is supposed to work or at least how we can trick it to work. Because the behavior of the game does not seem to follow any logic. It sometimes likes me, sometimes not. If you are coding you know how crazy this can drive someone. Sincerely, Deadbeef

ah gotcha! I thought you were refering to my question, but it was to kobeshow about him not know where to find it. Mucho confusion. All questions answered, thnx!

I cannot see an image of the ME in the video, only the options in special tab... I am also not a huge fan of watching multi-minute videos to (not) find an information that would fit into one line of text, because it requires me to sit patiently and watch the video, until the information I'm looking for appears. I am really bad at things like these, please dont take it as an offense ;) Thank you very much Zeus! That's what i was looking for. So in short: Client checks: "does not require alignment" in special menu, and I do nothing in mission editor/make sure that checkbox is off.

Hi Guys! I seem to have a couple of issues turning alignment process off for everyone on a server, whatever I try, there's always some people who say it works well, and some claim they have to align what ever I set. I also seem to fail at finding a clear complete guide on how the whole INS thing works. I understand the manual is yet to be made and I understand why it takes some time. The search only resulted in long threads where I could not find the info I was looking for :( So most pressing issue for me: - What kind of scope does the options in the special menu have. Is it only for the client himself and/or does it have an effect on the mission if it is set on the Mission builders computer? - What exactly does the "force alignment" option in Mission Editor do. Does it force the client to align it for 8 minutes, or does it force the client to be aligned on spawn? From the text it could be both ... Thanks! Beef

srsly, all I'm doing is defending my points. I always said its fine that things take time, I do not think I am bashing the devs, and I am certainly not intending to shed bad light on anyone. I only have rather high expectations to a helicopter-sim released in 2016. That said: an official anouncement by the devs acknoledging a list of things we continue to bring up again and again may shut this whole discussion once and forever. I think we've discussed this long enough, with no valid counterpoints being brought up so far at all.

I am getting tired of your kind of posts. You once again claim we compare the Gazelle to Huey or other DCS helicopters, which is not true. I am referring to fundamental flight-characteristics that *every* helicopter shares, in DCS, in X-Plane, and in IRL (never tried FSX). Why don't you tells us more details about "from what you can tell"? I would be very interested to learn why the gazelle is only reacting to pitch and roll on cyclic input, no blowback, no pitch change in collective drop and raise. Noone ever said it should pitch with rudder input, but should induce a roll component with the input, while pitch-change could very well be the consequence of a roll momentum (if you roll right without countering the nose would eventually drop, the induced slip component would have consequences too). Maybe you should read more carefully before you post such things? I read the section on VRS and tail, and I fail to follow the books author. It reads as if he was referring to the main rotors Vortex Ring ( = downwash, no State, this is permanent) as VRS, which is basically confusing two things. There are indeed states of flight in helicopters where the downwash can effect tailrotor effectiveness/efficiency (however you wanna name it), but none of these have to do with the Vortex Ring State, which basically describes the helicopter being caught in his own vortex, which cannot be countered with power alone, but the pilots needs to fly out of the vortex if altitude is suffiecent. (off topic, you can use the tailrotor thrust to get out of VRS, once in it, apply max-power, left pedal and right cyclic on left turning rotors, right pedal and left cyclic on right turning systems, no matter of fenestron or not) Did you not notice at all that in the section the book refers to vrs, it is actually talking about flying sideways to the left in a left-turning rotor-system? This describes a completely different phenomenon than what you are talking about. Once again, if you have viable points countering the things I have brought up, I am very very happy to learn I am wrong. However, please bring up valid points against things that have actually been brought up, before you claim you're getting tired. That book seems interesting nevertheless, thank you!

Interesting, I am not getting the event at all from clients. I also noticed that if for instance a Mig-29 is hit by an Aim-7 (all clients), and the mig pilot stays in control of the aircraft, isExist() would return false. I think it should only return that if the unit is either exploded or crashed ... or both. Would make more sense scripting wise.