derammo
-
Posts
298 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by derammo
-
-
-
Thanks for the reply, derammo. Just clarifying that the switches appear to require a change before acting on that binding.
For example: On initial start-up, Toggle switch is "on" and shows "illuminated red" on the (in my case, an BUO836A) game controller binding, but until a change is detected, Helios appears to maintain the default position as "false", as the status query is not made until "button pressed" or "button released".
Unsure how to script a workaround in lua, for example- pushing a dedicated sync button which in turn executes this script to "cycle all buttons" to ensure they are interrogated and therefore synchronized with Helios.
Would you agree this is how the (controller to monitor) binding logic works? If I am incorrect, please feel free to let me know.
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.
-
There are also some downsides with using the Hooks compared to Export.lua:
- One has to restart DCS for it to reread the Hooks scripts, compared to restarting the mission for Export.lua.
- It seems like there is no error output in any logs if you make a mistake in your Hooks code. For Export.lua errors, the errors are log in the dcs.log file.
These two things makes development slower. For the time being, I think I have to go on and use the Export.lua because of these issues, and because I have not been able to solve the list_inidication() thing.
It looks like that currently there is no ideal solution, or then I don't just know how to use the available API interfaces, and would be grateful for any help and advice.
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.
- One has to restart DCS for it to reread the Hooks scripts, compared to restarting the mission for Export.lua.
-
Techie question for those in the know:
Can Helios read a game controller button status directly(without reading it through a DCS profile)?
The options I see are to change to a value when either:
-Button Pressed
-Button Released
-As commanded by a profile
Experimenting with/bench testing a panel on my non-gaming computer but the initial readings have 50% chance of being incorrect until the switches are cycled. The Axis don't have this issue.
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
-
Perhaps that might be a question of intuitiveness... For the life of me I could not figure out how to build custom interfaces within Helios; not through the UI. I could move around panels, but in terms of creating something similar to what I did in IKARUS... it seemed impossible unless you were developing things behind the scences, in the code. And that might be the difference here.
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)
-
Same problem 3 monitor in operation together 1920x2616
The entry of the screen.aspect in the MonitorSetup.lua has no effect
name = _('A-10C');
Description = '24+15+10'
Viewports =
{
Center =
{
x = 0;
y = 0;
width = 1920;
height = 1080;
viewDx = 0;
viewDy = 0;
aspect = 1,7777777777778
The garfik is compressed to the first monitor
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 >
-
Take a look at my blog in my signature. IKARUS offers far more customization. You can build you own panels, buttons to create custom touch screen interfaces.
More specifically: https://guppy.home.blog/2019/07/19/intro-to-ikarus/
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.
-
derammo, how do you get DCS to send the view ports through the second graphics card? Is it an edit to the monitor.lua? [ <---pretending to know what I'm talking about]
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.
-
Thanks! The DCS API folder and the documentation in there was what I was looking for. Was it there a year ago, or did I just miss it?
I only had quick look now, but this seems the way to go, just like you suggest.
A year ago I wrote a plugin for physical simulator cockpit integration. I haven't documented it yet, so I didn't want to publish it. (And probably buggy, but works for my purposes.) Shortly after, I stopped playing DCS, but now I'm back in the game. :) I'll try to get some documentation done within a week or so, and then I'll give pointers.
And yes, I'm well aware of the existing solutions and I tried them and had a look at them, but in the end I wanted to do it my own way. My design goals were:
- It should be easy to add support for new aircraft without extensive coding. Most of the gauges (game output) and controls (input) are already described in the DCS game files in a structured machine readable format. This information is utilized as much as possible to avoid manual programming of the same information.
- A simple to use network protocol that can easily be integrated with various client software. This is achieved by sending all data as JSON. (If a more compact data format is needed, then support for CBOR can easily be added, since JSON can be encoded as CBOR.)
- Avoid sending more data than needed. This is achieved by allowing the client to request which parameters should be exported, at what maximum frequency and with which precision (per gauge). Data is only sent when the information changes at the requested precision. For example, the IAS is within the game a floating point number that in practice changes for each rendered frame in the game. In most cases, it is sufficient for the client software to know the IAS without decimals, for example, at the resolution of 1 km/h or 1 knot. If the IAS stays with that one km/h then an update of the IAS is not sent to the client.
- Keep the server side implementation fairly simple. (It's currently at about 600 lines of code).
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
- It should be easy to add support for new aircraft without extensive coding. Most of the gauges (game output) and controls (input) are already described in the DCS game files in a structured machine readable format. This information is utilized as much as possible to avoid manual programming of the same information.
-
Have you figured a way around this? cause Im having the same issue
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.
-
The "F10 Mark" (the red circle on the F10 map) feature is also available as a simple action in the Mission Editor. Look for "Mark to All/Coalition/Country/Group" in the Actions (right column in the ME).
With scripts you can dynamically get coordinates from a group or unit, check for unit type and distance between points etc. That is more complex than the Mission Editor and requires at least basic understanding of LUA code. With frameworks like Moose or MiST it gets much easier, but still you need an understanding of scritping and LUA in general. :thumbup:
Awesome. That's all the pointer I need. Thanks!
-
The closest you can do is set a briefing via Script or set a Mark on the F10 map...
The script engine allows for querying coordinate, unit type, etc. Using Moose or MiST it should be not too complex to find group distances and bearing/range to friendlies etc. to put together a 9-line, but as Grimes said, no way to get it into the A-10 or any other systems, as of today.
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.
-
Thanks both! BaD CrC, do you notice a performance hit from Helios? I know that adding a screen will affect performance just from the GPU driving more pixels, but have you ever looked at CPU utilization when running Helios?
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.)
-
Seeking help for how to change the output value from original object triggervalue.
For example. a 3 way toggle in HELIOS return 0/0.5/1.
C54,3001,1.0
C54,3001,0.5
C54,3001,0.0
But F/A-18C Dispenser Switch position is 0/0.1/0.2 like below
C54,3001,0
C54,3001,0.1
C54,3001,0.2
How to modify it from Helios Profile?
Thanks.
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.
-
1
-
-
Downloaded. Thanks. Looks like you did a lot of work!
Would it be possible to store the HeliosSettings.xml in the installation folder, instead of the My Documents\Helios folder? And also save the path to the My Documents\Helios folder in that HeliosSettings.xml file?
The reason I ask that is that then we could have 2 My Documents\Helios folders. One for the new profiles, and the other for the legacy profiles. And we could edit that xml file to point to the new folder.
Also, this would help with a bug where Helios crashes while writing the HeliosSettings.xml, and only part of the xml get's written. Causing Helios to continue to crash on load there after. This bug is hard for users to fix because when they uninstall Helios and delete the folder, and reinstall, the corrupt file still remains. They don't think to delete their Profile folder since it's the program that is crashing, and they don't want to lose all their profiles. This caused me problems on several occasions until I noticed that file was corrupt.
Just some thoughts. Thanks for your work. Cheers!
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 guys. Having problems with making the Harrier's ODU and UFC display the text values.
I have followed all the possible instructions to get the right Export.lua and also checked that it contains line to parse ODU and UFC text values, but the text is not comming to my profile composed from the AV8 ODU and UFC controls. All the other buttons work flawlessly, but the text.
I have also tried placing the text controls and binding it it Display text changed for ODU with no luck. I would happily exchange few messages and provide any possible lua script I have including my Helios profile.
Displaying ODU values and controlling the UFC from second monitor was the main reason to get Helios up and running, but now I feel desperate.
As I am C# developer in real life, I have also decided to fork and download Helios code to see if I can run it and maybe debug it, but haven't had enough time yet.
Is there a way how to force Export.lua or other scripts to write into any debug file to see if the ODU files are comming from DCS?
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 :)
Touchscreen not working? Obscure WIN10 setting
in PC Hardware and Related Software
Posted
Great find, thank you for sharing! If this crops up a lot in the future, we could put a test in Helios that checks if this is set and lets the user know.