Syd

I tried using "SOUND TO UNIT" action. Apparently it works only for singleplayer. When MP is launched it only works for client that runs the server. Everybody else doesn't hear anything. I checked long and short clips, neither worked. "SOUND TO GROUP" works fine both in SP and MP.

Thanks

Ok, but by using name as comment each one is different. Have you ever tried using the same names?

I've created a ONCE trigger that plays audio file to a client that is inside zone. Then I cloned this trigger for every client a/c I put in the mission, changing unit's name in every trigger. I ended up with seperate trigger for every individual unit, but I noticed that because I used "clone" function every trigger has the same name. My question is - what happens if you use the same name for different ONCE triggers? Will it switch all those triggers to completed after only one unit executes it? Essentialy making only the first unit to enter the zone hear the sound? Or maybe it doesn't matter?

Thanks for reply. I found those lines yesterday while doing further research. I also came by the tutorial you linked. The only problem is that reducing those values ultimately slows down fast scroll mode while button is being held down. With HMCS knob it's not a big issue since it's fast enough, but with CRS/HDG knobs it makes the bug travel a lot longer. I guess it will have to do for now but it sure needs an improvement. Are there any files/lines that describe how the mouse scroll wheel interacts with particular knob?

I have an issue with how rotary knobs behave when using keybind commands for CW and CCW rotation. It is a universal problem for all knobs - HDG, CRS, speed bug, altimter etc. Using keyboard or any other device for these CW and CCW commands, makes it impossible to set precise indication (unless you're lucky). No matter how short I try to press the key, the bug always travels for at least couple of degrees or inHgs in case of altimeter. There should be some critical time setting that would allow for those single short presses and precise setting. Much like it works when using mouse scroll wheel. Instead those binds are quite useless. Or maybe somebody knows how to make it work like that? Some lua file editing could do the trick?

I came across your topic since I have the same problem as yours. Original board and hall sensor works more like a switch than axis. In the original design the magnet slides closer and further from the hall sensor and I can't imagine any magnet and sensor that would give satisfactory axis effect in this configuration (distance the magnet travels is around 17mm). In my previous projects hall sensor always had magnets rotating around it. Did you change orignal magnet? What type of hall sensor did you use? Thanks for your help.

Hmmm, I have to check it on different maps then. I tried Marianas and Syria and it seemed the same.

Didn't know whether to ask here or in the mission editor section. I'm trying to set a cloud base 2000ft above airfiled elevation which is around 500ft AMSL. So I'm putting 2500ft in the ME weather settings window. I also want it to be an overcast layer so I use a density setting between 8 and 10 (cloud preset set to nothing). Despite setting 2500ft in the cloud base the actual base in game is lower (around 1700ft AMSL). When I try to increase it gradually nothing changes, only at some point the layer in the mission jumps to around 3100ft AMSL. Like it's impossible to set anything between 1700ft and 3100ft AMSL. I there any fix to that or am I doing something wrong?

It was one of the things I mentioned some time ago in this topic: Unfortunately I didn't get much response.

Here you go. I didn't switch to TCN mode since it's fine. dcs.log ehsi-mark.trk

When entering Markpoint menu (ICP 7) the bearing pointer and range indicator to STPT on the EHSI freeze . It only happens in EHSI's NAV mode. TCN mode works fine. It gest back to normal after exiting markpoint menu (Data Control Switch left).

Here it is. I go in full AP and AUTO mode - only turning STRG SEL mode off for a few seconds for a more precise "on the line" LGB drop. Then I go back immediately to full AP. Few seconds before the hit TGP goes automatically to the next STPT. Also the AUTO function could "react" a little faster - now the AP starts slowly turning back to active STPT before next one "kicks in". Anyway, hope it helps. auto ag.trk

Not sure if this is a bug but it'd be strange if correct. I was checking AUTO function in steerpoint menu and then was doing some laser bombing. To my surprise during the first bomb lasing STPT switched automatically to the next one, obviously ruining the drop. Again, not sure how it's in real a/c, but It would be quite logic for the AUTO function to be suspended in some modes (like A/G for example).

Yep. Elevation was the issue.

I was thinking about it, but after watching a video about JDAMs I thought DED takes STPT elevation from ME and it shouldn't be an issue now? I wil check it though. Thanks for reply

Today I decided to spend some time playing with TGP and JDAMs. Made a mission were I start in the air (if that's important), placed some practice target vehicles and added WPTs at the target's positions. As I switched to A/G and put TGP screen on I noticed some weird behaviour - the TGP camera was constantly drifiting slowly in one direction. It should initialy stay on a selected steerpoint, shouldn't it?. Only when I command TMS Up or RIght I get a lock and can start moving it around. After I push CZ the drift starts over again. Two more pieces of information: - deadzones on my RDR CRS are set correctly so that's not it, - during drift the TGP coordinates in top left don't change at all, as it was locked in one place all the time. I'm not puting this in the bug section yet because I haven't had a chance to play a lot with DCS lately so maybe I'm missing something.

One more thing just in case anyone from ED reads this stuff Wind is reported using thee figures, rounded to the nearest 10 degrees magnetic. For example wind 037 degrees would be reported as 040 degrees.

Forgot about measuring station's mast height. Tnx Dragon

Could you explain the "standard bottom read" thing? I'm not familiar with this.

That would be great if ED would fix the above in a process.. I had high hopes during new clouds release and though 2.7 is an awesome visual improvement, underneath it's the same old stuff.

I was thinking about writing this post for a long time but didn't know where to put it. Since this new section emerged, here are my thoughts about weather engine and it's flaws/bugs that I wish could be fixed. 1) WIND. Ideally one could choose between setting navigational ("to") and meteorological ("from") wind. It always brings up confusion in multiplayer missions with live ATC when people forget that they should add/subtract 180 degrees from the ME wind setting in order to have useful in-flight wind. The one that is being set right now (navigational) is used during preflight route calculations which is virtually non-existent in DCS. So it would be great to at least change it to meteorological wind setting ("from") as this is the most useful. Second thing - ME's setting is nav wind ("to") in knots, then the briefing report shows nav wind in m/s and in the end ATC reports it as meteorological ("from") wind in m/s. So we end up with three different wind report types! Why!? Pick one and stick to it. Ideally meteorological in knots everywhere since this is the one mostly used around the world. Third - wind layers in mission briefing are called GRND, 2000m and 8000m. Again why? Stick to ME values: 33ft, 1600 etc. What's more it's misleading, because GRND isn't GRND at all since if you are taking off from Vaziani for instance, than you are automatically in the 1600ft layer which by default has twice the wind set in 33ft (shown as GRND in briefing). Also, this "33ft" is strange. Why not just call it 0ft or sea lvl. 2) TEMPERATURE. This is a minor thing, but why is standard temperature in DCS 16*C? It is 15*C IRL. 3) PRESSURE. Whole QNH system should be remodelled. ME's QNH setting should be renamed to pressure at sea level. IRL QNH is calculated for each aerodrome individually based on local weather conditions. In DCS it is set for a whole map, but once you set temperature other than DCS's standard (16*C in DCS), QNH setting becomes useless for different aerodromes. I guess present system with QFE in briefing is a sort of walkaround but it could be fixed for instance with an option to ask tower about QNH (correctly calculated for each aerodrome of course). To be honest If I would dive into this topic than I would need to address the altimeter simulation, the aircraft's altitude setting in mission editor and a few more things. But these are much bigger issues. This whole post might be considered as nitpicking by most, and they're probably right. DCS experience is great despite above issues and I wouldn't be surprised if I didn't get any response to it, especially from the ED's side. With new stuff coming in all the time I guess they have more important things to focus on than wind units. Still it felt good to address those things and maybe in some time have someone look into them.

For me it's a typical behaviour in minus temperatures. Additionaly altimeter and speed indicator also freeze/show weird values. Turning on/off probe heat doesn't do anything. I even tried turning it on around line up before take off (like the official manuals state) and still no improvement. Maybe it's just me but I feel like it's happening more often with external wing tanks.

I'm not sure what you mean by "adjusted temperature in-game". If you're thinking about temperature error on the altimeter than yes - once you set temp. other than 16C than you will see that your altimeter indication is different than your ASL. To be precise - in temps lower than 16C your altimeter shows higher than you actually are, and for greater than 16C it's the opposite. That is why IRL in really low temperatures you have to calculate this error for safety reasons (mainly during approach phase).

Just a quick note on the temperature. From what I've checked, DCS's standard temperature is 16C. This is the value at which altimeter temperature error doesn't occur (at least to a certain altitude). 20C is nothing more than default ME setting.