virgo47

Does that help with radar and its tracks? I don't have the plane on trial anymore so I can't test it, but I don't know how this is related, I didn't mention any flight control problems, only radar behavior vs instructions discrepancy.

I fully agree. I know my flying is not great either, but this leader occasionally acts like he's flying a Red Bull show. It's annoying to fly half an hour and then get into VRS just trying to slow down behind that guy. But I need flying practice, so I take it as some kind of atonement to get better.

I asked about it on TP discord, and it seems to be type-related. But I don't know what data types TP recognizes internally. Somehow it worked previously, but now the RPM (and other gauges information) is not considered "worthy" of additional comparison operators. Reiner's answer suggests that it is likely a plugin issue.

I tried AutoPilot, Occupy seats 1/2 and eventually also Request Aircraft Control - when desperate. Perhaps the last one messed with it up irreversibly, I don't know. At any time after the message I expected to see the white indicators in my controls indicator, but I never saw them appearing.

I've just played this mission the first time, not knowing exactly what to do, I first took the wounded straight across the ridge - this definitely cost me some fuel. I was considering refuelling at the outpost, having the fuel pointer just around 4 and then told myself: "What the heck, at worst I'll play it again." I landed with the needle one small tick above 0 (=0.2). So yeah, it can be tight, but it seems possible. New FM here. I had a much bigger problem with the copilot telling me he'd fly while I could set the ADF, but he never really took over and the Autopilot keybind didn't do anything, whether I was in position 1 or 2. This puzzled me quite a lot, but I managed it somehow.

Hi @xoomigo. I've played with the patched COINS and UH-1H much more recently - and also nearly finished my page for it. As typical for me, it's much more crowded. The teaser is here: Here is the suggested inverted counters: ADF_GAIN|adf_gain|ADF Gain|6|3200|=ictr(65535)|100 INT_VOL|int_vol|Intercom Volume|6|3200|=ictr(65535)|100 UHF_VOL|uhf_vol|UHF Volume Control|6|3200|=ictr(65535)|100 VHFFM_VOL|vhffm_vol|VHF FM Volume Control|6|3200|=ictr(65535)|100 THROTTLE|throttle|Throttle Axis|6|3200|=ictr(65535)|100 THROTTLE2|throttle2|Copilot Throttle Axis|6|3200|=ictr(65535)|100 # And also one default switch position: UHF_SQUELCH_SW|uhf_squelch_sw|UHF Squelch Switch|4|0|OffOn|ON I went through many other ctr options, e.g. ADF_TUNE or ALT_ADJ_PLT, but all these sliders only increase the value, whether I slide up or down. The result in the cockpit always goes up, so the rest of the Huey ctr is mostly useless in TouchPortal - at least with sliders. But I also found some problems. Previously, in TP 3.x, I modeled ENG RPM and similar stuff with coloured values - this was based on "greater than" check. When I add vanilla IF into Touch Portal, I can use any of the following operators: But when I select the value from COINS, it only allows this: Is this TP 4.x related bug, or is there some other change (I noticed these are pct, not sure if they were always, or it was int before - really don't know if that would even help). This obviously breaks the panel - although, strangely, it works for old buttons - somehow they preserve the right condition, even though they don't offer it anymore. Lastly, I made some naive experiments. I've noticed in the readme that there is a support for some calculations, even since 2022-10: "Added transform character "*" and "/" in "int" value ..." So I tried this (in CommonData.pp ALT_MSL_FT|alt_msl_m|Altitude MSL (m)|0|0|=int(65535)*(0.3048)|0 The idea is - take ALT_MSL_FT from BIOS - this one now appears on two lines, one fo them original - the other my calculation. I can even find the value in the plugin, so I put it into the panel "display" near the top left corner. But it only shows 0. It does not calculate. Is it possible to do it this way? This would be great as I could remove "event" I used for L-39 panel to get the metric altitude instead of ft. I'm attaching the panel (including all the values) if you want to try it. dcs-uh1h-page-wip.tpz2

This one is notorious since some update. Some things were moved to UI Layer (which was a good unifying change). Some were left in other layers. I just fixed it on my end and moved on. I always treat the UI Layer as the highest priority.

Is there no tooltip on it? I've seen these in a couple of situations: Binding uses a modifier that was not configured - this is likely not your case. When this happens the offending binding is not even shown, so it can appear on an empty cell as well. Conflicting binding. This happens to me when I import a diff file (Input config) that does not remove the default binding for the plane and uses the same binding for something else as well. If it is in the same config, just try to press that combo repeatedly (click on the table first to focus on it) - it should cycle through all the bindings for the same combo. Conflicting binding with another layer, e.g. UI Layer. Obviously, different aircraft configs don't conflict with each other, but some config layers are used at the same time (plane + UI Layer, not sure about others). Strange cases. Sometimes I see it, restarting the game helps, or saving/loading the input config, etc. This can be caused by loading a diff file for another config (by accident or with a good reason) or when the changes in the system/aircraft defaults binding suddenly (e.g. after the DCS update) collide with your existing stuff in Config/Input.

I believe that realism and monitor (or VR displays, or whatever) don't work together well if you don't do something special about the visibility. People could see things further and smaller than what current monitors can provide, and some kind of smudge or something should be visible if it could have been visible in real, even if the 3D engine would not be able to provide it. Current dots are terrible because I see things better far off than when they get closer and the dot disappears. But something should be there, otherwise we would not see things that can be seen in real. It will never be 100% realistic anyway, if nothing else simply because of FOV vs monitor and many other reasons. And it will never work the same (and as well) for all users with various devices. But current solution doesn't seem to cover the mid-range very well and overblows the far end. And, what's even worse, does not seem to work in a comparable fashion across various devices - too far from it. This makes the whole discussion even harder.

I half agree and half not here. I agree that lever bound to axis is fine as long as the axis is reliable (no jitter), or you play around the problems as you did. I personally use thumbwheel on the STECS, which is not super ergonomics, but good enough for the throttle in UH-1H - and I use it just for fun when I want to practice governor failure - when four axis to control is not enough and you want the fifth . But I'm a newbie with Gazelle, I don't even see a governor switch there, so for me any precise control of this lever is not necessary - keys are enough. I use that feature that syncs the axis to cockpit controls and if I left the axis for fuel flow in the wrong position for Gazelle (e.g. playing a different plane before), I'd immediately found out, I'd need to fix the physical position of the axis - and annoyingly, restart the mission, because of the Starter switch not being ON. So, yes, it works with axis, and if your axis is reliable, it works well - but with cockpit sync you need to double-check your axes (or at least this axis) before starting/unpausing the mission. That said, is it really practical and/or necessary to have it on HOTAS axis? Do you use fuel flow for something in other situations than startup and shutdown? (Of course, it is still a valid personal preference. Whatever works for whoever.)

I also discovered the problem with a tiny movement of the fuel flow lever back shutting down the helo without any way to fix it. If the starter switch is ON (which, as previously mentioned, is NOT by default when hot starting), no problem, the RPM goes up again. But, strangely, if it's not ON, and it starts to shut down because of the tiniest fuel flow lever movement - putting starter ON at this moment does not help. This is quite frustrating and confusing really. I had the lever on HOTAS axis, but (again, as mentioned in this thread) this is obviously a wrong decision for this helo.

In an unexpected twist of events, I discovered a similar problem with UH-1H: So, perhaps, this is not Gazelle specific, but something generic with DCS FM radios - or something both modules share at least?

Recently I noticed a funny behavior of an FM radio in Gazelle (don't let the preview fool you, it's not about Mission Editor): I was quite surprised to discover - totally randomly really - very similar behavior in UH-1H, which let me think it's perhaps not module-specific. What I see in both cases is "two-stage behavior": the transmission stays noisy, whatever I do... and then, after something changes... the transmission is quiet, but I can bring it back noisy - and then make it clean! The set of switches is different in both helos, but the behavior doesn't seem to make any sense at all. Let's see the video: Notice how just changing the frequency makes the radio NOT working - but it's recoverable through the "noisy" squelch position - and suddenly, one can only have clean sound as well. Any meddling with the frequency selector "breaks" it again until you recover it with the procedure again. I don't think any radio works like that - especially considering, that at first I merely tuned 47Mhz and it started receiving something (although with noise). The trackfile and mission are attached. uh1h-funny-fm.trk uh1h-fm-radio-problems.miz

Good that it can be done with script, but one more input for altitude + AGL/MGL (with default AGL 0) would be indeed welcome. I have a tower on a non-prominent hill (in the area without any prominent hills) and the sound is clearly blocked even when I see most of the tower. This would help without the need for scripting.

It would be cool if the manual simply stated something like: "(Not available in this UH-1 variant.)" Or something. Now I only assume it's not available.

Just a quick update - the patch fixed the problem! And I messed with that VHF volume after all, probably mistaking VHF NAV with VHF (non-NAV), I'll post final set when I go through all ctr controls. For now, thank you VERY MUCH for the fix - and for inverted sliders!

@xoomigo Thank you - I can confirm the reverse sliders now work! However, I have bad news as well - any switch now sends NaN instead of normal values. If I import plugin from 09-15, it sends numbers: Command Sent: mgdc_l-39_ac_front_master_arm [MGDC_L-39_AC_FRONT_MASTER_ARM 1] Command Sent: mgdc_l-39_ac_front_master_arm [MGDC_L-39_AC_FRONT_MASTER_ARM 0] Current plugin sends this (different switch, but all do the same): Command Sent: mgdc_l-39_ac_front_asp_fkp [MGDC_L-39_AC_FRONT_ASP_FKP NaN] Command Sent: mgdc_l-39_ac_front_master_arm [MGDC_L-39_AC_FRONT_MASTER_ARM NaN] This crashes DCS instantly. So somehow we need the best from both versions. I'd recommend pulling the last version out of the upload page for the reputation sake. Finally, as a minor thing, I found that VHF volume is also inverted, I don't know how I missed it (maybe my head was inverted), so the set of changes for UH-1H is: ADF_GAIN|adf_gain|ADF Gain|6|3200|=ictr(65535)|100 INT_VOL|int_vol|Intercom Volume|6|3200|=ictr(65535)|100 UHF_VOL|uhf_vol|UHF Volume Control|6|3200|=ictr(65535)|100 VHFCOMM_VOL|vhfcomm_vol|VHF Volume Control (step size less than 8192 may not work)|6|8192|=ictr(65535)|100 VHFFM_VOL|vhffm_vol|VHF FM Volume Control|6|3200|=ictr(65535)|100 VHFNAV_VOL|vhfnav_vol|VHF NAV Volume Control (step size less than 8192 may not work)|6|8192|=ictr(65535)|100 Sorry if you felt under pressure, no need to rush, the capability is awesome and I'll wait for it. Or you can send me the stuff privately and I'll test it before release, if you want.

FM radio is described in the manual from p112, and the model is simplified, it should work fine for a few preset channels. However, I found some issues with the radio - some of them are tricky to replicate, as the radio seems to change the behaviour a bit: At first, it's playing whatever is on the first preset - but with excessive noise. TST is not different from other three "ON" positions. If you turn it off, it's quiet, and after turning it on again, it still behaves the same. All four positions are the same, playing the current preset channel with some noise. If I change the preset to another one, it's quiet - this may be OK, I don't have any station on the other preset. If I change it back - it is still quiet. Waiting don't help. Turning it off and on does not help either. However, I can start receiving the preset channel again if I go to TST - I can hear it with noise. And if I go to other ON positions - suddenly I can hear it without any noise as well! BTW: TST does not play the 1kHz tone as advertised. To summarize the behavior - in order to hear the preset correctly, you have to change to another one, than back, then go to TST and than to any ON position. I'm attaching the mission file and track file - and this video (which is the same mission, but not the same as track file): Lastly, a minor problem, but it got me confused for a bit - the mission editor shows AM for FM preset frequencies. The manual (p113) shows an old screenshot from the Mission editor, and it shows FM. Now it looks like this: gazelle-funny-fm.trk gazelle-radio-problems.miz

This is one of the first things I noticed after I had bought the module. I use Pedal Trim Type: Fade In/Fade Out (BTW: a neat option!) and the indicator shows the pedal white indicator in the middle after trim - while cyclic works as expected. Luckily, it's just an indicator issue, so it seems. But it's confusing nonetheless.

I was following the second training mission (weapons) and a few things attracted my attention: TV display related BCV panel power has three positions, yet only A and M seems to work. Confusingly though, page 40 mentions the other position as well: Should it work or not? The slew controls are hardly usable - with a ministick (axes) close to unusable. Anytime the other axis interferes with the one in motion, the one in motion stops immediately. So even a tiniest amount of vertical axis stops the fully deflected horizontal axis. Strangely, some combinations seem to work and sometimes the cross goes diagonally, but in general - it's unusable. The same seems to apply to the slew keys. If I hold right and tap up for a while, the cursor stops, although I'm still holding right. I attached the track file, it's the second training mission, I didn't bother to take off to make it easier, but that seems to make no difference. ALI position skipped is shown quite soon, TV cursor screen is towards the end (waiting for the cooling). no-ali-twitchy-slew.trk

Well, 50s is perhaps a bit exaggerated, but it's not impressively modern for sure. And likely anything sophisticated comes from Kazakhstan. (I mean France, of course.)

In my case, the pressure showing 0 happened in a hot UH-1H client slot. But I couldn't reproduce it with the same slot afterwards.

Hi, I PM'd you with the demonstration video.

You're right about the accent, it's pretty strong, but I watch the channel regularly and one will get used to it eventually.

Yeah, definitely, this video was very good - and the plane, oh... just about perfect!