Sprool

I'd probably look into getting it if it halps me use the Huey radios just via voice commands, Ive spent hours over the last few days trying to get VA profiles to work properly.

I did a fresh install of your Huey profile, also added a bit more gain to my mic. Now I can get it tuning the radios but the tuning they come up with does not match my request, and as shown in the log. I checked all keyboard commands are mapped properly as per the html page in the zip. I tried resetting and realigning. If you take the UHF radio, when you spawn in its set to 251.00 as default. I ask to tune to 255.0 and I get 306.0 I reset the freq to 300.00 as per your ReadMe, then command ' quick Reset Frequencies'. then I try tuning to 255.0 and I get something completely differnt. Do you think something may have changed in the default Huey frequencies since you released the profile? Can you confirm I should be setitng the following for a 'quick reset' as the frequencies I call are ending up on very different positions; On a fresh spawn, Nav = 107.0, quick reset recommends 113.0, VHF comm = 116.00, quick reset recommends 130.00, UHF = 251.00 quick reset recommends 300.00

Im only talking about changing the speech tigger phrase, eg from 'UHF comms tune' to 'set UHF radio' - that shouldnt break all the coding behind it? NB: even when I manage to get VA to understand UHF Comms tune I get the text parser error.

No I dont have Viacom, I have a workaround in VA to name the position of ctld options at the start of a mission so commands know where to find it.

I love these profiles - thx Bailey for all your work, but really struggling to get your Huey profiles working properly. I keep getting an error message in VA when I try to tune any of the radios to a certian frequency. I changed the trigger to "Set VHF Radio" then speak the freq, it seems to recognise this command easier, then I get; "Decimal token could not be converted : {TXT:saidTxtB4Decimal} With the UHF radio I get: Recognized : 'u.h.f. comm tuning' Error converting, [thirdDigit] to [thirdDigit] : Text parse error. Any way to correct this? This is version 1.00 of the Huey profile, has there been an update? Thanks!

I found a workround from Pfeil on the VA forum. It just needs to be told where CTLD is in the menu at the start of the mission then that F-key is assigned as a variable txt and used whenever ctld is called. THe position of the CTLD options is the only bit that changes, the rest of the ctld structure remains fixed. From Pfeil's post: Set logistics F[1..12] Code: [Select] Set text [logisticsMenuSlot] to '[F{TXTNUM:"{CMD}"}]' Code: [Select] "when I say: Logistics menu" Execute command - Open main menu press F10 Press variable key(s) [logisticsMenuSlot] and hold for 0,06 seconds and release

@Baileyis there a way to program voiceattack to get round the problem with ctld where it can appear at different positions in the comms menu? As such its breaking all my nice chained commands to drop smoke or pick up troops if i cannot guarantee the ctld submenu is not always at the F6 (for example) position of the comms / f10 options.

This doesnt work with ctld as it moves around the comms/F10 menu, depending on server, mission, airframe. I saw a voiceattack script where they guy first stated into voiceattack where the ctld option was, then the rest of the chained commands ran perfectly. I can set it all up to work in multiplayer but only if ctld is fixed on a same function key sa ive progranmmed.

Hi - I'm trying to standardise some joystick keypresses to trigger menu options in CTLD, using macros in the joystick software as well as trying to use VoiceAttack for things such as 'drop smoke', 'pick up troops', 'drop troops', but I found the comms menu items can be in differnt orders so pressing comms, F10 other, then CTLD can be sometimes on F4, f5, f6 or f7 (depending on server). If youve programmed everything to need F4 for CTLD submenus then it will no longer work properly on other servers. What part of the script will control this so I can get the position of the CTLD menu same keypress each time, to standardise it?

I have the x52 and find the pots so crap if i assign an axis to zoom it will not stay fixed, it keeps juddering the zoom in and out all the time

Back to the FC3 models again.. I just want to confirm if my understanding is correct, I am working on some bare-metal high specular skins for the FC3 airframes. Short example: {"su27_tex04", 0 ,"Su27_tex04_AAF4",true}; {"su27_tex04", 2 ,"su27_tex04_spc",true}; {"su27_tex04", 3 ,"empty",true}; 0 = the skin texture, 2 = the specular layer,, 3 = decal layer, I create a roughmet texture for Su-27_tex04.dds and call it Su-27_tex04_RoughMet.dds I then edit the above part of the description lua file to replace the '2' with "ROUGHNESS_METALLIC" and set the texture to read Su27_tex04_RoughMet {"su27_tex04", 2 ,"su27_tex04_spc",true}; -------> {"su27_tex04", ROUGHNESS_METALLIC ,"su27_tex04_RoughMet",true}; I then leave the 3rd line the same as its calling for a decal layer but the decal layer is to be left empty and pointing towards the default texture folder. Repeat process for tex01, tex02, tex03, tex05, tex06, tex07. Not sure about the tex02_compos and tex03_compos part - what does this control? Is that all correct so far?

Mines set up in the joystick profiler to spit out the default key presses to zoom in and out ('/', '*') - works a treat across every airframe

did some more testing. On Farp capture I spawn in ammo truck and fuel truck to drive to the farp using late activation. THen I can land the huey there, repair, rearm & refuel, so although it remains red in f10 and assigned to redfor, its usable by blue. So maybe it IS working ok, only the F10 map label is bugged

Is the lack of farp colour change a more recent bug then? Youtube videos I watched are from a couple of years back

Im not even at the stage of getting it to function, just the ownership never changes, it stays red and part of the red coalition. When you watch other videos on farp capture, including Suntsag's, the farp changes colour and alliegence changes. Even on the simplest mission just setting up an unarmed red farp, then driving a blue tank in triggers the message but farp does not change colour or alliegence, and it should do!

I'm struggling with capturing a farp, I set up the simplest possible test, a red farp and a blue tank just out of range. The tank then drives towards the farp and the triggers work - I get "Red Farp Captured" but the farp never turns blue. I run the identical test but on an airfirld and it works fine.

OK cheers - all sorted.

When i set up custom snap views in the F-14b, I jump into the F-14a and they are back at default.

Is there a way to copy over all the control keymapping (Hotas, keyboard, others) from the F-14b to use in the F-14a model without reprogramming manually everything already set up in the F014?

i dont really have a problem with Master Warning, alt and att hold, I can figure those out. At least we got the QFE making sense again

The texture file in question has no text on it - only the numbers - and swedish numbers are same as english you can see this from the image I posted up earlier.

..or just copy over the default texture from the dcs mods viggen default cockpit texture folder as per earier comments above ^^ !

LNS_VIG_CPT_UV05.rarheres the default one, I had to zi it up as it was >4mb, it sits in Eagle Dynamics\DCS World OpenBeta\Mods\aircraft\AJS37\Textures\ and it needs to be put into Eagle Dynamics\DCS World OpenBeta\Mods\aircraft\AJS37\Liveries\AJS37cockpit\English\

...if I can find them....

I found a solution, in the texture file LNS_VIG_CPT_UV05.dds I reversed the numbers indicated - originally was 9 on the left through to 0 on the right, this sorts out the issue in the English cockpit mod. You can find the file in ED>dcs world open beta>mods>aircraft>AJS37>Liveries>AJS37cockpit>English (Note: I added a yellow colour to help me detect the correct part of the texture file to edit - attached edited texture file at the bottom) LNS_VIG_CPT_UV05.dds