derammo

created https://github.com/BlueFinBima/Helios/issues/197

Ok there are a two separate things here. 1) Yes, it appears that a button does not register until it is changed at least once. I created a profile that just binds "pressed" and "released" on button 1 to a green light. If I hold the button down and then start Control Center, the light does not light up until I release and press again. 2) Lua isn't involved in this at all, and neither is DCS. This is a driver for the game controller, implemented in Helios against the DirectX DirectInput API. So I would say item 1) is a bug or feature-request against Helios Game Controller interface. It clearly was not designed for buttons that aren't use as triggers, i.e. that might be toggled to one side or another and stay there. So either you can file an issue here https://github.com/BlueFinBima/Helios/issues/new or I will do so.

I think I misunderstood, maybe. I though the proposed solution was to just run a script in the "export" context via the hook exactly one time, to install the normal LuaExportActivityNextEvent etc. handlers? If that isn't how this approach works, then it is suddenly a whole lot less interesting to me :). I was scheduling investigating and switching Helios to this approach in the medium time frame, but I haven't done the work yet.

yes, Helios has an interface for game controllers. 1) plug in your game controller 2) in Profile Editor, select "Add Interface" 3) each game controller will show up as an interface. Add one of them. 4) in the interface properties for that controller, you will see red lights for the buttons like the Windows game controller panel, where you can see that it can read your buttons 5) then create some bindings to whatever you want to have happen does this not function correctly for you? if so, please create a bug at https://github.com/BlueFinBima/Helios/issues/new and include your profile (*.hpf) file and tell us how it malfunctions. Thanks. PS: I didn't attach an example profile here because the name of the interface depends on the exact game controller you have, so my profile would unlikely work for you

Helios could definitely use some more documentation and maybe some training videos. For example, to make "green outline only" buttons, you would choose a button (I used a Tactile Square here) and then paint your own images to use. I'm no artist, so this looks like crap:

see https://forums.eagle.ru/showthread.php?t=264369 (I know you already posted there, but pointing others to the bug report)

You have a comma in your aspect ratio instead of a decimal point. So your aspect ratio ends up being 1. Test in Lua interpreter: Lua 5.1.5 Copyright (C) 1994-2012 Lua.org, PUC-Rio > a = 1,5 > print (a) 1 > a = 1.5 > print(a) 1.5 >

That's super interesting. As a Helios developer, I would love to know what you think Helios can't do in terms of customization. I mean you can use any images you want on the controls, so I am not sure what you think is not possible. If you know some specific limitations, please let me know so we can see about correcting it.

I don't think DCS knows jack about it :) My windows desktop happens to span multiple Nvidia cards. Then I set DCS to a window size equal to my entire desktop and configure a viewport that is just the main screen (yes monitorsetup lua, standard stuff.) I guess the Nvidia drivers are smart enough to realize the main 3D viewport is only on one card and so it renders on that card without involving the other one. This is pretty cool, because if the extra viewports were one big graphics context then it would not work. But it just happily cruises along, rendering the 3D view on the main card and all the rest of my desktop on the other card. I do know the cards have to be using the same driver for this to work. So you can't use a different card family (like some Quadro you have lying around) or some old card that can't use current driver. That's why I went to my local discount parts place and bought the cheapest Geforce that worked with latest drivers that I use for my main.

There is one comment up above that said you could get double digit frame drops with Helios or Ikarus. This sort of statement needs more context. Yes, if you are talking about dropping from 120fps to 105fps or something like that, then yes I could see that happening. Because if your export script is set to export every frame (instead of every so many milliseconds like Helios export script is) then you would in fact slow down significantly because your per-frame time slice is super short. So don't do it that way :). And if you are in an fps competition, then of course you wouldn't run a Lua script at all.

I run my extra viewports on a separate graphics card. I just threw a GTX 960 or some such junk (he he) in there to run my extra screens (touch screens) and that's where i render the extra viewports. So yeah, the nvidia driver is pushing a large screen area, but not to my primary card that just renders the main 3D view. Works fine with the exception that I run with vsync on and so my crappy 60Hz touchscreens are limiting everything to 60fps. That's fine for me, I never cared about more frames as long as it doesn't drop.

Sorry for the late response. For some reason I didn't get notified on this thread (must have been user error) until the next reply. Your work sounds interesting. I decided not to go the route of machine-extraction of the parameters from the aircraft Lua, because there is enough difference between different aircraft (or so I was assured by the folks doing it by hand today.) Finally, I realized that DCS-BIOS (specifically the DCSFlightPanels fork) has already extracted all the parameters for all the aircraft that exist and new ones as they come out. So I didn't think I could compete with that with automation, particularly for those cases where values are really better combined from multiple arguments in a callback function written by a human and then sent as one value. So what I finally did was to write Lua that executes DCS-BIOS module definitions and then captures the details of what arguments are being exported and as what type. This way, I plan to reduce the effort duplication, so we can use this data in different ways. I don't want to say too much here so I don't end up promising things that I won't ever ship, but I will reach out to you in PM to see if you want to share the data. Cheers, derammo

We just stopped using the value from the UI and hard coded the aspect ratio in the Lua. Somehow you are figuring out the Width and Height of the main viewport in your Lua, so just divide those two to get the aspect ratio, and don't rely on the UI value.

Awesome. That's all the pointer I need. Thanks!

Are you saying that a script can place an F10 mark that would be transmitted in multiplayer? That would be exciting.

In 2.5.5 and before, if you set an aspect ratio in the graphics settings UI, this value is provided in screen.aspect in the MonitorSetup lua scripts. In 2.5.6, screen.aspect is just set based on the size of screen (i.e. width/height) and does not consult the value in the UI. Therefore, monitor setup lua scripts that rely on getting the UI-configured value in this way will start having unexpected aspect ratios, since the meaning of this value was apparently silently changed. I am suggesting this is a bug. It takes me an insane amount of time to test this, so I did not confirm this repeatedly.

There are three separate things going on: 1) extra viewports for those things that can't be accessed via the export.lua interface, such as radar screens, MFD contents, etc. These are rendered by DCS and it uses more power to render more of them. Helios has nothing to do with these, but pretty much every virtual cockpit that uses Helios also uses these to get the "live video" sort of stuff. Unfortunately, people call these "monitor exports" or "exported view ports" which is super confusing, because they don't use the export interface of DCS at all. 2) Helios runs as an export.lua plugin script executed by DCS. This script is very efficient and even if you somehow managed to create so many updates per second that it becomes a problem, you can configure it to just send updates less often. In reality, this is never needed. 3) Helios runs as a separate PC application, usually on the same computer as DCS, because that's where the extra viewports are rendered on the screen. Some adventurous types use extra software like Iris to send the extra viewports to another PC, then you can run Helios on another PC. But usually you don't have to care, because Helios is a separate process and any modern CPU has a bunch of idle cores that DCS doesn't use. So you will not notice any CPU impact what so ever. In the future, when DCS uses Vulkan to actually use all your cores, then Helios will be competing for them, but it isn't anything major and you will have more cores before that work ever gets done (sorry ED, that was a joke! kinda…) source: I am a developer on Helios in the BlueFinBima fork.

thank you for the information!

Is it possible in mission scripts to generate a datalink message (for example, for A-10C) like the hard coded built-in JTAC sends when it sends data? If not, is there any other API that can be used to fake this, somehow creating dynamic mission mark points / waypoints / target points and just pretend they were received via datalink? These would not be static waypoints that are preloaded, because they depend on spotting a moving unit. That's why I think the correct interface is datalink (they would not previously exist in the client aircraft's context.)

We are tracking this as a bug in Helios https://github.com/BlueFinBima/Helios/issues/185 The command value mapping is apparently incorrect in Helios. It will be fixed in the next release. We don't currently have the ability to edit the DCS command code mapping in the Profile, so this needs to be fixed in code.

Ozone42: what plugin do you develop? Would love to see your code, since your request indicates you know the pain :)

This is very cool and I will consider it for Helios. That way, we each only have to have a separate hook file and nobody writes Export.lua. That is certainly more polite. However, it does not address the OPs question. The request was for DCS to support multiple separate LuaExportActivityNextEvent to be registered without them having to chain each other and invariably screwing up each other's event time when they do it wrong :) I don't hold any hope that part will ever happen. But at least not having to edit Export.lua from our "installers" or install instructions is a nice step forward. I will check into using just a hook for Helios that registers our dofile in the next version, which is all about exports anyway.

Please see my response here: https://github.com/BlueFinBima/Helios/issues/181 It is already possible to have as many Helios Documents folders as you want. You can separate your legacy stuff and new stuff that way. I use it every day to run a test and then destroy the entire folder :) PS: just now realized the query was from 2018, sorry for necro posting. But hey, useful information in there. I only saw it recently since it is a lingering issue in the Helios github

Hi There. I would happily look at this for you. If you want me to do so, file an issue on https://github.com/BlueFinBima/Helios/issues/new and provide a link to your Helios profile and Lua script you are using. If you would rather figure it out yourself, run Wireshark and capture the loopback adapter. The messages are just text strings sent in UDP on port 9089 or whatever you have configured. You can easily see what is being sent that way. To see what Helios is doing with the values, run Helios Control Center with "--loglevel=Debug" and read the ControlCenter.log in Documents\Helios. Also, if you are a C# dev and you want to contribute to Helios, please for the love of all that is in the sky do join us :) Cheers, derammo on GitHub PS: The only branch in your fork that is worth running is "Dev." Master is an abandoned mess :)

When working with a new airplane that isn't supported by Helios, there are two things you can do: 1) wait and Capt Zeen will figure it all out for you :) or 2) figure out all the bindings you need and write your own exports. This is a little bit technical, but doable if you are comfortable writing script code and reading code. You could start by looking at the exports already identified by the DCS-BIOS project, because they are always ahead. Today, Helios does not support DCS-BIOS as an interface, so you have to go read the code in the DCS-BIOS plugin for F-16 and write equivalent code in an Export file compatible with Helios. You would target the Generic interface in Helios if you don't have anything else running. If any of that sounded even remotely difficult to you, then you probably should not do that and just wait for a supported F-16 interface instead. That isn't intended as rude, but just to clarify that this task is either super easy or mind numbingly frustrating, depending on your background.