clickable radio communications

Mhe If you've had a look at my Helios profile you will know I spawn mine underneath the Eng Instrument panel which disappears when the Radio Comms menu is shown.

There is a good guide here by PeterP.

Don't know whether it will help but as you said on YouTube our setups are almost the same. LOL

Here is a look at my FUI/Resources/Radio/menu.res

\dialog
\begin
   \tag{-1}
   \coord{0, 20, 1024, 800}
   \color{50, 50, 50, 50}
   \musthavecursor{0}
   \drawitself{0}
   \acceptmouse{1}
   \fixedposition{0}
   \dontinflate{12}
   \onmainview{0}
   \layer{1000}
   \bordercolor{255, 255, 255, 255}
   \hasborder{0}
\end

\static
\begin
   \tag{2}
   \coord{922, 37, 1024, 768}
   \color{200, 200, 200, 50}
   \drawitself{0}
   \fonttype{font_arial_17}
   \fontcolor{255, 180, 0, 255}
   \alignmentleft
   \dottail
   \hasborder{0}
   \caption{}
\end

\multicolumnlistbox
\begin
   \tag{3}
   \coord{924, 420, 1024, 768}
   \defaultitem{Radio/command_list_box_item.res}
   \columnswidth{334}
   \marker1{Radio/command_list_marker.res}
   \bordercolor{255, 180, 0, 255}    
   \visiblescrollbar{0}
   \hasborder{0}
   \readonly{0}    
\end

anyone tried tweak with latest A10 patch ?

anyone tried with BS2 ?

I am on it and move and change size of coms screens, but no way to have it clickable neither movable with mouse ???

Works for me with 1.1.1.0 in A-10C

no differences in BS2 .000 and with patch 1111

should work the same

made a report about modifications between original files and the mod http://www.checksix-forums.com/showpost.php?p=1233416&postcount=4

EDIT : made a try for BS2 in 1920x1080 res for mainscreen http://www.checksix-forums.com/showpost.php?p=1233479&postcount=5

Hey guys. Working with Loz's profile on a slightly smaller screen. I can get the menu items to be reduced by changing their font size but I can't seem to get the 'button size' or 'row height' reduced to match the new font size. Can anyone help?

UPDATE:

Just thinking out loud here but I wonder if it has to do with the fact that I have both of my monitors stacked (vertical instead of horizontal) and that is causing the 768 height to be scaled across 2160 pixels (1920x1080 x 2). That would explain the large vertical size of each row... and I am guessing that there is no way round that ... unless I switch my monitors to a side-by-side config.

UPDATE:

Yeah. Looking at my setup I think it is related to my vertical stacking of monitors (2x 1920x1080 - one above the other). That ended up scaling badly when the 2160 was divided by 768 - leaving a large row height. Now, with the monitor 'side-by-side' I can get the comms to a decent size in the right area but I have to put the GUI entry in my monitors_setup.lua file to x=1920, y=0, width=1920, height=1080 - to get the comms menu shifted over to the right side monitor. The drawback of this is that Helios is showing the panel on top of the briefing and exit game dialogs.... grrrr.. so close!

Anyone have any idea how to make a similar change for DCS:World?

I can't find an equivalent menu.res file, though there are a few files containing "acceptmouse" none of them appear to be appropriate.

The radio-menue is completely reworked....

Files for appearance and behaviour are now in :

...\DCS World\Scripts\UI\RadioCommandDialogPanel

But I can't tell what exactly to do to get the click-able/moveable functionality back , I had only a brief look at the files.

BTW - Interesting Detail:

There are player-controlled radio-menu settings for ground-units and for a T-72/M-1 Abrams.....

>>> DCS World\Scripts\UI\RadioCommandDialogPanel\Config\

I had a deeper look now.

Things that we can try :

Edit file CommandDialogsPanel.lua in ...DCS World\Scripts\UI\RadioCommandDialogPanel

starting at line#160

--UI

do

local screenWidth, screenHeight = Gui.GetWindowSize()

 

local containerSkin = {}

local height = 400

local window = Window.new(0, 0, screenWidth, height, "CommandDialogsPanel.Window")

 

window:setHasCursor(false) << set to "true"

window:setSkin(containerSkin)

window:setHasCursor(false) << set to "true"

window:setVisible(true)

self.window = window

 

do

local font = base.skinPath..'../fonts/DejaVuLGCSansMono.ttf'

local itemSkin = Skin.staticSkin()

local colorGray = Color.grey(0.75)

itemSkin.skinData.params.insets = Insets.new(5, 5)

itemSkin.skinData.states.released[1].text.font = font

itemSkin.skinData.states.released[1].text.fontSize = 13

itemSkin.skinData.states.released[1].text.color = colorGray

itemSkin.skinData.states.released[1].text.shadowColor = Color.black()

itemSkin.skinData.states.released[1].text.shadowOffset = Size.new(1, 1)

itemSkin.skinData.states.released[1].bkg = Bkg2.singleLineBorder(colorGray)

 

local boldFont = base.skinPath..'../fonts/DejaVuLGCSansMono-Bold.ttf'

local selectedItemSkin = Skin.staticSkin()

selectedItemSkin.skinData.params.insets = Insets.new(5, 5)

selectedItemSkin.skinData.states.released[1].text.font = boldFont

selectedItemSkin.skinData.states.released[1].text.fontSize = 13

selectedItemSkin.skinData.states.released[1].text.color = Color.white()

selectedItemSkin.skinData.states.released[1].text.shadowColor = Color.black()

selectedItemSkin.skinData.states.released[1].text.shadowOffset = Size.new(1, 1)

selectedItemSkin.skinData.states.released[1].bkg = Bkg2.doubleLineBorder(Color.white())

 

local arrowsSkin = Skin.staticSkin()

arrowsSkin.skinData.states.released[1].text.font = boldFont

arrowsSkin.skinData.states.released[1].text.fontSize = 13

arrowsSkin.skinData.states.released[1].text.color = Color.white()

arrowsSkin.skinData.states.released[1].text.shadowColor = Color.black()

arrowsSkin.skinData.states.released[1].text.shadowOffset = Size.new(1, 1)

But I can also be totally wrong - just like I said - didn't tested anything up to now.

Sadly that appears to have made no difference.

I need to figure out how to move the menu too since at the moment its showing over onmy right hand monitor on top of the MFCD outputs on softTH.

I'll have another look through the lua later.

http://forums.eagle.ru/showthread.php?t=88889

refering to the above post I thought id aim this at PeterP

Ive noticed that the responses from atc to my comms is lined up on the left hand top corner of my main monitor...if you can find the where the response commands are in the lua files that may help you to work out where to put the comms menu...its a bit above my head so can you have a look at it please

it would be nice to have the menus on the top right of the main monitor again

thx brettmccl

Thanks!

But I won't dig around in the files as long DCS:Wold is in beta state.

There is just too much uncertainty to get things working right.

I have listed this issue/bug/design-flaw/whatever you may want to call it... as point #2. in this thread:A Plea for View-Export/Multi-head/TH Users.

I encourage everyone that is suffering the same/similar problems to subscribe to this thread and make yourself heard.

Some news:

I got a simple workaround, EDIT following file:

 

... DCS World/Scripts/UI/RadioCommandDialogPanel/CommandMenu.lua

 

Line 55:

 

menuWidth = 280

 

Increase this number (its in pixels) and the menu will mode to the left side. Example... I have main screen 1920 pixels wide and 800 pixels touchscreen to its right... so my menus now show on the touchscreen... when I increase this number from 280 to 1080 (adding the 800 pixels of the touchscreen) the menu shows 280 pixels over the main monitor... simple aye

thankyou PeterPerfect that works great good job....

my second screen is 1280 so i made it 1560 perfect

thanks for the help maybe we can have a mission together

Has there been any word on the direction ED is taking with this? With stand alone DCS: A-10C I was able to move the comms to my touch screen and use it for comms selection. Now, although the comms still show on that screen, I can not interact with them except via keyboard.

Unhappy face: :-(

There are a number of different radio menu implementations that have been considered over the years, including a mouse clickable version like you describe that I had also suggested at some point. However, the need to take your hand off the stick is a considerable disadvantage. Another approach that I would submit for consideration is the use of the keyboard arrows on the keyboard or the POV hat on the stick to cycle through the menu items. In this system, once the radio menu is open, you would press the down arrow/POV hat down until the desired option is chosen, then hit left or right arrow/POV left/right to open a submenu and then hit the mic switch again to transmit the selected message and simultaneously close the radio menu. When the radio menu is not in use, the hat would function as whatever it's normally mapped to. At least at first thought, this seems to me like a convenient and quick way to navigate the radio menu. Opinions?

Using a 4 way hat sounds interesting, currently there are 12 commands used, F1 to F12, F11 being the BACK button and F12 the exit so its usually 10, how about:

Press MIC switch, the menu pops up, then your TMS becomes your radio command control (since we all have it assigned to a easily accessible hat, that 4 way hat gives you 8 buttons that we are already used to by using the logic of the coolie, short and long commands, aside from that the mic switch for that radio would also double up using long ans short press, short closes the radio menu, long goes back to previous menu (or next if theres a another page of commands) so we lose 2 slots for commands so thats 2 formations, 2 air fields and to other random commands you will not be able to access that will not affect most, at the same time the function keys will still work the same way. Just my opinion:pilotfly:

Using a 4 way hat sounds interesting, currently there are 12 commands used, F1 to F12, F11 being the BACK button and F12 the exit so its usually 10, how about:

Press MIC switch, the menu pops up, then your TMS becomes your radio command control (since we all have it assigned to a easily accessible hat, that 4 way hat gives you 8 buttons that we are already used to by using the logic of the coolie, short and long commands, aside from that the mic switch for that radio would also double up using long ans short press, short closes the radio menu, long goes back to previous menu (or next if theres a another page of commands) so we lose 2 slots for commands so thats 2 formations, 2 air fields and to other random commands you will not be able to access that will not affect most, at the same time the function keys will still work the same way. Just my opinion:pilotfly:

This YouTube video is using audible voice commands using Guitar Guru:

http://www.youtube.com/watch?v=Dz2ZBPgbD7g

I have no idea if radio comms could be implemented in this way.

I see I previously posted this to Message #44.

(I wonder if Alzheimers is in my future... ?)

Ok. Here's what I was able to figure out with some tinkering..

Two files are important in DCS World - with regard to where the comms menu is positioned:

<Install_Loc>/Scripts/UI/RadioCommandDialogPanel/CommandDislogsPanel.lua - contains the code that positions the menu. Around line 166 you should see this:

-- DVD local window = Window.new(0, 0, screenWidth, height, "CommandDialogsPanel.Window")
local window = Window.new(0, 640, screenWidth, height, "CommandDialogsPanel.Window")

Ok ignore my commented line (to preserve the original values) marked with DVD. Pretty straight forward to move the comms menu down form the top by increasing the Y position (0 to 640 in this case). Now you'd think you could change the X position here as well, and you can, but only partially. As you can surmise from the code above, the window tries to take up your whole screen and unless you want to get more complicated with the code changes, you need to go to the second file to adjust the X position.

<Install_Loc>/Scripts/UI/RadioCommandDialogPanel/CommandMenu.lua - contains the code that offsets the comms menu in the window created in the above code. Around about line 55 you should see this:

-- DVD menuWidth = 280
menuWidth = 480

Changing from 280 to 480 actually moved the menu farther to the left - we'll see why below.

Now this is the offset from the right side of the window that the comms menu is displayed in. In the above code, all coordinates are from the top left. This value is the x position from the right side of the screen and at line 103 (around there) we can see how the X position is calculated (or adjusted) from a measurement from the right to a measurement from the coordinate system:

menuPanel:setBounds(width - menuWidth, 0, menuWidth, height)

I did try tinkering with a couple of other 'obvious' points in the CommandDislogsPanel.lua file but none of that experimentation panned out for me. Line 168 and 171 (roughly) is an example of a copy and paste 'error' on the part of the developers :smilewink:

window:setHasCursor(false)
window:setSkin(containerSkin)
window:setHasCursor(false)
window:setVisible(true)
self.window = window

You can see how the line window.setHasCursor(true) exists twice - and it shouldn't but it will only cause a developer a minute to figure out why changing the first line had no effect. Also, changing these lines from false to true did not help make the menu clickable (for me anyway - maybe I missed something else) but it did make it difficult for me to exit the game. Pressing Esc to get the exit menu up worked but all the keyboard inputs from that point on were trapped somewhere in input hell. It could be more general than that but in my experimenting I never actually tried starting the engines.

I do hope that the put a clickable comms menu back in. Those of us using Helios and a Touch Screen can make good use of this and remove the need for me to have a keyboard on my lap. As it is I modified my Helios profile to include a function key board that comes up with the comms menu.

I've had a fair bit of success with VAC - even with my lousy accented English. To me the best way to utilize it is clear: it needs to be integrated directly into DCS World as an option. All the contextual stuff would just work always and all the callsigns etc. would be correct all the time. It's probably not even a huge amount of work, since if I've understood correctly, VAC already comes with a pretty good API. Maybe ED could even contact the guy who did VAC system to help.

Just exposing the currently active radio options through Lua would enable some enterprising soul to create such an interface, but I have a hunch that it wouldn't be much more work to integrate VAC directly.

I've had a fair bit of success with VAC - even with my lousy accented English. To me the best way to utilize it is clear: it needs to be integrated directly into DCS World as an option. All the contextual stuff would just work always and all the callsigns etc. would be correct all the time. It's probably not even a huge amount of work, since if I've understood correctly, VAC already comes with a pretty good API. Maybe ED could even contact the guy who did VAC system to help.

 

Just exposing the currently active radio options through Lua would enable some enterprising soul to create such an interface, but I have a hunch that it wouldn't be much more work to integrate VAC directly.

It would be pretty cool for a program to translate the spoken language using whatever utility would be used. To take broken English, or even a non-English spoken language to be translated and let the computer do your talking as digital spoken language as is done in other venues as some telephone answering machines and company automated answering systems or how Windows 7 does it for the blind people.

I have worked in machine shops here in New York and New Jersey where guys were from other countries and I have learned to get basically what a person was trying to convey to me in English. The guys from the old Communist Poland and Yugoslavia were the worst to understand, for me. The Guild system is still alive in some European countries and not here in the USA, so the US gets a lot of skilled guys from Europe.

Believe me, anybody speaks English better than me trying to speak your/their language.

Ok. Here's what I was able to figure out with some tinkering..

 

Two files are important in DCS World - with regard to where the comms menu is positioned:

 

<Install_Loc>/Scripts/UI/RadioCommandDialogPanel/CommandDislogsPanel.lua - contains the code that positions the menu. Around line 166 you should see this:

-- DVD local window = Window.new(0, 0, screenWidth, height, "CommandDialogsPanel.Window")
local window = Window.new(0, 640, screenWidth, height, "CommandDialogsPanel.Window")

Ok ignore my commented line (to preserve the original values) marked with DVD. Pretty straight forward to move the comms menu down form the top by increasing the Y position (0 to 640 in this case). Now you'd think you could change the X position here as well, and you can, but only partially. As you can surmise from the code above, the window tries to take up your whole screen and unless you want to get more complicated with the code changes, you need to go to the second file to adjust the X position.

 

<Install_Loc>/Scripts/UI/RadioCommandDialogPanel/CommandMenu.lua - contains the code that offsets the comms menu in the window created in the above code. Around about line 55 you should see this:

-- DVD menuWidth = 280
menuWidth = 480

Changing from 280 to 480 actually moved the menu farther to the left - we'll see why below.

 

Now this is the offset from the right side of the window that the comms menu is displayed in. In the above code, all coordinates are from the top left. This value is the x position from the right side of the screen and at line 103 (around there) we can see how the X position is calculated (or adjusted) from a measurement from the right to a measurement from the coordinate system:

menuPanel:setBounds(width - menuWidth, 0, menuWidth, height)

I did try tinkering with a couple of other 'obvious' points in the CommandDislogsPanel.lua file but none of that experimentation panned out for me. Line 168 and 171 (roughly) is an example of a copy and paste 'error' on the part of the developers :smilewink:

window:setHasCursor(false)
window:setSkin(containerSkin)
window:setHasCursor(false)
window:setVisible(true)
self.window = window

You can see how the line window.setHasCursor(true) exists twice - and it shouldn't but it will only cause a developer a minute to figure out why changing the first line had no effect. Also, changing these lines from false to true did not help make the menu clickable (for me anyway - maybe I missed something else) but it did make it difficult for me to exit the game. Pressing Esc to get the exit menu up worked but all the keyboard inputs from that point on were trapped somewhere in input hell. It could be more general than that but in my experimenting I never actually tried starting the engines.

 

I do hope that the put a clickable comms menu back in. Those of us using Helios and a Touch Screen can make good use of this and remove the need for me to have a keyboard on my lap. As it is I modified my Helios profile to include a function key board that comes up with the comms menu.

As a quick workaround create a helios panel with F1-F12 keys on it.

Trigger it with the commsbuttons to appear. => No need to use a separate keyboard

I do hope that the put a clickable comms menu back in. Those of us using Helios and a Touch Screen can make good use of this and remove the need for me to have a keyboard on my lap. As it is I modified my Helios profile to include a function key board that comes up with the comms menu.

Now that the DCS World is out of Beta, I've installed and I'm really disappointed, that like you that I can no longer just use my touchscreen to activate the comms.

COME ON ED this can't be that difficult to put right.

:cry: :cry: :cry:

And what was wrong with the old Font and size before. This new one is too small and not at all distinctive??

Do the devs ever read these forums FFS.