Syd

Here you go. Same approaches - one with ccrp, the other with ccip. You can use F7 to look at ground unit next to aiming point. CCRP gives beautiful even spread, while CCIP hits way before with only two bombs landing after. Type of dumb bomb doesn't matter. I guess this might be simmilar issue with CCIP. Only I tested specific flight conditions. Others reported different problems in other configurations. F16_ripple_ccrp.trk F16_ripple_ccpi.trk

Last night I did a mission where I was bombing a runway. I used 12 rippled snakeyes with 600ft interval. Flight parameters - level flight, 500ft agl, 400kts. I started the drop when piper was on the runway threshold. To my surprise only 2 bombs landed after the threshold. First 10 hit the ground before. I later learned that the piper should point to the middle of the whole spread not the first bomb impact as I thought. So I did some testing and apparently it's bugged. CCRP and DTOS work as expected - bombs spread equally before and after the target. But CCIP gives different results depending on speed and ripple interval set. Sometimes bombs spread equally, sometimes almost all of them land in front or behind piper.

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