0xDEADBEEF

Here's an interesting army training video about mast-bumping: In short: if the rotor-disk is unloaded the disk can tilt more than its physical limits thus severing the main rotor mast. Most common (but not exclusive) cause is a "low-g pushover" maneuver, for instance if youre in a climb, then lower collective while pushing cyclic forward. But the video above will give you a pretty good idea what mast bumping is and how to avoid it.

Yes it is, it uses most units radars and if detected gives the BRA-Call. So if you destroy all enemy Radar units, they wont get braa calls. That's also why we see quite an increase in EWR deployments since the script was installed. It is written by Steggles: https://forums.eagle.ru/showthread.php?t=158076

SRS Server is restarted, issue fixed. Thank you and happy new year! :)

Great work Steggles! I found a small bug by coincidence today. In the validSearchRadars table the BUK SR designation is wrong. In the script it says: "SA-11 Buk SR 9518M1" while the GT.Name in the Database is "SA-11 Buk SR 9S18M1" (95 vs 9S), essentially leaving out the BUK-SR. cheers! Beef

I've cleaned it up a little bit (Samobject:getName() is unnecessary, because you start with the name in the first place after all). Also there is one caveat, mist.makeUnitTable does not only return numbered indexes, but also has one index named "processed" which you wanna skip. That may have been the reason why it did not work. Also the "for in pairs" loop can be used more efficiently as you can see. env.info() just puts a line in the log which can be helpful to actually understand what your code is doing. This works fine: SamList = {} function getRadars() local redUnits = mist.makeUnitTable({'[red][vehicle]'}) env.info(mist.utils.tableShow(redUnits)) for i, unitName in pairs (redUnits) do if type(i) == "number" then -- makeUnitTable also has a ["processed"] = time index which does not represent a unit local samUnit = Unit.getByName(unitName) local samSensors = samUnit:getSensors() if samSensors then env.info("unit '"..unitName.."' has sensors") if samUnit:hasSensors(Unit.SensorType.RADAR, Unit.RadarType.AS) then env.info(" - also has Radar") table.insert(SamList, unitName) end end end end end getRadars() trigger.action.outText(mist.utils.tableShow(SamList),20) hope this helps.

in the second example you are defining a global inside a function (SamList = {}). afaik it should still be a global, but that's the only thing I can think of. If you define SamList outside of the getRadars funciton (which you should do anyway, because you wanna access that gobally anyway I guess. this would work: SamList = {} function getRadars() local redunits = mist.makeUnitTable({'[red][vehicle]'}) for k, v in pairs (redunits) do local Sam = redunits[k] -- trigger.action.outText(Sam,20) local Samobject = Unit.getByName(Sam) Samname = Samobject:getName() local Sam_sensors = Samobject:getSensors() if Sam_sensors ~= nil then if Samobject:hasSensors(Unit.SensorType.RADAR, Unit.RadarType.AS) then SamList[#SamList +1] = Samname end end end end getRadars() trigger.action.outText(mist.utils.tableShow(SamList),20)

Bug 1: Multiplayer Situation: - Client launches "Matra Magic II" on any target or no target - script gets eventhandler call for "world.event.S_EVENT_SHOT" (same applies to "..._HIT" event) with a Weapon-object containing a "Matra S530D"! - if kill event follows it has weapon-string supplied properly as "Matra Magic II" This bug breaks any missile statistics being collected on multiplayer servers for the Mirage 2000 It may be related to the fact that Mirage Missile desriptions are inconsistent, it seems both Missiles can sometimes have the name "MATRA".

Hi all! I've been trying to avoid vehicles being eaten/driven underneath/submerged or hidden by farps for quite a while now. I've come down to writing a script that defines certain zones around a farp and selecting a random point inside that zone (100% outside of the farp-pad). I then run a script that creates a mission table with two waypoints (initial position and the new position I calculated) and sets it off using Controller.setTask(), I can also confirm the position of the waypoint is correct due to the flag that pops at the point, and the unit starts moving (all groups have one one single unit). Unfortunately in at least 50% of the cases, the unit stops short of the runway, and guess what? In many cases those units end up standing right ON the pad, where I want them to stay away from :( Does anyone have experience or a clue if or what I could do to make sure the units arrive at the designated location, and dont stop randomly between ~150 or 20m short of it? It is driving me completely crazy. Thank you! Beef

track sent :thumbup:

Confirmed not working in anything past 1.5.5.99.

Took a hit in MP last evening, managed to do a deadstick landing on the airport. Got repaired, took off again, had no Airspeed indication, a second repair did not fix it. Speaking off, is it really realistic to loose all fuel if you take a hit to one side? Would it not more logic to loose all the fuel in one tank instead of both?

I understand where you are coming from, but I disagree with you claiming it not being a "Real" issue. I am not curious to know where it is coming from, as it would not make a difference. If nobody reports it, it is not going to be fixed, and memory leaks are something you want to be fixed from a software developers point of view - no matter if "users will do, for any practical purpose". Bugs don't care about that, and neither you nor I know if this is the only symptom of this bug. That said I consider it a bug and I thus I have reported it, period. I think this is a very pointless discussion you are starting in a bug report forum (pointing at your second sentence).

Whaaat? Did I read and see ingame overlay?!? This being possible is a massively valuable piece of info on one hand, and a huge upgrade for SRS on the other hand! This is incredible news :thumbup: Thank you so much for your effort Ciribob and Jabbers_!

I noticed if I leave DCS (1.5.5.9) open in the Menu Screen during the day when I am not at home and I return home my Memory clogs up big time (between 15 and 25GB of RAM used, but not assigned to DCS). Closing every single application does NOT free the Memory, only restart helps. I was a little uncertain if it was not something else, but I was now able to crosscheck twice. If I leave the computer running idle for a day with DCS closed I end up with well under 10GB of RAM used. specs: Win10, 32GB RAM, GTX970, i7.

The SAS will come into play for sure, but afaik it is not supposed to cancel those effects completely but dampen them (I'd be surprised if it was not basically a PID controller). For instance, the EC135 or BK117 use SAS as well and those effects are still very much present, although dampened a lot. You still need to apply fwd cyclic on all of them in forward flight, even on the ka50 which also has some kind of sas, even though its not called sas but attitude hold. Apart from that, switching sas and gyro off still does not show the behaviour I described.

The only part I agree with you is learning the huey first, because it is a great platform that really teaches you how helicopters generally want to be treated. It's controls deflection are huge compared to most other models and response is rather mellow. It will teach you very nice reflexes that should more or less work with most helicopters you will ever fly (I am NOT saying they will fly the same, they only share a bunch of fundamentals). Please differenciate between "flyable" and "realistic". The missing cross-coupling of controls is a severe flaw. There is no blowback effect, collective is more centered than not most of the time regardless speed (every speed would require a different cyclic position in any helicopter), if you apply aft cyclic to slow down while lowering collective will still have the gazelle continue rolling backwards, if you had the altitude it would continue doing a complete loop and more. Collective still has no influence on pitch-attitude at all ... I'm glad you find it flyable, i still find it unrealistic and fundamentally wrong in some areas ...

I could repeat myself again, but I think I have explained it more than often enough, just check my statistics, I'm sure you will find a couple of threads where I explained in detail why this is the case. If you can proof me wrong I'd love to hear it, I'm never shy of admitting a mistake and learn something new. But rest assured it is very nasty habits.

Glad for you that you got practice done and it flies now fine for you. Please bear in mind this does not make the current FM more realistic ;) Polychop is working on it though, I'm positive they'll listen to the feedback and come up with something better in due time. +1

Why don't you write it like that from the start? on eyelevel, no insults, no accusations, no unnecessary rhetoric tools but straight to the point, I like that much better! :thumbup:

With all due respect, I dont think Ed should spend a lot of effort optimizing DCS for players who play on, excuse me, ancient hardware. This is nothing personal, development should go ahead instead of backwards. I play on 1080p on a 24 inch and I can see contacts 50km/25nm away frontal aspect with my eyeball Mk1 very easily! While I do like how that new system looks, ranging and visibility through clouds absolutely need some more work. I do like it much better than the old imposter system I have to admit.

Yes, I do miss your point, and your post did not help at all. Calling people pointless whiners and your rhetoric tools "common sense" (seriously?) are not bringing along any kind of point, and when did I ever not allow Razbam their time? The split happens between people who think the DM is fine and people who think it is seriously wrong, bringing in ww2 fighters and 21vsf5 servers is not illustrating a point either my friend, not at all. I am not interested in that kind of discussion, thank you! I appreciate respectful discussions. I also think I spent sufficient amount of effort illustrating my point, see you on a server :pilotfly:

I fail to understand the point of your posts. Sounds to me like you are trying to suppress feedback by labeling them as pointless complaints. I also really dislike the rhetoric tools you are using, sentences like "is there really a problem? Obviously only with you" have no place at all in any kind of constructive discussion - did you even realize there were more than one persons in this thread actually agreeing on the DM needing work?

I have explicitely pointed out that this incident is not the reason why I am posting, but the discussion that has resulted from it, which ended in pretty much what we see in this thread. Apart from that, I have the hit on video and I have the hit in the logs directly from the server. We all know that tracks can be inaccurate. But again, hit or not is not the point, point is the kind of discussion that evolves and is unneccesary. So you say we should not provide feedback at all? Sounds very constructive. Rhetoric tools like this sentence are going to bring every discussion forward, keep going, it is exactly what this thread needs! :thumbup: That said, I have a lot of understanding that developing a module of this complexity is no task of few months and that there have to be priorities. However, splitting a community in half may be a fair reason to adjust priorities (not saying they should be looking at the DM right now, but sooner than later. Razbam has done a marvelous job so far!). Of course there will be people complaining about changes, they always do.

Well he turned in front of me, so i had plenty of time to lock him up and send a Vikhr. It hit, he sent a S530 which went below me, he turned around and hit me with another S530D which brought me down. Him staying alive was not so much the reason of the post, but the pointless discussion that evolved after, where everyone is a weapons expert. My point is: What really sincerely bothers me, is that this topic creates dispute where there should not be any kind of dispute. If all fighters would have a rather similar damage-endurance we would not have this discussion. People who get along well otherwise suddenly start to fight over each other, the ones pro the current DM are usually Mirage Pilots, the ones against it are non-mirage pilots. This is not a good situation in a community and should be addressed in my opinion. That said, if you want my opinion about realism: a head on hit with a vikhr that leaves the mirage virtually undamaged apart from a dead engine does not sound very realistic to me ... (according to wikipedia the vikhr is impact-fuzed, not proxy, dunno if this is correct) edit: I just read some more on the vikhr fuze, while the box at the (german) wikipedia said impact-fuze, the text said it has a proxy fuze for A2A, which I guess was active since I did set the weapons mode to A2A (not head on, dont have that bound to a button) ...

I am very surprised how much discussion this topic creates. Imho it is completely indiscussable. Everyone who flies MP has noticed the Mirage survives at least 75% more hits than all other planes (A10 and su25 are heavily armored exceptions). It has created more dispute than the Su27s wings ripping off ... Razbam, can you please just adjust the damage model so it is not way stronger than all others so we can fly MP without having this permanent discussion going on with people bashing each other in chat? Thank you very much.